opensource transistor database

[nuclearcat]

It looks like my google-fu skills failing me, or i'm looking for something that doesn't exist (but obviously should).
I am making a boost converter, and I am trying to find the optimal transistor and other components for it, and in principle there is nothing difficult to add all the formulas in python script, try each transistor, find optimal circuit values for it, and estimate losses. Then i can make winners list and manually filter out those that dont work for me (price, wrong package type, etc).
But there is a problem, with all the huge selection of transistors, i did not find an opensource database for these transistors, that I could use in such a script.

Doesn't such database really exist?
E.g. where is present transistor model, Coss, V(miller plateu), Vgs, Q (th), and other parameters and it is parseable.

And, maybe if it doesn't exist i should create crowdsourced and opensource database?

[T3sl4co1l]

You can get close with the web APIs from several suppliers e.g. Digi-Key, Mouser, etc.

You won't find anything aggregating actual datasheet values unfortunately.  Perhaps scraping mfg websites (perhaps they have APIs too, YMMV) will give more info.

(Otherwise, you're welcome to scrape raw PDFs (probably including OCR as well).  It's... possible.  Feasible?  Good luck... )

With queried supplier catalogs, it's rarely necessary to flip through more than a dozen datasheets to find a set of acceptable transistors for a given application.  If you need more, it's a sign that you may be doing something wrong: consider reworking your application to a more conventional approach.  (A counter-example might be, selecting transistors for linear operation: a few use this keyword in their description, but those are expensive; cheaper commodity parts may be rated for DC SOA, but you'll never see those data in the catalog, you have to flip through all the datasheets to find out.  A positive example might be, something dependent on tight or oddball Vgs(th), or tempco or something; these are unreliable parameters and the design should be reconsidered to remove that dependency.)

Miller plateau, by the way, is relative to Vgs(th), and is typical given respective drive conditions (3.3, 4.5, 10V, etc.) and load.  It's certainly nothing you should be sorting by; more likely you'll search to select "logic level" types because of low drive voltage, or exclude because of low Vgs(th) and high Qg (causing very slow turn-off, increasing switching losses).

Tim

[kripton2035]

you can search with parameters on
https://octopart.com/electronic-parts/discrete-semiconductors/transistors
or for transistors only here :
https://alltransistors.com/

but no their database is not public, you can have an api access to octopart.(free for small number of search, pay if many searches)

[ajb]

A big downside to scraping distributor sites for this info is you'll be relying on how accurately and consistently the distributor has transcribed the datasheet parameters into their database.  The numbers may not be wrong per se, but they may list a value under one set of conditions for one part and a different set of conditions for a different part.  Using data direct from the manufacturer may be more accurate, but you still have to consider the measurement conditions for the parameters you care about, which could be hard to pull out of a datasheet programmatically. Also some datasheets may only specify some parameters via graph. 

I wonder how well machine learning could be applied to pulling all of the graphs out of a datasheet and quantifying them into tables that could then be filtered against.  Even just doing that on SOA plots would be a huge help, like Tim said trying to select a transistor for linear operation is a slog because you have to look at all the datasheets.  I might pay actual money for a tool that would let me enter a set of Id/Vds/t parameters and get a filtered list of parts.

[nuclearcat]

You can get close with the web APIs from several suppliers e.g. Digi-Key, Mouser, etc.

You won't find anything aggregating actual datasheet values unfortunately.  Perhaps scraping mfg websites (perhaps they have APIs too, YMMV) will give more info.

(Otherwise, you're welcome to scrape raw PDFs (probably including OCR as well).  It's... possible.  Feasible?  Good luck... )

With queried supplier catalogs, it's rarely necessary to flip through more than a dozen datasheets to find a set of acceptable transistors for a given application.  If you need more, it's a sign that you may be doing something wrong: consider reworking your application to a more conventional approach.  (A counter-example might be, selecting transistors for linear operation: a few use this keyword in their description, but those are expensive; cheaper commodity parts may be rated for DC SOA, but you'll never see those data in the catalog, you have to flip through all the datasheets to find out.  A positive example might be, something dependent on tight or oddball Vgs(th), or tempco or something; these are unreliable parameters and the design should be reconsidered to remove that dependency.)

Miller plateau, by the way, is relative to Vgs(th), and is typical given respective drive conditions (3.3, 4.5, 10V, etc.) and load.  It's certainly nothing you should be sorting by; more likely you'll search to select "logic level" types because of low drive voltage, or exclude because of low Vgs(th) and high Qg (causing very slow turn-off, increasing switching losses).

Tim

Yes, sure i can pick "any" that fits, and it will work, as always design have some margins for each parameter.
But also i like approach "make list of best performers for your application" and pick one i can afford (price and availability mostly), without wasting too much time, plus often i miss some cool models, because i dont like to waste hours on all suppliers, checking parameters of each transistor.
It will be also possible to make python app that will draw parametric curves for SMPS and flip them for each transistor selection by single click of button.
Isn't it cool, if such thing will be possible?

[nuclearcat]

A big downside to scraping distributor sites for this info is you'll be relying on how accurately and consistently the distributor has transcribed the datasheet parameters into their database.  The numbers may not be wrong per se, but they may list a value under one set of conditions for one part and a different set of conditions for a different part.  Using data direct from the manufacturer may be more accurate, but you still have to consider the measurement conditions for the parameters you care about, which could be hard to pull out of a datasheet programmatically. Also some datasheets may only specify some parameters via graph. 

I wonder how well machine learning could be applied to pulling all of the graphs out of a datasheet and quantifying them into tables that could then be filtered against.  Even just doing that on SOA plots would be a huge help, like Tim said trying to select a transistor for linear operation is a slog because you have to look at all the datasheets.  I might pay actual money for a tool that would let me enter a set of Id/Vds/t parameters and get a filtered list of parts.

I did some basic scraping tests with camelot and tabula, and it looks very promising.
IMO possible to do something with graphs as well, at least to make it mostly automated.

[nuclearcat]

Why are we wasting so much time with completely useless "pretty printed" two-column kerned line-wrapped serifed font nonsense that we literally don't have TIME to waste reading when what we could REALLY use is a parametric machine readable / understandable data set.

I suspect because nobody bothered yet to unify data format and to keep asking on manufacturers to make it available.
Like nobody bothered before to publish 3d models of components, but this days i can see more and more STEP models of component downloadable at manufacturers and distributors.
Probably simulation models, such as SPICE fit most of my requirements, but i didnt checked yet, if they have all i want.

[nuclearcat]

BTW for this ad-hoc purpose I suggest you probably should just "optimize" the circuit for a small number of ranges of "plausible transistors" of arbitrary characteristics within the domain you need and corresponding to real devices.  Analyze/simulate the actual efficiency differences between those and pick a couple sets of parameters / parameter combinations that really are "most optimum" and most distinctively useful for you.  Then just look parametricaly (with the pathetic tools / information sources available) for something that's close to those parameters greedily excluding things that are significantly different e.g. RdsOn, Vds max, Qg, whatever.  At lease the digikey or manufacturer search engines will have SOME of those key parameters as filtering keys.

That what i guess everybody do, and this is very sad and time consuming.
Especially with latest trends, some distributors parametric search getting worse, and data entry quality bring many questions.
Also most of this operations can be automated.

Beyond that you COULD download a bunch of SPICE models for different transistors and at least you COULD relatively more easily filter those for parameters you care about since it is a standard machine readable format.
Trouble factors:
1: Many transistors don't have spice models available.
2: Many idiotic manufacturers don't have the spice model linked immediately alongside the data sheet and even if they do their web sites are crap so you may have quite some difficulty downloading "a lot" of spice models and keeping straight what devices they correspond to.
3: Some spice models aren't very good and the parametric values aren't very realistic for some parameters or operating regimes.

Same goes for pulling and "scraping" data sheets.  Theoretically possible but hardly "convenient" for all kinds of stupid reasons that shouldn't prevail.

Exactly, that what i tried. Its not many transistor dont have, most of transistors seems dont have.
My guess also that providing full SPICE model require more information and efforts than making basic datasheet info more machine readable.

[T3sl4co1l]

SPICE is prone to the same shortcomings.  There are numerous versions, not all of which are freely available.  Berkeley 3f5 (the original, or XSPICE its later evolution), whatever variant Altium or Multisim, LTspice, etc. use, PSPICE, HSPICE -- the list goes on.  Each of which uses proprietary syntax and functions that aren't necessarily compatible, and even when they are supported (e.g. TABLE or IF() in XSPICE variants), there's no guarantee they'll even converge (these functions are notoriously numerically unstable, having poorly- or un-defined derivatives); supported tools (PSPICE, etc.) use hacks to improve convergence, sometimes at expense to accuracy (LTspice especially is notorious for trading off accuracy for speed).

The models themselves are equally mixed.  As I recall, newer models by Infineon are ground-up entirely new parametric models, bringing great accuracy to e.g. modern SuperJunction MOSFETs, completely avoiding the issues with built-in models (which were designed around, now archaic, IC processes); but running extremely slowly in most sims due to all the internal nodes and computations being done directly in the state matrix (i.e., not benefiting from native compiled implementations).

Older models from IR and such, are a modest compromise between accuracy (usually using LEVEL=3 or 6; 2 or 1 give poor results), ease of production (the tools used to generate the models are old and traditional), and performance.  Factors to beware of include Vds-dependent capacitances, which are often modeled wrong (e.g. it's wired to read Vdg not Vds), or not at all (e.g. some ST models use fixed capacitances(!!)).

It is at least easy enough to measure parameters from the models.  And knowing how to do this, both in the model and IRL, is a valuable skill.  How to know if your model sucks, when they're such a mess?  Measure it yourself, of course!

Illustrated example: I once characterized the STP19NM50N (now obsolete, but comparable parts are available in newer lines).  Here's comparing measured (noisy blue) and fitted (red) capacitance, to the datasheet:
https://www.seventransistorlabs.com/Images/STP19NM50N%20Coss%20Comparison.png
Here's an overlay between the corrected model (using a voltage-dependent capacitor of my own design) and measured data, switching waveform (gate charge and Vds):
https://www.seventransistorlabs.com/Images/STP19NM50N%20Model%20Gate%20Charge%2012V%204%20ohm%20Comparison.png
I'm not too familiar with all the parameters in the MOSFET model and how they interact, so I wasn't able to get a great fit, or perhaps a better fit simply isn't possible as SuperJunction is very different from the LEVEL=2 base I was working with.  For purposes of simulating switching transients, it's easily closer to average than a bogey individual part is expected to be, so I don't really care.  And for linear applications, the parameters drift enough that further accuracy is equally futile.

An interesting point to note about these, which you can see evidenced in the above waveform: at least in typical applications (say, discontinuous flyback, or ZVS), most of the Miller step occurs at very low drain voltages.  Most of the switching is already well and done by then, and it's just a matter of saturating down to Rds(on) in the remaining time.  The nonlinear capacitance helps you out greatly here -- whereas a constant-capacitance device would have switching energy predicted as Esw = 0.5 t_sw Vpk Ipk, these can give a fraction of that -- maybe a third, typical.

On the other hand, it counts as many times against you in hard-switched (capacitive load, e.g. CCM boost, or LLC driven below resonant frequency), where the device turning on, has to yank charge out of the opposing device, which doesn't happen for, well, about that much time, meanwhile the switching device is dissipating full supply voltage.

So, switching loss is highly dependent on load, and having a well defined load is key to efficient design.

Tim

[nuclearcat]

SPICE is prone to the same shortcomings.  There are numerous versions, not all of which are freely available.  Berkeley 3f5 (the original, or XSPICE its later evolution), whatever variant Altium or Multisim, LTspice, etc. use, PSPICE, HSPICE -- the list goes on.  Each of which uses proprietary syntax and functions that aren't necessarily compatible, and even when they are supported (e.g. TABLE or IF() in XSPICE variants), there's no guarantee they'll even converge (these functions are notoriously numerically unstable, having poorly- or un-defined derivatives); supported tools (PSPICE, etc.) use hacks to improve convergence, sometimes at expense to accuracy (LTspice especially is notorious for trading off accuracy for speed).

The models themselves are equally mixed.  As I recall, newer models by Infineon are ground-up entirely new parametric models, bringing great accuracy to e.g. modern SuperJunction MOSFETs, completely avoiding the issues with built-in models (which were designed around, now archaic, IC processes); but running extremely slowly in most sims due to all the internal nodes and computations being done directly in the state matrix (i.e., not benefiting from native compiled implementations).

Older models from IR and such, are a modest compromise between accuracy (usually using LEVEL=3 or 6; 2 or 1 give poor results), ease of production (the tools used to generate the models are old and traditional), and performance.  Factors to beware of include Vds-dependent capacitances, which are often modeled wrong (e.g. it's wired to read Vdg not Vds), or not at all (e.g. some ST models use fixed capacitances(!!)).

It is at least easy enough to measure parameters from the models.  And knowing how to do this, both in the model and IRL, is a valuable skill.  How to know if your model sucks, when they're such a mess?  Measure it yourself, of course!

Illustrated example: I once characterized the STP19NM50N (now obsolete, but comparable parts are available in newer lines).  Here's comparing measured (noisy blue) and fitted (red) capacitance, to the datasheet:
[url]https://www.seventransistorlabs.com/Images/STP19NM50N%20Coss%20Comparison.png[/url]
Here's an overlay between the corrected model (using a voltage-dependent capacitor of my own design) and measured data, switching waveform (gate charge and Vds):
[url]https://www.seventransistorlabs.com/Images/STP19NM50N%20Model%20Gate%20Charge%2012V%204%20ohm%20Comparison.png[/url]
I'm not too familiar with all the parameters in the MOSFET model and how they interact, so I wasn't able to get a great fit, or perhaps a better fit simply isn't possible as SuperJunction is very different from the LEVEL=2 base I was working with.  For purposes of simulating switching transients, it's easily closer to average than a bogey individual part is expected to be, so I don't really care.  And for linear applications, the parameters drift enough that further accuracy is equally futile.

An interesting point to note about these, which you can see evidenced in the above waveform: at least in typical applications (say, discontinuous flyback, or ZVS), most of the Miller step occurs at very low drain voltages.  Most of the switching is already well and done by then, and it's just a matter of saturating down to Rds(on) in the remaining time.  The nonlinear capacitance helps you out greatly here -- whereas a constant-capacitance device would have switching energy predicted as Esw = 0.5 t_sw Vpk Ipk, these can give a fraction of that -- maybe a third, typical.

On the other hand, it counts as many times against you in hard-switched (capacitive load, e.g. CCM boost, or LLC driven below resonant frequency), where the device turning on, has to yank charge out of the opposing device, which doesn't happen for, well, about that much time, meanwhile the switching device is dissipating full supply voltage.

So, switching loss is highly dependent on load, and having a well defined load is key to efficient design.

Tim

Wow! I wonder if datasheets have significant inaccuracies too, as SPICE models. But already extracting data from PDF charts wont give great degree of precision.
About IRL testing, it's great idea, so i will keep in mind, documenting some easy setup for measurements - might be handy too.
Also, based on your information - SPICE model is no-go.

Well defined load is great, but i believe it is real as spherical cow

[T3sl4co1l]

No, not really.  Just a matter of: how good is the information, actually?

So.  Taking a step back here.

Knowledge isn't static, it is a process.

You obtain some information, and then you verify it, to ever greater certainty as work and time goes on.

You start with information, data, anecdotes, statistics, whatever you want to call them.  You only gain knowledge when that information has been parsed, cross-referenced, corroborated, etc.

And sometimes that knowledge will be positive, confirming the facial truth of the info; and sometimes it will be negative, disproving that instead.  A negative result might not be all that useful -- there might be billions of ways of, say, configuring a circuit of just a few components -- but it is still, technically, forward progress to be able to test and discard individual configurations.


SPICE models might be good, they might be trash.  It's a good bet at least that, if they look like hack jobs (low LEVEL model, linear capacitances, poor fitting waveforms), they're probably not very representative, and if they look pretty solid, they are likely usefully representative.

Same for datasheets, same for anything else.  Same for what's on TV!  Don't let a single clip of news by your eyes without critiquing it in exactly the same way!  It's not just a good life lesson but a critical one, sadly one an awful lot of people miss out on (whether entirely, or through incomplete application thereof).

It also works the other way.  My note about well-defined loads should be read as instruction, not a mere condition.  As the designer, you are wholly, personally and solely responsible for the integrity of your design.  You have complete control over every facet of it.  You can model everything.  You can read datasheets until your eyes bleed, selecting the right parts, or seeing what's available.  (Well, in most practical projects, you won't exactly have unlimited time available, but it also happens often enough that a salaried position has substantial downtime between projects; you can use that time for entertainment or education, it's your choice!)  There is no need to leave this to chance, you can explore all corners of operation of your e.g. switching power supply, and see what happens to switching loss and all that under every possible condition, as well as what to do about it (e.g. for a resonant supply, simply stay at or above resonance; if it gets stuck below, maybe just bail -- fault out and wait a bit before resetting).

I'm not sure how well this thought process comes out from my above post -- perhaps it would be automatically understood as a story of such researches, to one who has experience with the process; perhaps to someone less so inclined, it just looks like me showing off a bunch of stuff I did.  Heh, or maybe I should've went with the spreadsheet view instead?  Hard to say, static infodumps hide a lot of the process through which they were created.  Obviously, that spreadsheet didn't appear out of thin air, but what does it all mean and how what it constructed?  Maybe it's more of white-noise than a puzzle to figure out... I don't know.


Not trying to scold here, it's just, I wish there were some way to convey this thought process that was intuitively, vacuously obvious, and immediately applicable.  Alas, it seems -- whether simply never having been exposed to, or taught it, or if through an innate inability to do so (I hope not!) -- many do not reach this realization.  So I fear I'm mostly talking into the abyss on philosophical (epistemological?) subjects like this.  Which I in turn justify to myself as at least being a vent with which to further solidify my own views of the subject, and perhaps someone will get lucky and benefit from it as well...

Tim

[nuclearcat]

First of all, i apologize for my English, I may be missing something or not translating my thoughts correctly.

I'm not sure how well this thought process comes out from my above post -- perhaps it would be automatically understood as a story of such researches, to one who has experience with the process; perhaps to someone less so inclined, it just looks like me showing off a bunch of stuff I did.  Heh, or maybe I should've went with the spreadsheet view instead?  Hard to say, static infodumps hide a lot of the process through which they were created.  Obviously, that spreadsheet didn't appear out of thin air, but what does it all mean and how what it constructed?  Maybe it's more of white-noise than a puzzle to figure out... I don't know.

For me, your post is very important. Because:
1) I am not talking to myself, the problem of inaccuracy and insufficient data exists and worries not only me. Although I only noticed a small part of the iceberg, you dug much deeper.
2) If someone did such measurements, maybe i can repeat it and others can repeat. Your data is inspiration. The question is how to make such measurements by cheap equipment.
Hopefully i might have enough time in future and skills to create something useful, similar to Markus Frejek transistor tester that evolved in enormously popular component tester ( https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/ ).
But a bit more modern. Let it be able to connect to internet, upload/download to database measured data, including parametric curves, improving it such way.
Also, if CPU benchmark websites exists, and by crowdsourcing can confirm vendor claims or user benchmarks, or reveal vendor cheating, maybe we can have same for components, at least transistors.
Especially this days, when many are getting components from questionable sources. You have problematic component that is probably counterfeit? Plug it and confirm if it match genuine one.
And of course, sometimes might give an idea if the manufacturer(esp. those new asian ones) has problems itself, and different batches have significantly different parameters.

Not trying to scold here, it's just, I wish there were some way to convey this thought process that was intuitively, vacuously obvious, and immediately applicable.  Alas, it seems -- whether simply never having been exposed to, or taught it, or if through an innate inability to do so (I hope not!) -- many do not reach this realization.  So I fear I'm mostly talking into the abyss on philosophical (epistemological?) subjects like this.  Which I in turn justify to myself as at least being a vent with which to further solidify my own views of the subject, and perhaps someone will get lucky and benefit from it as well...

Tim

Perhaps I did not quite understand what you said here(due language barrier), but my personal opinion, your information strongly pushes for a more correct perception of the situation. For example, i was mistaken, thinking that those few existing SPICE models more or less accurately correct. But it doesn't seem to be so ...

[T3sl4co1l]

Anyway, as for specific tests, the waveforms are pretty simple -- the switching and gate charge one for example is just a current source into/out of the gate, and measuring the gate and drain voltages.  Drain load is some supply voltage, and either a resistor or CCS to set the load current.  (I used a resistor, which is why the Miller plateau is more sloped than otherwise.  I think mfgs make use of both loads.  International Rectifier (now Infineon) always put the test circuit in the datasheets for example.)

Because gate current is small, the waveforms can be quasi-static, i.e. you don't need to rely on a high bandwidth scope or anything, just have a properly compensated probe and you're good.  And there's no issues like from stray circuit inductance.  Being able to acquire that waveform (e.g. I can download the waveform or screenshot from my TDS460 via GPIB, though I didn't have this facility at the time and actually used a photograph instead!), you can measure gate charge directly (current * time to reach Vgs(on)), and also Cdg (Crss) in part.

With the same setup, but with fast gate drive and a low current load (CCS or large value resistor), you can measure Coss(Vds).

With yet another setup, you could measure capacitances with respect to Vgs, though it's my experience that VDMOS has actually very little or no dependency on Vgs.  You'd think it'd be important as the control terminal, but nah, it's all dependent on Vds.

In fact, Ciss depends so much on Vds that I suspect one could quite profitably use a MOSFET as a low distortion variable capacitor, so long as Vgs < Vgs(th) -- otherwise if it goes above, the control voltage (Vds) gets pulled down and that's no good.

The static parameters are easy of course; Vgs(th) is measured with Vgs = Vds (i.e. D and G strapped together) and some Id applied.  Rds(on) is some Vgs(on) and measure Vds(Id) at one or more points.  g_fs isn't very important/useful honestly, but can be measured in the standard way (set up resistors to G and D for the defined voltage and current, and AC-couple some gate voltage in, and measure AC drain current out).  Body diode can be measured in the usual ways (Vf(If), etc.  Reverse recovery isn't as easy to measure, you need a particular pulse waveform to do it -- on the upside, it's usually quite well behaved (I've never seen a body diode that exhibits forward recovery), and related to Vds(max) (higher voltage MOSFETs have slow t_rr) so it's not much of a concern).  Vds(max) is usually safe to test by avalanche at low current; some devices might not survive high currents, but a mere mA should be alright, at least for most Si and SiC FETs.  Temp dependencies are pretty typical, like Rds(on) and Vgs(th) tempco.

