Broadcast Scan Request Acknowledgement

RE: Broadcast Scan Request Acknowledgement

Madhuri — Sun, 15 Jan 2017 05:28:19 GMT

hello seth,

I have exactly same requirements as you do but, additionally i need a timer and gpiote handler to run in background. do you ppl still suggest me to go ahead with nRF51 observer and advertiser or the solution like petter suggests. please guide me.please find post link text

thank you

RE: Broadcast Scan Request Acknowledgement

Petter Myhre — Mon, 20 Apr 2015 12:05:13 GMT

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

RE: Broadcast Scan Request Acknowledgement

Seth — Fri, 23 Jan 2015 20:40:09 GMT

Thanks, this is really helpful as well. -Seth

RE: Broadcast Scan Request Acknowledgement

David Edwin — Thu, 22 Jan 2015 10:16:25 GMT

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.

RE: Broadcast Scan Request Acknowledgement

Seth — Wed, 21 Jan 2015 15:17:22 GMT

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

RE: Broadcast Scan Request Acknowledgement

Petter Myhre — Wed, 21 Jan 2015 09:41:08 GMT

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.