Acknowledged
11 months ago

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?

pontusa
Parents
  • 11 months ago in reply to jim_m_58

    Okay. And I see roughly 20 devices on the sim and 3-4 on the watch. And all the 3-4 on the watch are ones with 16 bit UUID's. If you use nRF Connect (preferably on Android), can you see if any of the 13 devices you get on your watch have 128 bit UUIDS? Or perhaps when I think of it, since your BleScan app shows the UUID then my question is if any of your 13 results has a UUID which is not 16 bit + BASE UUID. 

    If it is that simple that Garmin simply cannot handle 128 bit UUID's then there's nothing I can do.

    What would be an improper file flashed to the nRF dongle? It works with my simulator and gives me all the results.

Comment
  • 11 months ago in reply to jim_m_58

    Okay. And I see roughly 20 devices on the sim and 3-4 on the watch. And all the 3-4 on the watch are ones with 16 bit UUID's. If you use nRF Connect (preferably on Android), can you see if any of the 13 devices you get on your watch have 128 bit UUIDS? Or perhaps when I think of it, since your BleScan app shows the UUID then my question is if any of your 13 results has a UUID which is not 16 bit + BASE UUID. 

    If it is that simple that Garmin simply cannot handle 128 bit UUID's then there's nothing I can do.

    What would be an improper file flashed to the nRF dongle? It works with my simulator and gives me all the results.

Children
  • 11 months ago in reply to pontusa

    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+

  • 11 months ago in reply to jim_m_58

    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.

  • 11 months ago in reply to pontusa

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

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

  • 11 months ago in reply to jim_m_58

    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!

  • 11 months ago in reply to pontusa

    I'm actually not sure I could get what you want.  Seems there is something with the way you advertise.  Maybe experiment with your advertiser and see if you can get blescan to see it, or get a Thingly52 so you can see first hand what works, grabbing any data you need yourself.  I suspect it has to do with the flags in the advertisement.  With nRFconnect on my android phone and a Thingy52, the flags are:

    GeneralDiscoverable,BrEdrNotSupported

    (Same on my Pi devices)