beacon advertise interval

[ziv123]

hello Nordic

i am working with nrf52832, sdk 6.0, softdevice s132 v7.0

i read around the forum that i can advertise a beacon packet every 20 ms 

but in the ble_app_beacon example the interval for the advertisement is written to be minimum 100ms ?? so where did that 20 ms go ?

however, since i don't know how to change the data of the message while advertising i put a timer handler that stops the advertise, update the data and start it again.

i put the timer to go every 50 ms and the advertisement interval every 50 ms i put a pin toggle every time i receive a ble from the address i am filtering..

1. the time is not fixed, maybe some messages are lost or maybe not sent, i don't know 

2. the intervals are larger then 50 ms .. more to the 100 ms  when they are sometimes fixed 

can you advice on this matter ?

i need to be sending changeable data in a beacon at list 30 times in one second

best regards

Ziv

[Karl Ylvisaker]

Hello Ziv,

i read around the forum that i can advertise a beacon packet every 20 ms 

but in the ble_app_beacon example the interval for the advertisement is written to be minimum 100ms ?? so where did that 20 ms go ?

I am not sure I follow your train of thoughts here - the lowest possible advertising interval is indeed 20 ms, but the beacon example provided in the SDK uses an advertising interval of between 100 and 200 ms, this is correct.
The reason for this is that beacons do not usually transfer a whole lot of data, and as such it is more power efficient to not advertise with the lowest possible interval. You may of course change this in your own application, to use the 20 ms advertising interval.

however, since i don't know how to change the data of the message while advertising i put a timer handler that stops the advertise, update the data and start it again.

If you are using the advertising module you may instead use the _advdata_update function.
However, the _advdata_update function has a known issue, which requires that you have two adv_data instances that you alternate between passing to update and updating.
That is to say: you may not pass a single advdata instance to advertising start, update the same advdata instance and then provide it as the argument to _advdata_update.
Instead, you will have to have two advdata instances, where you pass one as the argument to the _advdata_update function, and then you may update the other advdata instance, before calling _advdata_update again with the most recently updated(not currently in use) advdata instance.

1. the time is not fixed, maybe some messages are lost or maybe not sent, i don't know 

Advertisements are transfers without acknowledgments, and they may indeed be lost sometimes - there are no retransmissions because there is never any acknowledgements. This can happen more often if the devices are far apart, and if they are operating in a 2.4 GHz noisy environment. The time can not be completely fixed either, due to the random 10 ms delay that is added before every advertisement. This is part of the BLE specification and can not be removed.

2. the intervals are larger then 50 ms .. more to the 100 ms  when they are sometimes fixed 

Please elaborate on the exact timings you are seeing. How are you measuring this by the way, only the toggling pin, or do you also use the BLE Sniffer tool? 

i need to be sending changeable data in a beacon at list 30 times in one second

This is possible using beacon advertisements, since with a 20 ms advertising interval your worst case will be 30 ms between each advertisement, which again means that you will get more than 30 packets per second.
However, you will need to keep in mind that advertisement packets may be lost. This is the biggest drawback of using advertisements to transfer data, and also what makes advertisement data transfer infeasible if you need to make sure every packet is received.
In the latter case, you will need to establish a connection to ensure that every packet is received.

Please let me know if anything still should be unclear,
 
Best regards,
Karl

[ziv123]

hi Karl

good to read from you 

the thing i actually have to design is

1. a software for 150 units that receive data (specific for each of them) from one broadcasting unit that is connected to a pc

2. dLL for the beacon broadcasting gateway or dongle or whatever that is connected to the pc which is running some python app (will need some help with that later)

regarding the first part:

• I have no power saving issues since power will be given to all units all the time
• I was going for broadcasting and beacon to avoid making connection with each unit which i think will take a lot of time on Acks and reconnecting with a different unit every time. I would have sent one big message to all units ,if it was possible, and maybe send it multiple times in a second just to make sure every unit got it.
• So i was toggling myself between working on an extended beacon broadcast, to checking how much data i can transfer in the 31 byte message and how many times i can transfer it ,so that if one 31 byte message can contain data for 10 units, i have to see that i can send the message to all 150 units every one second

Karl Ylvisaker said:

You may of course change this in your own application, to use the 20 ms advertising interval.

can i also control the scan interval, and if so how and is there some issues i need to take under consideration when doing that ?

Karl Ylvisaker said:

Instead, you will have to have two advdata instances, where you pass one as the argument to the _advdata_update function, and then you may update the other advdata instance, before calling _advdata_update again with the most recently updated(not currently in use) advdata instance.

i could not find any _advdata_update function in the ble_advdata.h file. if or when i find the function you are referring to then do i need to stop the advertising and restart it like in the following code, and update in the middle or i can only update advdata in the timer handler and the broadcasting continue in its interval ?:

sd_ble_gap_adv_stop(m_adv_handle);
    err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
    APP_ERROR_CHECK(err_code);
    err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &m_adv_params);
    APP_ERROR_CHECK(err_code);
    err_code = sd_ble_gap_adv_start(m_adv_handle, APP_BLE_CONN_CFG_TAG);
    APP_ERROR_CHECK(err_code);

Karl Ylvisaker said:

This can happen more often if the devices are far apart, and if they are operating in a 2.4 GHz noisy environment

if i am using the ADDRESS FILTER:

    err_code = nrf_ble_scan_filter_set(&m_scan, SCAN_ADDR_FILTER, m_target_periph_addr); // Ziv
    APP_ERROR_CHECK(err_code);

    // Setting filters for scanning.
    err_code = nrf_ble_scan_filters_enable(&m_scan, NRF_BLE_SCAN_ADDR_FILTER, false); // Ziv
    APP_ERROR_CHECK(err_code);

