Selecting electronic components can be a frustrating process, one of trawling through the websites of distributors such as DigiKey, Mouser, or RS, and then poring over manufacturer data sheets. These documents produced as detailed guides to the technical specifications of a device contain enough to give an engineer everything they need to incorporate it into their designs.
Unfortunately many datasheets fall short of the ideal, and have instead become marketing documents designed to “win the socket”. This is a problem that vexes Boldport’s [Saar Drimer], and he has written a personal manifesto outlining his vision to make the world of datasheets a better place.
It’s a common-sense designer’s wishlist, and it’s one we could completely get behind. Chief among his desires are web-readable datasheets as well as the ubiquitous PDFs, with full data in human and machine readable forms instead of tiny printed graphs and tables. He also makes a plea for better UX testing to combat the scourge of the inaccurate pad layout, to which we’d add providing footprints ready-made for all popular CAD packages. These and the rest of his manifesto would be a game-changer, and wouldn’t displace the existing paper or PDF sheet for those who still use them. Whether or not the manufacturers will take heed is anyone’s guess, but to have such an ideal laid out is a start.
If you’re not familiar with [Saar]’s work, you’re in for a treat. Boldport produce some of the most beautiful artistic PCBs, and we’ve featured them before more than once.
Thanks to our colleague [Ted Yapo] for the header image.
” Chief among his desires are web-readable datasheets as well as the ubiquitous PDFs, with full data in human and machine readable forms instead of tiny printed graphs and tables.”
Semantic Web. ;-)
“web-readable datasheets as well as the ubiquitous PDFs, with full data in human and machine readable forms ”
If they were only in a common machine readable format the community would very quickly develop tools that converted it into every other format you want and then some.
Honestly though, I’m just happy that so many data sheets are still available for free in this copyright and patent encumbered mess of a world.
But which are cheaper?
After all, that’s all that’s going to really matter at the end of the day. The race to the bottom bites, once again.
I have recently worked on selecting an Bluetooth SoC for a new product, and as part of the process, I listed in a table all the important features of the parts available on the market, such as BT version, Tx power, Tx/Rx current, and a bunch of other parameters including price and lead time. The reason it took a just over a week is because the front page of the datasheets was written by the marketing teams, resulting in inaccurate information. For example, one SoC claimed to have a Tx power of 20 dBm, which is by any means impressive, however digging into the lelectrical characteristics deep into the datasheet, revealed that this figure is not for BT, but for a Sub-GHz mode, that SoC con work at. If This information was clear from the first page, it would have saved me a lot of time, as well as making me look at this manufacturer in the negative light of marketing BS, and I will probably avoid them in the future.
Name them, please!
Bring out the mob!
You should skip the first page and go straight to the parameter tables. Be sure to read the fine prints to understand the conditions that applied there.
The typ values and some of the performance curves are useful info to give you the idea of what to be expected from a *small samples* of parts. Only use the min and max one that are guaranteed by designed or testing.
On the topic of footprints for all, is this not what UltraLibrarian, and more recently SnapEDA are all about?
I feel providing the UltraLibrarian files, that are then translated to the required CAD package would be sufficient, and indeed, this is what TI and a few others already do!
And although I do agree with Saar generally (he and I have talked on this), I also think that the ability to search out and analyze data is core to the skill set of a competent engineer.
Unified simplistic formats are one thing, erroneous and missing critical data however is completely unforgivable in a datasheet.
“Footprints ready-made for all popular CAD packages”
Please for the love of God, no. More data in some specific proprietary format is never the answer.
Who gets to decide what is “popular”?
What PCB package version?
What about 5 years from now?
How about they just put the pad sizes and locations in a nice easy to use text table. Then we demand CAD tools that have some scriptable behaviors.
— Ditch PDFs in favour of browser-based viewing
No. While we can all agree that “PDFs are bloated, impossible to reliably parse, static, and a possible vector for malware”, this can be fixed or can be worked around using an Open Office or other such format. HTML/XML stuff is problematic and is not consistent.
And the author’s example of Atlas Scientific data sheets as a ‘standard’ is not only poor but is an apple to cucumber comparision. These are simplistic units, where the standard interface is to the hobbyist arduino. Wanna see good examples? Look at the old Burr Brown and LT data books for analog stuff, and an old Mot 68xxxx data book for controller ICs.
— Provide machine-readable information and formulas for figures
Damn right. I am certain that there will a special place in hell reserved for tech managers that published locked data.
— Create multiple views
Perhaps not. Significantly increases document complexity. But, in principle, a good idea.
— Perform user-experience (UX) testing
Pipe dreaming. More added expenses = more jobs out-sourced to Asia. Basic process should be for docs to be reviewed by the respective engineering team. And “UX testing” is what gave us Windoze 8, 10, and other such crap. User experience for whom? Engineers? Hobbyists? My doggy? They all want to see different stuff in different ways.
Use revision control
Most already do rev control, and is now considered a pro forma requirement per the ISO9k bull crap.
Place documents in permanent location in perpetuity
More pipe-dreaming. Unless you mean >10 years is “perpetuity”.
Keep users updated
And yet more pipe-dreaming. IAC, difficult to do with all of the new information security and privacy regulations. And per human nature, marketing dorks will abuse this badly.
+1000!
Thanks Brian, a reasonable response. They’re still trying to pry me off the ceiling of my office.
Saar,
No experienced hardware engineer would make these claims, especially that the Atlas Scientific datasheet should be even considered a real datasheet, it’s written for a novice hobbyist. It certainly doesn’t provide me what I need as an engineer designing this into a product and I design gas detection equipment daily.
Give up printable datasheets? ARE YOU DELUSIONAL!!! Don’t you keep design notebooks? I do, and a printed copy of the datasheet for ALL components used goes in the notebook. If there are questions later I can figure out what I was thinking at the time. I can add comments and notes on the sheets so I don’t have to re-invent the wheel later. If the part changes the documentation is traceable and I can compare a new sheet with the old one. Without the manufacturer sneaking the old one into hiding to cover their backside.
Once a datasheet is published to the web it might as well be considered carved in stone. There are many sites where I can locate a scanned datasheet for an obsolete part. The part may be gone but the datasheet lives on.
The only way you’re going to get common footprint files is for everyone to switch to Altium ( or pick a CAD package ) and abandon all hope. it’s just the way it is.
I do have a MAJOR problem with modern datasheets and the reluctance to put part numbering definitions in the datasheet. With multiple packages and ridiculously long part numbers these days, picking a part is almost as much a crap shoot as it can get. It’s not just the datasheet, the websites don’t define them any better. Go and figure out what the difference is between an “A” and a “B” mean for the 8th character in a part number and you’ll quickly understand.
“this can be fixed or can be worked around using an Open Office or other such format. HTML/XML stuff is problematic and is not consistent.”
What exactly do you mean by not consistent?
The days of “Designed for IE vs Netscape” were a long time ago. When was the last time you tried to go to a website and it didn’t display properly because it used non-standard html that your browser does not parse? Is that what you meant?
Open Office might be a small improvement in a way. Being free and open, so long as there are documents to be read in that format I am sure there will be an up to date application that can do it. I really can’t remember the last time I had any challenge with opening a PDF though. What problem would you be trying to solve?
HTML (as commonly used), OpenOffice, PDF and even MickeySoft Word are all document formats. They all describe the presentation of data. Sure you can derive the meaning in your head as you read it but that does nothing for helping you find the datasheet in the first place. Also, the format is fixed. If you just don’t like the format the author used or more importantly, if it doesn’t fit well on the device you are viewing it with you are out of luck. (OK, HTML when used with multiple CSS stylesheets can kind of address this second point although few authors are good at it).
Using a semantic rather than presentation oriented format would be a much bigger improvement. Search software could “know” what the part number is, what kind of part it is, what case styles it is available in, etc… It wouldn’t just be a big blob of text. For example. Say I wanted to find a JFET in a SO23 package. There could be a search form that has many fields, one is type and I select JFET. Another is package style and I select SO23. I press search and the results are quick and include EVERY JFET that is available in a SO23 package and NOTHING else. Now let’s say we are still using some presentation type document format. The best that can be done is to index all the text of every datasheet. Then search it for JFET and SO23. That is a lot more text to search through so it will take longer. Worse, there is going to be a lot of noise in the results. There will be datasheets that use those words somewhere in the text (perhaps in the application notes) but the part itself is not a JFET or is not available in the SO23 package. That sucks!
This kind of problem is exactly what XML was designed for. Personally I think XML is far to verbose. There is just too much framework cruft. And yes, people seem to have a hard time following standards so there are a lot of broken implementations out there for XML standards. That’s more a people problem than an XML problem though. There is no reason people will automatically be more consistant with applying any other standard.
Finally, if you really want a pdf or an OO document or any other format.. those can be automatically generated from an xml document after applying the stylesheet of your choice. One application that only has to be written one time can generate all of them for you. And someone else who likes another format… they can do the same. I don’t know why one would do this if there is already a good viewer for displaying the XML document and it has print capability. But you can if it makes you happy.
How about in the form of a Jupyter Notebook?
How about we just have pdfs in landscape instead of portrait, or have both. Anything extra as a view or print standard is just waiting for numerous different formats and more trouble. Standard tables at the back of the datasheet listing the x y offsets to reproduce the pads would enable simple OCR routines to read in the layout structure. Standardize these things and we’d all be happier and it’s not a great deal of work from a software point of view too.
Things I remember loving in datasheets:
– embedded links to report factual errors (TI)
Things I remember hating in datasheets:
– addresses to registers being given as an offset to the base address of the ip core with the base address being listed far away in the “memory map” chapter (TI)
– registers being described in an appendix of the datasheet instead of close to the functional description of each ip core (Xilinx)
– texts talking about about stuff (internal signals, disabled options for synthesis, …) that might once have been relevant to the chip designers but is meaningless in the final silicon (No, the NXP i.MX6 PCIe controller does not have MSI-X support…)
– omission of the fact that an ip core has been bought from another company
The Chinese lust for 200 pages of “table of contents” before the actual data sheet (book?) starts :-(
The format has spread like an Internet truth.
I absolutely hate datasheets that have a written table of contents in the first pages bu then don’t have an electronic table of contents.
Browser-based viewing instead of PDF is a *very* bad idea for datasheets. A website can’t easily be mirrored in a reliable way and it can go down for many reasons such as:
* The part gets discontinued but it may still be available for purchase from old stock or as an unofficial clone many years later. And even if the part gets totally unavailable and not used for new products any more, the datasheet can still be very valuable while repairing defective devices decades later.
* The vendor goes bankrupt or discontinues/sells the electronics parts business.
* The vendor gets bought by another company, nobody cares about keeping old stuff online.
* Someone at the vendor decides to redesign the website (e.g. migration to a new CMS), which often involves breaking old content (I had this problem several times while trying to download drivers for old hardware).
* Websites can go temporarily down for maintenance or technical problems.
* Websites sometimes get unavailable/blocked in certain countries for various reasons (e.g. blocked by the great firewall of China). For a PDF datasheet it is a lot more likely to find an unblocked mirror somewhere.
* Given the rapid evolution of the WWW, it is unlikely that an interactive web site designed today will still be usable 30 years later. An interactive datasheet designed 10 years ago would likely be using Adobe Flash (possibly limited to a certain old version of the flash player) and already be *very* inconvenient to use today. For a PDF file, it is very likely that there will still be a compatible reader in 30 years (assuming that the PDF is not using special extensions and works with a variety of different PDF readers today).
A PDF file gets often mirrored on other sites (e.g. distributors or dedicated datasheet mirroring sites) and very often stays available somewhere even if the original download link from the vendor gets unavailable. Additionally to that, a user can easily keep a local copy.
Additionally to the PDF datasheet there may indeed be other helpful resources such as:
* SVD files containing a machine-readalbe register description
* Spice models
* 3D models
* Machine-readable footprints (hope there will be a common format supported by all major PCB design programs one day)
* Design tools (which may very well be implemented as an interactive website)
A few points on reading datasheets:
— The typical parts are the ones shipped to someone else. You get the min/max ones.
— If no min/max is given it means they will ship you floor sweepings
— If an input doesn’t have both a max voltage and max current spec worry
— Power ratings are always for LN2 cooled diamond heatsinks
— “low” as in “low power” only means “not as bad as some other”
— A non-surge rated surface mount resistor can’t take any sort of surge
— Ceramic capacitors are measured at zero volts. Check the curves
— Water resistance means water gets in
— A production status of “active” can be “obsolete” before the PCB is done.
— If a graph cuts off at some value assume it goes bad just beyond there.
^ This. A properly done, clear and accurate mechanical drawing that anyone can easily transfer into their system of choice is by far the most universal solution.
* Always provide manufacturer recommended footprint layouts. Don’t make me to a competitor’s datasheet to get a recommended layout for the same package.
* Always list pad positions as x/y measurements from chip center point to pad center point. Even just as a table off to the side would be fine.
* Table of contents items should be links to their respective pages.
* PDF should have bookmarks for chapters and subsections.
* PDF page numbering should always match page numbers printed on the document.
Basically, what everyone wants, and summarizing from the comments here : well written PDFs, with correct table of contents and clearly defined footprint layouts. The rest of the things suggested are personal preferences, not necessary changes.
Printing web pages gets ugly really fast, and people will not take the time to write a datasheet as a web page and also write an adequate css/whatever-thing that renders the content in a way adequate for the printed page.
As for searching, well, most vendors have very good parametric searches in their homepages. Or one can always use digikey or mouser as a search engine just to discover suggested parts with the parameters desired.
The PDF should be proofread so that all the special symbols are properly rendered. too many datasheets are badly converted and have scrambled the symbols, or have unicode numbers in place of the symbol. How lazy is that?
Ever seen an SMD? Just make something that doesn’t look like that and you’re already 90% of the way there.
https://landandmaritimeapps.dla.mil/downloads/milspec/smd/96663.pdf