# HM-10 and DX-BT18 Module Working Summary

This note summarizes two imported module references used to reason about the Bluetooth path of the `UM25C` / `UM34C` family.

## Source Set

### `DSD TECH HM-10 datasheet.pdf`

- imported file: `Documentation/Research Resources/Manuals/DSD TECH HM-10 datasheet.pdf`

- pages: `38`

- SHA-1: `37f96b85b742312d8db592241c97fad95c7ac2a9`

- scope: generic `HM-10` BLE serial module reference

### `Users-Manual-4216091.pdf`

- imported file: `Documentation/Research Resources/Manuals/Users-Manual-4216091.pdf`

- pages: `14`

- SHA-1: `7e175833582422dcd8005399dc01d2f42d27e7b7`

- scope: `DX-BT18` dual-mode Bluetooth module user manual

- title page identifies:

  - `FCC ID: 2AKS8DX-BT18`

  - `Model Name: DX-BT18`

## Why These Matter

The current app models the `UM25C` / `UM34C` family as using an `HM-10`-style radio path over:

- service `FFE0`

- characteristic `FFE1`

These manuals help us understand whether that path is:

- generic `HM-10` BLE serial behavior

- or a more specific dual-mode module story that also explains desktop and iOS support

## Confirmed `HM-10` Baseline

The `HM-10` datasheet confirms a classic BLE-uart bridge shape:

- BLE version: `4.0 BLE`

- default service: `0xFFE0`

- default characteristic: `0xFFE1`

- characteristic mode: `Notify` and `Write`

- UART-side AT configuration before connection

Useful implications:

- this strongly supports the app's existing `FFE0` / `FFE1` assumption for the `UM` family

- it also supports the idea that the application-layer `0xF0` request and `130`-byte UM snapshot sit above a simple serial-like BLE transport

## Confirmed `DX-BT18` Details

The `DX-BT18` manual is even more interesting because it describes a dual-mode module:

- Bluetooth `4.2`

- `BR/EDR + BLE`

- UART interface

- default Bluetooth name: `DX-BT18`

- default SPP pairing code: `1234`

- default service UUID: `FFE0`

- default `Notify/Write` UUID: `FFE1`

- default `Write` UUID: `FFE2`

Additional points explicitly documented:

- the module supports `SPP` for desktop, notebook, Android phones, and Bluetooth master modules

- the module supports `BLE` at the same time

- the module can connect directly to `iOS` devices with BLE

- the SPP and BLE sides use the same module MAC address

- the Bluetooth names for SPP and BLE are the same

## Best Working Interpretation For `UM25C` / `UM34C`

These module documents help reconcile the previously awkward mix of clues around the UM family:

- Windows desktop software that looks serial-port-like

- Android app support

- iOS app support

- existing app code that uses an `HM-10`-style BLE service

Best current interpretation:

- the `UM25C` / `UM34C` family likely uses a radio path that is compatible with the `HM-10` style `FFE0` / `FFE1` serial bridge model

- a `DX-BT18`-class dual-mode module is a plausible concrete implementation because it explains:

  - BLE access for iOS

  - serial-port-style behavior for desktop

  - the same vendor family naming and wiring style

This does not prove every `UM25C` / `UM34C` device contains the exact same module, but it moves the current app assumptions onto much firmer ground.

## Transport-Level Validation For The Current App

High-confidence validations:

- keeping `UM25C` / `UM34C` on the `FFE0` / `FFE1` path is justified

- the current app's `HM-10`-style transport model is consistent with both manuals

- the family can plausibly expose BLE to iOS while still appearing as serial-port style in desktop workflows

Moderate-confidence inferences:

- `DX-BT18` may be closer to the real `UM25C` / `UM34C` module than a pure `HM-10`

- if so, `FFE2` may exist as a write-only characteristic even though the current app only needs `FFE1`

- dual-mode behavior may explain why family documentation mixes Bluetooth app control with desktop COM-port language

## Throughput and Framing Hints

The manuals provide useful transport hints, but not product payload maps:

- `HM-10` datasheet lists typical asynchronous throughput in the `2-6 KBytes` range

- `DX-BT18` lists example BLE throughput around `5 KB/s` under one test setup

- both manuals still describe a UART-bridge style transport, not a product-specific application protocol

This aligns with the existing UM-family parser model:

- BLE provides the transport

- the meter firmware defines the `0xF0` request and `130`-byte snapshot semantics

## What These Manuals Do Not Prove

These module manuals do not directly validate:

- the `0xF0` request command

- the `130`-byte UM payload size

- the byte offsets in the UM snapshot

- whether the installed module in a specific `UM25C` or `UM34C` is exactly `DX-BT18`

So they validate the radio shape, not the meter payload.

## Practical Implications For The Codebase

- keep the `UM25C` / `UM34C` transport separate from `TC66C`

- keep the `UM25C` / `UM34C` transport on the `FFE0` / `FFE1` path

- treat desktop serial-port clues for the UM family as compatible with BLE/iOS support, not contradictory

- if future captures show `FFE2` on a UM-family device, that would fit the `DX-BT18` manual and should not be surprising