Connecting GitHub Copilot to My Oscilloscope

Firmware can look perfectly reasonable in the editor. That does not tell you whether the pulse on the pin is the right width or what your I2C bus is actually sending.

The oscilloscope is new to me, and I’m still learning what it can do. Building and extending the MCP server has been a practical way to explore its capabilities while bringing it into my agent development workflow. Not heard about MCP see the excellent MCP for Beginners course.

With rigol-mcp, GitHub Copilot can query the scope directly and use its measurements while I work on the code. My test setup is a Rigol DHO814 and a Raspberry Pi Pico 2 W, with Copilot in VS Code.

First, Credit Where It Is Due

This project builds on erebusnz/rigol-mcp, originally created by Stig Manning. The original MIT licence and copyright notice are preserved.

I’ve since done considerable work to expand the server, particularly for the DHO814: coordinated acquisition, protocol decoding, waveform analysis, statistics, recording/replay, and verification that the scope actually applied the requested settings.

What the Connection Looks Like

GitHub Copilot connects to the MCP server from VS Code. The server runs in a container and talks to the Rigol over Ethernet. On the bench, the scope probes measure signals generated by the Pico. MCP gives the assistant tools it can discover and call. The server translates those calls into SCPI, the instrument’s command interface. Other MCP clients supporting stdio can use it too.

For example:

Save the scope setup. Configure CH1 and CH2 for two 3.3 V signals at 1 MHz, capture them together, and measure their phase difference. Ask before restoring the saved setup.

The response comes from instrument measurements rather than an estimate based on a screenshot. Lesson learned, probe grounding springs are your friend.

The Skill That Guides the Agent

The included rigol-scope skill guides how Copilot uses the MCP tools. Copilot loads it for Rigol tasks, turning a bench question into a repeatable workflow: identify the scope, check settings, save the setup, configure, capture, and measure.

For example:

Check whether CH1 has a 1 MHz PWM signal with a 25% duty cycle. Save the setup first, and ask before restoring it.

GitHub Copilot using a LLM can compare the measured frequency and high-pulse width against the expected 1 MHz and 250 ns. The skill favours numeric readings over screenshots, keeps scope calls sequential, and checks that settings took effect. Invalid readings prompt investigation, not invented results.

MCP provides access; the skill provides guidance. Asking before restoration keeps that decision with me.

A Pico Makes a Useful Test Source

I used the Pico 2 W to generate known signals on GP16 and GP18, connected to scope channels 1 and 2. Both probes were set to 10X, with short ground connections. The 12-case PWM sweep covered duty cycles, narrow pulses, divider boundaries, and phase offsets. Integer clock dividers removed the cycle-length variation that fractional division can introduce, without pretending the whole measurement system was jitter-free.

Results included a 13.35 ns pulse and a nominal 180-degree offset measured at 179.64 degrees with a 500 ns delay.

One detail mattered: with the selected integer timing, the requested 90-degree offset at 1 MHz became an actual target of 91.2 degrees. The scope measured 91.08 degrees. Comparing against the requested label alone would have made a good result look wrong.

The Scope Also Helped Debug the Server

I used GitHub Copilot with GPT-5.6 Sol and GPT-6 Astra to write my extensions to the MCP server, then test and debug them using the DHO814 through MCP and dev time was around 30 minutes. Testing on the scope caught problems the mocked instrument had missed.

For example, the DHO814 sometimes ignored horizontal-scale changes while acquisition was stopped. The timing tool now briefly runs acquisition to apply the settings, stops it again, and checks the readback.

Live tests also exposed misleading analysis: overshoot and undershoot exaggerated the reported voltage swing, and sampling differences made static PWM look modulated. The analysis now separates settled logic levels from overshoot and undershoot, and reports confidence and sample counts before calling duty-cycle variation modulation.

Reading I2C, SPI, and UART

Next, I generated protocol traffic on the Pico and tested the scope’s decoders through MCP:

• UART at 115200 baud, decoding “RIGOL MCP 55 AA” with CR/LF.
• I2C, decoding a write to 7-bit address 0x50, data 0xA5, and a low ACK bit.
• SPI at 100 kHz, mode 0, decoding MOSI 0xA5 using timeout framing instead of a separate chip-select probe.

Thresholds mattered as much as source selection. The decoder tool now accepts explicit voltage thresholds. A useful request is:

Configure I2C decoding with SCL on CH1 and SDA on CH2, both at a 1.65 V threshold. Trigger on START, capture a complete transaction, and return the decoded address and data.

The Pico I2C generator is a scope-only fixture with push-pull outputs, not something to attach to a shared bus. Real I2C needs open-drain signalling and pull-ups.

Measurements Before Screenshots

Screenshots help with display questions: zoom windows, overlays, and cursor positions. For frequency or decoded bytes, structured data is more useful. Saved captures keep the large waveform arrays out of the conversation while giving the assistant a summary and a file path.

Trying It on Your Bench

You’ll need a supported Rigol scope reachable over Ethernet and an MCP client. The server runs with Docker on Windows, Linux, and macOS, or with Apple Container on macOS. The DHO814 is the primary hardware-tested model, but the MCP server uses the Rigol DHO800/900 series API, so I'd expect other models in these families to work too.

Follow the README, choose one runtime, set RIGOL_IP to your scope’s address, and start the rigol-scope server in your client. No host Python installation is needed.

Check probe attenuation, voltage limits, and grounding. Scope ground clips are not floating inputs. Use one server per scope, save the setup before broad changes, and verify restoration afterwards. An assistant cannot check your physical wiring for you.

What Has Actually Been Tested?

Live testing also exercised statistics, cursors, search, mask counters, recording/replay, meters, math/reference operations, and RAW transfers. The acceptance report records the limits of that work.

Not all 897 catalog query/write forms have been hardware-tested. CAN and parallel decoding, deliberate network failures, and disruptive operations remain outside this acceptance run. Exercising a meter tool is not a calibration certificate.

Back to the Firmware

For me, the useful part is keeping a hardware question close to the code that caused it. Generate a signal, capture it, and make the next change with evidence from the pin, rather than just a discussion of what the firmware ought to do.

The code is on GitHub. Questions or results from another Rigol model? Let me know in the comments, or open an issue with the model and firmware version.

Cheers Dave