UM24C / UM25C / UM34C Notes from floriandotorg/um24c

Source project:

• https://github.com/floriandotorg/um24c
• file reviewed: src/App.js

Scope

This note captures protocol knowledge inferred from the external floriandotorg/um24c project.

It applies to:

• UM24C
• UM25C
• UM34C

It does not appear to cover:

• TC-66C

BLE Transport Hints

The external project uses:

• service 0xFFE0
• characteristic 0xFFE1
• notifications on 0xFFE1
• request command 0xF0 to trigger a new measurement snapshot

The connection flow matches the HM-10 style radio path already present in our project.

The imported HM-10 and DX-BT18 module references strengthen this:

• generic HM-10 documentation explicitly uses FFE0 / FFE1
• the DX-BT18 manual documents default UUIDs FFE0, FFE1, and FFE2
• the DX-BT18 manual also explains how a UM-family device could support both desktop serial-style workflows and iOS BLE workflows

Model Identifiers

The external project maps:

• 0x0963 -> UM24C
• 0x09c9 -> UM25C
• 0x0d4c -> UM34C

This is useful as a concrete reference for the 16-bit model field found at payload offset 0.

Snapshot Framing

The external project accumulates notification fragments until a total payload size of 130 bytes is available.

It then parses that 130-byte buffer as one UM snapshot and schedules the next 0xF0 request after about 500 ms.

Important note:

• this confirms a 130-byte UM payload
• it does not prove that the final notification is always 10 bytes long as a protocol guarantee
• that detail may only reflect the behavior observed by that project

Payload Layout Extracted From The External Project

All offsets below are byte offsets into the 130-byte UM payload.

Offset	Size	External interpretation	Notes
0	2	modelId	Used with the model map above
2	2	voltage	UM25C: raw / 1000 V, UM24C and UM34C: raw / 100 V
4	2	amperage	External project displays raw / 1000 A
6	4	wattage	Displayed as raw / 1000 W
10	2	temperature	External project uses only one temperature field here
14	2	group	Selected data group
16 + group * 8	4	capacityAmperage	Group-specific accumulated charge
20 + group * 8	4	capacityWattage	Group-specific accumulated energy
96	2	negativeDataLineVoltage	External project treats offset 96 as D-
98	2	positiveDataLineVoltage	External project treats offset 98 as D+
100	2	chargingMode	Uses the charging mode map below
112	4	duration	External project interprets as seconds and multiplies by 1000 for ms formatting
122	4	impedance	Displayed as raw / 10 ohms

Charging Mode Map

The external project maps the charging mode field at offset 100 as:

• 1 -> QC2
• 2 -> QC3
• 3 -> APP2.4A
• 4 -> APP2.1A
• 5 -> APP1.0A
• 6 -> APP0.5A
• 7 -> DCP1.5A
• 8 -> SAMSUNG

Comparison With Our Current Implementation

The external project confirms several parts of our existing UM parser:

• request command 0xF0
• expected response length 130
• model number at offset 0
• selected data group at offset 14
• duration at offset 112
• load resistance / impedance data at offset 122

It also exposes a few differences that should be treated as verification targets:

1. Current scaling for UM25C

Our code currently uses:

• UM25C: raw / 10000
• UM34C: raw / 1000

The external project uses:

• raw / 1000 for the shared amperage field

This is a high-value point to verify against real captures or device behavior.

2. Group capacity scaling

Our code currently divides group values by 1000 for:

• accumulated charge
• accumulated energy

The external project appears to present these values directly, without that division.

This may indicate:

• a difference in unit assumptions
• UI-only formatting choices
• or a real decoding discrepancy

3. D+ / D- offset naming

Our code currently interprets:

• offset 96 as usbPlusVoltage
• offset 98 as usbMinusVoltage

The external project interprets:

• offset 96 as negative data line voltage
• offset 98 as positive data line voltage

This should be verified carefully.

4. Extra fields present only in our code

Our UM parser also handles fields that the external project does not expose in its UI, including:

• Fahrenheit temperature at offset 12
• recorded AH / WH
• recording threshold
• recording state
• screen timeout
• screen brightness
• current screen

These may still be correct, but the external project does not help validate them.

Suggested Verification Priorities

When new captures or device access become available, verify in this order:

1. UM25C current scaling
2. group AH / WH scaling
3. D+ / D- offset naming
4. charging mode values
5. meaning of the extra UM fields parsed only by our code

Practical Value

This external project is useful mainly because it provides:

• confirmed model identifiers
• a second implementation of the UM snapshot parser
• concrete charging mode names
• a reference point for disputed field scaling

It should be treated as a strong comparison source, but not as final protocol truth.