Complete

CIQQA-789

All data would have to be sent through the ADV IND packets, and read from those same packets.

Bluetooth Low Energy - Scan Response issue

Hi everyone,

I'm currently developing an app for Garmin Edge 830 using Bluetooth to read some data from a e-Bike sensor (developed by me and my Team and used regularly with other displays and every smartphone).

I started my project from Nordic Thingy 52 demo, but I have found an issue that makes impossible to find some BLE devices. 

My sensor (which acts as an Advertising Peripheral in BLE communication) stacks some Beacon Data in the ADV IND packet, while Services Uuid, device name, appearance etc... are all in the Scan Response data packet. 

I noticed that in onScanResults callback in BLE Delegate, I am able to see only the data contained in the ADV IND Packet, but not the data contained in the Scan Resp Packet. The result is that I can't read the data contained in this packet (in my case Device Name and Service Uuids), so i am not able to connect to my device.

The only workaround I found for this issue is to change my e-Bike sensor BLE firmware to send all data in the ADV IND Packet instead of using the Scan Response Data, but this would make me change a communication infrastructure that has been used for years. 

Is this issue a bug? Or is it an expected behaviour (that is Garmin BLE stack ignores the data contained in the Scan Response Packet)?

Thank you very much and greetings,

Giovanni.

Former Member
Former Member
Parents

  • The BLE implementation in CIQ is kind of minimal, and I think it has to due with memory on the Garmin device.  There are things like the CIQ end can't discover things like services or characteristics - they have to be hard coded in the profiles in the CIQ app.  Also, an app can use 3 services (at most).  When you do a read or notification, the response seen by the CIQ end has a max of about 20 bytes .

    Have you looked at using getManufacturerSpecific data in the scan result?  I've not used it myself.

Comment

  • The BLE implementation in CIQ is kind of minimal, and I think it has to due with memory on the Garmin device.  There are things like the CIQ end can't discover things like services or characteristics - they have to be hard coded in the profiles in the CIQ app.  Also, an app can use 3 services (at most).  When you do a read or notification, the response seen by the CIQ end has a max of about 20 bytes .

    Have you looked at using getManufacturerSpecific data in the scan result?  I've not used it myself.

Children
  • in reply to jim_m_58

    It is possible to use the Manufacturer Specific data record, the Garmin sees it. I have a device which delivers it's MAC address this way. But the whole ADV IND scan record seems to be truncated to 20 bytes. So it's important in which order a device sends it's data in the ADV IND record, because only the first 20 bytes can be seen and, thus, used.

  • in reply to Former Member

    This is behaving as expected from what a member of the BLE team told me. None of the devices use active scanning; Therefore no scan requests, results in no scan packets to extract data from.

    So yes, it would have to be done through the ADV IND packets.

  • in reply to Former Member

    That doesn't really surprise me.  If you can for the UUID (like the nordic samples), can't your app know what it needs to? The services need to be hard coded in your app, As har as the name, if you look at the raw data for the thingy52 (where you'll see a name), could it be with where in the Adv it's located?  You'll notice the raw adv data also maxes out at 30 characters or so.

  • Former Member
    Former Member in reply to jim_m_58

    Hi Jim! 

    First of all, thank you for your response.

    Yes, i looked into getManufacturerSpecificData in the scan result and there i can only see the data contained in the ADV IND packet, not the ones in the Scan Response as I would. 

    It seems that the Scan Response packet is completely ignored by CIQ.

Copyright © 1996-2025 Garmin Ltd. or its subsidiaries