Use radio interrupts to determine when a broadcast starts or a scan starts or ends

[372020552]

I see an example of a central device and peripherals as one, and I see it using the following three registers to determine the start or end of the broadcast, the beginning or end of the scan, and the beginning or end of the Bluetooth connection during a radio outage:

NRF_RADIO->POWER

NRF_RADIO->FREQUENCY

NRF_RADIO->SHORTS

NRF_RADIO->POWER	NRF_RADIO->FREQUENCY	NRF_RADIO->SHORTS	remark
==0			According to the following three judgments is the end of the broadcast or the end of the scan or the end of the connection event
!=0	==2	==0	Think it's the beginning of the scan
!=0	==2	!=0	think it's the beginning of the broadcast
!=0	!=2	do not care	Is thought to be the beginning of a connection event

I have not found a basis for appeal in the official documents, I would like to ask if this is a basis? Or can you tell if the scan starts or ends, the broadcast starts or ends, and the connection event starts or ends based on the devices above that are integrated with the central and peripheral devices?

[run_ar]

 Hi,

We do not have a map for this. And I do not think you will be able to predict what the next event is by looking at these registers (probably depend a little on the complexity of your application). Guess you can see that broadcast and connection as master will always start with a TX, then RX. While in Scan and Connection  as peripheral, it will start in RX, then TX. Maybe if you combine this with a timer to keep track of events you could better predict the next event (problem is broadcast has a random component, and if you have multirole it will be hard to predict how the scheduler will priorities conflicting events, in addition the scheduler can change this really close to the actual event). Also you could use the radio notification api to get an event prior to and/or after an event (This also triggers on flash activity, but shouldn't be a problem if you check the radio power register).

What is the use case for this? why do you need to try to predict the next event and previous event?

[372020552]

Thank you for your reply!

I think of a peripheral and central device as one device, broadcast interval 300ms;The scan window is 250ms and the scan interval is 300ms。

I want to broadcast in the scan idle 50ms, that is, after the scan idle start 25ms this point in time broadcast, this time I need to scan after the start of a 25ms timer, when the timer time is up, turn on the broadcast。So I want to know the end of the scan。

[run_ar]

Hi,

Do you plan on having any other roles at the same time? like a connection? or is this the only scenario where you need to predict roles? It this is the only scenario you could use radio notifications on the inactive event to start a timer that lets you start advertising in the 50ms window. Please remember the advertiser has a 0-10ms random number so it's not possible to time it to exactly 25ms. due to this random number you will have to only advertise once, if you try to have a advertisement interval of 300ms the advertisements could drift and conflict with the scan window.

One option if you need to have the advertiser at that exact option, is to use the timeslot api and implement your own advertisement routine at this exact place. But keep in mind you might violate the bluetooth core spec if you do not have the random delay for the advertisement.

[372020552]

Thank you for your reply!

Do you plan on having any other roles at the same time? like a connection?

Answer：Yes；

I wonder if broadcasts and scans are scheduled by the protocol stack on devices that are integrated with peripherals and central devices to ensure that they do not conflict, and that users only need to set the corresponding time parameters (e.g. broadcast intervals, scan window times, and scan intervals)? At the same time as peripherals and central devices as one of the devices, through radio event interruption inactive and inactive events is difficult to predict is the beginning and end of the broadcast, the beginning and end of the scan?

[run_ar]

The central role connection and the scanner is scheduled to avoid conflict if you use the right parameters. But the peripheral role is set up by the peer device and could be in conflict with one of the other role. The SD will then prioritize according to the table: SoftDevice timing-activities and priorities And yes broadcast is also hard to predict as it has the random component as part of it's advertisement interval.

[372020552]

Thank you very much！