R_G is maybe one of the harder ones?  You need an AC setup specifically for that.  Tie D and S to GND (or maybe leave D open), measure G-S impedance at say 1MHz.  It'll have some capacitance and resistance, and there you go, R_G is the ESR.  If you don't have an impedance bridge / analyzer, maybe set up a resonant tank, measure the effect of the gate load, and solve for R and C.


And as for databases, whether it's useful enough that a reasonably general/global/complete one should exist, I don't know; but at this point, since one does not, it's a huge amount of effort to create let alone maintain, and even if there's the distributed cost of a million engineers spending ten extra minutes a day doing that, it may still be hard to justify.

And because of all that effort, it would be really, really helpful to be able to monetize it...

And so it is, that you have services like Octopart.  Though more for the supply/inventory side, but they retain some component data as well.


On a related philosophical/speculative note, I suspect AI won't actually come to literally every domain; as it is right now, there's only the most profitable applications of it, on databases too huge to use anything else with, and with immediate commercial benefit.  It may happen that some aspects of EE for example are at least facilitated (and indeed, we've had autorouters for decades; they've almost always been bad, but there are some nice ones, give or take what you're willing to pay for them -- they don't trickle down as well as other technology, it seems -- see what I mean, yet?), but I doubt that the profession will be obsoleted, at least any time soon, if not ever.  (I would allow that it might be at least partially obviated, like by somehow creating ICs so richly functional, and somehow so easy to use, and reliable, that circuit design is basically even more trivial an affair than Arduinos.)

