# 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.

- 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

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.