ble_radio_notification_evt_handler_t timeslot API and softdevice

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

endnode — Wed, 01 Feb 2017 12:54:12 GMT

On a first look it seems to me kind of overkill to fire timer for one-time period on each such event, I'd rather set infinite timer and sync it once with adv. interval (and then resync as needed - hourly or longer?). Again it works until you don't require 100% timer accuracy over long periods. In that case you would need to go with custom (or open source) stack and make this inherit feature of low layers...

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

Roger Clark — Tue, 31 Jan 2017 22:42:08 GMT

Johnnofleek

Yikes...

I presumed the same as you, that the radio event related to when the radio was going to transmit, not all of the internals of what other stuff it was doing

I wonder if there is a way to read some other register or part of the SD to determine what the event was caused by.

But, If you get loads of interrupts, I guess, checking for what the type of radio notification, is going to wake the CPU up far too much, and not be a usable solution for low power application.

I think Nordic need to clarify this, and how you are supposed to update data in between transmissions.

BTW. I see that the event handler is passed a flag to say when the radio is inactive, so wonder how many interrupts per advertising period you get when that flag is false

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

johnofleek — Tue, 31 Jan 2017 21:12:17 GMT

Roger The radio notification event looks like it's driven - not surprisingly - by all radio events - so in my case we get 10ish events per second from the timeslot , 2ish per second for the soft device advert and some additional ones. You are correct you can select a notification delay and also test to see if the event indicating the start or end of the timeslot. I was hoping the events only occurred for softdevice related radio events but I was wrong. It would be great if we could sync the advertising data with the transmissions - but without a "source" indicator I think we will have to live with the random ish updates. Thanks for the info on the receivers missing data - in our use case it's not the end of the world but it would be good if we weren't adding additional random behaviour (1,2 or 3 transmissions) to the system

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

Roger Clark — Tue, 31 Jan 2017 20:03:27 GMT

could you start a timer from a radio notification event, for half the period of the advertising ?

I still dont understand the issue with "context" here, cant context issues be overcome with a global semaphore

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

Roger Clark — Tue, 31 Jan 2017 20:01:00 GMT

Johnofleek

can you explain in a bit more detail why the radio notification doesnt work for you?

I have not personally used it, but I thought there were settings to be notified in advance of the transmission.

Are you just advertising e.g. is this just a beacon?

BTW. Are you aware that virtually no receiver , especially in a phone, gets data every advertising transmission.

In my experience, phone apps often only get notified of about a third of the actual transmissions

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

johnofleek — Tue, 31 Jan 2017 14:23:41 GMT

I'm currently running a 1 second timer and updating the ble advertising data when the timer event occurs. The softdevice advertises every 500ms Over the air I see either 1,2 or 3 advertisements with the same payload I think this means that the advertisement intervals are not sync'd with the standard app timers -I guess this could be due to the time slot advertisements clashing with the softdevice advertisements It's a shame there's no context available in the ble_radio_notification_evt_handler_t cbh. I guess we could synchronise the updates by putting some sort of semaphore between the main timer and the ble_radio_notification_evt_handler_t cbh . Maybe also speed up the main timer to 500ms

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

endnode — Tue, 31 Jan 2017 11:40:06 GMT

Hi Kristin, Roger,

I believe that timer actually might solve it if you set it to the middle of the adv. interval then jitter should oscillate a bit but in average you could run both adv. interval and timer in sync. Of course this isn't usable if you need 100% precision over long period of time (hours/days).

Cheers Jan

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

Roger Clark — Tue, 31 Jan 2017 10:22:06 GMT

@Kristin

Thanks for the clarification

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

FormerMember — Tue, 31 Jan 2017 10:11:38 GMT

Yes, that's correct. So probably it is better to use the timer to update the advertising data every N'th connection event. In some cases, the advertising data will be updated every N'th interval, and sometimes every (N-1)'th interval (due to the random delay for each advertising event).

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

Roger Clark — Tue, 31 Jan 2017 09:11:35 GMT

Kristin

Isn't there automatic jitter introduced in when the device advertises, (to prevent collisions) ?

Is there any conflict there ?

BTW. I do something similar (using the App timer) but I only update the advertising packet every 15 seconds, with a 1000ms advertising period.

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

FormerMember — Tue, 31 Jan 2017 09:00:59 GMT

The easiest way to change the advertising data between two advertising events, is to use app_timer/the RTC to run with the same timeout interval as the advertising interval. Since we know that the advertiser will advertise at a given interval, having app_timer/the RTC to update the advertising data with the same interval will make the advertising data change for each advertising event.

RE: ble_radio_notification_evt_handler_t timeslot API and softdevice

endnode — Mon, 30 Jan 2017 16:22:57 GMT

Interesting question. I'm using radio notification events to alter adv. data because I never run connection and GAP Peripheral role simultaneously. Hard to say how to filter out other events when running in parallel... Looking forward to the answer;)