Difference between revisions of "RDTech UM series"

From sigrok
Jump to navigation Jump to search
(Set status to the standard "planned" (as in: not yet supported, but we want to see it being supported).)
(Add UM25C/UM34C information)
Line 1: Line 1:
{{Infobox multimeter
{{Infobox multimeter
| image              = [[File:UM24C_display.jpg|180px]]
| image              = [[File:UM24C_display.jpg|180px]]
| name                = RDTech UM24C
| name                = RDTech UM24C/UM25C/UM34C
| status              = planned
| status              = planned
| connectivity        = serial over Bluetooth
| connectivity        = serial over Bluetooth
Line 21: Line 21:


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.
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.
[TODO: Abstract introduction, as most of the above information also applies to the UM25C and UM34C, but list their differences.]


== Protocol ==
== 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.
1-byte commands are sent to the device, and in the case of 0xf0, the device responds with a 130-byte data dump of the current device status. All other commands return no acknowledgement.


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.
Each device (UM24C, UM25C, UM34C) has a similar command and response format, but the commands and responses vary slightly by device type.  These variations are documented below. Unfortunately this means you will need to know what type of device you are communicating with to take full advantage of it.


=== Commands to send ===
=== Commands to send ===


Multiple commands may be sent at once; e.g. you could set the recording threshold to 0.28 A and rotate the screen by sending 0xccf2 immediately.  An exception appears to be requesting the data dump; it doesn't seem to return the 130-byte response unless you wait a bit after sending other commands.
Multiple commands may be sent at once; e.g. you could set the recording threshold to 0.28 A and rotate the screen by sending 0xccf2 immediately.  An exception appears to be requesting the data dump; it doesn't seem to return the 130-byte response unless you wait a bit (approximately 0.2 seconds) after sending other commands.


{| class="wikitable"
{| class="wikitable"
!Byte !! Type !! Meaning
!Device !! Byte !! Type !! Meaning
|-----------------------------------
|-----------------------------------
| 0xf0 || device control || Request new data dump; this triggers a 130-byte response
| UM24C/UM25C/UM34C || 0xf0 || device control || Request new data dump; this triggers a 130-byte response
|----
| UM24C/UM25C/UM34C || 0xf1 || device control || Go to next screen
|----
| UM24C/UM25C/UM34C || 0xf2 || device control || Rotate screen
|----
|----
| 0xf1 || device control || Go to next screen
| UM24C || 0xf3 || device control || Switch to next data group
|----
|----
| 0xf2 || device control || Rotate screen
| UM25C/UM34C || 0xf3 || device control || Go to the previous screen
|----
|----
| 0xf3 || device control || Switch to next data group
| UM24C/UM25C/UM34C || 0xf4 || device control || Clear data group
|----
|----
| 0xf4 || device control || Clear data group
| UM25C/UM34C || 0xa0 - 0xa9 || device control || Set the selected data group (0-9)
|----
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.30 A (inclusive); add the value after the decimal point to 0xb0 (0.00 is 0xb0, 0.30 is 0xce)
| UM24C/UM25C/UM34C || 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.30 A (inclusive); add the value after the decimal point to 0xb0 (0.00 is 0xb0, 0.30 is 0xce)
|----
|----
| 0xd0 - 0xd5 || configuration || Set device backlight level between 0 and 5 (inclusive); 0 is dim, 5 is full brightness
| UM24C/UM25C/UM34C || 0xd0 - 0xd5 || configuration || Set device backlight level between 0 and 5 (inclusive); 0 is dim, 5 is full brightness
|----
|----
| 0xe0 - 0xe9 || configuration || Set screen timeout ("screensaver") between 0 and 9 minutes (inclusive), where 0 disables the screensaver
| UM24C/UM25C/UM34C || 0xe0 - 0xe9 || configuration || Set screen timeout ("screensaver") between 0 and 9 minutes (inclusive), where 0 disables the screensaver
|}
|}


Line 61: Line 67:
| 0 || 2 || marker || Start marker (always 0x0963)
| 0 || 2 || marker || Start marker (always 0x0963)
|----
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 to get V)
| 2 || 2 || measurement || Voltage - UM25C: millivolts (divide by 1000 to get V), UM24C/UM34C: centivolts (divide by 100 to get V)
|----
|----
| 4 || 2 || measurement || Amperage (in mA, divide by 1000 to get A)
| 4 || 2 || measurement || Amperage - UM25C tenth-milliamps (divide by 10000 to get A), UM24C/UM34C: milliamps (divide by 1000 to get A)
|----
|----
| 6 || 4 || measurement || Wattage (in mW, divide by 1000 to get W)
| 6 || 4 || measurement || Wattage (in mW, divide by 1000 to get W)
Line 79: Line 85:
| 98 || 2 || measurement || USB data line voltage (negative) 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 || 2 || 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)
| 100 || 2 || measurement || Charging mode index, see below
|----
|----
| 102 || 4 || measurement || mAh from threshold-based recording
| 102 || 4 || measurement || mAh from threshold-based recording
Line 101: Line 107:
| 128 || 2 || marker || Stop marker (always 0xfff1)
| 128 || 2 || marker || Stop marker (always 0xfff1)
|}
|}
=== Charging modes ===
Not all devices support detection of all listed charging modes, but the index between devices is consistent (e.g. index 1 will always be QC2).
{| class="wikitable"
!Index !! Display !! Meaning
|-----------------------------------
| 0 || UNKNOWN || Unknown, or normal (non-custom mode)
|----
| 1 || QC2 || Qualcomm Quick Charge 2.0
|----
| 2 || QC3 || Qualcomm Quick Charge 3.0
|----
| 3 || APP2.4A || Apple, max 2.4 Amp
|----
| 4 || APP2.1A || Apple, max 2.1 Amp
|----
| 5 || APP1.0A || Apple, max 1.0 Amp
|----
| 6 || APP0.5A || Apple, max 0.5 Amp
|----
| 7 || DCP1.5A || Dedicated Charging Port, max 1.5 Amp (D+ to D- short)
|----
| 8 || SAMSUNG || Samsung (Adaptive Fast Charging?)
|}
=== Unknown response fields ===
Bytes 0+1 and 128+129 are not entirely known yet.  They were believed to be device-specific start/stop markers, but some variations have been observed.
On UM24C, all observed units seem to be 0x0963/0xfff1 so far.
On UM25C, 0x0963/0xfff1 and 0x09c9/0xfff1 have been observed on two different units, but they do not appear to change over time on the specific units themselves.
On UM34C, all observed units so far have 0x0d4c as the first two bytes, but the last two bytes vary each time the device is polled.  The values drift up and down over time, but will change completely after a device reset.  For example:
<pre>
2019-02-09 16:55:35,150 DEBUG: Start: 0x0d4c, end: 0x79cd
2019-02-09 16:55:47,837 DEBUG: Start: 0x0d4c, end: 0x75f8
2019-02-09 16:55:49,031 DEBUG: Start: 0x0d4c, end: 0x78c3
2019-02-09 16:56:08,855 DEBUG: Start: 0x0d4c, end: 0x7bd9
[reset]
2019-02-09 16:58:01,091 DEBUG: Start: 0x0d4c, end: 0x2c2d
2019-02-09 16:58:52,247 DEBUG: Start: 0x0d4c, end: 0x19e5
2019-02-09 16:59:10,683 DEBUG: Start: 0x0d4c, end: 0x19e5
2019-02-09 16:59:29,816 DEBUG: Start: 0x0d4c, end: 0x18ea
</pre>