This diversion maybe sounds a bit random, but a similar thought process applies -- if there's simply not enough value in doing it, it won't be done.  We could indeed create the database of which you speak -- but it won't be trivial to do, even though all of the building blocks are known and proven (web scraping, PDF OCR and data scraping, queryable databases or APIs, etc.).  The challenge in launching such a thing, is in proving that that cost is justified by some kind of payoff (typically monetary).  Even if we can show that it wastes millions of engineer-hours per year, it's not the case that we can harness every single dollar of that time.

Tim

[pardo-bsso]

Not digital, but many university libraries (thankfully) still carry their copies of the NTE/ECG catalogs and cross references.

[vk6zgo]

The big underlying problem is that companies (and many engineers) are apparently misinformed and mistaken that web sites and data sheets (though this also applies to all research / books etc.) should be designed specifically for humans to interactively read as a "user interface" and "pretty formatted document".

That's fundamentally a misguided approach.

The *primary* purpose of "publishing" something should be to encode its INFORMATION (not formatting -- just information) for MACHINE READABLE processing.

That actually makes the useful bit (the information & data) able to be searched, indexed, and manipulated by computer programs whether standardized ones or custom ones (i.e. YOUR specific search / filter / model / analysis parameters).

As a trivial byproduct it then would be possible to filter and format the information into "reports" or "documents" containing selected information in selected formatting so that a human CAN read over the information as a document.  But this is often much less relevant and much less necessary than a human being able to guide
a richly parametric search and "import" process over the databases as a whole so that a human doesn't HAVE to read through 99.999% irrelevant documents to get to the few ones that match their interests, but rather can focus on creating useful works with the selected excerpts of parts / data which are relevant to their query.

