This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Multiple beacon advertisement

Hi,

I am trying to find a good solution for multiple beacon advertising using s132_nrf52_3.0.0_softdevice and sdk 12.1 on nrf52.

Looking at other similar threads: devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

I can not find a recommended approach to this requirement. Even the sample codes do not advertise more than one beacon at the time, for example Eddystone example in sdk (ble_peripheral\experimental_ble_app_eddystone) does not rotate advertising the three eddystone frame types, just advertise uid. Seems to be due to SD limitation to track one radio activity at the time.

Would you please help with best recommended approach to implementing the following requirements to have the frames below advertised in rotation?

  • iBeacon advertisement -- configurable from 100ms to 10000ms, fixed payload.
  • Eddystone TML advertisement mainly (if not all: Eddystone-UID, Eddystone-URL, Eddystone-TLM) -- configurable from 100ms to 10000ms with updating payload
  • Custom frame advertisement -- once a second but with updating payload

questions:

  1. Would I need to have one frame advertise on softdevice and the other two using timeslot? The current sample code (only adv. two frames, seem to be not power optimized: experimental_ble_app_multiactivity) are there better complete examples available? Please advise how it could be made power optimized, or is the use of timeslot result in more current drain.

  2. Can a dedicated application timer be used for each frame and I use softdevice call sd_ble_gap_adv_data_set() to update the advertising frame each time on interrupts or would the adv. need to be stopped/started on each interrupt? How collisions could be avoided?

  3. The Eddystone specification suggest to advertise the core -UID, -URL, -TLM by rotating them in each advertisement. Please suggest how the example should be modified to achieve this?

Thanks.

  • Then you have clearly a problem. I don't have any new magic advice on top of these you already read and linked from this forum. My last words would be: this kind of use case is known limitation of Nordic stacks and it might get really difficult to implement it even with one GAP Peripheral role and time-slots for remaining types of adv. packets (mainly because as far as I understand it these won't get through stack so these won't be connectable). If you really want to succeed going with Zephyr or other open source stack looks more promising.

Related