== Board pictures ==
== Board pictures ==
=== UM24C ==


Not great pictures, but hopefully they'll be useful.
Not great pictures, but hopefully they'll be useful.
Line 118: Line 174:
== Links ==
== Links ==


* [https://www.aliexpress.com/item/RD-UM24-UM24C-for-APP-USB-2-0-LCD-Display-Voltmeter-ammeter-battery-charge-voltage-current/32845522857.html Direct AliExpress UM24C link] (select "UM24C" under "Color")
* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C Bluetooth interface tool] (Python 3)
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)


[[Category:Device]]
[[Category:Device]]
[[Category:Multimeter]]
[[Category:Multimeter]]
[[Category:Planned‏‎]]
[[Category:Planned‏‎]]

Revision as of 02:56, 10 February 2019

RDTech UM24C/UM25C/UM34C
UM24C display.jpg
Status planned
Source code [1]
Connectivity serial over Bluetooth
Features measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode), color display (26x26mm, 128x128px)
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.

[TODO: Abstract introduction, as most of the above information also applies to the UM25C and UM34C, but list their differences.]

Protocol

1-byte commands are sent to the device, and in the case of 0xf0, the device responds with a 130-byte data dump of the current device status. All other commands return no acknowledgement.

Each device (UM24C, UM25C, UM34C) has a similar command and response format, but the commands and responses vary slightly by device type. These variations are documented below. Unfortunately this means you will need to know what type of device you are communicating with to take full advantage of it.

Commands to send

