Advertisement in time slot API at 100ms with connection handling in softdevice

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

Dmitry — Tue, 26 Feb 2019 17:23:50 GMT

You can count required length by yourself - for example, if your advertising data takes 28 bytes, one packet takes (16:header + 28:data + 3:crc) * 8 = 376 usec, and full 3-channel cycle will take 376+400+376+400+376 = 1928 usec. Here is another point - since you don't expect any response from host, you can decrease interval between packets to 150 us (NRF_TIMER0->CC[0] = 150) and maybe even more. The shorter your slot, the better chance that it won't be blocked by SoftDevice.

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

NO69124 — Tue, 26 Feb 2019 16:52:21 GMT

I have set up two different addresses so that the two advertisements show as two devices in nrf Connect.

Do you think I should try to reduce the length of the windows in order to avoid being interrupted by the stack ?

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

Hung Bui — Tue, 26 Feb 2019 16:49:42 GMT

Do you have the same address on the connectable and the non-connectable advertising packets. If you do, this maybe just the distance between them not the distance between each non-connectable advertising packets.

It depends on the size of the advertising packet and the number of channel, I think 5.5ms should be enough, especially when you don't have any RX window to listen to any request.

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

NO69124 — Tue, 26 Feb 2019 16:06:56 GMT

Here is what nrfConnect shows me some messages with 100ms and some with <5ms. See below :

Thanks for the responses. I see now that those errors might be normal.

I will try tomorrow to check with a logic analyzer.

Do you know by any chance if the length of the time slot I have configured (5500us) is enough or maybe too big a single advertisement packet ?

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

Hung Bui — Tue, 26 Feb 2019 15:09:18 GMT

Hi,

I'm not really sure why you have 5ms between two messages. Isn't it the interval you plan to have is 100ms ?
One trick to show how the timeslot is being scheduled is to toggle a pin when you are inside a timeslot. Then using the logic analyzer to visualize it. It would be very useful if you can provide one.

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

Dmitry — Tue, 26 Feb 2019 14:06:43 GMT

As you can see in the code, in case of conflict it schedules earliest timeslot. You have two ways: instead, schedule next slot in double adv_interval (blocked advertisement is lost in this case), or set some flag on error to skip radio activity in earliest slot, just schedule next one right in NRF_RADIO_CALLBACK_SIGNAL_TYPE_START (sometimes interval will be a bit larger than 100 ms). Anyway SoftDevice should have a priority over a beacon packets - broken connection is much worse thing than lost advertisement, and you have no way to get stable 100 ms interval while any connection is active. Again, I don't see any issue with that.

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

NO69124 — Tue, 26 Feb 2019 13:07:57 GMT

OK. I see the "TODO: A proper solution should try again" in the evt_handler. Is there a better way to handle those errors ?

When I look at the iBeacon advertisement packets in nrf Connect, it seems that the advertisement interval is not very stable. Sometimes I have about 100ms between two messages, and sometimes, I end up with less than 5ms between two messages. Is there a way to get a stable interval and avoid these <5ms interval packets ?

RE: Advertisement in time slot API at 100ms with connection handling in softdevice

Dmitry — Tue, 26 Feb 2019 12:53:45 GMT

You get radio errors because your advertisements sometimes overlap with SoftDevice ones. This might be an issue when you're implementing a connection over a timeslot. But in case of advertisements, there's no strict timing requirements, so just ignore these errors - they're handled in app_beacon_on_sys_evt().