← Back to team overview

kicad-lib-committers team mailing list archive

Re: Decoded fp-lib-table and re-organisation ideas

 

Thanks for the initiative, John, for starting the conversation with your
own observations.

> > * Printtrafo_CHK: Some sort of PCB transformers, but not sure about
> >   the meaning of "CHK". The rest of the description seems rather
> >   generic to metric PCB transformers (EI38, etc).

> CHK ist just a firm. http://chk-elektronik.de/

As per the convention, this can be renamed to "Transformers_CHK"

> > * Iut: Instrument under test? Just seems to be three pin
> >   header-looking footprints?

> Seems to be belonging to Mr. Charras? It sounds like the institute,
where Mr. Charras worked.

I remember having asked a good while ago when we first played with Github
libraries, but unfortunately I can't remember what it is and I can't seem
to be able to find it back. We'll need some insight from someone else.

> > * PFF_PSF_PSS_Leadforms: might be better to call these "Allegro
> >   Current Sensors", as these footprints seem specific to Allegro.
> >   Or maybe as both this and Hall-Effect_Transducers_LEM  are pretty
> >   small, merge this into a generic "Hall Effect Sensors" library?

> Hall Effect Current Sensors are rare. So it might be ok to put LEM and
> Allegro into one library.
> But there is a difference between Hall Effect Current Sensors for
> measuring a current, and simple Hall Effect Sensors which deliver a
> digital 1-0 output, just to recognise the position of a magnet or coil.
> Keep this in mind.

One library would indeed suffice, IMO. As per the convention, its name
should simply be "Hall_Effect_Sensors".

> > * Oscillators seems to contain only two Silicon Labs parts. I am not
> >   very clear on the difference between this and "Oscillator-Modules",
> >   and there are only 4 components between the two libraries.  Do we
> >   intentionally distinguish between crystals and oscillators, and do
> >   we categorise resonators as crystals?

> I make a difference between Oscilator Modules and crystals, because
> crystals are resonators, which can be used for oscillators, but also for
> filtering. But Oscilator modules cannot used for filtering.

Good point.

> > * Crystals_SMD: there are only two footprints here, can't they just
> >   go into Crystals, which also has several SMD components?

> For my opinion: yes.

I think the better solution would be to mve the SMD components from
Crystals to Crystals_SMD, and then rename Crystals into
Crystals_ThroughHole.

> > * Connectors_Serial_MOLEX: These seems to be MolexPico blade
> >   connectors. Would other Molex ranges like "Pico-Lock" and
> >   "Lite-Trap" go in here? Does "Serial" mean only single row?
> >
> > * Housings_SIP9: Couldn't this be genericised to all SIP modules?

> For my opinion: yes.

Yes.

> > * Muonde: Microwave - from "mu" (the greek letter) and "Onde" (wave
> >   in German). I got there eventually.

> Maybe you are guessing right. But the german word for wave is "Welle".
> "Muonde" sounds french.

indeed. There are many parts in there which I'm not sure why they are. For
example, what has a 7812. In the convention, the part name should be first.
If we can strip this library down to only the microwave shapes, then its
name could be something along those lines.

> > * Mechanical_Sockets: These seem to be restricted to DIN41612
> >   sockets.

> Of course. This library was originated by me, and i named it
> "Mechanical_Socket-Plug_DIN41612-Stuff_RevA" I do not know wether it got
> renamed, but the parts are all DIN41612. I addet "mechanical" and
> "stuff", because of the card guides, wich are pure mechanical without
> electrical contact.

I made it more generic so we'll be able to include other mechanical
sockets. Also there is no need for the revision in its name. Finally, it
would be great if this one was renamed to Sockets_Mechanical, so that it
goes along the other sockets. Actually this is one thing we will need to
specify in the convention: Specialization of some part goes after and not
before, due to alphabetical ordering.

> > * Capacitors: Wouldn't most of these fit into one of Capacitors_SMD,
> >   Capactitors_Tantalum_SMD, Capacitors_ThroughHole or
> >   Capacitors_Elko_ThroughHole? And don't Capacitors_ThroughHole
> >   and Capacitors_Elko_ThroughHole have a lot of overlap?

> Tantalum is a polarised capacitor. Elko is german short for an
> electrolytic capacitor, which is also polarised. So i suggest categories
> polarised/non-Polarised and THT/SMD and combinations.
> polarised-smd
> polarised-THT
> non-polarised-smd
> non-polarised-THT
> and, maybe, "special-capacitors" or "tunable-capacitors"

This has been worked on recently by Alejandro Méndez. In fact, the library
Capacitors had to be deleted, because all of its content had been added to
the other corresponding libraries. I just did so. "Elko" could be renamed
to "Electrolytic" so that it's in english.

> > * Discret & Oddities: Can the contents of these be distributed into
> >   the relevant other or new libraries?

> Discret are not "oddities". There are mostly standard parts in.

Most if not all of the content of this library can indeed be distributed to
the other relevant libraries.

> > * Socket_Strips and Pin_Headers: aren't these basically the same?

No. One is a female connector, the other one is male. Look at the 3D
representation and you will understand.

Follow ups

References