Multiple commands may be sent at once; e.g. you could set the recording threshold to 0.28 A and rotate the screen by sending 0xccf2 immediately. An exception appears to be requesting the data dump; it doesn't seem to return the 130-byte response unless you wait a bit (approximately 0.2 seconds) after sending other commands.

Device Byte Type Meaning
UM24C/UM25C/UM34C 0xf0 device control Request new data dump; this triggers a 130-byte response
UM24C/UM25C/UM34C 0xf1 device control Go to next screen
UM24C/UM25C/UM34C 0xf2 device control Rotate screen
UM24C 0xf3 device control Switch to next data group
UM25C/UM34C 0xf3 device control Go to the previous screen
UM24C/UM25C/UM34C 0xf4 device control Clear data group
UM25C/UM34C 0xa0 - 0xa9 device control Set the selected data group (0-9)
UM24C/UM25C/UM34C 0xb0 - 0xce configuration Set recording threshold to a value between 0.00 and 0.30 A (inclusive); add the value after the decimal point to 0xb0 (0.00 is 0xb0, 0.30 is 0xce)
UM24C/UM25C/UM34C 0xd0 - 0xd5 configuration Set device backlight level between 0 and 5 (inclusive); 0 is dim, 5 is full brightness
UM24C/UM25C/UM34C 0xe0 - 0xe9 configuration Set screen timeout ("screensaver") between 0 and 9 minutes (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 - UM25C: millivolts (divide by 1000 to get V), UM24C/UM34C: centivolts (divide by 100 to get V)
4 2 measurement Amperage - UM25C tenth-milliamps (divide by 10000 to get A), UM24C/UM34C: milliamps (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 2 configuration Currently selected data group, zero-indexed
16 80 measurement Array of 10 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 2 measurement Charging mode index, see below
102 4 measurement mAh from threshold-based recording
106 4 measurement mWh from threshold-based recording
110 2 configuration Currently configured threshold for recording (in centiamps, divide by 100 to get A)
112 4 measurement Duration of threshold recording, in cumulative seconds
116 2 configuration Threshold recording active (1 if recording, 0 if not)
118 2 configuration Current screen timeout setting, in minutes (0-9, 0 is no screen timeout)
120 2 configuration Current backlight setting (0-5, 0 is dim, 5 is full brightness)
122 4 measurement Resistance in deci-ohms (divide by 10 to get ohms)
126 2 configuration Current screen (zero-indexed, same order as on device)
128 2 marker Stop marker (always 0xfff1)

Charging modes

Not all devices support detection of all listed charging modes, but the index between devices is consistent (e.g. index 1 will always be QC2).

Index Display Meaning
0 UNKNOWN Unknown, or normal (non-custom mode)
1 QC2 Qualcomm Quick Charge 2.0
2 QC3 Qualcomm Quick Charge 3.0
3 APP2.4A Apple, max 2.4 Amp
4 APP2.1A Apple, max 2.1 Amp
5 APP1.0A Apple, max 1.0 Amp
6 APP0.5A Apple, max 0.5 Amp
7 DCP1.5A Dedicated Charging Port, max 1.5 Amp (D+ to D- short)
8 SAMSUNG Samsung (Adaptive Fast Charging?)

Unknown response fields

Bytes 0+1 and 128+129 are not entirely known yet. They were believed to be device-specific start/stop markers, but some variations have been observed.

On UM24C, all observed units seem to be 0x0963/0xfff1 so far.

On UM25C, 0x0963/0xfff1 and 0x09c9/0xfff1 have been observed on two different units, but they do not appear to change over time on the specific units themselves.

On UM34C, all observed units so far have 0x0d4c as the first two bytes, but the last two bytes vary each time the device is polled. The values drift up and down over time, but will change completely after a device reset. For example:

2019-02-09 16:55:35,150 DEBUG: Start: 0x0d4c, end: 0x79cd
2019-02-09 16:55:47,837 DEBUG: Start: 0x0d4c, end: 0x75f8
2019-02-09 16:55:49,031 DEBUG: Start: 0x0d4c, end: 0x78c3
2019-02-09 16:56:08,855 DEBUG: Start: 0x0d4c, end: 0x7bd9
[reset]
2019-02-09 16:58:01,091 DEBUG: Start: 0x0d4c, end: 0x2c2d
2019-02-09 16:58:52,247 DEBUG: Start: 0x0d4c, end: 0x19e5
2019-02-09 16:59:10,683 DEBUG: Start: 0x0d4c, end: 0x19e5
2019-02-09 16:59:29,816 DEBUG: Start: 0x0d4c, end: 0x18ea

Board pictures

= UM24C

Not great pictures, but hopefully they'll be useful.

Links