How I gave my old test box a second life with a browser GUI

Nov 06, 2026 Last reply: 11 hours ago 3 Replies

First reply

WrenCopper_1950

I did something similar last year with mine, except I stopped at a Python script instead of a full web page. My goal was just using it as a cheap signal source for testing an amplifier I was repairing, so I never needed the scope side at all. The driver thing matches what I saw…

Read the full reply

When the box I use on the bench stopped getting software updates, I figured I'd either live with the old client or sell it. Instead I spent a couple of weekends writing my own bitstream for the FPGA inside it and building a web page to drive it. Turns out Chrome can talk to the USB device directly, so the whole thing runs from a single HTML file with nothing installed. The part nobody warns you about is the drivers. If the vendor's tools are installed, Windows grabs the device before the browser does and you get nothing in the USB picker. I uninstalled the old client, replugged, and it showed up straight away.



Practical tips from the process: keep your HDL changes small and re-synthesize often, becuase a full rebuild after a big edit is a miserable way to find a typo. And start with just the scope channels working before you touch the generator or supplies. Getting one thing on screen makes the rest fall into place much faster than trying to bring it all up in one go.


I did something similar last year with mine, except I stopped at a Python script instead of a full web page. My goal was just using it as a cheap signal source for testing an amplifier I was repairing, so I never needed the scope side at all. The driver thing matches what I saw on Linux too. I had to add a udev rule before anything except the vendor software could open the device, and it took me an embarrassing evening of reading forum threads to figure that out.

Your suggestion about starting with one channel and building out is exactly how it went for me, just by accident. I got the waveform generator working first because that was all I needed, and when I later wanted to add a simple voltmeter readout it was easy because the structure was already there.

The one thing I'd add is that I keep the vendor software on a seprate old laptop that never touches the hardware. I use it for the calibration routines and firmware updates, then do everything else with my own setup. Some of the calibration data lives in the device and I did not want to risk writing garbage into it, so I let the official tool handle anything that writes to persistent storage.

Ran into a fun quirk when I tried the browser route on my own bench gear last winter. The bulk transfers would stall out after a few seconds untill I dropped the packet size way down. Turns out asking for more than 16 KB per transfer was tripping somethig in the USB stack, and once I capped it everything ran clean for hours. No idea if that hits every chipset but it's the first thing I'd check if the stream stutters. Also worth keeping a serial console open on the side while you debug, watching the raw bytes scroll by caught a framing bug for me that the web page was happily hiding.

I keep every synthesized bitstream in a dated folder next to the exact source that produced it, wich came out of losing a known good build to a careless edit early on. Rolling back to the old file and diffing the two versions of the source found the culprit in a couple of minutes, which beat re-reading everything line by line. Curious whether you keep your constraint file under version control as well, because mine had drifted from the actual board wiring and I chased a phantom connection bug for a whole afternoon before I thought to check it.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required