Looking for PN100 BJT Spice file - Page 1
Forum section: electronics / general

author: Circlotron
author_rank: Super Contributor
timestamp: June 25, 2025, 01:37:42 pm
content: Looked high and low but can't find one. Any suggestions?

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 25, 2025, 01:51:47 pm
content: I suggest you find a spice model of a transistor that is similar to it, then dive a bit deeper into spice model syntax and change some properties to make it behave more like the BJT you want.A little bit later...https://eu.mouser.com/datasheet/2/308/PN100-1301575.pdfGeez, it's just a general purpose small BJT. This thing is probably exchangeable with any of a 1000 others like it. Elektor used to call these things "TUN" (TransistorUniversalNPN)

author: Ian.M
author_rank: Super Contributor
timestamp: June 25, 2025, 02:27:09 pm
content: That datasheet implies it crosses to a MMBT100, for which OnSemi have a PSPICE model (and its a 'vanilla' SPICE3.MODEL MMBT100 NPN... not a proprietary subcircuit abomination).

author: Circlotron
author_rank: Super Contributor
timestamp: June 25, 2025, 11:19:26 pm
content: Quote from: Doctorandus_P on June 25, 2025, 01:51:47 pmYeah, I know. I have a reel with about 1900 pcs left on it and I just wanna see what kind of tricks I can pull with them. Want to get a model that is dead on.Off topic, but I sometimes wonder why there are so many quite similar general purpose transistors. Obviously there are some specific differences, but I can't imagine why there needs to be so many with just very minor differences.

author: floobydust
author_rank: Super Contributor
timestamp: June 26, 2025, 02:28:49 am
content: National Semiconductor 1989 Process 10: PN100, PN2222. 2N3415, MMBT100, 100AI have no idea why there are zillions of jellybean transistors out there, with no real "press release" or announcement for the new ones - you just stumble onto the part and wonder what is better about it compared to the old jellybeans. "non-overlay, double-diffused, silicon epitaxial".

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 26, 2025, 12:16:54 pm
content: Quote from: Circlotron on June 25, 2025, 11:19:26 pmDesigning for exact specifications of a jellybean transistors would be folly. BJT's have quite wide production tolerances. The most well known is the spread in Beta (Hfe) If you design a circuit for such specifics, you are designing unreliable circuits that work with some of the BJT's in your batch, but not with others. There is a lot of literature out there on how to design reliable and precise circuits and minimizing the influences of the spread of production parameters. That is a lot more interesting and important topic to learn about.You could never achieve a simulation of the whole production range of a BJT with a single model for a spice simulation. If you want to attempt this, then dive into the "monte carlo" part of simulators. With that you can vary parameters and run a simulation multiple times to see a range over which the simulations vary when parameters change, but I have not done this myself, don't have experience there.

author: Circlotron
author_rank: Super Contributor
timestamp: June 26, 2025, 12:27:31 pm
content: Quote from: Doctorandus_P on June 26, 2025, 12:16:54 pmI am somewhat aware of that. My main thought was to have a model that was specific to that transistor, so even if it was not accurate to the nth degree, at least it would be a closer approximation perhaps than if it were a generic model.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 26, 2025, 12:40:11 pm
content: Quote from: Circlotron on June 26, 2025, 12:27:31 pmHold on to that thought. It's an important one. Learning which paths are worth pursuing, and which paths should be ignored is a very important skill to learn. And I know because I'm not good at it, and I constantly get lost in all the swamps around the righteous path that I attempt to follow.

author: Ian.M
author_rank: Super Contributor
timestamp: June 26, 2025, 01:12:39 pm
content: LTspice supports overriding .model parameters. You can define a new .model in terms of an existing one but with certain parameters changed.Seehttps://ltwiki.org/?title=Undocumented_LTspice#AKO_Aliases_.28A_Kind_Of.29andhttps://ltwiki.org/LTspiceHelp/LTspiceHelp/Q_Bipolar_transistor.htmHere's a little demo of a PN100 (using the OnSemi MMBT100 model) with very primitive biassing, that sweeps the hFE (actually the Bf) between the datasheet limits.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 26, 2025, 03:33:11 pm
content: Quote from: Ian.M on June 26, 2025, 01:12:39 pmThat may be so, but why do this in this case?I really don't like adding extra layers of redirection just because it's possible.Spice models of BJT's tend to be fairly simple text files, with well defined syntax. You can also put multiple spice models into the same file, so you can copy your base model a few times and then give those copies names like "NP100a", "NP100b" though "NP100z" This gives you plenty of room to experiment with changing parameters, and also going back to an earlier revision if you discovered you forgot to check some simulation parameter in a previous run. Or to add two different models to the same simulation and observe the differences in a single graph.A while back I did some (short) experiments in KiCad (&ngSpice), in which I also had a text editor with the spice models open. From what I recall, saving the file with the text editor, and then re-running the simulation did run the simulation with the updated parameters in the file. But I am a forgetful person and I'm not sure about this, but it's easy to test and verify in whatever simulator you are using.

author: Ian.M
author_rank: Super Contributor
timestamp: June 26, 2025, 04:04:35 pm
content: The reason that overriding one or more transistor parameters with ako: is desirable is that its a cleaner way of varying the parameter(s) for a specific sim than by editing the device library. Other sims sharing the same library won't be affected. My example was a little artificial as I pasted the OnSemi MMBT100 model (rearranged slightly to reduce the line count) directly into it rather than including the library with .lib, so I can see why you'd think it had an extra layer of redirection.