sigrok - User contributions [en]

RDTech UM series

2019-02-15T23:56:11Z

Fo0bar:

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

The meter can be connected to power by plugging it into any one of the supported line inputs (see above; the different line options vary by model). Besides allowing for different connection options, there is a function within the UI to calculate the impedance of a cable by running a test first directly plugged in to a power supply, then unplugging and running again via the cable. Otherwise, line functionality is identical no matter which line input you choose.

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.

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.

== Bluetooth ==

Unlike most devices of this type, these communicate through serial-over-Bluetooth (RFCOMM); the manufacturer provides apps (for Android, Windows and Apple iOS; downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, the Bluetooth board is a separate layer that connects to the serial pads using pogo pins (UM24C) or scissor-spring tension pins (UM25C, UM34C). UM24C has a generic open module board with a Beken BK3231 chipset. UM25C and UM34C have a shielded DX-BT18 module board (which should be compatible with HC-05/HC-06).

There is no Enable pin passed between the Bluetooth board and the main board; the model name is (presumably) programmed into the module in Command mode at the factory, and the module is always in Data mode during normal operation. Communication between the boards is done at 9600 8-N-1.

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

== Protocol ==

Approximately 500ms after applying power, the device sends 0xff. However, this is usually before a Bluetooth connection can be established, so the host end will likely never see it.

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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>

These are most likely checksums of some sort. Here's some full sample dumps:

<pre>
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 44 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8c
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 45 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fc 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8f
</pre>

Samples 3 and 4 are identical, but were captured at different times. Samples 1 and 2 have two bytes different (44 -> 45 earlier and 01 -> 00 later) which should have an identical result if it were a simple sum, but result in 688c -> 688d. Samples 2 and 3 have two bytes different (14 -> 15 and 45 -> 46, a cumulative difference of 2), but both result in 688d. Samples 4 and 5 have one byte different (fe -> fc), but result in 688d -> 688f.

All of these suggest some sort of "add if even or subtract if odd" iteration, but I haven't been able to find a process which results in the expected checksum differences.

== Board pictures ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T18:04:52Z

Fo0bar: Add info about BT chipsets

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C). UM24C has a generic open module board with a Beken BK3231 chipset. UM25C and UM34C have a shielded DX-BT18 module board (which should be compatible with HC-05/HC-06).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 meter can be connected to power by plugging it into any one of the supported line inputs (see above; the different line options vary by model). Besides allowing for different connection options, there is a function within the UI to calculate the impedance of a cable by running a test first directly plugged in to a power supply, then unplugging and running again via the cable. Otherwise, line functionality is identical no matter which line input you choose.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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>

These are most likely checksums of some sort. Here's some full sample dumps:

<pre>
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 44 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8c
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 45 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fc 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8f
</pre>

Samples 3 and 4 are identical, but were captured at different times. Samples 1 and 2 have two bytes different (44 -> 45 earlier and 01 -> 00 later) which should have an identical result if it were a simple sum, but result in 688c -> 688d. Samples 2 and 3 have two bytes different (14 -> 15 and 45 -> 46, a cumulative difference of 2), but both result in 688d. Samples 4 and 5 have one byte different (fe -> fc), but result in 688d -> 688f.

All of these suggest some sort of "add if even or subtract if odd" iteration, but I haven't been able to find a process which results in the expected checksum differences.

== Board pictures ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T08:47:28Z

Fo0bar: /* Unknown response fields */ Checksum speculations

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 meter can be connected to power by plugging it into any one of the supported line inputs (see above; the different line options vary by model). Besides allowing for different connection options, there is a function within the UI to calculate the impedance of a cable by running a test first directly plugged in to a power supply, then unplugging and running again via the cable. Otherwise, line functionality is identical no matter which line input you choose.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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>

These are most likely checksums of some sort. Here's some full sample dumps:

<pre>
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 44 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8c
0d 4c 01 fe 00 00 00 00 00 00 00 14 00 45 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fe 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8d
0d 4c 01 fc 00 00 00 00 00 00 00 15 00 46 00 00 00 00 00 0b 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 04 00 01 86 9f 00 00 68 8f
</pre>

Samples 3 and 4 are identical, but were captured at different times. Samples 1 and 2 have two bytes different (44 -> 45 earlier and 01 -> 00 later) which should have an identical result if it were a simple sum, but result in 688c -> 688d. Samples 2 and 3 have two bytes different (14 -> 15 and 45 -> 46, a cumulative difference of 2), but both result in 688d. Samples 4 and 5 have one byte different (fe -> fc), but result in 688d -> 688f.

