Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Extended advertising data with nrf52832 not detectable.

Utilizing two nrf52832 dev kits, both flashed with v6 of the SD and using V15 of the sdk.  

Using two examples from the SDK, the ble_peripheral/ble_app_rscs and a slightly modified ble_central/ble_app_blinky_c to test out extended advertisement packets.  

Our goal is to be able to utilize more than 31 bytes to advertise specific data that will help us coordinate between devices.  So to first just test we are using the rscs code which by default has  extended advertisements enabled and the blinky_c to just look for the specific named device, list it out using NRF_LOG_INFO and connect to it to make sure we can.  

So far we cannot see or connect to the device unless we change: 

init.config.ble_adv_extended_enabled = true;  to false which of course disables extended advertisements.

The moment we set that to false and reflash the rscs, everything works just fine.  

Is there something specific we are missing?  Does the scanning application need to do something different as well?  

We have also tested this with iPhone 8/X using nRFConnect and a TI chip with custom code equivalent to blinky_c, none can see the nrf52832 device when extended = true.  What are we doing wrong?  

Both our DK's are QFAAB0 revisions. 

Parents
  • Two things I found the other day.  

    1. Yes, when you want to scan for a device that is using extended packets, you must setup the scan with extended = 1.  It is unclear if this affects scanning for devices that do not use extended packets as I couldn't find any details in the doc about that. 

    2. There is a ble_central_and_peripheral/experimental/ble_app_hrs_rscs_relay which does use extended scanning and connects to the rscs example.   And while it isn't the type of behavior we are wanting, it at least connects so hopefully we can use it to figure out more details.

    Still many open questions, extended packets should mean we can have more data in the advertisement, but there doesn't appear to be any clear example of this anywhere.  And while the documentation is fairly detailed, one has to know exactly what you are looking for before the docs help.  The rscs example enables extended but doesn't appear to use extended advertising anywhere, or maybe I am just missing it.      

    So questions:

        Is there any direct example or specific places to look (docs or otherwise), when the goal is to send larger data during the advertisement?  

        What is the maximum size of the full advertisement name if the extended packet can be over 31 bytes?  Is it still only less than 31 bytes?  Or could I have a name that is 50 bytes and other data in the advertisement that has another 50 bytes of sensor coordination?  All of our devices are within a small area generally so moving to one of the mesh network methods seems like total overkill at this point.   

    Any suggestions?    

  • Hi,

    I agree that if all the devices are within radio distance of each other it may be overkill to use Bluetooth Mesh (although it is possible to limit the time to live for mesh packets to one jump.)

    I can confirm that extended packets must be enabled both for advertising and for scanning.

    You will still scan for and find legacy advertisements, with extended enabled.

    The theoretical max length of an AD Structure is 255 bytes plus the length field itself (one byte). Please note that the length includes both data as well as one byte for the AD type (such as "complete local name", "manufacturer specific data", etc.)

    Unfortunately for version 6.0.0 of the SoftDevices the advertising set is still limited to 31 bytes, but we are planning to have extended advertising sets for next SoftDevice release. With that in place you can increase the amount of data in the AD Structures.

    Regards,
    Terje

Reply
  • Hi,

    I agree that if all the devices are within radio distance of each other it may be overkill to use Bluetooth Mesh (although it is possible to limit the time to live for mesh packets to one jump.)

    I can confirm that extended packets must be enabled both for advertising and for scanning.

    You will still scan for and find legacy advertisements, with extended enabled.

    The theoretical max length of an AD Structure is 255 bytes plus the length field itself (one byte). Please note that the length includes both data as well as one byte for the AD type (such as "complete local name", "manufacturer specific data", etc.)

    Unfortunately for version 6.0.0 of the SoftDevices the advertising set is still limited to 31 bytes, but we are planning to have extended advertising sets for next SoftDevice release. With that in place you can increase the amount of data in the AD Structures.

    Regards,
    Terje

Children
Related