2n3904 SMD SOT 23 issues

[paulvdh]

SOT23 pin numbering has been troublesome for at least 30 years.
“Industry” can not agree with themselves on which side pin number 1 is.

One PCB layout vendor’s software solved this by naming the pins of transistors “E”, “B”, and “C” and make 6 variants of SOT-23 Packages available, also with “B”, “C” and “E” as “pin numbers” without actually using numbers for the pins. I thought it was a rather neat solution for this problem.

I would not even dare to say a 2N3904 from one manufacturer has the same pin assignment then a 2N3904 from another manufacturer. Some transistors in TO-92 have become infamous because they were manufactured with different pinouts.

This is one of the rare cases in which the transistor testers of those cheap DMM’s are useful. Solder a few wires to one of your SOT-23 transistors and test the Hfe. When Emitter and Collector are reversed the Hfe will be much lower.

I can also highly recommend one of these:

Review: Transistor Tester

These transistor testers originated in Germany and there are now 20+ variants which are very suitable for quick testing of all kind of electronic components and their pinouts.

[paul001]

Thanks, I have just to be carfull and check it. Will make some new symbols with SOT extension.

[qu1ck]

Official library already has MMBT3904 symbol with the right footprint, that is the smd variand of 2n3904.

[BobZ]

@paulvdh

I would not even dare to say a 2N3904 from one manufacturer has the same pin assignment then a 2N3904 from another manufacturer. Some transistors in TO-92 have become infamous because they were manufactured with different pinouts.

I have certainly seen confusion on SOT23 pin numbers but not with physical pinout of any single TO92 types such as 2N3904. My most recent consulting job had some wrong SOT23 pinouts. I once fought with a pcb-mounted transformer on which the two rows of pins were both numbered left to right instead of counter clockwise starting from the lower left.

[Piotr]

@paul001

What would be the easy way to correct this?

Such problems are the reason that we, since over 30 years, use the assumption - one symbol = one footprint. If we were using 2N3904 THT and SMD we would have two separate symbols in our libraries. In such solution you can number E,B,C at one symbol according to your THT footprint numbering and the other according to your SOT23 numbering. That way we don’t need more than one SOT23 footprint .

[davidsrsb]

But you do end up with very bloated library sizes. People complain about the KiCad installer size now, and the libraries are the main cause

[Rene_Poschl]

@davidsrsb

But you do end up with very bloated library sizes. People complain about the KiCad installer size now, and the libraries are the main cause

Symbols and footprints are not to blame for the installer size. Nearly all of the library size is taken up by 3d models.

---

@Piotr

one symbol = one footprint. If we were using 2N3904 THT and SMD we would have two separate symbols in our libraries.

What you describe is a fully specified symbol. This is where you have a symbol for every specific part. That symbol at least points to the correct footprint but can also hold additional information like order details for creating the BOM.

Most of KiCads symbol library is already comprised of such symbols and most new contributions must be made this way. This of course then means that any specific symbol really is only valid for a specific component. For example the symbol for 2n3904 is only valid for this specific part which is only available in TO-92 package. (Which means @paul001 gave us a wrong part number)

As @qu1ck already mentioned above the correct part number is MMBT3904 which is also available in the KiCad library.

[Piotr]

@davidsrsb

But you do end up with very bloated library sizes.

Not so much.
Since 1988-2005 we were assembling our products ourself and we always were trying to have as small elements list as possible (not because of software problems but because of number of drawers to store them). So for example I had in my PCB program only the resistor values we used before and using any new value always was a decision if it is really needed.
When we started to order at contract manufacturer I stop being so restricted in element lists as it became not my drawers number problem but their
When 2 years ago I decided to move from Protel to KiCad I found having about 400 symbols from which I decided that about 200 are ‘must have’ in KiCad and others “will add when will be needed”.
Now my KiCad SchLib directory is 134kB and my PcbLib is 404kB. Together less then one typical jpg photo. Till now I have defined only few KiCad PCBs using only elements from my libraries. I suppose they will be may be 2 or 3 times bigger in near few years as I think most typical elements I use I already have.
I don’t think it is very bloated library.

[Piotr]

@Rene_Poschl

This of course then means that any specific symbol really is only valid for a specific component.

I’m not sure if here under ‘symbol’ you understand its name or one element in symbol library.
Previously I used different names for each different component.
Now (in KiCad) I decided to accept having the same name for different components. I use it for different sizes resistors. But I can imagine having the THT transistor library and SMD transistor library and having in both the symbol named 2N3904. So no noticeable difference at schematic.

