Hi,
I have an application which is developed using nRF5 SDK version 17.1.0
Migrating to nRFConnect SDK is not an option at this stage of the project.
The application uses the SoftDevice version s140_nrf42_7.2.0_softdevice to communicate with mobile devices using BLE. The mobile devices are typically iPhones or Android phones.
Further - my devices communicate with each other to share fine timing information using ESB packets. The exchange of timing information is scheduled using the Timeslot API. I think that this is well trodden ground, from what I can make out.
The structure of the application closely follows the example here:
In accordance with the example above, I request a first timeslot of type NRF_RADIO_REQ_TYPE_EARLIEST.
In the callback from this timeslot, I calculate the time I need to wait until my desired packet exchange, and request further timeslots of type NRF_RADIO_REQ_TYPE_NORMAL with NRF_RADIO_PRIORITY_HIGH to schedule my real packet-exchange timeslots at accurately defined times. The subsequent timeslots are requested from the radio_callback via the return code NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END until the final slot has been granted, when I return from the radio_callback with the return code NRF_RADIO_SIGNAL_CALLBACK_ACTION_END.
The layout of my timeslots is as follows (the scope traces show a 1s reference clock, and a GPIO which is just being used as a timing flag for observation):
All timeslots requested are 40ms long, and as you can see, the cadence is as follows:
SLOT 1: (Type NRF_RADIO_REQ_TYPE_EARLIEST)
This is scheduled close to the falling edge of a 1.0 second clock. I have no expectation of the accuracy of the arrival time of this slot.
SLOT 2: (Type NRF_RADIO_REQ_TYPE_NORMAL)
The distance of this slot from the previous (EARLIEST) slot will be close to 1.0s, but is calculated and scheduled appropriately to arrive right on the next falling edge of the 1.0s reference clock. This is the first slot whose arrival time I care about.
SLOTS 3 and Subsequent: (Type NRF_RADIO_REQ_TYPE_NORMAL)
These are all scheduled to be exactly 1.0s after the previous timeslot.
This scheme works well, with all slots being scheduled correctly, until I introduce BLE connections.
If one device has a BLE connection to the central, then everything still works correctly.
If two or more of the other devices also have connections to the central, then I start getting timeslots cancelled.
- The first timeslot (which is of type NRF_RADIO_REQ_TYPE_EARLIEST) is never cancelled. It is always granted and always arrives.
- Subsequent timeslots of type NRF_RADIO_REQ_TYPE_NORMAL are frequently cancelled with an NRF_EVT_RADIO_CANCELED event to the signal handler.
I have experimented a little with the BLE GAP parameters, and have some reason to believe that they have an impact on the probability of success of the timing scheme above.
I haven't been able to find any guidance on how to set the parameters of my BLE connection to help the Timeslot API to schedule what seems like a fairly relaxed requirement (a 40ms timeslot once every 1.0s for a maximum of 10 repetitions).
My question is as follows:
Is it possible for me to arrange the scheduling, or the parameters of my BLE connections to improve the rate of success of the timeslots?
- I have some flexibility to choose the length of the timeslots, and the interval between them if that can help
- I can also set different minimum connection intervals, maximum connection intervals and slave latency.
- Typically, I have been using a minimum connection interval of 20ms, a maximum of 100ms and a slave latency of 5. But I have some freedom to change these if necessary.
I'd greatly appreciate any suggestions. I can share code if necessary - though my code isn't very different from the example, and I have the feeling that this is more of a setup issue than a hunt for a code bug.
Thanks in advance..