Fastest Method to Update Advertisement Data

[FA]

Hi,

Assume that we want to send a data array by putting it in consecutive advertisement packets. I know that data update has to be done by calling ble_advdata_set(...). The question is after starting the advertisement by sd_ble_gap_adv_start(&m_adv_params) how do we call ble_advdata_set() during the advertisement intervals.

After reading other posts, my understanding is that:

1- We should use radio_notification to get a signal after the radio becomes inactive, i.e., after it sent a packet.

2- In the radio_notification_event_handler, we can call to update the data.

• First, is this the best method?

• If yes, for getting notifications only after a packet is sent, I should use sd_radio_notification_cfg_set and ble_radio_notification_init together? Also, in this case the distance parameter can be ignored?

Thanks!

[puz_md]

Hi FA,

Concerning your questions:

• Yes, this is the best (and probably the only) method to send consecutive data with each advertising signal.

• Yes, you should call both funktion. ble_radio_notification_init() first and sd_radio_notification_cfg_set() after the init call. In fact, notification() internally already calls sd_radio_notification_cfg_set() but it activates notifications both before and after radio activity. So you need the extra call to sd_radio_notification_cfg_set() to enable it only for post radio events. Yes,the distance parameter is not used for post radio events. For a clean implementation, set it to NRF_RADIO_NOTIFICATION_DISTANCE_NONE.

Although you may send out consecutive data this way, I think your communication design will not work in the end. There is no guarantee that all advertising packets will reach the receiver (there is no handshaking and there may always be some interference on the radio frequencies caused by other devices). Also, the Observer device may disable reception for a short moment when the end of the receive window is reached (I'm not sure is real 100% scanning without interruption is supported by the SoftDevice). This is why you should expect that advertising packets will randomly be "lost" and not received by the Observer.

If you want reliable and fast transmission of your data array, you will have to use the GATTS layer with a connection based method (which uses handshaking). Transfer of large data blocks can also be faster this way (shorter communication intervals are allowed in connected mode), but the data cannot be broadcasted to multiple receiving devices at the same time.

If your data does not change over the time, your approach with the advertising data may be feasible when you send the data array multiple times (with offset information) and the Observer collects data that it missed when it is re-transmitted later.

Good luck!

[FA]

Thanks for your answer and recommendations. Are you aware of any example project about the GATTS layer with the connection based method? At some point I think I need to compare the two approaches based on the amount and frequency of data that needs to be transferred.

[puz_md]

In fact, all Bluetooth services use the GATT layer. It is a basic element of Bluetooth Smart / Bluetooth Low Energy.

I haven't worked much with the samples provided in the SDK, but I remember several pieces of text referring to the "Heart Rate Sensor" (HRS) example which seems to be the default example to explain things.

Are you familiar with the Bluetooth Core Specification?

https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439

Vol.3 Part G describes the GATT profile, Vol.3 Part C describes the GAP profile which is responsible for connection management and advertising. You will have to understand these sections if you want to know what you're doing.

For a connection, you need a "Peripheral" and a "Central" role (see GAP profile), the Central connects to the Peripheral which usually contains the GATT Server. Implementation using the GATT layer will definitely be more implementation work compared to your approach with the advertising data, but it is the official way to go.