AI firmware for the DL3031 DC electronic load

CH1What it does today

None of the functions in Rigol's documentation for the load is missing now: each is done, done within the caps below, or built and waiting for a bench test (see Not done yet).

The caps. The first release limits the load to 3 A, 60 W and 60 V in software and turns the input off above 50 °C, inside the hardware's 150 V, 60 A and 350 W: what our bench supply can drive and so prove. They come up one step at a time, each step tested first.

New compared with Rigol's firmware

• Updates from a computer. A new build is sent over the LAN or USB and installed, or run from RAM to try it first; a power cycle brings back the installed one.
• A waveform history. Every reading is kept at seven resolutions, so changing the Roll window shows the whole history at once instead of starting the trace again.
• Fast-capture numbers over SCPI. Ripple, edge times and recovery time of the last capture, readable by a computer.
• Von in CR that works. The stock firmware's :RESistance:VON command does nothing; in the AI firmware it sets the CR page's own Von.
• Fast screen reads. A computer reads the screen as a BMP over the LAN in about 0.8 s.
• A live readings page in the web interface, next to the settings pages.
• More safety. The input goes off when the controlling computer goes quiet for 10 s, every reading is checked against the trips, and a refused key says why on screen.
• A clearer screen. Anti-aliased text, a real Ω, and each function's soft keys with their live values.

Beyond Rigol's firmware

None of these is in Rigol's own DL3000 firmware. Each one has been run on our DL3031, and they come with the next firmware file.

CH2Measured on the bench

The release caps, 3 A and 60 W, on 13 October: in CC from 12 V, 1.0, 1.5, 2.0, 2.5 and 3.0 A read 1.0003, 1.4997, 2.0001, 2.5006 and 2.9998 A (the supply 0.9979 to 2.9983 A); in CR, 6 Ω and 4 Ω from 12 V drew 1.9896 and 2.9807 A; in CP from 21 V, 60 W held 59.99 W (2.8672 A, the supply 2.8667 A) for two minutes while the two temperature sensors went from 28.9 to 31.4 °C. 3.01 A, 3.9 Ω and 61 W were refused.

These runs were made on our DL3031 against a Rigol DP2031 bench supply at 12 V, with the supply's own current limit as a second guard (0.5 A, and 0.2 A for CV). The two instruments' readings are compared at every step. Neither is a calibrated reference, so these show that each mode does what it is set to, not the load's accuracy.

• CP follows the voltage. At 3 W with the supply lowered to 10 V, the load drew 0.3022 A at 9.983 V (3.02 W).
• Transient. Continuous at 10 kHz between 0.1 A and 0.4 A: a mean of 0.2505–0.2509 A at 50 % duty and 0.1751–0.1757 A at 25 % (the supply 0.244–0.250 A and 0.171–0.175 A).
• Von. With Von at 13 V, above the 12 V supply, the input waits and draws nothing; at 11 V it sinks 0.2012 A; with the latch on it stays on when Von goes back to 13 V.
• List. 0.1, 0.3 and 0.2 A for 4 s each, two passes: 0.1006–0.1007, 0.3012 and 0.2013–0.2014 A on the load (the supply 0.098, 0.298–0.301 and 0.197–0.199 A). The input went off at the end, and a list stopped part-way resumed in the step where it stopped.
• Battery test. Stopped by time after 20.0 s with 1.612 mAh and 0.0193 Wh; by capacity at 1.003 mAh after 12.8 s; by voltage, with V_Stop at 11 V, when the supply was lowered to 10.8 V.
• OCP and OPP tests. The supply, current-limited to 0.3 A, stood in for the device under test: the OCP ramp found its limit at 0.34 A and the OPP ramp at 4.0 W. A C_Min of 0.36 A made the same run fail as "lower limit exceeded", and with nothing to trip, a 6 s time limit ended a run as a timeout.
• Limits. A V_Limit of 5 V refused to turn the input on at 12 V; at 13 V the input went off as the supply was raised past it (read 13.141 V). A C_Limit of 0.08 A turned off a 0.1 A sink.
• Factory test. In CC at 0.30 A with a window of 0.25 A to 0.35 A, the test passed at 0.301 A. With Min raised to 0.32 A it failed, and the input stayed on.
• CC+CV. Set to 10 V, with the supply at its 0.2 A current limit, the load held 9.992 V at 0.202 A.
• Short circuit. From the supply's 12 V, the short held 2.9999 A at 11.93 V. With the supply limited to 2 A, the supply went into current limit and the input read 0.018 V. CC, CR and CV each came back to their own mode after the short.
• Von in CR. With the CR page's Von at 13 V, above the 12 V supply, the input waited and drew nothing; at 11 V it drew 0.2009 A.
• A silent host. When a computer turns the input on and then stops talking, the AI firmware turns it off after 10 s: the current was gone between 10 and 11 s.

