P-Channel Mosfet (DSG) -> (GSD)

I have made a single-cell battery charging / overcharging protection circuit and am stuck on selecting hardware for my mosfet! I am using Q_PMOS_DSG SOT-23 from the kicad library but cannot find a ‘DSG’ mosfet module anywhere online…I was able to locate a ‘GSD’ p-channel mosfet so is the solution as simple as rewiring the schematic?

Better explained: my current configuration is pin1 = Drain, pin2 = Source, pin3 = Gate…if i rewire to accommodate the new module, can i achieve the desired original effect if I rewire original pin1 to pin3 on the new mosfet? (effectively, pin1 = Gate, pin2 = Source, and pin3 = Drain) seems like the logic would change…all help welcome and appreciated!

The libraries are lacking in many regards and are not well maintained. The library maintainers have made it a trip to the moon to accept feedback, suggestions, inputs and improvements.

Make your own libraries, that’s so much easier.

Check the datasheet of your PMOS, there’s no standard for pin numbering in SOT23 package.
Just make sure your drain, source and gate goes to right pads, regardless of their number.

3 Likes

A bit unfair to be honest. Remember a general library will always be a compromise between the wishes of different people. It can simply not fit everyone perfectly.

Just make an issue on gitlab. However, I suggest you use a more appropriate tone as you will get much better results that way.
For links to the respective places see I found a bug. What now?

3 Likes

Ah, very helpful! Thank you!

The generic symbols (the ones in the device lib) don’t represent specific components. So if you use them select the symbol such that it connects the correct footprint pad to the function as shown in the datasheet of the component you selected.

You can of course also check the transistor libraries if there is a fully specified symbol already existing for your selected component (unlikely as there are thousands of transistors and we simply can not have symbols for everyone). If there is no symbol for your specific part then you can always copy the generic symbol with the correct pin numbering into your personal library and make it into a fully specified one.

Further reqading How does KiCad know which symbol pin represents which pad of the footprint? and Tutorial: How to make a symbol (KiCad v5.1.x)

SOT-23 is a particularly package because of “historical” reasons.
There is no standard for that package over where pin 1 is located.

A thing that can help is that a “pin number” in KiCad is a 4 character alphanumeric string. This is for example used for BGA’s, in which pins have coordinates in much the same way as on a chessboard.

Combine this and you can simply use “G”, “D” and “S” as Pin Numbers in the Schematic symbol, and also use these numbers in a personalized Footprint.

Once you’ve figured out how to do such things it is a 2 minute job, and that makes such things a lot quicker then enless searches over Internet in the hope of finding exactly what you want / need.
And on top of that, over time you will grow your own libraries for custom parts you’ve made.

This suggestion would however limit the footprint to only represent transistors. Which means you need another footprint for diodes and yet another one for bipolar transistors. Not really a scalable solution. Oh and you will of course need one footprint per possible pad assignment.

So in my mind it is much simpler to have one footprint with one pad numbering and then draw symbols to fit that footprint. After all it is much easier to make multiple symbols. And they have much fewer critical things to get right
You really only need to have the correct pin number assigned at the right place of the symbol. Everything else is just uncritical graphics. A footprint on the other hand at least needs to have the correct pad sizes at correct position and possibly also exact graphics for alignment on multiple layers plus for DRC also a correct courtyard.
Plus it is unlikely that you will need to update your symbols but your footprints might need to change as technology evolves or if you ever change your way of doing things (a switch from handsoldering to reflow could mean you now need to redo all your footprints)

For almost all Packages I agree, but SOT-23 is a weird thing.

But stilll I agree with Rene. Just use an existing SOT-23 Footprint for KiCad, and adjust the pin numbering for your schematic symbol to match it.

But be careful. Because of the SOT-23 weirdness, it may be different from what the datasheet of your devise suggests, so be extra careful here.

I can agree with you here. Well, things are relative so, with a hint-word “volunteer”, i can also disagree…
Just mention, but i do not want to focus more on personal opinions presented above.

Can you support that statement with some examples? (curiocity)

We(me and you) have clearly experienced different behavior from those “library maintainers”, and this is the main reason i am asking.

I have no intention to spoil this subject or argue about opinions… I am just curious.

Well, having tried working with GitHub (I gave up) and now GitLab (where I’ve also given up), contributing to the KiCAD library (which I’ve offered several times), my conclusion is that getting a German citizenship is easier than uploading a new/updated library.

GitHub/GitLab is constructed for geeks, by geeks and used by geeks.

TLAs, strange checkout/in procedures, geeky language, authentifications that I’ve never heard of etc.
KiCAD will never win volunteers with this.

I am an experienced hardware engineer with lots of knowledge in schematic design and PCB layout that would like to share my knowledge.

Why not just make a “Submit New/Modified Library” upload function? An editor needs to look at the modifications anyway. To avoid drowning, a vetting of the contributors could be done (but not the GitXXX way!).

This is no complaint about the maintainers who do a great job (this is also a chapeau to Rene, re post #3), but about the infrastructure, which scares competent people away.

There, got that off my chest :slight_smile:

1 Like

Thank you for your answer.

Git is also a great tool behind those platforms. With a little push, i bet you can get yourself at the point that you can confident make actions from terminal/cmd.
I base that statement on the fact that being an experienced hw engineer is way more difficult to accomplish than mastering git.
As every new sw tool you must understand its concepts, mess a little, break, fix, etc… devoting time in general.
I had saw in one of @Rene_Poschl 's posts, this, and it is great. I suggest to give it a try.

I have nothing to do with electronics except enjoying (as a hobby)…at least for now. My field is in electromechanical appliances, and yet, 2020, learning git in order to:

a) ease myself (after understanding its greatness)

and b) try to oppose on both of those statements. :stuck_out_tongue:

For the fun of discussion mostly.
If i hadn’t tried contributing, your comment probably could have scared me away too.
One of some personal contributing motives is, i don’t have to re-design the wheel from scratch because somebody else did it once. I can help by pushing it further…

Compromise personal preferences for better official libraries IMHO is a great deal.

You can then have symbols needed/used copied somewhere else, and then with a little more of your *personal efford you can fit them to your *personal preferences.

In my opinion this is way more beneficial for the KiCad community.

Best regards.

I hope i’ve expressed my thoughts correctly.