Again: Symbol Library not consistent even with default datasheet data and pin numbering?

Unfortunately, I do not have access to gitlab I am trying to write on this forum plus I ask other pollsters to check with me…

This is quite frustrating. Did you actually learn something from the other thread? The reason for the problem was not that you took the latest datasheet. The reason was that you didn’t read the correct datasheet for that part and didn’t check the symbol and the footprint after re-assigning another footprint to the symbol.

I tried to make my workflow description generic enough to cover all cases – number 3 says “or create from scratch”, and numbers 4 and 5 cover the case where you base your library part on existing libraries. Here it is again:

As far as I can see, the other writers here have repeated the same points in different ways, or this repeats their points. The important detail which isn’t covered is the thrice repeated point in my post in the other thread: KiCad needs correct pin and pad numbers in the symbol and in the footprint. These must follow the actual pins of the actual component, following its datasheet.

I suggested a simple exercise because it may help in understanding how the datasheet, symbol and footprint are linked together through the pin/pad numbers and how you have to read datasheets to work with KiCad libraries. If you would create a couple of your own library parts from scratch you probably wouldn’t need to start new threads asking about problematic KiCad libraries. In the case of this MMBT3906 you would see immediately that the link to a datasheet is wrong and it wouldn’t confuse you at all.

And how can I know it? Out of the crystal sphere?

Listen: i order things to JLCPCB. right?
Ok, then on THAT part this is the datasheet I read and I couldn’t even imagine other datasheets.

This in the picture is the one I got. I checked IT and I assigned the pins as they are into THAT datasheet. I told this zillions of times.

I said that in the previous topic … hence no reasons to take again out the MMBT when it was out of the game since the beginning.

Try it that way

Yes, the KEC footprint is non-conformant, but the fix is not to provide all combinations in the SOT-23 footprint in KiCad, that just makes it more confusing. Rather an examination of the KEC datasheet would have shown that they swapped both the pad numbers and the electrodes, thus it is still equivalent to the other SOT-23 3904s.

So sue KEC and quit bothering us about the 3904. Asking for a datasheet update for the MMBT3906 is fair enough but beyond that, you’re just trying to dig up the previous discussion about the 3904 and we are going in a circle again.

Right and I couldn’t guessing it at that time. But that discussion is closed.

For this one, instead, as we told above, it seems no one will care about to update or to remove datasheet links from the library … so as I said already in the start of this topic, I understand the data reported in libraries, are unreliable. hence i understand it’s way better to avoid pre-bounded items, but to go on generic, gones, to create the bound with footprint etc saving this in my own library. As in the old time with OrCad and P-CAD under DOS … :-/

It’s all there in that topic. I don’t need a crystal ball; I just read what you said and what was in the datasheets and in the KiCad library items. We don’t need to go through that again, do we?

What? You started this topic where we are writing/reading right now with MMBT3906 and now you say there’s no reason to take it out again? You asked clarification for it and I tried to clarify it and also told that it would be clear if you would follow the good workflow and would understand how KiCad library system works.

I just see one foundational problem behind both topics: namely that you don’t grasp clearly how you should handle the KiCad libraries, and indeed any EDA libraries in general.

If you have a part and datasheet from JLCPCB – it doesn’t really matter at all which and from where – you follow that datasheet and either find existing or create new symbol and footprint for it, according that datasheet. It’s that simple. Now you get bogged down to irrelevant details which are not big problems at all and we are going around in circles.

In THIS topic yes, … I’m was referring to the reference to the old one.
Sorry for the confusion.

Excuse me, but in which cad are they reliable? And how to do it without a librarian? In any case, this is a job that should be paid and then does not guarantee the absence of errors… There are real-time services that give only those components that you need in the current form… This approach markedly facilitates search and minimizes errors…

1 Like

And just like that, now i think you are just trolling.

I already wasted my money, I have not time to waste.

This was caused after some unverified actions of yours as it was pointed out.

Sadly most of us had that experience at least once and no sane person can be happy for that.

You were suggested to always verify third party content before spending any money upfront.

I believe you should also invest into “wasting” some time to clear some confusion that you might have, in order to save yourself from experiencing the same situation in the future. But that is your own choice.

Is there a point to keeping this thread going? It is getting a little too personal.

yes and this I got it. Be sure that from now on, to the light on what I read here, nothing will be left without deep prior investigation.
In fact what one would have is just to go ahead and to have some reference points.
But unfortunately I see those ones are fading quickly out. It means I have to see what to do and how in a different way.

Indeed, please you can close it.