SOT-23 Pin-Out: base and emitter are inverted

Layout
62

I checked the project when I discovered the inversion.
The project didn’t have anything reverted.
So the point 1 is not applicable
For the point 2 … it should be checked with JLCPCB

I opened one of the backups of last year (the project was made with version 6.0.2)
EDIT: this is one of the transistors available in the project. all are inverted. They are all 2N3904 and 2N3906

EDIT 2: notice that (I’m seeing it now) the footprint on the EasyEDA of JLC is correct, instead. And it respects the numbering of the symbol (as I say since the beginning. That numbering must be followed). The one of KiCAD is only one SOT-23 and it’s not even forecast the inverted version.

I guarantee you that if ever there was the inverted in KiCAD, it could help to arise the question to myself eventually.

For the point 1:
You can see it’s not flipped. Is it? yes it si because kiCAD assigned with numbers to the only one SOT-23 available.
However … please here all the stuff … let’s understand what is occurred.
Following the KEC I respected the sequence: 1 2 3 = E B C.

Then I assigned the SOT-23 … 1 goes to 1, 2 goes to 2, 3 goes to 3.

But unfortunately the 2 and 3 from KEC are inverted respect the KiCAD footprint and the IPC document.

It mounts the KEC (S) version.

image
image907×597 10.5 KB

image
image2075×1173 177 KB

For the point 2.
Her you find also the Datasheet I screenshotted in the opening.

63

Your symbol is 2N3904, which is a TO-92 package part
Normally that part is 123=EBC, exactly as shown on your schematic.

64

but on my schematics respects the datasheet for the SMD which is SOT-23

65

I’m totally fresh to this thread so I’m starting from zero. Here is my verdict after looking through the evidence.

KEC’s package diagram swaps 1 and 2 and is wrong WRT IEC and KiCad. However this is of no consequence, as the sequence, from left to right with the middle pin pointing up is still BCE. So their transistors are in fact compatible with the other SOT-23 3904s.

Your tracks are wrong. And the reason, as davidsrsb has just beat me to it, is because the symbol you picked is 2N3904, wihch is the TO-92 package. You should have picked the symbol MMBT3904, which is correct. Just pull up the symbol browser, search for 3904 and alternate between the 2N3904 and MMBT3904 and you will see the B and E swap pin numbers.

66

i think you missed the parts into the discussion … since I explained what about the MMBT and what about is depicted into the KEC datasheet: it’s SOT-23 not TO92 at all.
In KiCAD is MISSING the footprint SOT-23 with the 1 and 2 reverted
With the 1 and 2 from datasheet KEC …

It should be present and called SOT-23R (R stand for reverted) at least one is constrained to verify the pins.

My schematics is correct. It respect eh KEC datasheet.
And the PCB is correctly respecting the assignment … this assignment is wrong due the wrong foot-print

I mean: the footprint is correct based on the standard, but it’s missing the less standard configuration.

This less standard configuration is, instead, present on EasyEDA.

What does it cost to include into the KiCAD library a SOT-23-R ??
@Aris_Kimi

67

No, KEC made a mistake in the numbering according to the standards but not in the physical assignment of the electrodes to pins.

This made you make the mistake of choosing the wrong symbol.

68

oh boy … ok got it …

69

Seeing your schematic I am surprised that you have pin numbers at transistor. But this time it helps.
I have never had it at schematic. It is because I prefer to be able to draw schematic as compressed as possible. I even have no the circle.

At your picture I have added B and E according to that datasheet:

SOT23REV
SOT23REV2075×1173 163 KB

So your design is clearly reverted against that datasheet (and also MMBT3904) what was probably said more than 10 times so point 1 is applicable.
You don’t have transistor with reverted pads but your design has reverted pads.
How it happened - only you can said. I can only say once more:

70

I have said somewhere at the thread begin. There is no reason to have all combinations of pins at symbols and at footprints. It is enough to have all combinations at symbols.

71

We don’t have to guess, it’s all clearly visible. The symbol pin numbers and the footprint pad numbers didn’t match correctly, considering their functions (B C and E). It happened because the footprint of a fully defined part – i.e. a fixed combination of a symbol and a footprint – was changed to an incompatible one. The footprint was correct for another symbol which had different pin numbering order.

To understand this you have to understand three things:

First, KiCad connects pins to pads with corresponding pin numbers and pad numbers.

Second, KiCad connects pins to pads with corresponding pin numbers and pad numbers.

Third, KiCad connects pins to pads with corresponding pin numbers and pad numbers.

When these three points are understood it’s easy to understand why this went wrong.

These datasheets don’t define symbols pin numbers. They define only package pin numbers. Therefore you have to take one part, read it’s datasheet (for that part number and not another!) and deduce the symbol pin numbers and footprint pad numbers. If there already exists a symbol with correct pin numbers in the libraries you can copy that and change the name. If its footprint also has correct pad numbers according the same datasheet (for exactly that same part number!) and is otherwise correct for the part, you don’t have to do anything else. If the footprint has wrong pad numbers, you have to create a new footprint or find another correct footprint with correct pad numbers.

2 Likes
72

yes, I used a symbol with the pin numbering respecting the one on the KEC datasheet as you can see.
then assigned it to the only one footprint in the KiCAD: SOT-23
No way out.

Not having all combinations at symbols, partially contributed to this issue.
Indeed if a SOT-23-R was there, at least it could rise the benefit of the doubt.
At the end the most common delivery is the IPC Standard and the reverted one can occur (as it occurred)

