Digi-Key open sources alpha version of an "atomic" parts library


#1

This looks quite exciting:

The goal of the digikey-kicad-library library is to offer a collection of well defined parts that include assigned footprints. This meant to augment KiCad’s default library and give users another choice in library paradigm (meaning that it is One Solution, not The Solution). It contains 1-to-1 symbol to footprint assignments to meet the needs of those who prefer that style. It does not currently include the idea of a one symbol to many footprints primarily because that defeats the purpose of having an orderable part number ready in the Bill of Materials.


Standard lib missing relay?
KLC: policy on obsolete symbols needed
New to Kicad, 15 years Eagle User :0
Digi-Key's KiCad Library
#2

Thanks for pointing this out!

I cloned their repo and counted the number of parts in each library. While there isn’t a lot of stuff in each category, it is a nice start. Kudos to Digikey!

Accessories.lib:1
Addressable_Specialty.lib:1
Alarms_Buzzers_and_Sirens.lib:2
Balun.lib:2
Barrel-Audio_Connectors.lib:5
Capacitive_Touch_Sensors_Proximity_Sensor_ICs.lib:1
Clock-Timing-Clock_Generators_PLLs_Frequency_Synthesizers.lib:1
Clock-Timing-Programmable_Timers_and_Oscillators.lib:5
Clock-Timing-Real_Time_Clocks.lib:4
Coaxial_Connectors_(RF).lib:3
Current_Transducers.lib:3
D-Sub_Connectors.lib:2
DC_DC_Converters.lib:2
Data_Acquisition-ADCs-DACs-Special_Purpose.lib:1
Data_Acquisition-Analog_to_Digital_Converters_(ADC).lib:3
Data_Acquisition-Digital_Potentiometers.lib:3
Data_Acquisition-Digital_to_Analog_Converters_(DAC).lib:1
Data_Acquisition-Touch_Screen_Controllers.lib:1
Digital_Isolators.lib:2
Diodes-Bridge_Rectifiers.lib:6
Diodes-Rectifiers-Arrays.lib:4
Diodes-Rectifiers-Single.lib:23
Diodes-Zener-Single.lib:2
Display_Modules-LED_Character_and_Numeric.lib:2
Embedded-Microcontrollers.lib:25
Encoders.lib:1
Evaluation_Boards-Embedded-MCU_DSP.lib:0
Evaluation_Boards-Sensors.lib:1
Ferrite_Beads_and_Chips.lib:8
Fixed_Inductors.lib:3
Fuses.lib:2
Gas_Sensors.lib:3
Humidity_Moisture_Sensors.lib:4
Image_Sensors_Camera.lib:3
Infrared_UV_Visible_Emitters.lib:3
Inrush_Current_Limiters_(ICL).lib:2
Interface-Analog_Switches-Special_Purpose.lib:1
Interface-Analog_Switches_Multiplexers_Demultiplexers.lib:5
Interface-Controllers.lib:14
Interface-Drivers_Receivers_Transceivers.lib:7
Interface-I-O_Expanders.lib:5
Interface-Modules.lib:1
Interface-Sensor_and_Detector_Interfaces.lib:2
Interface-Specialized.lib:1
LED_Indication-Discrete.lib:37
LEDs-Circuit_Board_Indicators_Arrays_Light_Bars_Bar_Graphs.lib:3
Linear-Amplifiers-Audio.lib:14
Linear-Amplifiers-Instrumentation_OP_Amps_Buffer_Amps.lib:32
Linear-Comparators.lib:14
Logic-Buffers_Drivers_Receivers_Transceivers.lib:14
Logic-Flip_Flops.lib:3
Logic-Gates_and_Inverters.lib:18
Logic-Multivibrators.lib:2
Logic-Shift_Registers.lib:5
Logic-Signal_Switches_Multiplexers_Decoders.lib:1
Logic-Translators_Level_Shifters.lib:4
Magnetic_Sensors-Compass_Magnetic_Field_(Modules).lib:1
Magnetic_Sensors-Linear_Compass_(ICs).lib:6
Magnetic_Sensors-Switches_(Solid_State).lib:2
Memory.lib:2
Memory_Connectors-PC_Card_Sockets.lib:4
Microphones.lib:2
Modular_Connectors-Jacks.lib:3
Modular_Connectors-Jacks_With_Magnetics.lib:1
Motion_Sensors-Accelerometers.lib:23
Motion_Sensors-IMUs_(Inertial_Measurement_Units).lib:5
Motion_Sensors-Tilt_Switches.lib:2
Navigation_Switches_Joystick.lib:1
Optical_Sensors-Ambient_Light_IR_UV_Sensors.lib:8
Optical_Sensors-Photo_Detectors-Remote_Receiver.lib:1
Optical_Sensors-Photodiodes.lib:12
Optical_Sensors-Photointerrupters-Slot_Type-Logic_Output.lib:0
Optical_Sensors-Phototransistors.lib:4
Optical_Sensors-Reflective-Analog_Output.lib:3
Optoisolators-Logic_Output.lib:3
Optoisolators-Transistor_Photovoltaic_Output.lib:7
Optoisolators-Triac_SCR_Output.lib:2
Oscillators.lib:5
PMIC-AC_DC_Converters_Offline_Switchers.lib:2
PMIC-Battery_Chargers.lib:12
PMIC-Battery_Management.lib:3
PMIC-Current_Regulation-Management.lib:6
PMIC-Full_Half-Bridge_Drivers.lib:6
PMIC-Gate_Drivers.lib:7
PMIC-LED_Drivers.lib:12
PMIC-Motor_Drivers_Controllers.lib:7
PMIC-OR_Controllers_Ideal_Diodes.lib:3
PMIC-Power_Distribution_Switches_Load_Drivers.lib:8
PMIC-Power_Management-Specialized.lib:3
PMIC-RMS_to_DC_Converters.lib:3
PMIC-Supervisors.lib:5
PMIC-Thermal_Management.lib:4
PMIC-V-F_and_F-V_Converters.lib:3
PMIC-Voltage_Reference.lib:10
PMIC-Voltage_Regulators-DC_DC_Switching_Controllers.lib:7
PMIC-Voltage_Regulators-DC_DC_Switching_Regulators.lib:2
PMIC-Voltage_Regulators-Linear.lib:29
PMIC-Voltage_Regulators-Special_Purpose.lib:1
Power_Relays_Over_2_Amps.lib:3
Pressure_Sensors_Transducers.lib:6
Programmable_Oscillators.lib:1
Pushbutton_Switches.lib:2
RFID_RF_Access_Monitoring_ICs.lib:1
RF_Amplifiers.lib:1
RF_Antennas.lib:1
RF_Demodulators.lib:1
RF_Detectors.lib:2
RF_Evaluation_and_Development_Kits_Boards.lib:2
RF_Receivers.lib:5
RF_Switches.lib:2
RF_Transceiver_ICs.lib:20
RF_Transceiver_Modules.lib:52
RF_Transmitters.lib:1
Rectangular_Connectors-Headers_Male_Pins.lib:3
Resistor_Networks_Arrays.lib:1
Rotary_Potentiometers_Rheostats.lib:1
Signal_Relays_Up_to_2_Amps.lib:6
Slide_Switches.lib:2
Sockets_for_ICs_Transistors.lib:0
Solid_State_Relays.lib:3
Specialized_ICs.lib:4
Specialized_Sensors.lib:1
Surge_Suppression_ICs.lib:1
TVS-Diodes.lib:21
TVS-Mixed_Technology.lib:1
Tactile_Switches.lib:9
Temperature_Sensors-Analog_and_Digital_Output.lib:18
Thermal_Cutoffs_(Thermal_Fuses).lib:1
Thyristors-DIACs_SIDACs.lib:3
Thyristors-SCRs.lib:2
Thyristors-TRIACs.lib:3
Toggle_Switches.lib:3
Transistors-Bipolar_(BJT)-Arrays.lib:4
Transistors-Bipolar_(BJT)-RF.lib:2
Transistors-Bipolar_(BJT)-Single.lib:131
Transistors-Bipolar_(BJT)-Single_Pre-Biased.lib:2
Transistors-FETs_MOSFETs-Arrays.lib:5
Transistors-FETs_MOSFETs-RF.lib:1
Transistors-FETs_MOSFETs-Single.lib:29
Transistors-JFETs.lib:3
Trimmer_Potentiometers.lib:1
USB_DVI_HDMI_Connectors.lib:21


