1 of 1 people found this helpful
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.