Acknowledged

I'm creating a ticket to find out why this flag is required and whether it's something we can improve.

Connect IQ BLE scan issue

**UPDATE** Found the reason. The watch will never (in our case) find a scan result from a BLE device which doesn't advertise General Discoverable Mode. However, running your FW on a nRF dongle will get those scan results. I'm not sure the reason why they behave differently. But I guess we can hope that you support getting scan results from devices which doesn't advertise General Discoverable Mode in the future, just like android, iOS, wearOS and watchOS does.

I have an application which starts BLE scanning and then shows the result. It does however work drastically different on a simulator vs an actual watch:

- If I run it on the simulator for Fenix 6X PRO with a nRF plugged into my computer then I see all the desired scan results from devices that are nearby. The app will find almost all the nearby devices and the scan results will properly contain the device name, service UUID etc.

- If I build the app, put it on my Fenix 6X PRO watch and then launch it then it works very intermittently. For some periods of time it doesn't get any scan results. Other periods it will get 1-3 different scan results over and over again, and it's never the result of the desired device.

Our peripheral device advertises regular BLE with a service UUID of 128 bits. The results we see on the watch are only for devices which advertises 16-bit service UUIDS. 

Example of results I do get on the watch when doing BLE scanning:

- FE50 (0000FE50-0000-10000-80000-00805F9B34FB) with name Google

- 1523 (00001523-0000-10000-80000-00805F9B34FB) with name TT214H BlueFrog

- FE4D (0000FE4D-0000-10000-80000-00805F9B34FB) with name EBDMR-CB-DD (Casambi)

The names here have been gotten from nRF connect b/c the watch always thinks that the name (scanResult.getDeviceName()) is null.

What can be the reason for the app functioning so differently on a simulator and a similar watch? Why does it only show some scan results?

I have also tried with BleScan on that same watch and it gets the exact same scan results as I get in my app. Why does that watch only get those results?

  • Brandon wrote "I'm creating a ticket to find out why this flag is required and whether it's something we can improve." 6 months ago. Wanted to ping and see if anything has happened?

  • Understand that if Garmin decides to change the BLE on their devices, it will very likely only be rolled out to the newer devices,  Many device rarely, if ever get new FW after they've been out for a while.  It's been over 4 months for the Fenix 6 series and over a year for the fr945 and fenix5+

  • Yeah, good point, but perhaps Nordic has made a specific FW to be used together with CiQ? So made by Nordic for Garmin. But not sure, perhaps just the generic BLE FW.

    Regarding discoverable. We have a product already on the market which advertises the way it does. Plus, I feel like discoverable doesn't really mean much in BLE. It used to in classic BT (BR/EDR) and has sort of just made its way into BLE to make sure BLE fits the spec. If a BLE device advertises (and doesn't advertise non-connectable) then it by pure logic is discoverable, regardless of the flag or not. So disregarding what we're doing it still sounds like a good idea for Garmin to look into why they indeed require the flag and if that's really a good thing.

  • The hex file you flashed is from Nordic, not Garmin.

    Is there a reason you don't want your devices to be discoverable?

  • Yeah, you actually got it. It's the GeneralDiscoverable flag which makes it not work.

    Our peripheral devices doesn't advertise it. Android, iOS, wearOS watches, watchOS watches don't care about that. But apparently CiQ for Garmin does. 

    Also find it a bit strange that their FW on a nRF dongle doesn't care about it but their actual watches do.

    Anyway, now we know. I guess all we can do is hope that they change it. Thanks for help!