does it change something regarding noises or every message from any device is received and read all the way anyway  and only then is filtered ?

Karl Ylvisaker said:

How are you measuring this by the way

i toggle a pin in the case of ' NRF_BLE_SCAN_EVT_FILTER_MATCH '  in the ' scan_event_handler(...) '

i look at the pin in the scope in a 50ms for each square 

Regarding the second thing:

if you can recommend a gateway or a device, gateway or other that connects to a pc via usb and comes with a convenient API so i can wrap it and supply the customer with an easy API for the data needed to be transferred to all the 150 units via bl, that would be great. 

i read some about the nrf52840 dongle but someone wrote that it has a lot of over had regarding softdevice and serialization if i recall and actually recommend using a designated device (for us price of such device is not an issue)

hope to read from you soon 

best regards

Ziv

[Karl Ylvisaker]

Hello Ziv,

This is not the library that was referenced in the ticket I linked.
The correct reference is this one.

The Radio Notification feature is written about in the SoftDevice documentation.

Best regards,
Karl

[ziv123]

hi Karl

it falls on the priority .. i don't really know from where to take the priority .. it falls here:

__STATIC_INLINE uint32_t __sd_nvic_is_app_accessible_priority(uint32_t priority)
{
  if( (priority >= (1 << __NVIC_PRIO_BITS))
   || (((1 << priority) & __NRF_NVIC_APP_IRQ_PRIOS) == 0)
    )
  {
    return 0;
  }
  return 1;
}

also, not sure what is the distance (second parameter for the function) units, 

"The time from an Active event until the radio is activated." time in sec / ms / micro sec / nano sec ?

also, does it means the time from an advertise start till the handler is called? 

if it set to 0, can it cause some problems since i change the data transferred in the advertised packet ?

best regards

Ziv 

[Karl Ylvisaker]

Hello again Ziv,

ziv123 said:

it falls on the priority .. i don't really know from where to take the priority .. it falls here:

What error is generated? Which arguments did you pass the failing function?
I will need more information to help you.

ziv123 said:

also, not sure what is the distance (second parameter for the function) units,

ziv123 said:

if it set to 0, can it cause some problems since i change the data transferred in the advertised packet ?

Please use the defined enumerations. You may not configure the Radio Notification to be generated 0 us before the next Radio Event, as that would be at the start of the Radio Event itself.

ziv123 said:

also, does it means the time from an advertise start till the handler is called? 

That depends, you can be notified either / both before the next Radio Event, or after. Please see the Radio Notification feature documentation, an exempt reads:

If it is enabled, the ACTIVE signal is sent before the Radio Event starts. Similarly, if the nACTIVE signal is enabled, it is sent at the end of the Radio Event. These signals can be used by the application developer to synchronize the application logic with the radio activity. For example, the ACTIVE signal can be used to switch off external devices to manage peak current drawn during periods when the radio is ON, or to trigger sensor data collection for transmission during the upcoming Radio Event.

Best regards,
Karl

[ziv123]

Karl Ylvisaker said:

Which arguments did you pass the failing function?

i passed ' NRF_RADIO_PRIORITY_NORMAL ' 

err_code = ble_radio_notification_init(NRF_RADIO_PRIORITY_NORMAL, NRF_RADIO_NOTIFICATION_DISTANCE_5500US 	
, data_update_timer_handler);

and it fails

[ziv123]

hi Karl

i managed.. i copied the APP_IRQ_PRIORITY_LOW from the example and now it works.

not sure if it works better or how much is a safe distance for a 31 bytes beacon (for now i set it to NRF_RADIO_NOTIFICATION_DISTANCE_3620US ) 

i still only encode the new advdata and nothing else within the handler .. seems ok, hope no surprises later.

so a lot of thanks on this long long thread for now, my fault, though i guess i am always worried that new threads takes longer time to get replied 

we can close this thread i think.. for more questions on this matter or other i will open a new one 

best regards

Ziv

[Karl Ylvisaker]

Hello Ziv,

ziv123 said:

i passed ' NRF_RADIO_PRIORITY_NORMAL ' 

ziv123 said:

and it fails

I will need to know which error is generated when a function fail, to be able to help you find the root cause. However, it here seems that you were able to resolve the issue yourself, great!

ziv123 said:

not sure if it works better or how much is a safe distance for a 31 bytes beacon (for now i set it to NRF_RADIO_NOTIFICATION_DISTANCE_3620US ) 

i still only encode the new advdata and nothing else within the handler .. seems ok, hope no surprises later.

As long as you keep the event handler short ( such as just updating the advdata structure ) you should be fine - 3.6 ms is a long time.
However, you should make sure that this update is not postponed due to some other high-priority ( application layer, non-SoftDevice ) event is being generated and processed in the meantime.

ziv123 said:

so a lot of thanks on this long long thread for now

It is not problem at all, Ziv. I am happy to help!

ziv123 said:

my fault, though i guess i am always worried that new threads takes longer time to get replied 

We do not prioritize new tickets over old tickets, no worries. To receive better help faster, it is key to provide all the necessary information immediately, so we quickly get up to speed on the issue and conditions you are facing.

ziv123 said:

we can close this thread i think.. for more questions on this matter or other i will open a new one 

Great! Please do not hesitate to open a new ticket in the future if you should encounter any other issues or questions.
To keep the forums tidy and easy to navigate, it is best to open a new ticket as soon as the questions diverge from the initial ticket.

Good luck with your development, Ziv!

Best regards,
Karl