#3

1 to 1 symbol to footprint assignments will facilitate library management especially to newbies like me. This is a good ONE SOLUTION, not THE SOLUTION. Digikey, thanks.
Mbeh


#4

but … but … but … do they follow the KLC?

A quick glance at three random footprints says: They do!

:scream:

(Didn’t check naming conventions, though).


#5

and it’s published under the CC-BY-SA 4.0 license, so should be safe to use for open source projects, right?


#6

Excellent!!!


#7

Not only that, it appears that they chose the same license, and the same license exception, that the KiCad libraries will be using. So I would think that would make it possible to use symbols and footprints from the Digi-Key library as a basis for symbols and footprints in the KiCad libraries and vice-versa. Awesome!


#8

Pretty cool isn’t it - http://kicad-pcb.org/libraries/third_party/

(The DigiKey licensing scheme was based on ours!)


#9

Another good thing about the Digi-Key library is the extensive information included with each part: 11 fields versus the 4 standard fields of most parts. They also include an MPN field so all the parts work with KiCost (I know that is mostly of interest to me).


#10

Thanks for the attention guys. We’ve been poking at this project for a while. This is truly a ground up effort from several Digi-Key technicians and engineers; an “oh, wouldn’t it be cool if this existed” idea. Please give some grace, it is not complete, there are many things to fix and ideas to hash out. We welcome any feedback and want to make sure we can have a baseline set of parts that people can have some level of trust in (always check for yourself!). You’ll see some blog posts in the future about how we went about creating this and what some of the underlying principles are.

