Verify SPICE simulations against a real oscilloscope
I have been experimenting with using Claude Code for hardware development over the past few weeks. Task: I have been experimenting with using Claude Code for hardware development over the past few weeks. I looked at some projects that use Claude similarly to how one would in software development: Write a prompt in natural language, let Claude create a circuit. I found it somewhat tricky to express what I want to build in plain English. It worked fine for trivial circuits but became difficult for more complex designs. I also realized that Claude Code really shines when it can get immediate feedback. So I tried a different approach: give Claude access to my oscilloscope and a SPICE simulator. This has become extremely valuable for validating SPICE circuits and models, embedded programming, and data analysis. In particular the data analysis had been very tedious before: normalizing the time axis, aligning data, and so on. Usually I would just eyeball it. Below is a deliberately simple demo showcasing my setup and workflow. The circuit and MCU are trivial. The point is to illustrate the approach, which scales well to much more complex circuits and real embedded projects. A few lessons learned: Oscilloscope Claude doesn't see your physical setup. Don't let it guess what is connected where. Make sure Claude never gets stale measurement data. Don't dump raw data into Claude's context. Save it to a file and let Claude interact with it indirectly. Microcontroller Give Claude a pinout/pinmux map explicitly. Prepare a Makefile that exposes functions like build, flash, ping, and erase, and encourage Claude to rely on it. Claude should not construct these commands on the fly. Repos lecroy-mcp: MCP server for LeCroy oscilloscopes spicelib-mcp: MCP server wrapping spicelib rc-filter-demo-files: the demo setup from the video; tools: Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: Claude cannot see the physical setup, so users must explicitly provide pinout maps and avoid letting it guess connections. Raw measurement data must not be dumped into the context; it should be saved to files for indirect interaction. The source does not state specific operational costs or integration constraints beyond the need for MCP servers (lecroy-mcp, spicelib-mcp) and a prepared Makefile..
Tools
Published on Agent Work Atlas:
Overview
I have been experimenting with using Claude Code for hardware development over the past few weeks.
Workflow
I have been experimenting with using Claude Code for hardware development over the past few weeks. I looked at some projects that use Claude similarly to how one would in software development: Write a prompt in natural language, let Claude create a circuit. I found it somewhat tricky to express what I want to build in plain English. It worked fine for trivial circuits but became difficult for more complex designs. I also realized that Claude Code really shines when it can get immediate feedback. So I tried a different approach: give Claude access to my oscilloscope and a SPICE simulator. This has become extremely valuable for validating SPICE circuits and models, embedded programming, and data analysis. In particular the data analysis had been very tedious before: normalizing the time axis, aligning data, and so on. Usually I would just eyeball it. Below is a deliberately simple demo showcasing my setup and workflow. The circuit and MCU are trivial. The point is to illustrate the approach, which scales well to much more complex circuits and real embedded projects. A few lessons learned: Oscilloscope Claude doesn't see your physical setup. Don't let it guess what is connected where. Make sure Claude never gets stale measurement data. Don't dump raw data into Claude's context. Save it to a file and let Claude interact with it indirectly. Microcontroller Give Claude a pinout/pinmux map explicitly. Prepare a Makefile that exposes functions like build, flash, ping, and erase, and encourage Claude to rely on it. Claude should not construct these commands on the fly. Repos lecroy-mcp: MCP server for LeCroy oscilloscopes spicelib-mcp: MCP server wrapping spicelib rc-filter-demo-files: the demo setup from the video
Reported result
The author reports that this approach is extremely valuable for validating SPICE circuits, embedded programming, and tedious data analysis tasks like time-axis normalization. However, no specific quantitative metrics or measured outcomes are provided in the source. The author notes that the method scales well to complex circuits, but this remains a qualitative observation without empirical data.
Human role
The original post does not say how a person stayed involved.
Limitations
Claude cannot see the physical setup, so users must explicitly provide pinout maps and avoid letting it guess connections. Raw measurement data must not be dumped into the context; it should be saved to files for indirect interaction. The source does not state specific operational costs or integration constraints beyond the need for MCP servers (lecroy-mcp, spicelib-mcp) and a prepared Makefile.
Try it
I want to set up a hardware validation workflow using Claude Code. I have a [replaceable: specific circuit design] and access to a [replaceable: oscilloscope model] and [replaceable: SPICE simulator]. Please use the lecroy-mcp and spicelib-mcp servers. First, save any measurement data to a local file named [replaceable: filename.csv] instead of pasting it into the chat. I will provide a pinout map at [replaceable: path/to/pinout.md] and a Makefile with targets for build, flash, and ping. Do not construct these commands yourself; rely on the Makefile. Start by running a dry run on a trivial RC filter circuit to verify the data analysis pipeline for time-axis normalization. Show me the intermediate results and ask for my confirmation before proceeding to any complex embedded programming tasks or flashing the MCU. If any input files are missing, ask me for the specific path or content before attempting to guess.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.