Radio Notification and Tprep time.

[Luk3]

Hello,

I want to use Radio Notification before connection event (ACTIVE signal). My routine takes 4 ms but Tprep time have huge range - from 167 us up to 1550 us, so even Tndist = 5500 us can be insufficient. Processed data need to be send in incoming connection event. How to estimate how long Tprep can take in my application? From what does it depend?

device: nRF52832
SD: 4.0.2

[run_ar]

Hi,

First I would recommend updating to sd 4.0.5. I am still waiting for feedback on weather Tprep can be estimated. While waiting, I assume you are aware you can also get an nActive event after the connection event and use that to prepare for the next event? is that something that could work for you? Worst case you could also start a timer on the active that you use to run your routine a bit earlier than what you can achive using only the active signal. Just use the connection interval minus the time needed to run your routine.

[Luk3]

Hi,

My device is measuring in real time user activity. Connection interval is 200 ms and I need to sample analog signal just before connection event to minimize input lag. Measured data are visualized on the LCD panel and 200 ms delay is noticeable. Using nActive and timer is solution.
Where I can find sd 4.0.5? SDK 13.1.0 comes with 4.0.2, SDK 14 comes with sd 5.0.0

[run_ar]

You can find s132 v4.0.5 on the nRF52832 product page.

Most likely you can use the active event. As you see the time the sd uses in the higher priority interrupt is 165 µs (Tp). The note that says: "Note: All packet data to send in an event should be sent to the stack t_prep before the Radio Event starts." is valid if Tprep is 167µs, but the SD will not block the application for 1550 µs before the event. So you should be able to finish processing and place the packet in the tx buffers in your case.

Note that if you decide to use the nActive event the connection event length could vary, depending on the number of packets being sent and if you use Connection event length extension, so you probably should use the active event in addition check the length of the connection event.

[Luk3]

Thank you for link. I was looking for SD in SDK package.

It's clear but in the worst case P activity will interrupt processing 42 us before end (5500 signal distance minus 4000 processing time minus 1542 worst P activity start time), after 165 us processing will end but data will be send in the next connection event.

[run_ar]

As far as I know the 165 µs of processing will happen just before the connection event, not at 1542µs, even if you get interrupted at this time. Data should be sent in the following event as long as it is placed in the buffers before 167µs.