Videos

These are screen captures from the load's own framebuffer over the LAN, at about 1.6 frames a second, shown at real time. The panel was driven through its keys by AI (Claude) over the LAN, and the bench supply was set up over SCPI before each take. The readings are real. Nothing is drawn on a PC.

Screens

The load's own 480 × 272 screen, read over the LAN and doubled without smoothing; real current from the bench supply. Click a screen to enlarge it.

CH3Waveforms

The waveform page plots current, voltage, resistance or power. In Roll the window runs from 8 s to 80 h, and the firmware keeps every reading at several resolutions, so a new window shows its whole history at once. Print saves the screen as a BMP and the trace as CSV on a USB stick in the front port, Record logs a run to CSV, and Play Back reads a file back onto the page. The trace's 400 points and the screen are also readable over SCPI, and Store and Recall lists, reads and deletes the files on the stick.

With the continuous transient selected, the fast capture takes 400 samples of current or voltage at 4 µs to about 1 ms per sample (250 kSPS down to 0.98 kSPS, windows of 1.6 to 409.6 ms) and measures ripple, edges and recovery time on them. On our unit it captured a 1 kHz transient at 8 µs per sample, 257 captures out of 260. On the supply's 12 V the trace moved between two codes 3.7 mV apart: the supply's ripple is below one step of the capture on its 150 V range.

CH4Remote control

The same SCPI commands work over USB (USBTMC), a raw socket on TCP port 5555 and VXI-11. pyvisa opened the load as TCPIP::<ip>::INSTR with both its own backend and a system VISA library, and read *IDN?. The load announces itself over mDNS and answers the LXI identification.

Its web interface on port 80 has the instrument, network status, network settings and password pages, and a read-only page with the live voltage, current, power and resistance. Every setting made there goes through the same checks as a SCPI command. A host can also press any front-panel key with :SYSTem:KEY, and read the screen over the LAN in about 0.8 s with the screenshot query (a 391,736-byte BMP).

How it stays safe

• The input starts off. The firmware turns it off as soon as the measurement board is reachable at boot, and again on every fault, watchdog reset, hand-over to a new image and update restart.
• Trips on every reading. Above 60 V, 3.15 A or 63 W (5 % over the caps), above 50 °C, on a protection latch, a reverse connection, a link error or a stale reading, the input goes off.
• One gate to the hardware. Every frame to the measurement board passes one check that lets through only what the current mode and the caps allow.
• Nothing is overwritten. The firmware reads the unit's factory calibration from the NAND and never writes it. The one byte it writes in the EEPROM is the update request, after the new update file on the stick has been checked.
• Saving to the unit's memory stays off. Power-on Last, the custom identification string and Disk C would save to the unit's own flash or EEPROM, where the factory calibration also lives. Those writes are built and switched off until we switch them on deliberately, and each write path can reach only its own records, by construction.
• RAM first. Each new build runs from RAM, and is tested there, before it is installed.

Installing it, and going back

The first public release opens after a legal review, with the date announced here: one small file (about 1.3 MB) for a USB stick. Rigol's boot loader stays on the unit as it is and installs it the way it installs a Rigol update:

1. Copy the file, DL3000Update.GEL, to the top folder of a FAT32 USB stick, keeping its name as it is.
2. With the load switched off, plug the stick into the front USB port, then switch the load on and press Help while the logo shows.
3. The boot loader installs it. The screen stays dark for about two minutes: don't switch the load off. It then starts the AI firmware.

