The four example instruments

Transport and protocol

Link

TCP over LAN, SCPI. The host or IP address is entered by hand on the page.

Port

5555 by default, changeable on the page

Timeout

3000 ms by default (100 to 20000 ms), for connect, read and write; 20 s for a screenshot, 10 s for waveform data

Status

a full status read every 1 s while connected

Live waveforms

2, 4, 8, 12 or 20 fetches per second (4 by default), only while the oscilloscope page is shown with its Live switch on

On the DHO924S with firmware 00.01.02, a second query on the same TCP connection gets no answer. So each status field is read on a connection of its own, with a 5 ms pause before each connection, and a waveform fetch shares one connection.

On the page

• Run, stop, single, autoset and force trigger from the toolbar; timebase and trigger level steps; edge trigger slope.
• Acquisition type, memory depth, averaging and bandwidth limit.
• Live waveforms of all four channels, with time and voltage cursors; each channel's V/div on its tile; a "Screen" view like the scope screen and a "Fit" view on one volt axis.
• Measurements, screenshots captured and previewed in the app, screenshot and waveform CSV export.
• A SCPI console that sends a command or a query as typed.

Limits

V/div

500 uV/div to 10 V/div at a 1x probe, both ends times the probe ratio; steps 1-2-5

s/div

1 ns/div to 1000 s/div; a step outside the scope's real range is rejected by the scope

Channels

1 to 4

Averages

a power of two from 2 to 65536

Memory depth

Auto, 1k, 10k, 100k, 1M, 10M, 25M, 50M

Waveform

1000 points per channel, the screen record

Not supported or not confirmed

• No discovery: the host or IP address is entered by hand.
• LAN only: there is no USB (USBTMC) path.
• The status refresh is read-heavy and reconnects for each operation, by design.
• Trigger: only the edge trigger.
• Acquire type: high resolution is read when the scope reports it, but cannot be set.
• Bandwidth limit: only off and 20 MHz.
• Waveforms: the screen record only (1000 points), not the acquisition memory.
• No hardware tests in the code.

Full page with the SCPI commands, timing and sources: docs/devices/rigol-dho924s.md. The page itself: docs/manual/oscilloscope.md.

Transport and protocol

Link

USB serial port, Modbus RTU. The port is chosen from a scan of all ports or entered by hand.

Line

9600 baud by default (1200 to 115200), 8N1, no flow control

Slave address

1 by default (1 to 247)

Timeout

400 ms by default (100 to 5000 ms), for each exchange

Polling

every 500 ms while connected; a failed poll ends the connection with an error

Every write is followed by a read of the whole status, so the page shows any value the supply clamped or normalized.

On the page

• Measured voltage, current and power, polled continuously.
• Voltage and current setpoints, OVP and OCP; the output switch.
• Memory presets M1 to M6: recall and store.
• Protection and communication state.

Limits

Voltage

30 V for the setpoint, OVP and presets

Current

10 A for the setpoint, OCP and presets

Power

300 W (30 V x 10 A) for OPP

Presets

6 slots, M1 to M6

The limits are constants in the driver, not read from the supply. A negative value is refused; a larger one is clamped to the limit.

Not supported or not confirmed

• The driver assumes the current HM310T register map.
• OPP and the decoding of the protection bits are still provisional.
• The model id is shown as a raw number, not decoded.
• No hardware tests in the code.

Full page with the registers, timing and sources: docs/devices/hanmatek-hm310t.md. The page itself: docs/manual/supplies.md.

Transport and protocol

Link

USB CDC serial port, FNIRSI's binary protocol, the one of the DPS-150

USB ID

2E3C:5740; a port scan detects the supply by it. On macOS it prefers the /dev/cu.* port. The port can also be picked by hand.

Line

9600 baud, 8N1

Timeout

1000 ms by default (200 to 5000 ms)

Polling

a state dump every 500 ms while connected; a failed poll ends the connection with an error

Other IPS3608 tools report that the front panel stays locked until the session is closed, so the app closes the session whenever the connection ends. Writes are not acknowledged by the supply; the app reads the state back after each, so the page shows any clamping.

On the page

• Output voltage, current and power, CV/CC mode and protection state.
• Voltage and current setpoints, OVP, OCP and OPP; the output switch.
• Memory presets M1 to M6: recall and store.
• Temperature, Ah and Wh metering, OTP and LVP, and the device limits.

Limits

Voltage

36 V for the setpoint, OVP and presets

Current

8.2 A for the setpoint, OCP and presets

Power

295.2 W (36 V x 8.2 A) for OPP, the factory OPP setting

Presets

6 slots, M1 to M6

The page's fields go up to the maximum voltage and current the supply reports, and never above the driver's limits. A negative value is refused; a larger one is clamped to the limit.

Not supported or not confirmed

• The CC/CV and protection codes follow the DPS-150 mapping; only the idle values (CV, no trip) have been observed on hardware.
• OTP, LVP, brightness, volume and metering are read from the supply, not set by the app.
• The telemetry frames the supply pushes on its own are not used.
• The length of the state dump on other firmware: only 139 bytes were seen.

Hardware test: hardware_round_trip, ignored by default. It needs the output off, nudges the voltage setpoint and restores it.

Full page with the frames, registers, timing and sources: docs/devices/fnirsi-ips3608.md. The page itself: docs/manual/supplies.md.

Transport and protocol

Link

USB HID, 64-byte reports. The meter is a composite device; only its HID interface carries measurements.

USB ID

2E3C:5558; the first meter with it is opened, exclusively on macOS

Stream

100 samples per second, shown as one averaged reading per 100 ms

Keepalive

once a second; 2 s without data ends the session with an error that suggests replugging the meter

On the tested meter, one request (0x81) followed by back-to-back requests froze the firmware until a power cycle. So the app never sends 0x81 and keeps at least 100 ms between any two writes, also across connections.

On the page

• Voltage, current, power, D+, D- and temperature.
• A trend of voltage, current and power as three strips over the last 30 s to 10 min.
• Energy (mWh), capacity (mAh), duration and peak current and power, added up from every 10 ms sample; reset from the page or on connect.
• A recording of every raw 10 ms sample to a CSV file (t_s, voltage_V, current_A, power_W, dp_V, dn_V, temp_C); it stops on disconnect or a stream error.

Limits

The app writes no values to the meter, so there are no value limits. Resolution as decoded: 10 uV, 10 uA, 1 mV for D+ and D-, 0.1 degree.

Not supported or not confirmed

• Only the first attached meter is used.
• Tested on one meter; its firmware version was not read.
• The protocol stays unverified for the FNB48, the FNB48S and the C1, so they are not detected.
• Totals live in the app, not on the meter, and restart on every connect.
• Byte 12 of each sample and the 0x03 report are not decoded.
• The mass storage and CDC interfaces of the meter are not used.

Hardware tests: fnb58_hardware_stream and fnb58_runtime_session, both read-only and ignored by default. On macOS, close the app first and run them one at a time.

Full page with the reports, timing and sources: docs/devices/fnirsi-fnb58.md. The page itself: docs/manual/meter.md.