Open Mesh radio_signal_callback busy loop

[Pete]

I was having some troubles using the app_timer (RTC1) shortly after mesh startup, so I enabled the PIN_IN_CB and PIN_IN_TS debug pins, and saw some interesting behavior.

My app periodically calls rbc_mesh_enable(). On the first enable, it looks like everything is fine, and we're in the timeslot with what looks like random infrequent calls to the callback.

After calling rbc_mesh_disable(), waiting about 100ms ,and then calling rbc_mesh_enable(), there is a period of ~20ms that looks ok, followed by a period of very frequent callbacks to radio_signal_callback that lasts about 66ms. During this time, I do not receive any RTC1 callbacks.

Any ideas what this might be?

[Hung Bui]

Hi Pete, How often do you have BLE activity in your application ? I did a test here and count the number of NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED multiply by TIMESLOT_SLOT_EXTEND_LENGTH_US I get exactly the size of the time slot I have (usually it's the advertising interval minus a few milliseconds).

So what happens is that we try to request as quick as possible maximum size for the timeslot but requesting each time TIMESLOT_SLOT_EXTEND_LENGTH_US and request again when we get approved (NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED event). After that the CPU won't be waken up again to do extending.

If you comment out the line you mentioned, we only request extension when we start a timeslot. This result in 19ms timeslot as you have seen (not sure why it's not 20ms).

We would suggest you to increase TIMESLOT_SLOT_EXTEND_LENGTH_US to 50 or 100ms, then the number of NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED will be reduced and you should see shorter period where the PIN_IN_CB is toggled.