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

    Hi, thanks for the response. If you read the last part of my post you see that I tested your app and found that it got me the same results as my own application. So those 3 UUID's that I wrote about are more or less the only 3 I get when I run your BleScan app.

    When you do a 16 bit UUID you typically use 0x02 or 0x03 as the common data type and then your 2 byte UUID. This translates to the UUID + base UUID seen in the app. 

    I can see that the devices that I get results of advertise their UUID in that way.

    Our device has 0x07 as common data type and a 128 bit UUID. 

    When I run in the simulator using the nRF dongle everything works perfectly.

    On a similar Watch (Fenix 6x pro) I only seem to ge the 16 bit UUID responses.

    Our full raw advertise data is 29 bytes long (so shorter than some that are actually found which are 30 bytes long). So we have a flag 0x04, then our 128 bit UUID and then our 9 byte local name.  

    Is it just that simple that Garmin watches only support 16 bit UUID's? I find it very strange that they never mention that anywhere. 

Comment
  • 11 months ago in reply to jim_m_58

    Hi, thanks for the response. If you read the last part of my post you see that I tested your app and found that it got me the same results as my own application. So those 3 UUID's that I wrote about are more or less the only 3 I get when I run your BleScan app.

    When you do a 16 bit UUID you typically use 0x02 or 0x03 as the common data type and then your 2 byte UUID. This translates to the UUID + base UUID seen in the app. 

    I can see that the devices that I get results of advertise their UUID in that way.

    Our device has 0x07 as common data type and a 128 bit UUID. 

    When I run in the simulator using the nRF dongle everything works perfectly.

    On a similar Watch (Fenix 6x pro) I only seem to ge the 16 bit UUID responses.

    Our full raw advertise data is 29 bytes long (so shorter than some that are actually found which are 30 bytes long). So we have a flag 0x04, then our 128 bit UUID and then our 9 byte local name.  

    Is it just that simple that Garmin watches only support 16 bit UUID's? I find it very strange that they never mention that anywhere. 

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)