Ben @ Digi-Key


#11

Hi Ben,

This is another excellent news with Digi-Key in its headline! I simply wanted to express my gratitude for you and other Digi-Key people for the support we receive. We are happy to see big companies contributing to open source projects, and obviously KiCad is the closest to our hearts, so your efforts bring particular delight. I believe the new library will be a great help to the users. Thank you very much!


#12

We started with the previous version of the KLC and ended up deviating as it made sense (and sometimes when it didn’t). It sure would have been nice if Oliver and the librarians’ awesome KLC 3 would have been out when we started, but we will revise and improve what we have for consistency. The footprint naming needs quite a bit of work, but it’ll eventually be more consistent with the KLC standards where it makes sense.


#13

For those of us who are REALLY newbies (and thoroughly confused by KiCad’s library structure), is there a tutorial or instructions for installing these libraries into KiCad ? I am retired and working on IOT devices around my home is my hobby, and KiCad makes my designs a lot easier to understand and build. many of the parts I use come from Digi-Key. I am finding the KiCad library structure so confusing that I find it easier to re-create my unique parts when I start a new project. I wish there was a way to create the part and footprint once.


#14

Eschema and PCB were separate programs that were merged. Knowing this helps to partially understand the structure. It is being reworked for the next version release.

Generally Kicad loads a default set, but not all, libraries. On a slow computer loading all can take a little time so that’s why the default behavior is not to load everything. This can make you believe ‘stock’ parts are missing when they simply haven’t been loaded. Look at your library paths in Eschema to find out where they are located. Open a few. They are text files. When you create a new part you generally want to make a new lib in your name space for it. Before saving new parts you have to set your private library as ‘current’. You also have to make sure it is in the list of libraries that are loaded.