All of these suggest some sort of "add if even or subtract if odd" iteration, but I haven't been able to find a process which results in the expected checksum differences.

== Board pictures ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T06:45:47Z

Fo0bar: Update explanation of line inputs

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 meter can be connected to power by plugging it into any one of the supported line inputs (see above; the different line options vary by model). Besides allowing for different connection options, there is a function within the UI to calculate the impedance of a cable by running a test first directly plugged in to a power supply, then unplugging and running again via the cable. Otherwise, line functionality is identical no matter which line input you choose.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T06:31:14Z

Fo0bar: Stylize model names by their body colors, since the names look very similar and are hard to separate

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T06:16:50Z

Fo0bar:

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM25C and UM34C have a switch which lets you turn on and off the Bluetooth functionality.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T05:12:44Z

Fo0bar: Fix typo

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM34C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T03:22:04Z

Fo0bar: Add general information about all three

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ rdtech.aliexpress.com]
}}

== What is it? ==

The RDTech UM24C (~$12 USD), UM25C (~$16 USD) and UM34C (~$18 USD) are USB load meters which can measure various properties for USB devices including their voltage, amperage, wattage, resistance, capacity, temperature, data line voltage, and charging mode. They 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). They also allow graphing the amperage and voltage over time, on the device's display itself, as well as rotating the display contents into any orientation.

The UM24C, UM25C and UM34C are extremely similar, but have several differences:

* UM24C supports USB-A male / USB-microB female line, USB-A female load.
* UM25C supports USB-A male / USB-microB female / USB-C female line, USB-A female / USB-C female load.
* UM34C supports USB-A male / USB-microB female / USB-C female line, USB-A female load.
* UM34C supports USB 3.0 data passthrough; UM24C/UM25C are USB 2.0 only.
* UM25C displays and sends 1mV / 0.1mA live resolution, UM24C/UM34C are 10mV / 1mA live resolution. Note that this is applicable for instantaneous view only; aggregates are the same for all three models.
* UM24C is maximum 3A current, UM34C is 4A, UM25C is 5A.
* UM24C only supports detection of unknown (normal) charging mode, QC2.0 and QC3.0, UM25C and UM34C support detecting additional charging modes. This does not affect the line/load from negotiating a charging mode, just the meter's ability to detect it.
* UM24C is not supported by their Apple app, only UM25C and UM34C.

The UM25C is the most fully featured of the three, but is missing USB 3.0 data passthrough (UM24C only). If you have to buy one, get the UM25C, but if possible get both the UM25C and UM34C. The UM24C is a slightly older product feature-wise.

