USB-Meter
/
Documentation
/
Research Resources
/
Specifications
/
UM24-UM25-UM34 Family Compatibility Note.md
Newer
■
■
■
■
■
■
■
■
■
■
Older
45 lines
|
4.116kb
| 1 |
# UM24 / UM25 / UM34 Family Compatibility Note |
|
| 2 | ||
| 3 |
This note records what can currently be inferred from the archived `UM24` resource bundle about the `UM24C`, `UM25C`, and `UM34C` family. |
|
| 4 | ||
| 5 |
## Confirmed Facts |
|
| 6 | ||
| 7 |
- the archived manual is explicitly labeled `UM24C` |
|
| 8 |
- the archived PC software package is explicitly labeled `UM24C` |
|
| 9 |
- the `UM24` line is known to use classic Bluetooth serial-port style communication and is not intended to be supported by this application |
|
| 10 |
- the newly imported `User_Manual_UM34C.pdf` uses mixed model labels internally: `UM25/UM25C` in one heading and `UM34/UM34C` in the technical parameter section |
|
| 11 |
- the same newly imported PDF titles its app section `UM34C Android APP Instruction` |
|
| 12 |
- a separate `UM25` manual has now been imported as `Documentation/Research Resources/Manuals/UM25 User Manual.pdf` |
|
| 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 |
|
| 16 |
- the two Android APKs are branded more generically around RuiDeng / `UM Meter` |
|
| 17 |
- the duplicate "3 in 1" PDF is byte-for-byte identical to the already imported `UM24C` manual |
|
| 18 | ||
| 19 |
## Quick Inspection Results |
|
| 20 | ||
| 21 |
- quick string scans of the Android APKs surfaced RuiDeng branding but did not immediately expose model-specific names such as `UM25` or `UM34` |
|
| 22 |
- quick string scan of the PC software archive surfaced `UM24C` labeling and installer/runtime filenames, but no direct `UM25` or `UM34` hits |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 29 | ||
| 30 |
## Working Assumption |
|
| 31 | ||
| 32 |
- use the imported Android applications and vendor contact document as family-level reference material that may still help with `UM25C` and `UM34C` |
|
| 33 |
- exclude classic-Bluetooth `UM24` support from current application scope |
|
| 34 |
- use the imported `User_Manual_UM34C.pdf` as a family-level UI and feature reference, while keeping its model-specific claims tentative |
|
| 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 |
|
| 37 |
- use the imported manual and PC software primarily as `UM24C` references until stronger cross-model evidence is found |
|
| 38 | ||
| 39 |
## Practical Implication |
|
| 40 | ||
| 41 |
- focus implementation effort on the app-supported `UM25C` / `UM34C` direction rather than classic-Bluetooth `UM24` |
|
| 42 |
- treat the `UM25` manual as the best current guide for user-visible features and supported control surfaces |
|
| 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` |
|
| 45 |
- for UI, wording, and software workflow clues, the imported APKs may be useful even if the desktop package stays `UM24C`-centric |