The PCBnew stuff will be separate but the same principles apply. I have no idea how much this changes when version 5 comes out. That draws closer.

The good thing about text files is that in the beginning I was creating a new lib for every new part because I was offered the choice. I went back and was able to do cut and paste and make one file out of it.

Also, keep in mind English is not the native language for developers so things that seem to have what you might consider an inappropriate name made sense to someone. :wink:

It may be quirky but it really isn’t hard once you see what is going on and have done it a few times, but yeah, it is far from intuitive out of the box.


#15

I’m trying to gather some community opinions here. I posted a github issue here that covers the topic.

Does anyone want to weigh in on how we should handle items that go obsolete? I don’t really think they should be deleted completely, but should they be moved, segmented or named differently? How should this be handled?


KLC: policy on obsolete symbols needed
#16

I agree that they shouldn’t be deleted. Your purpose as a distributer is a little different and we need to respect that. People sensitive to bloat would be appreciative of the fact they aren’t forced to download and store stuff they can never use though. I think your target audience would say segment. This way it could also be a warning to a user on something that might have just recently gone obsolete, provided they keep their libs up to date. Sad to say you need to think about ‘blame’ too.


#17

Oh, boy, an eternal question!

The problem is that a user, especially the hobbyist, will pull your library and assume that everything in it is readily available. So perhaps a custom field in each component symbol called “Status” will be helpful. Populate that field with "Active, “NRND,” “Obsolete.” The problem is that Status change won’t be obvious to the user, so the next time the library is pulled the change will be missed. And that doesn’t address parts already placed on the schematic.

Since schematics in Kicad V5 will embed the symbol in the schematic and not rely on the presence of the original library after placement, part of your dilemma is resolved. That is, if you move obsolete parts out of the mainline library into a separate “obsolete” directory, the user’s schematic won’t break. The user may be confused the next time s/he starts a new design using that part and finds it’s no longer in your library; hopefully that will lead to checking DigiKey’s web site and finding out that the part is obsolete. That still doesn’t help the surprise of “Oh, the part went away between when we first entered the schematic and we had the boards made.”

Professional users will generally run a preliminary BOM and have purchasing verify that parts are available (and likely won’t use your library anyway).


#18

So far I have heard a few options between here and discussions elsewhere.

  1. Pull Non-Active parts out and place in one big monolithic library without any extra categorization. This would end up in the current organization as dk_obosolete.lib
  2. Pull parts from the current library set and put an the entire taxonomy in a separate folder with a shadow taxonomy includes a each family library of obsolete parts. ex there would be both dk_Encoders.lib and dk_obsolete_Encoders.lib .
  3. If there was a preference for keeping all parts in one major set of libs and one taxonomy, how about prefixing symbol name with something like o_ (or z_ so it ends up at the bottom or nrnd_, or any other suggestion) so we have individual part numbers listed as o_CN2240. Sounds a bit obscure, but quite workable. It saves hunting in multiple places.

Indeed, this is already there and is continually updated on each lib push/update.

I’ve written scripts to segment and organize libraries in pretty much any manner we’d need so the overhead with any option is pretty low. It’d be really nice if there was more hierarchy available for lib management, but alas, users are a bit stuck for the moment.

Yup, there’s no delusions there. We just though it’d be nice to offer an atomic list to the segment of the population who’d find it useful.

[quote=“hermit, post:16, topic:8520”]
provided they keep their libs up to date
[/quote] Ain’t that the truth.


#19

Any idea how widespread the library adoption is at this point? I don’t know much about the inner workings of github but I’m guessing there’s now good way to use it to get the actual users input?


#20

User input in github is quite cryptic. Ir really has no good way for discussions. One can use issues for that but they are designed to report bugs.