RDTech UM series
 | |
| Status | |
|---|---|
| Source code | [1] |
| Connectivity | serial over Bluetooth |
| Features | measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode) |
| Website | rdtech.aliexpress.com |
What is it?
A ~$13 USB load meter; it measures various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. It can track up to 11 groups of mAh/mWh capacity data, one of which is ephemeral (and disappears after replugging the device), nine of which are persistent until cleared, and one of which whose recording is only activated above a certain current threshold (and which can be recorded in parallel with any of the other 10 data groups). It also allows graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.
Unlike most devices of this type, this one communicates through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation here), but not protocol documentation nor source code.
Note that this is specifically about the UM24C - the UM24 is the version *without* Bluetooth communication, although it's unclear whether the serial pads are still exposed and functional on that model. On the C model, the Bluetooth board is a separate layer (using an off-the-shelf serial-to-Bluetooth module) that connects to the serial pads using pogo pins.
The manufacturer has indicated that the firmware is not designed to be upgradeable and doesn't provide updates; nevertheless, the SWIM pin for the on-board STM8 chip is exposed, as are the other necessary pins for STM8 debugging. It's unclear whether the chip will allow eg. dumping, though.
The load meter can be connected either by plugging it in directly using its USB male plug end, or by connecting it using a cable and the micro-USB port on top. These are functionally equivalent; in both cases, both power and data are passed through and measured in the same way. I've not observed any difference in measurements between these two modes of operation.
It's unclear whether measurement of data lines is accurate enough to theoretically be used as a logic analyzer, but given the strange stability of the values during testing (unlike the voltage on the power lines) and the low-end STM8 chip, I suspect it's not.
Protocol
Clearer documentation (as well as a JS implementation of the protocol) are coming soon, but below are my rough notes of the protocol, that I've figured out by reverse-engineering the Android application. The device won't auto-send any data; you're expected to send 0xf0 any time you want new data, eg. on a timed loop.
All data returned by the device consists of measurements and configuration status, in 130-byte chunks. To my knowledge, it will never send any other data. All bytes below are displayed in hex format; every command is a single byte.
Commands to send
| Byte | Type | Meaning |
|---|---|---|
| 0xf0 | device control | Request new data dump; this triggers a 130-byte response |
| 0xf1 | device control | Go to next screen |
| 0xf2 | device control | Rotate screen |
| 0xf3 | device control | Switch to next data group |
| 0xf4 | device control | Clear data group |
| 0xbN | configuration | Set recording threshold to a value between 0.00 and 0.15 A (where N in the byte is 4 bits representing the value after the decimal point, eg. 0xb7 to set it to 0.07 A) |
| 0xcN | configuration | Same as 0xbN, but for when you want to set it to a value between 0.16 and 0.30 A (16 subtracted from the value behind the decimal point, eg. 0.19 A == 0xc3) |
| 0xdN | configuration | Set device backlight level; N must be between 0 and 5 (inclusive) |
| 0xeN | configuration | Set screen timeout ('screensaver'); N is in minutes and must be between 0 and 9 (inclusive), where 0 disables the screensaver |
Response format
All byte offsets are in decimal, and inclusive. All values are big-endian and unsigned.
| Offset | Length | Type | Meaning |
|---|---|---|---|
| 0 | 2 | marker | Start marker (always 0x0963) |
| 2 | 2 | measurement | Voltage (in mV, divide by 1000 to get V) |
| 4 | 2 | measurement | Amperage (in mA, divide by 1000 to get A) |
| 6 | 4 | measurement | Wattage (in mW, divide by 1000 to get W) |
| 10 | 2 | measurement | Temperature (in celsius) |
| 12 | 2 | measurement | Temperature (in fahrenheit) |
| 14 | 1 | unknown | Not used in app |
| 15 | 1 | configuration | Currently selected data group |
| 16 | 80 | measurement | Array of main capacity data groups (where the first one, group 0, is the ephemeral one) -- for each data group: 4 bytes mAh, 4 bytes mWh |
| 96 | 2 | measurement | USB data line voltage (positive) in centivolts (divide by 100 to get V) |
| 98 | 2 | measurement | USB data line voltage (negative) in centivolts (divide by 100 to get V) |
| 100 | 1 | measurement | Charging mode; this is an enum, where 0 = unknown/standard, 1 = QC2.0, and presumably 2 = QC3.0 (but I haven't verified this) |
| 101 | 1 | unknown | Not used in app |
| 102 | 4 | measurement | mAh from threshold-based recording |
| 106 | 4 | measurement | mWh from threshold-based recording |
| 110 | 2 | configuration | Currently configured threshold for recording |
| 112 | 4 | measurement | Duration of recording, in seconds since start |
| 116 | 1 | configuration | Recording active (1 if recording) |
| 117 | 1 | unknown | Not used in app |
| 118 | 2 | configuration | Current screen timeout setting |
| 120 | 2 | configuration | Current backlight setting |
| 122 | 4 | measurement | Resistance in deci-ohms (divide by 10 to get ohms) |
| 126 | 1 | unknown | |
| 127 | 1 | configuration | Current screen (same order as on device) |
| 128 | 2 | marker | Stop marker (always 0xfff1) |
Board pictures
Not great pictures, but hopefully they'll be useful.
