Overview
Reverse‑engineered the BLE protocol of wireless SMPTE timecode hardware to expose live sync data, pairing behavior, and initialization requirements for custom tools.
Problem
Atomos/TimecodeSystems UltraSync BLUE units support only a limited number of paired devices and provide no official API for custom integrations. The goal was to recover the BLE protocol so third‑party tools could read timecode reliably while respecting the device’s required initialization sequence.
Hardware
- UltraSync BLUE timecode units
- nRF52840 sniffer hardware
- Linux host running Wireshark for BLE capture and analysis
- macOS with the official UltraSync BlueSlate app
- MAX driver boards with 7‑segment displays for low‑cost timecode slates
Protocol
Identified the custom timecode service UUID, primary notify/read characteristic, and the frame count/config channel required for reliable initialization.
| UUID | Purpose | Properties |
|---|---|---|
9383b854-8bee-11e7-bb31-be2e44b06b34 |
Timecode Service | — |
9383b110-8bee-11e7-bb31-be2e44b06b34 |
Primary Timecode | notify, read |
9383b110-8bee-11e7-bb79-be2e44b06b34 |
Frame Count / Config | read, write |
ce8dadf8-b7e0-4d9e-94cd-43f84803b361 |
Secondary Timecode / Status | notify, read |
0252db82-f8a8-4874-b5cd-e65b7b3309b9 |
Status / Sync | notify, read |
Manual Reference
Initialization Sequence
- Read frame count/config characteristic.
- Read device name.
- Subscribe to primary timecode notifications.
The official app fails to read timecode reliably unless the frame count characteristic is read first.
Tools & Methods
- BLE discovery and live notifications with Python (Bleak).
- Packet capture via PacketLogger/Wireshark and macOS logging.
- Frida hooks to monitor outgoing BLE traffic from the UltraSyncBlueSlate macOS app and extract UUID usage.
- Binary analysis of the vendor app to map UUIDs and init sequences.
Key Technical Challenges
- Proprietary pairing handshake — Decoded a custom 3-way handshake (CCID, BCID, Accept) with no documentation by testing all writable characteristics and analyzing 150+ pairing attempts across multiple tools.
- State-dependent behavior — Found that the UltraSync Bluetooth menu must be open during pairing for devices to appear, and that timecode streaming is limited to 10 packets unless properly paired, requiring precise connection timing.
- Hidden protocol semantics — Determined that the device name shown in the UltraSync menu is stored in a custom CTRL characteristic (0x000F), not in BLE advertising or Generic Access, after exhaustive testing of 15+ characteristics.
- Platform-specific BLE limitations — Worked around macOS CoreBluetooth restrictions where peripheral device names cannot be customized, affecting how UltraSync identifies connected devices.
- Race conditions in pairing — Early BCID reads returned all zeros due to timing issues; added retry logic and delays to reliably read the 4-byte persistent identifier before timeout.
- Incomplete protocol implementation — Achieved ~90% success with working pairing and continuous timecode reception, but device names still don’t display in the UltraSync menu despite being stored, suggesting additional undocumented validation steps.
Outcome
The resulting spec enables reliable timecode reads and custom integrations without relying on the official app, while preserving proper initialization and pairing behavior.
It also makes it possible to build inexpensive digital timecode slates using off‑the‑shelf Bluetooth receivers, 7‑segment displays, and MAX driver boards to show frame‑accurate timecode.