[dchisholm]

@davidsrsb

But you do end up with very bloated library sizes. People complain about the KiCad installer size now, and the libraries are the main cause

It’s not just library sizes. It affects the design process when you have to sort through a myriad of parts with differences that are ultimately important, but not significant to the particular stage of the design process where you are currently working. For the specific example we are discussing here . . . . most of the time, when I put “2N3904” on a schematic, what I REALLY mean is “small-signal NPN transistor”. At some point I must return to consider package type, distributor stock, assembly methods, maintainability, the company’s “Preferred Parts List”, whether it pushes ratings limits (e.g., IC=250 mA or Vce=48V), etc. Choosing between “2N3904”, “PN3904”, “MMBT3904”, “PZT3904”, “SST3904” makes my brain hurt and distracts me from thinking through a design.

Dale

[Rene_Poschl]

My workflow in that case is to place the generic symbol as a placeholder and then when I make the decision what to order replace that symbol with the fully specified one. (This ensures i have the correct pin assignment and correct footprint for the part while still being able to later select what exact part i order)

[Piotr]

@Rene_Poschl

My workflow in that case is to place the generic symbol as a placeholder and then when I make the decision what to order replace that symbol

My workflow is to stop working on schematic till I make the decision what to order and made fully specified symbol. Practically I just don’t start drawing schematic till I have all symbols to be used done.

[Rene_Poschl]

I am only this strict about integrated circuits. For passives i give myself a lot more freedoms. (I however rarely work with analog stuff so my usecases might be a bit different to some others)

[paulvdh]

I do not make very much schematics, but half of them are tryouts of ideas and concepts without even having an intention of making it to the PCB stage. Therefore I usually don’t bother much for fully specified schematic symbols, and generic symbols for transistors are even preferred because they automatically put on the brakes if I decide to make a PCB for it later.

For me, it’s a hobby, and soldering a one-off on vero board is similar in time then the hours needed for a proper PCB design.

If I was using KiCad in a more “production” type environment I would maintain my own libraries of fully vetted, checked and verified parts and would use the KiCad libraries as “nice to have as templates”, but never to be trusted.

[BobZ]

@Rene_Poschl

As @qu1ck already mentioned above the correct part number is MMBT3904 which is also available in the KiCad library.

Yes I think it is asking for trouble to use one symbol to cover both TO-92 and SOT23 transistors such as 2N3904 and MMBT3904. The problem is the pin number assignments are different. But many ICs are provided in different package sizes with the same pin number assignments. Am I missing something if I see less risk in using one symbol to cover those?

[Rene_Poschl]

@BobZ

Am I missing something if I see less risk in using one symbol to cover those?

Higher chance of human error. If you have a fully specified symbol that you trust (because for example you already used it in a project) then you can not really make a mistake here. If you use a generic one then you can easily assign a wrong footprint.

In the end the idea is to move some responsibility from the system designer over to the library maintainers.

[paulvdh]

So I’ll do little experiment. The goal of this experiment is to update the schematic from the 2N to the MMBT variant without removing the original schematic symbol because that would mess up the connection between Eeschema & Pcbnew. (component placement and such).
Please make a backup first if you want to follow along.

In Eeschema press A for Add and type in “3904” in the search box. This gives me 8 different transistors, including the “2N” and MMBT variants.

Then I placed the 2N3904 on the schematic and pressed [F8] to get it on the PCB. Ah, forgot annotation, so that pops up in between. It’s a fully specified symbol, so I get a TO92 on the PCB.

Back to the schematic: Hover & press C for Copy, and place a copy of the 2n3904 next to the previous one. F8] again, and also place it next to the other one on the PCB.

Back to the schematic, hover over the right 2N2904 and press E for Edit. In the symbol properties window, click on the bookcase right from the entry field for “Library Reference:”

Type in “3904” in the search box (you could have placed that string on the clipboard) and select the MMBT variant.
Back in the schematic, bot transistors now look like 2N3904, but the pin assignment is different:

Back to Edit the right transistor:

Now I’ve broken coherency. The footprint is still a TO-92 package, but the pin assignment for that package is not correct.

Hmmm, slightly annoying, how can we fix this?
Ah: I see a button with [ Update Fields from Library ] That sounds promising. I click on it and I get this:

The “Value” field was not selected, and I also want to update that, so I also select it and then click on [ OK ]
In the symbol properties, the value changed to the MMBT variant, Footprint also changed to SOT-23.

Looks good, so I press [ OK ] in the Symbol Properties window. Now I have both an 2N3904 and a MMT3904 in the schematic:

[F8] and I have now both transistors and in the same locations as they were before, so placement is preserved.

So this works, but having to do this for 100’s of components is boring work. It seems to be reasonably save, If you forget a few transistors, they will stay in TO92 package and you see that quickly on the PCB.

But still… How can this be improved?
We need some stuff to work with, so first copy the 2N… a few times and also put them on the PCB:

Aaahhrrggg, this is slightly annoying. I was hoping I could change the Library Reference from within Eeschema / Tools / Edit Symbol Fields

In Symbol Fields I can single click on the value field of the MMBT3904, Copy it, and then paste the value field to Q101, Q103-Q105 The trouble is we do not want to do this with the “value” field, but with the “Library Reference” field. And the “Library Reference” is not in the Symbol Fields spreadsheet.

A short trip to CvPcb, but it seems unlikely I can change the Library references here, so it was a short trip.

Bit of good ol’ browsin’ through the menu’s and I find:
Eeschema / Tools / Edit Symbol Library References That sounds promising…

So I click on the “Transistor_BJT:MMBT3904” text in the Current Library Reference column, and paste the text into the New Library Reference column for transistors “Q101, Q103, Q104, Q105”. I have to fiddle a bit with the text here, because I pasted a long string starting with the text "Q102 and ending with a carriage return. I only want the text from the Library reference. So after editing that single line of text it looks like:

Then I press on [ Apply ] and [ OK] to go back to Eeschema, and nothing seems to have changed. The base of the 4 old transistors still seems to be connected to pin2, while it should have changed to pin 1. As soon as I move or change any of the old 2N transistors, the pin assignment reflects the changes I just made. To me this looks like a Bug in KiCad V5.1.5 Is this still in the nightlies? I do not have 5.99 installed.

Saving the schematic, then exit Eeschema and restart Eeschema from the project manager fixes it. It was just the graphics that were not updated.

The last step to fix this would be to click on the [ Update Fields from Library…] in the “Symbol Properties” dialog for all the transistors in one go. Bit of the good ol’ browsin’.
Eeschema / Edit / Update Fields from Library, also select the “Value” field and [ OK ]
And Voila, I’ve now got 5 MMBT3904 transistors on my schematic:

There is only one problem with this. It works for the transistors, but it also resets the value fields of all your capacitors and resistors. That is of course the reason why the “( )Value” is not checked by default when doing Eeschema / Edit / Update Fields from Library.

So I think I’ve found another bug in Eeschema V5.1.5
The text and the tooltip of Eeschema / Edit / Update Fields from Library… / Options / Reset fields which are empty in library contradict each other:

The wanted behavior here (for me) is to set the value fields of the transistors from 2N3904 to MMBT3904, but preserve the value fields of all resistors and capacitors. No matter whether I check the checkbox for [ ] Reset fields which are empty in library the value fields of the resistors and capacitors always get reset.
Can someone please confirm this? To me it looks like a good reason to make KiCad V5.1.6.

[BobZ]

Holy smokes you have a lot more patience (and much better memory for the keyboard shortcuts) than I do. You also get a lot deeper into KiCad menus. My attitude would usually be to pick a library transistor (from my library) based on NPN or PNP and SOT23 or TO92 (Yes there are many more packages but trying to simplify here) and then edit the properties once I put it onto the schematic. 2n3904/3906/4401/4403 all have “standard” pinouts for the TO92 or SOT23 packages. If I need something other than that, then it will get more care “up front” when I put it down on the schematic.

Also I tend to delete the circles around transistors. It feels like added visual clutter which does not add information. Shortening the pins (no I am not using “Crisco”) allows me to pack the schematic a little better without losing clarity.

@Rene_Poschl

In the end the idea is to move some responsibility from the system designer over to the library maintainers.

When I think of library maintainers, I think of Cadence which seems to have massive “overhead”. I think of ExpressPCB as the equivalent of a 1 person 8 foot boat with a small outboard motor, KiCad as a 20 foot 6 person motorboat with two large outboard motors, and Cadence as a 5000 passenger cruise ship. That last one might have 2-3 people just taking care of the engines. Do you think it is common to have anyone more or less dedicated to being a KiCad library maintainer?

I guess I should also note: I am doing my own stuff here and not working on a team of engineers all using KiCad.