Hello,
I would like to report what appears to be a defect in the Connect IQ Bluetooth Low Energy implementation on the fenix 8.
== ENVIRONMENT ==
- Watch: fenix 8, 43 mm. Firmware: 22.41 ANT/BLE/BT: 29.24
- Connect IQ SDK 9.2.0 (2026-06-09)
- Application type: data field, minApiLevel 3.1.0, permission BluetoothLowEnergy
- Peripheral under test: Android phone acting as BLE peripheral (GATT server + advertiser)
- The watch is simultaneously connected to a phone through Garmin Connect
== SUMMARY ==
Toybox.BluetoothLowEnergy scanning delivers ScanResult objects that carry no advertising payload. getRssi() returns plausible values, but getDeviceName(), getServiceUuids(), getManufacturerSpecificData() and getRawData() return null or empty for essentially every result.
== TEST PERIPHERAL ==
Legacy connectable ADV_IND containing:
0x01 Flags = 0x02
0x09 Complete Local Name = "VARGSOC"
0xFF Manufacturer Specific Data = company 0xFFFF, payload 0x5647
0x03 Complete list of 16-bit Service UUIDs = 0xFFF0
0x16 Service Data = 0xFFF0, value 0x01
Scan response carries the 128-bit service UUID 6b9f5f00-7b1e-4b7a-9d3a-1f6c0a5e0001.
Verified with nRF Connect on a second Android phone: every field is parsed correctly, RSSI about -45 dBm at 30 cm distance.
Raw capture of an earlier build of the same packet (before Service Data was added):
0x02010208095641524753 4F4305FFFFFF56470303F0FF
11 07 01005E0A6C1F3A9D7A4B1E7B005F9F6B
== OBSERVED ON THE WATCH ==
During a single activity session the data field counted 710 ScanResults. Of these:
- 0 returned a non-null getDeviceName()
- 0 returned manufacturer data for company 0xFFFF
- 2 returned any service UUID at all
- best RSSI observed: -42 dBm
A byte-wise search for the ASCII sequence "VARGSOC" inside getRawData() never matched.
The advertising layout was varied during testing: 128-bit service UUID only, 16-bit service UUID only, manufacturer data only, and with Service Data appended so that the 16-bit UUID list is not the final AD structure. None of these changed the result.
== SECOND ISSUE: CONNECTION ==
Because identification by advertising content was impossible, the application was changed to connect to the strongest candidate (RSSI >= -65 dBm) and to verify the expected service after connecting. In that mode pairDevice() is accepted without throwing, but onConnectedStateChanged() never reports CONNECTION_STATE_CONNECTED. The attempt times out. Tested with 12 s and 40 s timeouts, and with candidates at -42 dBm, which is the test peripheral itself.
== RELATED REPORTS ==
This matches the existing forum report "Connect-IQ Ble advertising layer parsing bug", where a Bluetooth sniffer confirmed that the over-the-air bytes were correct while Connect IQ returned different data; reproduced on the simulator, fenix 6X and fenix 6S. A separate report states that scan results are only produced for peripherals advertising 16-bit service UUIDs and that getDeviceName() always returns null.
== QUESTIONS ==
- Is this a known defect, and is a fix scheduled for a fenix 8 firmware release?
- Is there an advertising layout that Connect IQ parses reliably on current firmware?
- Is pairDevice() to a third-party peripheral expected to work while the watch maintains its Garmin Connect phone connection?
I can provide the complete source of both sides, raw captures and a sniffer log on request.
Best regards, Yuriy
