Timeslot API

[Kieran Affleck]

Hi,

I've asked a couple of questions around this before but that was before I thoroughly researched into what I was actually asking.

I would like to attempt to use the timeslot API, similar to the Multiple Role Observer example, to allow two S110 devices to communicate, sending data on event (such as a button press) and constantly polling to receive data.

However, I don't fully understand that example and would much prefer is I was able to simplify it to a level similar to this example and would like any advice regarding this, or an explanation to the functionality of the example itself?

Thanks

[Ulrich Myhre]

I am not sure if I understand you correctly, but you want two devices based on S110 to communicate by advertisement and scanning? And thus add the observer capability through the radio timeslot API?

First, you should consider using the S130, which supports advertising and scanning concurrently. This removes the need to think about scheduling yourself, and comes with the proper qualification (needed if you are making a product that will hit end-users). It also allows you to create a connection between the two devices and use that as a reliable communication channel, and then do non-connectable advertisements while the connection is going. The Flash/RAM requirements are a bit steeper though.

If you cannot use the S130, and I've understood your question correctly, then implementation should not be very difficult - depending on your needs. If you only need passive scanning, i.e. not sending any scan requests, you simply configure the radio to RX. You can optionally implement some rudimentary address matching yourself here to avoid interference from other advertisers. If you want to send get the scan data as well, it quickly turns into the complexity of the example you linked to. In short words, you want to wait for data in RX mode, having a SCAN_REQ PDU ready to send. When you receive an interesting advertisement that allows scanning, you fill inn the advertiser address into the PDU and send it 150us after. This is done automatically by the radio peripheral if the TIFS register is set to 150 and the SHORTS between READY/START is set. After another 150us, the radio needs to RX again to get the response. This is done in the same way. No need to set up any timers or anything.

While this is quite simple to set up, the scheduling makes it very hard to do efficiently. You have to implement some algorithm yourself to make sure that you are switching between scanning often enough, but not more than necessary. You also have to make sure you are not overstaying the allotted time you get in the timeslot itself, including the overhead of context-switching back from your handlers.

[Ole Bauck]

So you want to do something like the radio example in the SDK with continuously having the radio in RX mode on both sides unless the are sending packets, inside the timeslot? In that case you should be able to do this without problems, just make sure to also call NRF_RADIO->POWER = 1 when entering the timeslot or the registers will be inaccessible.