- Import HM-10 and DX-BT18 module references
- Browse files
-
bogdan committed 2 weeks ago
-
1 parent dad48d5commit 75b39bd
Showing 9 changed files
with
176 additions
and
3 deletions
BIN
Documentation/Research Resources/Manuals/DSD TECH HM-10 datasheet.pdf
Binary file not shown.
+16
-0
Documentation/Research Resources/Manuals/README.md
@@ -45,6 +45,22 @@ Recommended naming: |
||
| 45 | 45 |
- SHA-1: `e325f7708f18400fd774f60219e76395797c51cc` |
| 46 | 46 |
- extraction status: reviewed; summarized in `../Specifications/PW0316 BLE Module Working Summary.md` |
| 47 | 47 |
|
| 48 |
+### `DSD TECH HM-10 datasheet.pdf` |
|
| 49 |
+ |
|
| 50 |
+- status: added to repository |
|
| 51 |
+- apparent scope: generic `HM-10` BLE serial module reference relevant to the `UM25C` / `UM34C` transport path |
|
| 52 |
+- pages: `38` |
|
| 53 |
+- SHA-1: `37f96b85b742312d8db592241c97fad95c7ac2a9` |
|
| 54 |
+- extraction status: reviewed together with `Users-Manual-4216091.pdf`; summarized in `../Specifications/HM-10 and DX-BT18 Module Working Summary.md` |
|
| 55 |
+ |
|
| 56 |
+### `Users-Manual-4216091.pdf` |
|
| 57 |
+ |
|
| 58 |
+- status: added to repository |
|
| 59 |
+- apparent scope: `DX-BT18` dual-mode Bluetooth module manual, relevant to the `UM25C` / `UM34C` transport path |
|
| 60 |
+- pages: `14` |
|
| 61 |
+- SHA-1: `7e175833582422dcd8005399dc01d2f42d27e7b7` |
|
| 62 |
+- extraction status: reviewed together with `DSD TECH HM-10 datasheet.pdf`; summarized in `../Specifications/HM-10 and DX-BT18 Module Working Summary.md` |
|
| 63 |
+ |
|
| 48 | 64 |
### `User Maual for Operation and PC software and APP of TC66(C) Type-c USB PD Trigger Meter 2019.6.5.pdf` |
| 49 | 65 |
|
| 50 | 66 |
- status: added to repository |
BIN
Documentation/Research Resources/Manuals/Users-Manual-4216091.pdf
Binary file not shown.
+6
-0
Documentation/Research Resources/Payload Notes/UM24C-UM25C-UM34C from floriandotorg-um24c.md
@@ -30,6 +30,12 @@ The external project uses: |
||
| 30 | 30 |
|
| 31 | 31 |
The connection flow matches the HM-10 style radio path already present in our project. |
| 32 | 32 |
|
| 33 |
+The imported `HM-10` and `DX-BT18` module references strengthen this: |
|
| 34 |
+ |
|
| 35 |
+- generic `HM-10` documentation explicitly uses `FFE0` / `FFE1` |
|
| 36 |
+- the `DX-BT18` manual documents default UUIDs `FFE0`, `FFE1`, and `FFE2` |
|
| 37 |
+- the `DX-BT18` manual also explains how a UM-family device could support both desktop serial-style workflows and iOS BLE workflows |
|
| 38 |
+ |
|
| 33 | 39 |
## Model Identifiers |
| 34 | 40 |
|
| 35 | 41 |
The external project maps: |
+134
-0
Documentation/Research Resources/Specifications/HM-10 and DX-BT18 Module Working Summary.md
@@ -0,0 +1,134 @@ |
||
| 1 |
+# HM-10 and DX-BT18 Module Working Summary |
|
| 2 |
+ |
|
| 3 |
+This note summarizes two imported module references used to reason about the Bluetooth path of the `UM25C` / `UM34C` family. |
|
| 4 |
+ |
|
| 5 |
+## Source Set |
|
| 6 |
+ |
|
| 7 |
+### `DSD TECH HM-10 datasheet.pdf` |
|
| 8 |
+ |
|
| 9 |
+- imported file: `Documentation/Research Resources/Manuals/DSD TECH HM-10 datasheet.pdf` |
|
| 10 |
+- pages: `38` |
|
| 11 |
+- SHA-1: `37f96b85b742312d8db592241c97fad95c7ac2a9` |
|
| 12 |
+- scope: generic `HM-10` BLE serial module reference |
|
| 13 |
+ |
|
| 14 |
+### `Users-Manual-4216091.pdf` |
|
| 15 |
+ |
|
| 16 |
+- imported file: `Documentation/Research Resources/Manuals/Users-Manual-4216091.pdf` |
|
| 17 |
+- pages: `14` |
|
| 18 |
+- SHA-1: `7e175833582422dcd8005399dc01d2f42d27e7b7` |
|
| 19 |
+- scope: `DX-BT18` dual-mode Bluetooth module user manual |
|
| 20 |
+- title page identifies: |
|
| 21 |
+ - `FCC ID: 2AKS8DX-BT18` |
|
| 22 |
+ - `Model Name: DX-BT18` |
|
| 23 |
+ |
|
| 24 |
+## Why These Matter |
|
| 25 |
+ |
|
| 26 |
+The current app models the `UM25C` / `UM34C` family as using an `HM-10`-style radio path over: |
|
| 27 |
+ |
|
| 28 |
+- service `FFE0` |
|
| 29 |
+- characteristic `FFE1` |
|
| 30 |
+ |
|
| 31 |
+These manuals help us understand whether that path is: |
|
| 32 |
+ |
|
| 33 |
+- generic `HM-10` BLE serial behavior |
|
| 34 |
+- or a more specific dual-mode module story that also explains desktop and iOS support |
|
| 35 |
+ |
|
| 36 |
+## Confirmed `HM-10` Baseline |
|
| 37 |
+ |
|
| 38 |
+The `HM-10` datasheet confirms a classic BLE-uart bridge shape: |
|
| 39 |
+ |
|
| 40 |
+- BLE version: `4.0 BLE` |
|
| 41 |
+- default service: `0xFFE0` |
|
| 42 |
+- default characteristic: `0xFFE1` |
|
| 43 |
+- characteristic mode: `Notify` and `Write` |
|
| 44 |
+- UART-side AT configuration before connection |
|
| 45 |
+ |
|
| 46 |
+Useful implications: |
|
| 47 |
+ |
|
| 48 |
+- this strongly supports the app's existing `FFE0` / `FFE1` assumption for the `UM` family |
|
| 49 |
+- it also supports the idea that the application-layer `0xF0` request and `130`-byte UM snapshot sit above a simple serial-like BLE transport |
|
| 50 |
+ |
|
| 51 |
+## Confirmed `DX-BT18` Details |
|
| 52 |
+ |
|
| 53 |
+The `DX-BT18` manual is even more interesting because it describes a dual-mode module: |
|
| 54 |
+ |
|
| 55 |
+- Bluetooth `4.2` |
|
| 56 |
+- `BR/EDR + BLE` |
|
| 57 |
+- UART interface |
|
| 58 |
+- default Bluetooth name: `DX-BT18` |
|
| 59 |
+- default SPP pairing code: `1234` |
|
| 60 |
+- default service UUID: `FFE0` |
|
| 61 |
+- default `Notify/Write` UUID: `FFE1` |
|
| 62 |
+- default `Write` UUID: `FFE2` |
|
| 63 |
+ |
|
| 64 |
+Additional points explicitly documented: |
|
| 65 |
+ |
|
| 66 |
+- the module supports `SPP` for desktop, notebook, Android phones, and Bluetooth master modules |
|
| 67 |
+- the module supports `BLE` at the same time |
|
| 68 |
+- the module can connect directly to `iOS` devices with BLE |
|
| 69 |
+- the SPP and BLE sides use the same module MAC address |
|
| 70 |
+- the Bluetooth names for SPP and BLE are the same |
|
| 71 |
+ |
|
| 72 |
+## Best Working Interpretation For `UM25C` / `UM34C` |
|
| 73 |
+ |
|
| 74 |
+These module documents help reconcile the previously awkward mix of clues around the UM family: |
|
| 75 |
+ |
|
| 76 |
+- Windows desktop software that looks serial-port-like |
|
| 77 |
+- Android app support |
|
| 78 |
+- iOS app support |
|
| 79 |
+- existing app code that uses an `HM-10`-style BLE service |
|
| 80 |
+ |
|
| 81 |
+Best current interpretation: |
|
| 82 |
+ |
|
| 83 |
+- the `UM25C` / `UM34C` family likely uses a radio path that is compatible with the `HM-10` style `FFE0` / `FFE1` serial bridge model |
|
| 84 |
+- a `DX-BT18`-class dual-mode module is a plausible concrete implementation because it explains: |
|
| 85 |
+ - BLE access for iOS |
|
| 86 |
+ - serial-port-style behavior for desktop |
|
| 87 |
+ - the same vendor family naming and wiring style |
|
| 88 |
+ |
|
| 89 |
+This does not prove every `UM25C` / `UM34C` device contains the exact same module, but it moves the current app assumptions onto much firmer ground. |
|
| 90 |
+ |
|
| 91 |
+## Transport-Level Validation For The Current App |
|
| 92 |
+ |
|
| 93 |
+High-confidence validations: |
|
| 94 |
+ |
|
| 95 |
+- keeping `UM25C` / `UM34C` on the `FFE0` / `FFE1` path is justified |
|
| 96 |
+- the current app's `HM-10`-style transport model is consistent with both manuals |
|
| 97 |
+- the family can plausibly expose BLE to iOS while still appearing as serial-port style in desktop workflows |
|
| 98 |
+ |
|
| 99 |
+Moderate-confidence inferences: |
|
| 100 |
+ |
|
| 101 |
+- `DX-BT18` may be closer to the real `UM25C` / `UM34C` module than a pure `HM-10` |
|
| 102 |
+- if so, `FFE2` may exist as a write-only characteristic even though the current app only needs `FFE1` |
|
| 103 |
+- dual-mode behavior may explain why family documentation mixes Bluetooth app control with desktop COM-port language |
|
| 104 |
+ |
|
| 105 |
+## Throughput and Framing Hints |
|
| 106 |
+ |
|
| 107 |
+The manuals provide useful transport hints, but not product payload maps: |
|
| 108 |
+ |
|
| 109 |
+- `HM-10` datasheet lists typical asynchronous throughput in the `2-6 KBytes` range |
|
| 110 |
+- `DX-BT18` lists example BLE throughput around `5 KB/s` under one test setup |
|
| 111 |
+- both manuals still describe a UART-bridge style transport, not a product-specific application protocol |
|
| 112 |
+ |
|
| 113 |
+This aligns with the existing UM-family parser model: |
|
| 114 |
+ |
|
| 115 |
+- BLE provides the transport |
|
| 116 |
+- the meter firmware defines the `0xF0` request and `130`-byte snapshot semantics |
|
| 117 |
+ |
|
| 118 |
+## What These Manuals Do Not Prove |
|
| 119 |
+ |
|
| 120 |
+These module manuals do not directly validate: |
|
| 121 |
+ |
|
| 122 |
+- the `0xF0` request command |
|
| 123 |
+- the `130`-byte UM payload size |
|
| 124 |
+- the byte offsets in the UM snapshot |
|
| 125 |
+- whether the installed module in a specific `UM25C` or `UM34C` is exactly `DX-BT18` |
|
| 126 |
+ |
|
| 127 |
+So they validate the radio shape, not the meter payload. |
|
| 128 |
+ |
|
| 129 |
+## Practical Implications For The Codebase |
|
| 130 |
+ |
|
| 131 |
+- keep the `UM25C` / `UM34C` transport separate from `TC66C` |
|
| 132 |
+- keep the `UM25C` / `UM34C` transport on the `FFE0` / `FFE1` path |
|
| 133 |
+- treat desktop serial-port clues for the UM family as compatible with BLE/iOS support, not contradictory |
|
| 134 |
+- if future captures show `FFE2` on a UM-family device, that would fit the `DX-BT18` manual and should not be surprising |
|
+5
-0
Documentation/Research Resources/Specifications/README.md
@@ -34,3 +34,8 @@ Useful content for this folder: |
||
| 34 | 34 |
|
| 35 | 35 |
- working summary for the vendor BLE module manual used by the `TC66C` radio path |
| 36 | 36 |
- focuses on GATT channels, UART bridge behavior, packet sizing, and what the module manual does and does not validate |
| 37 |
+ |
|
| 38 |
+### `HM-10 and DX-BT18 Module Working Summary.md` |
|
| 39 |
+ |
|
| 40 |
+- working summary for the `HM-10` and `DX-BT18` module references related to the `UM25C` / `UM34C` family |
|
| 41 |
+- focuses on `FFE0` / `FFE1`, dual-mode behavior, and how desktop plus iOS support can coexist |
|
+6
-0
Documentation/Research Resources/Specifications/UM24-UM25-UM34 Family Compatibility Note.md
@@ -11,6 +11,8 @@ This note records what can currently be inferred from the archived `UM24` resour |
||
| 11 | 11 |
- the same newly imported PDF titles its app section `UM34C Android APP Instruction` |
| 12 | 12 |
- a separate `UM25` manual has now been imported as `Documentation/Research Resources/Manuals/UM25 User Manual.pdf` |
| 13 | 13 |
- the `UM25` manual explicitly includes Android app, iOS app, and Windows PC software sections for `UM25C` |
| 14 |
+- imported `HM-10` and `DX-BT18` module references both support the `FFE0` transport family already assumed by the app for `UM25C` / `UM34C` |
|
| 15 |
+- the `DX-BT18` manual explicitly describes a dual-mode module with BLE for iOS and SPP-style behavior for desktop / Android environments |
|
| 14 | 16 |
- the two Android APKs are branded more generically around RuiDeng / `UM Meter` |
| 15 | 17 |
- the duplicate "3 in 1" PDF is byte-for-byte identical to the already imported `UM24C` manual |
| 16 | 18 |
|
@@ -21,6 +23,8 @@ This note records what can currently be inferred from the archived `UM24` resour |
||
| 21 | 23 |
- the imported `UM34C` PDF reads like an operational manual for the same product family and strengthens the case that RuiDeng reused documentation structure across closely related models |
| 22 | 24 |
- the newly added `UM25` PDF likely gives us a cleaner model-specific source for separating `UM25` behavior from `UM24C` and `UM34C`, but it still needs review |
| 23 | 25 |
- the reviewed `UM25` PDF confirms that `UM25C` had official Android, iOS, and Windows software support, which makes it a better primary product reference than the older `UM24C` manual |
| 26 |
+- the imported `HM-10` and `DX-BT18` radio references make the current `FFE0` / `FFE1` BLE transport assumption for the UM family significantly more credible |
|
| 27 |
+- the `DX-BT18` dual-mode description offers a plausible explanation for why UM-family material mixes iOS BLE workflows with Windows serial-port workflows |
|
| 24 | 28 |
- the existing external project note for `floriandotorg/um24c` remains the stronger indication that `UM24C`, `UM25C`, and `UM34C` are closely related at the protocol level |
| 25 | 29 |
|
| 26 | 30 |
## Working Assumption |
@@ -29,6 +33,7 @@ This note records what can currently be inferred from the archived `UM24` resour |
||
| 29 | 33 |
- exclude classic-Bluetooth `UM24` support from current application scope |
| 30 | 34 |
- use the imported `User_Manual_UM34C.pdf` as a family-level UI and feature reference, while keeping its model-specific claims tentative |
| 31 | 35 |
- use the reviewed `UM25` manual as the current best product-level reference for `UM25C` |
| 36 |
+- use the imported `HM-10` / `DX-BT18` references as transport-level support for the existing UM-family radio model, while still treating the exact installed module as unconfirmed until hardware verification |
|
| 32 | 37 |
- use the imported manual and PC software primarily as `UM24C` references until stronger cross-model evidence is found |
| 33 | 38 |
|
| 34 | 39 |
## Practical Implication |
@@ -36,4 +41,5 @@ This note records what can currently be inferred from the archived `UM24` resour |
||
| 36 | 41 |
- focus implementation effort on the app-supported `UM25C` / `UM34C` direction rather than classic-Bluetooth `UM24` |
| 37 | 42 |
- treat the `UM25` manual as the best current guide for user-visible features and supported control surfaces |
| 38 | 43 |
- for payload decoding and Bluetooth behavior, keep comparing `UM25C` and `UM34C` observations against `UM24C` notes |
| 44 |
+- for transport assumptions, `FFE0` / `FFE1` remains the right default path for `UM25C` / `UM34C` |
|
| 39 | 45 |
- for UI, wording, and software workflow clues, the imported APKs may be useful even if the desktop package stays `UM24C`-centric |
+3
-3
Documentation/Research Resources/Specifications/UM25 Manual Working Summary.md
@@ -177,9 +177,9 @@ Useful as a product-behavior reference: |
||
| 177 | 177 |
|
| 178 | 178 |
Important transport caveat: |
| 179 | 179 |
|
| 180 |
-- the PC section clearly describes Bluetooth COM-port use, which fits classic serial-port style communication on Windows |
|
| 181 |
-- the same manual also describes an iOS app, which means transport behavior cannot be reduced to the PC workflow alone |
|
| 182 |
-- for implementation, radio and protocol details still need to be verified from runtime captures or app analysis before we lock assumptions |
|
| 180 |
+- the PC section clearly describes Bluetooth COM-port use, which fits serial-port style communication on Windows |
|
| 181 |
+- the imported `DX-BT18` module manual shows one plausible way this can coexist with iOS support: the module can expose SPP-style workflows for desktop while also supporting BLE for iOS |
|
| 182 |
+- for implementation, exact module identity is still not fully proven, but the current `FFE0` / `FFE1` transport assumption is now much better supported |
|
| 183 | 183 |
|
| 184 | 184 |
## Relationship to Current App Scope |
| 185 | 185 |
|
+6
-0
USB Meter.xcodeproj/project.pbxproj
@@ -63,6 +63,8 @@ |
||
| 63 | 63 |
1C6B6BAA2A2D4F5100A0B001 /* UM25 User Manual.pdf */ = {isa = PBXFileReference; lastKnownFileType = image.pdf; path = "UM25 User Manual.pdf"; sourceTree = "<group>"; };
|
| 64 | 64 |
1C6B6BAB2A2D4F5100A0B001 /* User_Manual_UM34C.pdf */ = {isa = PBXFileReference; lastKnownFileType = image.pdf; path = User_Manual_UM34C.pdf; sourceTree = "<group>"; };
|
| 65 | 65 |
1C6B6BB02A2D4F5100A0B001 /* PW0316_User_Manual_V2.9.pdf */ = {isa = PBXFileReference; lastKnownFileType = image.pdf; path = PW0316_User_Manual_V2.9.pdf; sourceTree = "<group>"; };
|
| 66 |
+ 1C6B6BB22A2D4F5100A0B001 /* DSD TECH HM-10 datasheet.pdf */ = {isa = PBXFileReference; lastKnownFileType = image.pdf; path = "DSD TECH HM-10 datasheet.pdf"; sourceTree = "<group>"; };
|
|
| 67 |
+ 1C6B6BB32A2D4F5100A0B001 /* Users-Manual-4216091.pdf */ = {isa = PBXFileReference; lastKnownFileType = image.pdf; path = "Users-Manual-4216091.pdf"; sourceTree = "<group>"; };
|
|
| 66 | 68 |
1C6B6B982A2D4F5100A0B001 /* Software README.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = README.md; sourceTree = "<group>"; };
|
| 67 | 69 |
1C6B6B992A2D4F5100A0B001 /* Android Apps README.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = README.md; sourceTree = "<group>"; };
|
| 68 | 70 |
1C6B6B9B2A2D4F5100A0B001 /* Vendor Contacts README.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = README.md; sourceTree = "<group>"; };
|
@@ -77,6 +79,7 @@ |
||
| 77 | 79 |
1C6B6BAD2A2D4F5100A0B001 /* UM25 Manual Working Summary.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "UM25 Manual Working Summary.md"; sourceTree = "<group>"; };
|
| 78 | 80 |
1C6B6BAE2A2D4F5100A0B001 /* TC66 Manuals Working Summary.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "TC66 Manuals Working Summary.md"; sourceTree = "<group>"; };
|
| 79 | 81 |
1C6B6BB12A2D4F5100A0B001 /* PW0316 BLE Module Working Summary.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "PW0316 BLE Module Working Summary.md"; sourceTree = "<group>"; };
|
| 82 |
+ 1C6B6BB42A2D4F5100A0B001 /* HM-10 and DX-BT18 Module Working Summary.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "HM-10 and DX-BT18 Module Working Summary.md"; sourceTree = "<group>"; };
|
|
| 80 | 83 |
1C6B6B932A2D4F5100A0B001 /* Payload Notes README.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = README.md; sourceTree = "<group>"; };
|
| 81 | 84 |
1C6B6B962A2D4F5100A0B001 /* UM24C-UM25C-UM34C from floriandotorg-um24c.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "UM24C-UM25C-UM34C from floriandotorg-um24c.md"; sourceTree = "<group>"; };
|
| 82 | 85 |
1C6B6BAF2A2D4F5100A0B001 /* TC66C Transport and Payload Working Note.md */ = {isa = PBXFileReference; lastKnownFileType = net.daringfireball.markdown; path = "TC66C Transport and Payload Working Note.md"; sourceTree = "<group>"; };
|
@@ -172,6 +175,8 @@ |
||
| 172 | 175 |
1C6B6BAB2A2D4F5100A0B001 /* User_Manual_UM34C.pdf */, |
| 173 | 176 |
1C6B6BAA2A2D4F5100A0B001 /* UM25 User Manual.pdf */, |
| 174 | 177 |
1C6B6BB02A2D4F5100A0B001 /* PW0316_User_Manual_V2.9.pdf */, |
| 178 |
+ 1C6B6BB22A2D4F5100A0B001 /* DSD TECH HM-10 datasheet.pdf */, |
|
| 179 |
+ 1C6B6BB32A2D4F5100A0B001 /* Users-Manual-4216091.pdf */, |
|
| 175 | 180 |
); |
| 176 | 181 |
path = Manuals; |
| 177 | 182 |
sourceTree = "<group>"; |
@@ -186,6 +191,7 @@ |
||
| 186 | 191 |
1C6B6BAD2A2D4F5100A0B001 /* UM25 Manual Working Summary.md */, |
| 187 | 192 |
1C6B6BAE2A2D4F5100A0B001 /* TC66 Manuals Working Summary.md */, |
| 188 | 193 |
1C6B6BB12A2D4F5100A0B001 /* PW0316 BLE Module Working Summary.md */, |
| 194 |
+ 1C6B6BB42A2D4F5100A0B001 /* HM-10 and DX-BT18 Module Working Summary.md */, |
|
| 189 | 195 |
); |
| 190 | 196 |
path = Specifications; |
| 191 | 197 |
sourceTree = "<group>"; |