VMC

1. What it is

2. The hard parts

• Identifying a device from raw frames The app tells one hardware variant from another by reading specific 32-bit registers over Bluetooth — the device type and the ALSC insert — and building a key from a range of ASCII bytes. None of this is announced by the protocol; it had to be worked out from the wire.
• Frames that arrive in pieces Bluetooth notifications do not respect frame boundaries. Every chunk goes into a buffer that validates a checksum and the declared length before the frame is accepted, so a truncated read is dropped rather than parsed as data.
• A link that drops in the field A watchdog watches the connection. When the link goes stale the app rebuilds it and re-sends identification in one pass, rather than making the engineer start over.
• A connect that fails the first time After a scan, the first connection attempt can fail with a transient controller error. A short pause and a single retry makes it reliable, and the retry is part of the discovery flow rather than something the user has to trigger.
• A UI generated from XML Parameter menus are built from cloud-hosted XML, parsed into models and rendered generically. Field engineers get a configuration screen that matches the firmware in front of them.

3. Notes

• A presentation mode runs the whole app offline with representative values, for demonstrations where no hardware is at hand.
• Picking a location on the map writes it straight into the device's own geolocation parameters.

4. Contact

Something to build, fix or hook up? Write — replies usually land within a day, EU timezone.