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