search

edatasheets / digital-datasheets

Apache License 2.0
11 stars 5 forks source link

Tolerances expressed as percentages #87

Open mawildoer opened 6 months ago

mawildoer commented 6 months ago

Hi folks! We've recently created atopile to design circuit boards with code.

Someone shared your great work with us and we were thinking it might be a great schema to query our component database as well. So far, the most important generics are the jelly-bean passives like resistors and caps.

One problem we've run into (and solved) was the discontinuity, poor clarity and difficulty querying passives with percentage tolerances:

What are your thoughts on value + tolerance vs. ranged values?

rsnancollas commented 6 months ago

Hey Matt,

This is a good question. Our current approach has been using the "value" struct: https://github.com/edatasheets/digital-datasheets/blob/main/part-spec/common/values.json#L18.

We specify "min", "typ", and "max", which would give you the ability to define a resistor or capacitor (say a 100ohm resistor with a 1% tolerance as: min: 99, typ: 100, max: 101), but that does add a bit more lift for vendors writing datasheets.

We could consider having the spec use a percentage instead, but that does mean there are more ways of representing a value within the spec, which is a bit of a disadvantage.

What do you think about this value spec - would it work for your usecase?

rsnancollas commented 6 months ago

Actually, I'm thinking that maybe you meant the tolerance field on passives (resistor, capacitor, inductor, etc.)?

Perhaps the correct answer is that we should leverage the "values" field for the range, but still include the tolerance as a field.

Since I'm expecting most of these datasheets will be generated, that could be part of the generation for passives.

mawildoer commented 6 months ago

Sorry for the delay!

That makes sense in a lot of ways - I guess for you folks having redundant information (eg. tolerance multiple times) isn't a big problem, while we're attempting to strip our queries down to the bare minimum amount of information required.

Is there some guidance on where we can pare down these queries using this schema to reduce the fields we send? In that case, we just need to assume that servers/APIs that can be queried can accept partially populated queries. That said they'd need to respond with complete structures to maintain complete compatibility for clients expecting the data. It'd be niceif there were a tool to complete partial queries to make it easier to fill in the blanks here!

rsnancollas commented 5 months ago

Hmm so you're thinking if you wanted to send a query like: "a resistor between 12K and 13K" and you were querying a database filled of digital datasheets using this schema, you'd want a tool that would maybe generate queries for both the range of resistor values (if given) and the typical value + tolerance?

mawildoer commented 5 months ago

I'm not sure I'm quite following, but perhaps an illustration is valuable here:

For that query of a 12kΩ to 13kΩ resistor: