Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameter aliasing when importing from provider #767

Open
Verox- opened this issue Nov 11, 2024 · 0 comments
Open

Parameter aliasing when importing from provider #767

Verox- opened this issue Nov 11, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Verox-
Copy link

Verox- commented Nov 11, 2024

Is your feature request related to a problem? Please describe.
When importing parts from different providers the parameters created from the import can have wildly different names for the same property. This makes parametric search significantly less useful without a lot of manual fix-up during the import process.

Take, for example, the Vishay IRF610PBF imported from Octopart, and the ONSEMI BS170 imported from TME. Being MOSFETs they both have a Drain-Source Voltage property, however, on the BS170's parameters page it is refered to as Drain-source voltage, and on the IRF610PBF it is refered to as Drain to Source Voltage (Vdss). Now, if I wanted to search for a MOSFET with a Vdss of >= 60V I wouldn't be able to reliabily do so, as the parameter to search on for each part is different for the same property.

This becomes a compounding problem the more information providers you use, and the larger the part database becomes.

Describe the solution you'd like
A method of defining parameter transforms or aliases would resolve this issue. During configuration you could create a parameter Drain-Source (Vdss) and configure it as normal, then, as an additional step, define any parameter named Drain-source voltage when importing from TME, or named Drain to Source Voltage (Vdss) when importing from Octopart should instead be put in the Drain-Source (Vdss) parameter.

This has potential for improvement; some providers will provide (for example) Maximum operating temperature and Typical Operating Temperature as a part of an operating temperature range, or some may provide them as a discrete values. This solution could be implemented to permit the transformation of the discrete values in to the Typ. and Max. fields as part of a single parameter. In a similar vein, this would permit consistent grouping of parameters across providers.

Describe alternatives you've considered
A similar functionality exists as Alternative names which can be added to certain categories. I don't believe this would work as you would still need to manually fixup properties. It'd also reduce simple consistency on the parameters page.

Another alternative is to simply use one information provider. This isn't really practical as many info providers do not have a complete list of components, or cost LOTS of money.

@Verox- Verox- added the enhancement New feature or request label Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant