Extended advertising data with nrf52832 not detectable.

RE: Extended advertising data with nrf52832 not detectable.

tesc — Wed, 25 Apr 2018 16:33:57 GMT

6.1 release, although release schedule is unknown to me at the moment.

RE: Extended advertising data with nrf52832 not detectable.

Mark — Wed, 25 Apr 2018 15:12:58 GMT

Will this be done in a upcoming minor release soon or something that is slated for a major release that will be a while? I understand you can't give any specific dates or schedule, but at least understanding if this is an upcoming minor 6.1 type release or a major 7.0 release would help for now.

RE: Extended advertising data with nrf52832 not detectable.

tesc — Wed, 25 Apr 2018 14:42:00 GMT

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

RE: Extended advertising data with nrf52832 not detectable.

Mark — Tue, 24 Apr 2018 13:29:03 GMT

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?