-
-
Home: the 4-step pipeline (read BOM, compare days, code verifies, Nemotron explains)
-
Each BOM line matched to the jlcparts catalogue by LCSC number or name + footprint
-
Alerts: 2 events, 6 code-verified substitutes, explained by NVIDIA Nemotron
Inspiration
As a first-year electronics student, I noticed the same problem again and again: a board design is finished, but one part on the bill of materials (BOM) goes out of stock or jumps in price, and finding a safe replacement means hours of datasheet comparison. Chatbots will happily suggest replacements, but they can invent part numbers or miss a spec. I wanted a tool where code makes the safety-critical decision and the AI only explains it.
What it does
- Reads a BOM CSV (KiCad / EasyEDA / JLCPCB format) and matches each line to the open jlcparts catalogue of JLCPCB/LCSC parts (LCSC number first, then part name + footprint).
- Snapshots stock and price and compares them with the next day: out of stock, low stock, price jump, missing, back in stock.
- For an affected LDO regulator, finds substitutes that pass hard checks in plain Python: same output voltage, same package, equal or better output current, max input voltage and dropout, in stock, and physically plausible catalogue data. Results are ranked cheapest first.
- NVIDIA Nemotron on Nebius Token Factory turns only those verified facts into a plain-English alert with differences, cost impact and a reminder to confirm the pinout.
How I built it
Python + Streamlit, deployed on Streamlit Community Cloud. Component data comes from jlcparts (MIT licence). The substitute checker is rule-based Python. The alert agent calls nvidia/nemotron-3-super-120b-a12b through Nebius Token Factory's OpenAI-compatible API, passing structured JSON facts, with a template fallback so the app still runs without a key. I built it with AI coding assistance (Claude); the design decisions, verification and testing are mine.
Challenges
- The free catalogue's stock field does not change day to day (0 of 1,509 parts changed over 8 days), so a true daily diff was not possible. I documented this and made the demo replay a clearly labelled simulated next day instead of faking live data.
- Catalogue parameters are messy and sometimes physically impossible (e.g. 0.012 V dropout for a 1 A LDO), so I added a rule that rejects implausible data rather than trusting it.
- Deployment: a one-character-short API key in the cloud secrets cost me time, and taught me to verify secrets by length and fingerprint, never by eye.
- Python was new to me; I came from C.
Accomplishments I'm proud of
A pipeline where the AI can't recommend a part the code hasn't verified, and an honest demo.
What I learned
Use AI where it is strong (explaining, writing for humans) and plain code where correctness matters. Verify your data source before building on it.
What's next
More part categories (MOSFETs, capacitors, MCUs), a live data source such as LCSC's official API (only the snapshot step changes), scheduled daily runs with email/Discord alerts, and a whole-BOM cost-impact summary.