I mean, it’s not a great issue to have both of them.

73

Only if you are willing to deviate from datasheets. There is no footprint for the KEC part of this thread in the KiCad footprint libraries because the SOT-23 footprint has different pad numbers.

Tormy could have just used the MMBT symbol/footprint combination in the KiCad libraries, just changing its name, and it would have been functionally compatible with the KEC part, but it would have had wrong pin and pad numbers. It’s a choice to be made: accept different numbers which can cause problems later because the pin/pad numbers don’t match with the datasheet; or create a new library part with pin/pad numbers according to the datasheet.

74

Right but don’t forget what I told when I listed how I designed it and the issues I got: i just couldn’t.
Because the MMBT was not available in stock of JLC so I chose for the 2N3904S and the 06S.
The only one datasheet for these devices is the one I show.

I even not opened any MMBT datasheet ever since, because iif it’s not used, no reason to open it)

Ten I chosen for the symbol that matched the pin numbering declared into that datasheet (see screenshot)

When I selected the footprint of KiCAD, nothing I repeat: nothing, was making me thinking “hey stop, something ambiguous here, let’s check more deeply”
Indeed into the datasheet of KEC is clearly written SOT-23 (look at the picture here below, in the ox under the pin-out … it’s not written anything else and it is big like a house: SOT-23)
And I used the only one SOT-23 of KiCAD, very confident it was the correct choice.

KiCAD’s libraries are missing that combination of footprint.

yes after I have found the disaster I created my one. But this is not the way to go, on my view, because many other ppl can fall down in the similar situation.

image
image698×726 78 KB

75

Many other people make their own libraries and those that use check… And it’s not just about kicad…

76

Yes, and the MMBT part in the KiCad libraries if fully functionally compatible with 2N3904S. The board manufacturer doesn’t care about pin/pad numbers. You could have changed the value to “2N3904S” and the manufacturer would have been happy, and you could have placed the 2N3904 part there and it would have just worked. I’m not saying you should have done so, I just want you to understand why this would have worked.

So far so good…

Well, that is the root of the problem. If you don’t already understand how KiCad libraries work and that pin numbers can change from datasheet to datasheet, you may fall into this trap. Hopefully not anymore, and hopefully others who read this thread don’t fall into it. It’s not of course your fault, but you falsely accused KiCad libraries having errors.

You mean that KiCad libraries should have other symbol/footprint pin number combinations? Well, it doesn’t hurt and I’m all for it, but adding one transistor doesn’t help much if there are tens and hundreds of parts which we don’t even know of and can cause similar problems. It’s just a must to learn to check the library items you use and read the datasheets carefully. As has been already said a couple of times: not just with KiCad, but with any EDA tool.

77

I don’t think an alternate SOT-23 footprint is needed. I think it would just increase confusion.

Rather what the EDA user needs to do is to correlate the pin function with the standard SOT-23 numbering. Then it will be seen that despite KEC’s bogus pin numbers, the physical L-R sequence is still BCE which makes sense because KEC would want to be compatible with the other SOT-23 3904s. After that it’s a matter of choosing the correct symbol no matter what is named.

What matters is the physical configuration. Numbers are subservient to that.

For example for nixies and vacuum tubes in general the numbering is clockwise looking at the bottom. Which makes sense as tube writing was done underneath the chassis on the socket. So I had to tell the footprint wizard to generate a circle of pads numbered clockwise as opposed to the anticlockwise of ICs.

1 Like
78

“hey stop, something ambiguous here, let’s check more deeply”

I believe that this( yours ) inner voice is there now, and that the next time that you will start modifying anything you will probably hear it screaming… :slight_smile:

If not all, then surely most of every PCB designer has been in your position at least once.

70+ posts, on a topic for a 3pin symbol, seems really funny to me now, honestly.

Headache for the library maintainers. For sure. Maybe not immediately, but at some point will do.

Once again, we( librarians ) are trying to keep the official libraries production ready.

When you are modifying things, you ought to check for breakage.

You also ought to verify “third” party content when you choose to make use of that.

We decided that( for our sanity )we will push some flexibility over to the symbol side.

I mean, it’s not a great issue to have both of them.

Maybe to you, but we are not that many people to afford introducing every possible variant in every possible way just because some manufacturers are making our “life” harder.

After all, KiCad’s library is a great great sample library for someone to start with.
It has bugs, known and unknown, it is getting better and better but not as fast as one might want.

I only have one solution. Get involved.

I really really do not want to waste more time on that cursed SOT-23. Can we please move the discussion to SOT-23W? Or to TSOT-23? :stuck_out_tongue: Just kidding, those last mentioned are not IPC compliant AFAICT, but i am out now. :slight_smile:

1 Like
79

Right, but a EasyEDA has it (if you check the JLCPCB component I linked, there is the footprint for EasyEDA. that footprint was also ignored but just because I don’t use EasyEDA :slight_smile: ), there is nothing preventing KiCAD to have t as well … since it’s way better than EasyEDA under many points, it can be also in this.

80

Indeed :slight_smile:

81

No problem

to me the most important things are the most important footprints combinations available.

they are not infinite. But once they are in it, the system is mor reliable.
Where with the word “reliable” I mean: it helps you to stop just in time, before you can make induced errors.

At the en it’s an instrument. As it, it should help you preventing things, like in many things it already does.