Broadcast Scan Request Acknowledgement

[Seth]

My application:

I have a peripheral (S110) that registers important alerts and immediately broadcasts them to any central that is listening. There will be some amount (ideally 10-12 bytes) of manufacturer specific data in the advertisement packets. It is very important that at least one device recognizes the alert being broadcast, and as such I am trying to build my application to broadcast until it knows that the alert has been "heard". I had initially hoped to use the peripheral as a simple broadcaster that accepted a scan response as a form of acknowledgement (I didn't need the second packet to transfer more data, but I wanted to use the response from the central as the acknowledgement.) However, I’ve found that there is no straightforward way to create an application event when the SoftDevice receives and responds to a scan request.

Additional application constraints This is a battery powered device and needs to conserve as much power as possible, so I want to stop broadcasting as soon as a central get the alert, or after some timeout. I hope to not ever timeout as the alerts are important, but I also don’t want the device broadcasting until it dies if nothing is around to receive the alert.

Another constraint is that the peripheral device is going to have a more powerful antenna and longer range than the centrals (smart phones). This means that there will be times when something picks up the alert, but doesn’t have the range to transmit the response. This also means that a dedicated connection is impractical (and I want multiple phones to be capable of receiving the alert).

I did a ton of research through devzone and found a few people trying to do similar things. Here are two workarounds that I found, and a possible 3rd option that I’ve come up with:

Use the timeslot API and circumvent the SoftDevice DevZone post: devzone.nordicsemi.com/.../

I haven’t tried this yet but I’m hesitant to use non-supported code for my application because this is one of the most important features, and I don’t feel comfortable debugging this example code if problems arise. Additionally, this does slightly more than I need in that it gives information about the central that responds to the scan request, which I don’t need (just an acknowledgement that something has heard.

Use radio notifications DevZone post: devzone.nordicsemi.com/.../

The basic idea behind this is to use radio notifications and the timer to measure the amount of time the radio spends in transmit versus receive modes, and infer that a change in the time (I’m not clear on what this difference would be exactly) to detect when a scan response has been issued. The post says that this method would be “pretty reliable”, but it sounds pretty hacky to me.

My possible solution/question Would it be possible to advertise as a connectable device and then simply sever the connection when the central responds as a means of alert acknowledgement (or timeout after a specified time)? This would still need to send the manufacturer specific data in the advertising packets. Is this a feasible solution? How would this method affect the power consumption of the device? Any comments on this approach, or an alternate strategy would be greatly appreciated.

Finally I would love it if Nordic added this to the SoftDevice’s capabilities!

Thanks, Seth

[Petter Myhre]

Thank you for the detailed and clear description.

Timeslot: If you get into trouble with the examples from GitHub we will still support you as best as we can.

Radio Notifcations: It sound a bit hacky to me as well, but it could work.

Your solution: It should be possible. Please see this. You could simply disconnect when you get the BLE_GAP_EVT_CONNECTED event. Then you could stop sending alerts. It is hard to say how much it will affect the power consumption, it depends on how often these alerts will be sent, and how many centrals that are going to get them.

With the next release of the S110 SoftDevice, version 8, it will be possible for the application to be notified when the SoftDevice receives scan requests. If you are interested in when it will be released you should contact the Sales Manager for you area. If you don't know who it is, please send me a PM with your location.

[Seth]

Thanks Petter! This is a great answer all around. I'll ask about the release of S110 8, and I think for the time being I will try using my solution. Thanks, Seth

[David Edwin]

The [nRF51 Oberver and Advertiser over the timeslot] (github.com/.../nRF51-multi-role-conn-observer-advertiser) will be supported and enhanced and use it if it fits your needs and timeline. I would also encourage you to use it to understand your solution and then wait for the S110 v8 for a Softdevice based solution. This will give you better control and understanding of your solution.

Additionally the Timeslot based solution allows you to even access packets with a bad CRC i.e. even if the central's scan request was not picked up fully by the radio, this may be useful as when you have multiple centrals around the broadcaster, they are very likely to trash the scan request and the connect request (esp. if there are multiple centrals). So if you actually get a packet on the RX when you are expecting a scan request, the solution allows you to see that something was attempted to be sent. You will not get such fine control on the softdevice implementations.

Additionally: You can modify the code to send connectable advertisements so that the CONNECT_REQ can be used the acknowledgement and the link will be automatically severed. This acts as an ack and has the limitation of the central needing 6 x connection interval used to detect the link loss on the central side. However this does not have any impact on the broadcaster side.

Suggestions - summary : Use the nRF51 Oberver and Advertiser over the timeslot as it is now, iterate on it and provide comments, we will be happy to improve it. You can then eventually move to the S110 v8 when it is available for your needs, but the time can be used to validate this solution. It is also possible due to the fine radio control available that this is actually a better solution.

[Seth]

Thanks, this is really helpful as well. -Seth

[Petter Myhre]

This is not an answer. Add it as a new question, and link to this question if it is relevant.