periodic timeslots problem

[yaron]

Hi

I am using nrf52832 with softdevice s132_nrf52_3.0.0. In my appliocation I need to do periodic measuremets, and it is critical that softdevice doesn't interrupt during the mesurement period. I have tried using the timeslot API to do that, but I can't get periodic timeslots without delays. (once every x ms I get "NRF_EVT_RADIO_BLOCKED" event and need to request a new timeslot).

My default advertising interval is 40 ms, and my measure period is also 40 ms (needed slot length of 1 ms). I have tried chaning the advertising interval, but it doesn't solve the problem. I am asking for timeslots using "NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END" with high priority.

Can I achieve periodic timeslots without any delays?

[Øyvind Karlsen]

Hi,

If you request a timeslot every 40 ms and also use an advertisement interval of 40 ms there is always a chance that they will collide. Longer timeslot lengths increases the chance of collision.

Do you only need to advertise, or will the device connect as well? If you need to just advertise the solution is straight forward. Use radio notifications that trigger after each advertising event. Then you will automatically get your 40 ms measurement interval.

Best regards,

Øyvind

[yaron]

Hi Øyvind I have tried using radio notifications, but I saw that I still don't get periodic T.S. I have measured the timimg difference between consecutive radio notifications (active only), and got 40-50 ms.

In SoftDevice Specification S132 SoftDevice v3.0, section 16.5 you can see that the time difference between consecutive advertising events is "Adv Interval + random delay". Can I set the random delay to 0?
Thanks Yaron

[Øyvind Karlsen]

Hi,

See this thread.

What kind of measurements are you doing, and are you sure that they must be 100% periodic?

BR,

Øyvind

[yaron]

I am measuring SAADC, and it must be 100% periodic. Is there some example using Nrf52?

[XavierYin]

What about setting up PPI which connects RTC event and SAADC tasks for periodical measurements. Perhaps further setup SAADC cross-limit events and only trigger interrupts in such events. Ideally your MCU will not leave sleep simply for checking SAADC measurements, it only need to work when some real-world event happens.