A human can literally only read so many data sheets, web pages, books, or whatever in their life time even if they did nothing else.  Maybe some thousands of them.

A typical modestly powerful computer of today can process circa as much information in a second as a human can read in a life time (e.g. 25,000 transistor data sheets).

Why are we wasting so much time with completely useless "pretty printed" two-column kerned line-wrapped serifed font nonsense that we literally don't have TIME to waste reading when what we could REALLY use is a parametric machine readable / understandable data set.

Probably because the computer based search will bring up devices which are obsolete, unavailable in a particular country, fake, or of known poor reliability.

My method, admittedly biased towards the repair of existing equipment, consists of the following:-

(1) Does it have three legs?

(2) Is it used elsewhere in the equipment for a non-critical job? (manufacturers like to do this, as it reduces the number of component types required in their inventory).
Often the non-critical position can be replaced with a "jelly bean" part, releasing the better component for critical service.

(3)Is it NPN, PNP, or a FET?

(4)What does Philips use?-----this is a bit obsolete, but other manufacturers can be substituted.

In my experience, there is very little novel circuitry around, so some other company probably already does something  similar.
In my case, Philips devices were most readily available.

(5) Start looking online.

(6) After looking online to no avail, look more closely at the circuit, to try to determine which characteristics of the original device are vital to the application, & which are not.