Unlike most devices of this type, these communicate through serial-over-Bluetooth; the manufacturer provides apps (for Android and Windows, downloads including device documentation [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code. On the C models, 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 (UM24C) or scissor-spring tension pins (UM25C, UM34C).

Note that this is specifically about the '''C''' models - the UM24, UM25 and UM34 are the exact same functionality but *without* Bluetooth communication. The UM25 and UM34 have pads which you could solder a TTL adapter to (if you disassemble the device) and get the same functionality. The UM24 has pads, but the firmware does not appear to support communication.

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 ==

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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T02:01:15Z

Fo0bar: /* Response format */

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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.

{| class="wikitable"
!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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || unknown || See below
|----
| 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 || unknown || See below
|}

=== 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T01:59:10Z

Fo0bar:

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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.

{| class="wikitable"
!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.

{| class="wikitable"
!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).

{| 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 ==

=== UM24C ===

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM24C

2019-02-10T01:56:54Z

Fo0bar: Fo0bar moved page RDTech UM24C to RDTech UM series: Now covers UM24C/UM25C/UM34C

#REDIRECT [[RDTech UM series]]

RDTech UM series

2019-02-10T01:56:54Z

Fo0bar: Fo0bar moved page RDTech UM24C to RDTech UM series: Now covers UM24C/UM25C/UM34C

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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.

{| class="wikitable"
!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.

{| class="wikitable"
!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).

{| 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 ==

=== UM24C ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-02-10T01:56:20Z

Fo0bar: Add UM25C/UM34C information

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C/UM25C/UM34C
| status = planned
| 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 = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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.

{| class="wikitable"
!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.

{| class="wikitable"
!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).

{| 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 ==

=== UM24C ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== Links ==

* [https://rdtech.aliexpress.com/store/923042 RDTech AliExpress store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C/UM25C/UM34C Bluetooth interface tool] (Python 3)

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

RDTech UM series

2019-01-27T02:51:01Z

Fo0bar:

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| status = Not Supported‏‎
| 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 = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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 || 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; this is an enum, where 0 = unknown/standard, 1 = QC2.0, and presumably 2 = QC3.0 (but I haven't verified this)
|----
| 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)
|}

== Board pictures ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== 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://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C Bluetooth interface tool] (Python 3)

[[Category:Device]]
[[Category:Multimeter]]
[[Category:Not Supported‏‎]]

RDTech UM series

2019-01-27T02:07:24Z

Fo0bar: Fix 0xb0 - 0xce range

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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 || 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; this is an enum, where 0 = unknown/standard, 1 = QC2.0, and presumably 2 = QC3.0 (but I haven't verified this)
|----
| 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)
|}

== Board pictures ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== 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 AliExpres store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C Bluetooth interface tool] (Python 3)

RDTech UM series

2019-01-26T18:46:56Z

Fo0bar: Add links

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.15 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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 || 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; this is an enum, where 0 = unknown/standard, 1 = QC2.0, and presumably 2 = QC3.0 (but I haven't verified this)
|----
| 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)
|}

== Board pictures ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

== 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 AliExpres store]
* [https://github.com/rfinnie/rdumtool rdumtool - RDTech UM24C Bluetooth interface tool] (Python 3)

RDTech UM series

2019-01-26T18:34:41Z

Fo0bar: /* Response format */ Additional minor information

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.15 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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 || 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; this is an enum, where 0 = unknown/standard, 1 = QC2.0, and presumably 2 = QC3.0 (but I haven't verified this)
|----
| 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)
|}

== Board pictures ==

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

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

RDTech UM series

2019-01-26T18:22:17Z

Fo0bar: Assume the "unknown" positions are the high bytes of the next byte, since they all follow the same pattern

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.15 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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 || 2 || 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 || 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)
|----
| 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 || 2 || configuration || Recording active (1 if recording)
|----
| 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 || 2 || 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.

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

RDTech UM series

2019-01-26T18:16:51Z

Fo0bar: Correct position of charging mode, after I was able to find a QC2.0 device

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.15 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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, possibly meant to be the high byte of position 15
|----
| 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 || unknown || Not used in app, possibly meant to be the high byte of position 101
|----
| 101 || 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)
|----
| 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 || unknown || Not used in app, possibly meant to be the high byte of position 117
|----
| 117 || 1 || configuration || Recording active (1 if recording)
|----
| 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 || Possibly meant to be the high byte of position 127
|----
| 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.

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

RDTech UM series

2019-01-26T18:09:47Z

Fo0bar: Correct voltage (centivolts, not millivolts) and "Recording active" position, add other notes

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

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.

{| class="wikitable"
!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
|----
| 0xb0 - 0xce || configuration || Set recording threshold to a value between 0.00 and 0.15 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
|----
| 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.

{| class="wikitable"
!Offset !! Length !! Type !! Meaning
|-----------------------------------
| 0 || 2 || marker || Start marker (always 0x0963)
|----
| 2 || 2 || measurement || Voltage (in centivolts, divide by 100 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, possibly meant to be the high byte of position 15
|----
| 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 || unknown || Not used in app, possibly meant to be the high byte of position 117
|----
| 117 || 1 || configuration || Recording active (1 if recording)
|----
| 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 || Possibly meant to be the high byte of position 127
|----
| 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.

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>

RDTech UM series

2019-01-26T17:49:18Z

Fo0bar: Convert protocol tables to wikitables

{{Infobox multimeter
| image = [[File:UM24C_display.jpg|180px]]
| name = RDTech UM24C
| connectivity = serial over Bluetooth
| features = measures USB devices; voltage, amperage, wattage, resistance, capacity, temperature, voltage over USB data lines (charging mode)
| website = [http://rdtech.aliexpress.com/ 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 [https://www.mediafire.com/folder/0jt6xx2cyn7jt/UM24 here]), but not protocol documentation nor source code.

Note that this is specifically about the UM24'''C''' - 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 ===

{| class="wikitable"
!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
|----
| 0xb''N'' || 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)
|----
| 0xc''N'' || configuration || Same as 0xb''N'', 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)
|----
| 0xd''N'' || configuration || Set device backlight level; ''N'' must be between 0 and 5 (inclusive)
|----
| 0xe''N'' || 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.

{| class="wikitable"
!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.

<gallery>
File:UM24C_board_1.jpg
File:UM24C_board_2.jpg
File:UM24C_board_3.jpg
File:UM24C_board_4.jpg
File:UM24C_board_5.jpg
File:UM24C_board_6.jpg
File:UM24C_board_7.jpg
</gallery>