# 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