(7) Armed with this information, re-search the Internet.

[bob91343]

Back in the day, there were printed books detailing transistor parameters.  I have several of those and still use them occasionally.

But I don't think there is a master database available today.

An excellent source of information might be an applications engineer from the larger manufacturers.  Of course they tout their own brand but you can defuse that somewhat by talking to a few companies.  Your application needs to have large quantity promise.

[nuclearcat]

This diversion maybe sounds a bit random, but a similar thought process applies -- if there's simply not enough value in doing it, it won't be done.  We could indeed create the database of which you speak -- but it won't be trivial to do, even though all of the building blocks are known and proven (web scraping, PDF OCR and data scraping, queryable databases or APIs, etc.).  The challenge in launching such a thing, is in proving that that cost is justified by some kind of payoff (typically monetary).  Even if we can show that it wastes millions of engineer-hours per year, it's not the case that we can harness every single dollar of that time.

Tim

Yes, this is one of the most difficult tasks - making this project sustainable and demanded. (Sure if anyone need such database at all)
About sustainability, if i wont use heavy software stacks, it can work on the cheapest hosting that is not burden for me($5-$15), and the database will be updated by the community.
With copy on a github it wont die (i prefer to keep it completely open).
Still i am not entirely sure such thing will have any demand, if most of people are satisfied with current time spent on searching and existing proprietary parametric search engines on octopart/findchips/distributors. On my experience they have very high degree of errors, limited and incomplete, and there is little you can do (contribute) to fix annoying mistakes.

But it's definitely not me who will do it, since i'm located in the ass of the world with almost nonexistent financial services.