Force BLE Stack to skip connection events

Hi Morten, 

If you know when these events will occur, you can set up slave latency. 

A dirty trick would be to just hold the link-layer-engine in reset while you want to block RF activity. It can be done in the LLECTRL register. There is every chance that it will crash the stack, though. 

An elegant way would be to go into the OSAL task list, delete the next connection event and schedule the one after that. 

Peder

Hi Peder,

I am also interested in doing this, and I am looking into deleting connection events.  I'm assuming that the connection events are handled by the LL in LL_ProcessEvent.  Is this correct?

I don't see a way to find out what events are scheduled.  I can put in a breakpoint and read the value for events but I don't know what the events are and I don't see any OSAL events listed in ll.h or anywhere else to be honest.

Can you give me a few more hints on how to achieve skipping connection events?

Thanks,

Jacob

Hi,

If you specifically want to skip connection events, the only way to do this would be to:

- Use slave latency with some value
- In the normal case if you don't want slave latency, call HCI_EXT_SetSlaveLatencyOverrideCmd
- When you want to skip:
-- (Disable SlaveLatencyOverride if applicable)
-- Send a notification or something, so that a connection event is forced
-- Disable fast-tx via HCI_EXT_SetFastTxResponseTimeCmd()
-- After the next connection event, you should now have an RF-silent period, unless the stack must respond to or acknowledge an LL control packet or do a retransmission.

The reason it sounds a bit shaky in that last point is that we have no facility to circumvent the BLE specification for this 'feature'.

Best regards,
Aslak

Thanks for the response.  The reason I want to skip events is because I'm working on an application that turns on some timing critical behavior which requires sub-ms response times when the task is active.  I have observed that the Bluetooth stack appears to have both OSAL tasks and ISR calls that last for more than 1 ms which destroys my desired behavior if it happens while I am performing the timing critical task.  When the critical task is done I need to switch back to the highest possible connection speed for data transfer however.

To prevent Bluetooth from interrupting the timing too frequently I am currently requesting connection parameter updates from time to time.  I thought it would be easier to stay at a faster connection interval of 20ms, set a relatively high slave latency, and then just skip connection events when I'm running the timing critical task.

It sounds like HCI_EXT_SetFastTxResponseTimeCmd() may be exactly what I'm looking for.  I don't need to skip specific events, I just want to skip the maximum allowed based on the connection parameters.  I'll give this a shot.

Thanks!

Jacob

A more passive approach would be to use HCI_EXT_ConnEventNoticeCmd() to let you know when a connection event ends. Then use LL_TimeToNextRfEvent() to figure out when the next link layer events.  If you have enough time to do the task do it, otherwise wait until the chip decides to use the slave latency.