The app's old parser expected a multi-anchor protocol:
[count][anchorID+rangeMM+RSSI+age]×N (min 10 bytes)
HAL's firmware sends a fixed 8-byte packet:
[int32 front_mm LE][int32 back_mm LE]
With the old parser data[0] was interpreted as anchor count
(e.g. 0xF8 = 248 for a 4.6m reading), the loop guard failed
immediately, and every notify returned [] — hence "waiting for
ranging data" despite the tag showing live ranges on OLED.
Changes:
- BLEPackets: detect 8-byte HAL format by length; decode as
anchor id=0 (Front) and id=1 (Back); legacy multi-anchor path
retained for forward compatibility
- AnchorInfo: rssiDBm is now Optional (nil when not reported);
label maps id 0→"F", 1→"B" for the two-anchor HAL format
- BLEStatusView: guard on optional rssiString before rendering
Auto-reconnect confirmed correct (2s delay, bluetooth-central
background mode declared in Info.plist).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
sl-ios
12338f491e