connection event -- bleprofile_sendNotification -- when is transmit queue locked out

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
joki_2146851
Level 3
Level 3
5 likes given First like received First like given

In my application, I'm trying to readout data just before it gets sent to minimize latency.

Currently I am using the 1.2 SDK because I use the 20732s module. I can't use the new features that give me a callback to perform a readout just before the connection event, so I'm stuck using the fine timer. After studying the fine timer I have found that though the timer is almost synced with the connection events (connection interval set to 50ms, fine timer set to 50ms) when going into sleep is disabled, however there is time walk between the timer firing and the transmission  signal (I monitor the current impulse on the chip to see the transmission). This time walk prevents me from minimizing the latency between reading the data and the connection event when sleep is

disabled.

When sleep is enabled, the timer fires just before the connection event, but I'm not sure how much just before as the current monitoring I have is not perfectly precise. The problem I have is that when I read out in the timer and call bleprofile_sendNotification, the send seems to either be buffered by one connection event, or the transmit queue is locked or something like that once the connection event begins and doesn't allow what I have enqueued at the beginning of the timer event to be sent immediately.

Can someone answer what happens with respect to the transmit queue when the connection event starts with respect to the timer, and perhaps how much time I have to try to cue the data before the queuing is locked out (or whatever is happening happens)?

Is there anyway to adjust when the finetimer with respect to the connection event in sdk1.2? I actually tried something sneaky trying to set the xstal warm-up period longer so that the timer may fire later, closer to the next connection event, but that did not work either as that just left the timer firing at the same time and just leading with more warm-up time. Perhaps there is some chip configuration register that might control this?

also I have been using the two functions a bit:

bleapputils_currentTimeUs() and

bleapputils_currentNativeBtClk

What clock are these based on?

0 Likes
1 Solution
Anonymous
Not applicable

As a workaround, I advise that you set the fine timer to as low as it will go (12.5ms) and update the sensor data as frequently as possible within the 50ms connection interval. This will minimize latency to the minimum duration of the fine timer at the cost of power consumption. If you can get the timer properly aligned, then you can further minimize the latency to below the fine timer interval, but this method will guarantee a worst case of 12.5 ms if you miss the interval on the 4th timeout of the interval.

>>Can someone answer what happens with respect to the transmit queue when the connection event starts with respect to the timer, and perhaps how much time I have to try to cue the data before the queuing is locked out (or whatever is happening happens)?

Answer: This would require very low level analysis by developers to say exactly how long before TX the queue is locked. Moreover, using the fine timer you will not be able to achieve the level to synchronization necessary for this information to be relevant.

>>Is there anyway to adjust when the finetimer with respect to the connection event in sdk1.2? I actually tried something sneaky trying to set the xstal warm-up period longer so that the timer may fire later, closer to the next connection event, but that did not work either as that just left the timer firing at the same time and just leading with more warm-up time. Perhaps there is some chip configuration register that might control this?

Answer: No, the fine timer is a very low priority app-level timer, and will not allow you to reliably achieve the level of synchronization that you want.

View solution in original post

1 Reply