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?

[Pete]

Commenting out this: github.com/.../timeslot.c seems to fix the busy loop, and the mesh still renews the timeslot. I'll continue to see if I have other side effects from commenting that out. The only other thing that is weird is that it seems like the timeslots are 19ms in length, when I would expect 10ms since m_ret_param.params.extend.length_us is set to 10000.

[Hung Bui]

Hi Pete,

I can see the same issue here. We will investigate further. One thing you can change is to increase TIMESLOT_SLOT_EXTEND_LENGTH_US and see if it would occurs less often. Commenting out the extending code is not recommended. We will check why there is such a long busy loop.

19ms maybe is the result of 10ms initial timeslot and 01 extension, just my guess.

[Pete]

I don't think changing TIMESLOT_SLOT_EXTEND_LENGTH_US would have an effect, since the busy loop is already a much faster cycle than that. It looks to me like the callback is trying to extend the timeslot immediately after every callback that indicates the timeslot was successfully extended. So I would expect a busy loop. Shouldn't the timeslot only be extended after some delay?

[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.