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
  • 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)

  • 11 months ago in reply to jim_m_58

    You mind sharing their full raw advertisement data?

  • 11 months ago in reply to pontusa

    Yes, I'm sure.  The Thingy52 and my Raspberry Pi devices use 128 actual UUIDS.  You can see some basic code I did for the pi devices here:

    forums.garmin.com/.../would-you-like-some-raspberry-pi-with-your-connect-iq

  • 11 months ago in reply to jim_m_58

    Not sure what you mean. We have a bunch of peripheral devices which advertise on this format:

    0x01 0x06
    0x07 128 bit UUID
    0x09 9B local name

    If I open nRF Connect on my phone then I can see those scan results in that app. So the phone isn't advertising, it's scanning.

    But my questions is: from the 13 results you get in your actual watch. Are you certain that some of them use proper 128 bit uuids? You can scan with nRF connect on your phone and see the same results and verify it. And just to clarify:

    00001523-0000-10000-80000-00805F9B34FB is indeed 128 bits but its still regarded a 16 bit UUID due to 0x02/0x03 as common type.

  • 11 months ago in reply to jim_m_58

    where are you advertising from?  I've never heard of anyone seeing advertisements from a phone app for example.  Just stand alone devices.