Time slot jitter range?

[eyalasko]

Hello,

Out application is using the time slot api to generate ~29ms (35Hz) burst of pulses.

Occasionally, the interval between two adjacent pulses extends to ~35ms (i.e. +6ms).

I could not find any information on the time slot delay ranges (referring to the requested interval), what is the maximum delay one can expect?

What factors affect this delay, how it can be minimized (at least statistically)?

Our platform is nRF52832, SDK15.2, Softdevice S132 6.1.0

Thanks for any advice.

[ovrebekk]

Hi 

What kind of pulses are you talking about? 

If you are generating pulses on an IO pin there might be alternative ways to do this that would not be dependent on the accuracies of the timeslot (connecting a timer directly to a pin through the PPI for instance). 

Can you give me a bit more information about what the SoftDevice is doing in this scenario? What kind of Bluetooth activity is going on when the issue occurs?

Best regards
Torbjørn

[eyalasko]

Hi ovrebekk

I'm using 4 PPI channels (triggered by Timer) to generate a sequences (a.k.a. 'pulses') that control a medical system.

Each sequence is comprised of 4  gpios toggling within window of <1ms.
11 sequences, spaced ~29ms apart form a burst (total burst time of approx 300ms).
Occasionally we get ~35ms between adjacent sequences (marked in the attached photo)
Burst is triggered by a physiological algorithm every few seconds.

The phenomena happens when in a BLE connection (not sure about the connection parameters though),
BLE Communication from the application side occurs only in between bursts

[ovrebekk]

Hi

Have you checked the possibility of using the PWM module to create these pulses?

Depending on how the 4 GPIO's are toggled within the 1ms window it is quite possible the PWM can be configured to do the same, while allowing you to just playback a long sequence of PWM values from RAM. 

As for the issue with the timeslot it is a bit weird you would see such a long delay if there is no BLE activity other than keeping the link alive. Is there any way you can find out the connection interval used?

I will check with the stack developers if they have some idea what the cause of the delay might be. 

Best regards
Torbjørn

[eyalasko]

look here, similar jitter was discussed before in this forum, might be a clue...

[ovrebekk]

Hi 

Not sure how much it helps. You could use the radio notification feature, but unless the connection interval is longer than 300ms you would still be hit by radio activity at some point. 

Could you try to map the RADIO READY and END events to a pin using the GPIOTE and PPI?

Then you will get a pin toggle every time the radio is active, and it should be possible to verify both what connection interval is being used, and how the radio activity is playing into this. 

Best regards
Torbjørn