Representative results only · all C code here is synthetic · no TI code is included or displayed details

Results are representative and informational only. Under Texas Instruments' C2000 software license terms, real TI SDK source code is confidential and licensed for internal use only, so no TI code is included, displayed, processed, or emitted here. All C code on this site is synthetic, written for this demo, with invented names and values that resemble typical power-converter firmware. The generated headers compile against this demo's sample firmware in CI; the "legacy" files used for the audit are illustrative and not guaranteed to compile on any target. Product ratings come from public IntelliPower data sheets; all circuit values and gains are invented. Independent demo, not affiliated with or endorsed by AMETEK, IntelliPower, or Texas Instruments. TI, C2000, and Code Composer Studio are trademarks of Texas Instruments.

Independent demo · AMETEK IntelliPower AI Automation Intern

Change a requirement. See what breaks.

Change hardware and see which firmware constants fail. Compare inductor candidates against real core data, with calculations and source evidence beside each result.

Runs in your browser · No install or account · Nothing uploaded

Start here · about a minute

Follow one hardware change from failure to repair.

  1. Try the alternate board. Open Firmware, then apply Rev B to the 1500 VA product.
  2. See why it fails. The sensor cannot cover the required protection limit.
  3. Try a repair. Recheck the result and inspect the generated C code.
Open the walkthrough →
Firmware · Initiative 2

Generate checked firmware constants.

Trace configuration constants to product ratings and hardware assumptions. Inspect the generated C header and its changes from baseline.

Explore Firmware →

AC input→Rectifier / PFC→DC bus→Inverter→AC output
A failed modeled check blocks C code generation.
  • 3 real IntelliPower data sheets, cited per value
  • 3 of 33 legacy constants contradict the data sheet
  • 0 values written when any gate fails
Magnetics · Initiative 1

Find a starting point for an inductor.

Compare core size, inductance at peak current, and winding fit. Review the checks alongside each design.

Explore Magnetics →

Try this Change peak current and select Size it, or inspect a flagged past design.
  • 12 synthetic drawings, read back from PDF
  • 10 real cores with cited data
  • checks agree with the blind key on 12 of 12

First-pass screening. Core loss, AC winding loss, temperature rise, and engineering validation remain outside this model.

Carry the requirement into Magnetics.

In Firmware, select PFC in Power flow and follow its inductor sizing link. Magnetics opens with that estimated requirement filled in, ready to compare against real cores.

The handoff is a first-pass estimate; the sizing method and assumptions remain visible in each tool.

What supports the results?

Built with AI agents under my direction. Calculations and gates are deterministic; AI drafts legacy-constant classifications for human review. See the measured AI results →

RealIntelliPower product data sheets; Magnetics Inc. and Ferroxcube core data; the posting.
SyntheticThe legacy firmware corpus, the magnetics drawings, and their blind answer keys.
AssumedControl board, design choices, inductor ripple, processor pairing. Tagged in the tools; listed in How it works.

Not claimed: power-electronics design, loop tuning, finished magnetics designs, EMI, or certification. Engineers own those; these tools carry and check their numbers.

Why I built this: the posting, assumptions, and week-one checks
Screenshot of the AI Automation Intern posting on AMETEK's careers site: about us, job summary with two initiatives (magnetics design automation; firmware modification and calibration automation), and key responsibilities
The posting on AMETEK's careers site, posted Oct 15, 2026, captured Oct 16, 2026 (jobs.ametek.com/job/Orange-AI-Automation-Intern-CA-92865/1420689600). Scroll inside the box, or click for full size.

The posting describes six problems: magnetics design iterations, hand-edited firmware constants, specs that aren't machine-usable, provable validation, undocumented process, and responsible AI adoption. This demo addresses the first two (magnetics: the data step and first-pass sizing; firmware constants: end to end) and supports the next four.

#AssumptionWhy I think soConfidenceHow to check
A1Calibration and config constants live in C source (#defines / const tables)The posting says soHighRead one product's source
A2Many constants derive from data sheet ratingsData sheet fields map cleanly to limits (1500 VA ÷ 120 V × 1.20 = 15 A)MediumTrace ten constants to their origin
A3Alternate-component substitutions change sense gainsEngineering postings: "qualify new, or alternate components"MediumAsk how the last substitution was handled
A4The processor is a TI C2000 partPosting asks for TI chipsets; public site says DSP firmwareMediumLook at a board
A5Specs are not machine-readable todayAll three data sheets checked contain an internal inconsistencyMediumSee the spec source of truth
A6Some calibration is per unit at a test stationThe phrase "calibration gains"LowAsk production test
A7Past magnetics designs live in drawings and spreadsheets, not a databaseThe posting asks for a tool trained on "historical designs"MediumAsk for ten recent inductor drawings

AI practiceLegacy auditReview reportsTim Otholt · backstory