In addition to the archiving challenge, just the fact that PDFs are the de facto standard in distributing datasheets makes it very challenging to build knowledge bases like FindChips since it is so unfriendly to parse. There is a huge amount of data variety in these documents in terms of structure, formatting, and language.
For whatever reason footprints, pinouts, and dimensions have been distributed via pdfs as the de facto standard, leading to a bunch of wasted work as people have to create their own foot prints, symbols, and 3d models over and over again.
It might seem wasted, but the reality is that a “standard” footprint does not really make sense. Soldering and assembly is not a perfect craft and it requires hundreds of considerations to methods used, environment of use, desired reliability etc. for example look up the footprint differences for wave soldering compared to hand soldering. For aerospace use reliability is king, for mobile devices space is a premium.
Furthermore, there aren’t really any standards for packages and hence it is difficult to trust foorprints. A TSOP package from one manufacturer manufacturer is not necessarily the same as a TSOP package from another. This is not a hypothetical — I’ve been bitten by this.
There are tools to assist in and automate a lot of this, but since most of the time is spend on other parts of a product it simply isn’t very critical.
A standard footprint might not make sense, but a standard format for distributing component pad placement definitely does. Most ECAD systems already have tools in place to generate proper landing pad offsets from footprint.
And you're right that one can never fully trust downloaded libraries, but a lot of the issues could be mitigated if manufacturers distributed their own files. TI does this for most of their devices and it's a big draw for a lazy designer like me.
I'm really surprised there isn't a better solution in the industry - building a library might not take as much time as the rest of electrical design work but it's still a large sink, to where many teams (even as small as 6 engineers or so) result to hiring a full time "librarian" to manage footprints and component libraries.
While manufacturer's may have very small deviations in their footprints, by and large almost every IC conforms to some kind of JEDEC compliant package. From there, IPC-7351B [1] has mathematical recommendations on footprints ranging from Class 1 (minimum required) to Class 3 A/B (ultra-reliable). Obviously those are just suggestions, but manufacturers have been aligning more and more with them. My daily ECAD/EDA tool is Altium, and I can't remember I had to manually make an IC footprint. I use their IPC Wizard[2] to make it all for me. As a bonus, I get a nice STEP model too with my export.
A lot of good stuff has begun to happen in this regard. At least KiCad has a large and pretty decent quality collection of footprints; I think other tools are making similar efforts.
However, I wish they would make it easy to adjust these footprints or make derivatives of them, without having to essentially redraw them.
For a looong time I’ve wanted to apply geometric constraint solving to drawing footprints. This would allow for having a base footprint which defines the constraints and then parameter files could introduce the specific dimensions needed. I’ve been working on it at https://github.com/henrikh/footwork-ecad and the parts are there, but I’d love to collaborate on it with someone :-)
>> For aerospace use reliability is king, for mobile devices space is a premium.
That's a great point. But how many different footprints need to exist for a 1206 led package from one manufacturer? Infinity? Or is it something more like 5?
>> A TSOP package from one manufacturer manufacturer is not necessarily the same as a TSOP package from another. This is not a hypothetical — I’ve been bitten by this.
But that's a different issue of a manufacturer not conforming to the spec they've published for their product. Same as a carabiner failing at a load of 100kg when it's rated for 500kg.
>> But that's a different issue of a manufacturer not conforming to the spec they've published for their product. Same as a carabiner failing at a load of 100kg when it's rated for 500kg.
Package names are, in some fashion, marketing and branding. The manufacturers publish their own specs and do adhere to them. There are also standards (mentioned in other comments), but they are typically more general.
I’m not saying this is ideal – but that is simply the reality.
> A TSOP package from one manufacturer manufacturer is not necessarily the same as a TSOP package from another.
Yeah, I've noticed this too. I now have to check the specific measurements (pin pitch etc) in the datasheets before buying, regardless of what the product page states about packages. I still on occasion make mistakes and get super tiny packages that I can't use without a pick and place machine...
This is mostly caused by both manufacturers and footprint library authors/EDA vendors using their own nomenclature for packages instead of the JEDEC standard names. This is especially apparent with gullwing SMD packages (anything from SO(IC) to LQFP) which are mostly same across manufacturers but vary widely in what they are called.
This is exactly the industry-problem SamacSys are trying to solve with their ECAD content (Symbols / Footprints / 3D Models). They are independent and offer their ECAD Models unlimited for free to Engineers. All the leading EDA formats are supported like KiCAD, Eagle. Their website (ComponentSearchEngine.com) where you can download the content also offers builder tools and a free fast turn around request service, so you can get models for almost every part you want quickly even if its new. SamacSys are distributing their ECAD Models to Findchips.com, Mouser, RS etc and behind all the leading EDA tool companies like Mentor, Zuken etc. Currently over 15,000,000 parts have CAD models. Hopefully this industry challenge is finally solved! - full disclosure i have worked with SamacSys, hence having the knowledge but they are really about fixing this problem for engineers so wanted to comment.
My friend and I built a project to see how much we could automate symbol and footprint generation from drawings. We got busy and never polished it off, but it’s avalible at https://pinpoint.parts in case anyone wants to try.
Sorry in advance, I just noticed our cert expired (I thought we set up automatic rotation, hmm..)
Within my domain of expertise (space engineering), the problem is even worse. Not only do suppliers provide haphazard information about parts through PDF documents, there's very little, if any, real convergence on what to actually provide to the engineer.
I'm confident that these highly unstructured PDF datasheets are going to go the way of the dinosaurs, but it's quite challenging to integrate any smarter solutions into the business chain.
My domain of expertise is the space industry, and it's stunning how much of a mess datasheets are. As an engineer on different missions, I couldn't understand why I was spending so much time trying to "undo" all of the work the suppliers had done to create these documents, to be able to get the data into into the tools that I needed to use and actually start my real work.
In the space industry at least, there's a concerted effort going on to try to replace these PDF documents with electronic, machine-readable equivalents. Through the European Cooperation for Space Standardization (ECSS) [1] and work being done by agencies like ESA [2], and private industry [3], but really it's not yet taking hold for a lot of operational reasons.
We're actually working on trying to digitalize the entire global supply chain by converting PDF datasheets into something that allows more intelligent engineering work. We're currently serving "level-1" through our website: https://satsearch.co.
We've also prototyped a way to cast the datasheets into something more usable with ESA and a number of other partners. We've currently serving this digitalized data through our API: https://api.satsearch.co, which is being integrated into industry tools.
The real dream for me is to get to the point where the engineer can work with this kinda data natively within their tools and skip the entire PDF datasheet fiasco. Ideally, the data can then even be operated on my multi-objective optimization algos to speed up the entire design process.
Disclaimer: I'm one of the co-founders at satsearch and we started our startup precisely because I was just sick of dealing with PDF datasheets.