Going back is the same three steps with Rigol's own firmware file for your model, which Rigol publishes on its DL3000 product page under Software & Firmware; we don't host it. Once the AI firmware is on, later versions can also be sent from a computer over USB or the LAN: it writes the new file over the one on the stick in the load, checks it, and restarts into the boot loader. So keep Rigol's file on a second stick.

The AI firmware is ours from the first instruction; Rigol's boot loader on the unit installs it. So far it has been tested on our DL3031 only.

The hardware

The DL3031 is Rigol's single-channel DC electronic load. Its controller is a small ARM system, and everything analog sits on a measurement board with its own FPGA, reached over one SPI link.

The AI firmware replaces all of it with a single no_std Rust image that runs one polled loop. It shares its screen look and some of its drawing and SCPI code with the NovaOS instruments. Every driver in it is ours: the LCD controller, the front panel's 3 Mbaud link (keys, knob and LEDs), the measurement board, a read-only NAND reader for the calibration, USB device and host, and Ethernet with the smoltcp TCP/IP stack.

The measurement board's FPGA

Everything the load measures and regulates passes through an FPGA on the measurement board. It runs the ADC that reads voltage and current, one mains cycle per reading, and the 400-sample fast capture. It sets the current and voltage setpoints and the protection thresholds, reports the protection trips, times the transients and the lists, and switches the relays, the Vmon and Imon outputs and the fan.

The part is most likely a Xilinx Spartan-6 XC6SLX9. We have not read the chip's ID code on our own board yet.

The AI firmware talks to the FPGA over its SPI link, in the frames the board expects, and never changes it. It loads nothing into the FPGA and writes nothing to wherever the FPGA's configuration is stored.

Our own FPGA design

We are studying our own FPGA design for this board, which keeps the same link to the AI firmware. These are possibilities, each limited by the board's own parts:

• Deeper captures with triggers. Thousands of samples instead of 400, within the FPGA's block RAM, with a pre-trigger and triggers on a voltage or current level, a transient edge or a list step.
• Continuous streaming of voltage and current to a computer, at many thousands of readings a second. The one ADC has to switch between them, and that sets the limit.
• A choice of integration time and filter, from under a millisecond to many mains cycles, trading speed against noise.
• Longer lists with finer step timing, and arbitrary current profiles played from a table, as fast as the analog current loop can follow.
• A sine on top of a DC current, with the FPGA measuring the response of the supply under test: its output impedance across frequency.
• Tests timed in hardware: OCP and OPP ramps in microsecond steps instead of 20 ms steps, with the trip point caught within one ADC sample.

It cannot change the power stage and its limits, how fast the analog current and voltage loops respond, or the one ADC that voltage and current share. Any such design would first be loaded over JTAG into the FPGA's volatile memory only, so switching the load off and on brings back the original. Nothing would be written to the board until the design is proven. None of this is scheduled.

Not done yet

• Saving to the unit's own memory: power-on Last, the custom identification string, and saving and deleting on Disk C. They are built and switched off for now, because the flash and EEPROM also hold the factory calibration. Setups go on a USB stick in the meantime.
• GPIB through Rigol's USB-GPIB converter: written, not yet tried, as we don't have one.
• A full-scale short, and anything past 3 A or 60 W. The caps come up step by step, each step tested first.
• Bench checks still waiting for a scope or a cable: the digital I/O pins, remote sense, the Vmon and Imon outputs, and RS-232. Their code is in.

Notes from the bring-up

• The panel is upside down. The 480 × 272 panel is mounted rotated 180 degrees relative to the LCD controller's scan, so the firmware draws every frame rotated to match.
• No debug cable needed. A fault paints its type, the program counter and the fault address on the panel; the firmware's own watchdog resets a hung image, and the next boot logs how the previous run ended. Bring-up runs with no JTAG or serial cable attached.
• Readings over whole mains cycles. Each reading is the mean of 20 records, one mains cycle each: 336 ms at 60 Hz, 400 ms at 50 Hz. A new one comes every 50 ms, and a level step shows at 90 % in about 0.55 s.