Sending and receiving beacons on demand.

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Fri, 24 Apr 2020 09:16:47 GMT

Hello,

[quote user="ilnadi"]Please see attached wireshark log we took using a PCA10000 with nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3. If the timing is what you would expect from S140, then we wil evaluate the timeslot example further.[/quote]

I have taken a look at the provided sniffer trace, and I have some questions:
I see 10+ devices - which one is the beacon in question? Please capture the traffic from the specific device, instead of capturing all devices(since there is a lot of BLE noise in development environments). We will only need to monitor and evaluate 1 of the beacons, to determine if their advertising timing is feasible for your application.

I am also not sure what you mean when you say "if the timing is what you expect from S140", could you elaborate?
If you would like me to check if the beacon is behaving as expected, you would need to provide your connection parameters and wanted behavior.
Could you also tell me more about your issue with the capture? Are the advertising intervals not as expected, or are you seeing other unexpected behavior?

As a side note, are you planning on using scan requests and responses in your application?
That could be something to look into doing, if you are going to use beacons.

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Thu, 23 Apr 2020 02:02:23 GMT

devzone.nordicsemi.com/.../Advertising_5F00_9600ms_5F00_20200422.zip

RE: Sending and receiving beacons on demand.

ilnadi — Thu, 23 Apr 2020 01:47:40 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/245856"]If this does not fit your application requirements, then I suggest making use of the Timeslot API to schedule proprietary radio communication window[/quote]

Based on a quick look, this again seems to drive the radio registers directly. we are trying to avoid operating at that level foe now.

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/245856"]The timing from the nRF Connect app is dependable, but as I mentioned earlier, I suggest that you use a Sniffer tool to analyze BLE traffic, since it gives you a much higher level of detail.[/quote]

Please see attached wireshark log we took using a PCA10000 with nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3. If the timing is what you would expect from S140, then we wil evaluate the timeslot example further.

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Tue, 21 Apr 2020 13:37:00 GMT

Hi again,

Thank you for your patience.

[quote user="ilnadi"]we have now run some experiments and not quite sure whether we are seeing an issue or not.[/quote]

What do you mean by this, are you no longer seeing the original issue?

[quote user="ilnadi"]Have you been able to confirm how soon after sd_ble_gap_adv_start() the first beacon will be transmitted? [/quote]

I have not looked further into how long it takes the hardware to respond to the call, but However, please keep in mind the random 3 - 13 ms delay added before advertising packets, as written about in the S140 documentation - advertising scheduling and suggested intervals and windows in particular.
The delay is part of the BLE specifications, and can not be omitted if you are to use BLE.
You may check it by using a Sniffer tool for monitoring the BLE traffic, complete with timestamps and contents of each advertised packet.

If this does not fit your application requirements, then I suggest making use of the Timeslot API to schedule proprietary radio communication windows.
Using a proprietary protocol could significantly reduce your latency, which sounds to be your main concern. Timeslots will give you complete control(no SD interruption) over the radio for their duration. If you would like to take a look at this, I can recommend this tutorial on setting up the Timeslot API for starters.
This example code could also be useful to have a look at, when looking for demonstrations of Timeslot API usage for the purpose you describe. Unfortunetely, said example is now a bit old - written for the nRF51 DK - but it is still relevant and the principles still hold.

[quote user="ilnadi"]We are detecting the beacons using nRF Connect for Android v.4.24.1 and see a 30-50ms difference in beacon-to-beacon timing even though we are calling sd_ble_gap_adv_start() with fixed (3.2sec) intervals. We are pretty sure about our timing because this timing also controls the other radio which has been tested in detail. How dependable is the timing from nRF Connect for Android?[/quote]

The timing from the nRF Connect app is dependable, but as I mentioned earlier, I suggest that you use a Sniffer tool to analyze BLE traffic, since it gives you a much higher level of detail.
With the Sniffer tool running, you are also able to capture a sniffer trace - a log of the BLE traffic - so that I may better see what you are experiencing on your end.

Looking forward to resolving this issue together,

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Mon, 20 Apr 2020 19:54:41 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/245311"]Yes, or at least immediate in the sense that it will not have to wait for a given timeslot to begin advertising.
I am unsure of the real-time delay between the function call and the first advertisemen[/quote]

we have now run some experiments and not quite sure whether we are seeing an issue or not.

Have you been able to confirm how soon after sd_ble_gap_adv_start() the first beacon will be transmitted?

Additionally we need to know a few things about sd_ble_gap_adv_stop():

what would happen if we call this while the beacon is being transmitted?
how soon after calling this are we guaranteed that the transmitter will not turn on

We are detecting the beacons using nRF Connect for Android v.4.24.1 and see a 30-50ms difference in beacon-to-beacon timing even though we are calling sd_ble_gap_adv_start() with fixed (3.2sec) intervals. We are pretty sure about our timing because this timing also controls the other radio which has been tested in detail. How dependable is the timing from nRF Connect for Android?

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Fri, 17 Apr 2020 19:11:49 GMT

Hello,

[quote user="ilnadi"]We will experiment and see if it works. One question: will the first beacon go out immediately when we call sd_ble_gap_adv_start()?[/quote]

Great, I'll look forward to any updates on the development!
Yes, or at least immediate in the sense that it will not have to wait for a given timeslot to begin advertising.
I am unsure of the real-time delay between the function call and the first advertisement.

[quote user="ilnadi"]Is this example relevant?[/quote]

Yes, you may use the Eddystone beacon as your foundation instead of the beacon example. I do not suppose it will make you able to broadcast any faster or "on demand" - since it still follows the BLE Specifications - but you could definitely make use of its added security features.

[quote user="ilnadi"]Can we listen at specific times for beacons while transmitting a beacon? [/quote]

You may scan for advertisement packets at specific times, yes.
Just remember that a beacon is non-connectable, so what you are listening for is advertising packets.

[quote user="ilnadi"]Does this mean we have to operate as "multirole"? It looks like S140 can support this, please confirm.[/quote]

I can confirm that S140 supports the multirole, as demonstrated in the experimental multirole exmaples from the SDK.
However, I am not sure it is multirole you are looking for, since the functionality demonstrated in multirole is to act both as a central and peripheral device.
The central role is the initiator of BLE connections and communication.
However, I do not see why the beacons would need to act as a central at any time? Perhaps I am missing something in my understanding of your application?

[quote user="ilnadi"]I looked at the examples under "ble_central_and_peripheral" and "ble_app_hrs_rscs_relay" seems the most relevant. is there a better multirole example?[/quote]

Both these examples are good examples for demonstrating a device acting both as a central and a peripheral, but as I said I am not sure this is what you are looking for.
Just remember that these are experimental examples.

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Thu, 16 Apr 2020 14:31:48 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244915"]If you are concerned about IP, I can convert this ticket to a private ticket - viewable only to you and the support staff here at Nordic Semiconductor. Would you like me to do that?[/quote]

I think you understood my problem so no need.

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244915"] Aha, I see what you mean. Well, I suppose you could attempt to start an advertising at the beginning of the slot and stop it at the end - could you attempt this, and let me know if it suits your application?[/quote]

We will experiment and see if it works. One question: will the first beacon go out immediately when we call sd_ble_gap_adv_start()?

Is this example relevant?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Fble_sdk_app_es.html

It seems to be for telemetry, which is closer t what we'redoing than an information beacon. Plus the encryption part of is is compelling.

Now we have to discuss the second part: receiving.

We need the same devices to listen for beacons when they are not transmitting (blue boxes in the picture above).
Can we listen at specific times for beacons while transmitting a beacon?
Does this mean we have to operate as "multirole"? It looks like S140 can support this, please confirm.
I looked at the examples under "ble_central_and_peripheral" and "ble_app_hrs_rscs_relay" seems the most relevant. is there a better multirole example?

thank you

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Thu, 16 Apr 2020 09:57:23 GMT

Hello,

[quote user="ilnadi"]Please see attached drawing, this is the best I can do without violating NDA.[/quote]

If you are concerned about IP, I can convert this ticket to a private ticket - viewable only to you and the support staff here at Nordic Semiconductor. Would you like me to do that?

[quote user="ilnadi"]I only asked about Radio HAL because of the solar beacon example you pointed to. I have no desire to control the radio at that level. [/quote]

That is good. I linked you that example because I thought it sounded like you would like to control it directly - since it seemed SD scheduling of packet transfer was infeasible for your application.

[quote user="ilnadi"]This is why originally asked about how I can manually send/receive packets using the SDK. If there are no examples, please point me to the drivers you mention above, and I'll go from there. I have not been able to find such in the SDK (see above for what I was able to find).[/quote]

You are correct that there is no examples of this in the SDK, because of the specifications for BLE Communication. They dictate the possible range and order of connection- and advertising-intervals - so it is not supported to send packets whenever.
However, I suppose you could attempt to start and stop advertising rapidly, to achieve this using the Beacon example - but I have not tried this myself so I can not guarantee it will work, but you may attempt it to see if it suits your requirements for on demand advertising.

[quote user="ilnadi"]The "problem" slots are the striped ones that he devices may use asynchronously based on events beyond this discussion.[/quote]

Aha, I see what you mean. Well, I suppose you could attempt to start an advertising at the beginning of the slot and stop it at the end - could you attempt this, and let me know if it suits your application?

Looking forward to resolving this issue together,

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Wed, 15 Apr 2020 17:47:17 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244764"]The example demonstrates use of the Radio HAL directly, which you could read more about here. You are free to do this as well, but I would highly recommend that you rather make use of the drivers and examples from the SDK - to make things a lot easier.[/quote]

Karl,

I only asked about Radio HAL because of the solar beacon example you pointed to. I have no desire to control the radio at that level.

This is why originally asked about how I can manually send/receive packets using the SDK. If there are no examples, please point me to the drivers you mention above, and I'll go from there. I have not been able to find such in the SDK (see above for what I was able to find).

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244764"]Could you possibly provide an overview of the entire radio period, which indications of how long each time-slot is, and how many there are? I am having a hard time understanding why setting up a broadcaster, such as in the beacon example, is not feasible for your application[/quote]

Please see attached drawing, this is the best I can do without violating NDA. The "problem" slots are the striped ones that he devices may use asynchronously based on events beyond this discussion.

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Wed, 15 Apr 2020 14:05:10 GMT

Hello,

[quote user="ilnadi"]first,both radios are controlled by the 52840 so we can easily schedule both. the question was more about sending BLE packets on demand. [/quote]

I see. Well, here I would have to refer to the BLE specification with regards to how transfers between connected devices must be done - at the agreed upon connection intervals. However, with non-connectable devices such as beacons(broadcasters) in your case, the advertisements can happen at any given interval within the specific advertising range - by setting the advertisement interval accordingly. You could potentially also start the advertisement following an interrupt, thus ensuring that the advertisements sync up with your other devices.

Alternatively, you can ensure that you are broadcasting in the allotted time-slot by having an advertising interval which is bound to occur within the time-slot(preferably also accounting for potential packet loss).

[quote user="ilnadi"]This is because in certain circumstances the customer wants us to re-broadcast in unused slots to increase the chance of reception. [/quote]

Could you possibly provide an overview of the entire radio period, which indications of how long each time-slot is, and how many there are? I am having a hard time understanding why setting up a broadcaster, such as in the beacon example, is not feasible for your application.

[quote user="ilnadi"]this example is 5yrs old and does not use softdevice or nRF SDK. Instead it writes directly to a handful of RADIO registers. I want to make sure it is still OK to use.[/quote][quote user="ilnadi"]Is there any equivalent SDK functionality to use (without SD)? I found ble_radio_notification, radio_config, and nrf_radio.h but none of these have send/receive functions.[/quote]

The example demonstrates use of the Radio HAL directly, which you could read more about here. You are free to do this as well, but I would highly recommend that you rather make use of the drivers and examples from the SDK - to make things a lot easier.

Looking forward to solving this issue together,

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Tue, 14 Apr 2020 22:50:20 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244456"]This is demonstrated in the Solar Beacon example. Note how the sensor_handler is called at an interval, every time a reading is to be done and thereafter transferred, the rest of the time the device consumes very little power.[/quote]

I wanted to confirm a few things:

this example is 5yrs old and does not use softdevice or nRF SDK. Instead it writes directly to a handful of RADIO registers. I want to make sure it is still OK to use.
Is there any equivalent SDK functionality to use (without SD)? I found ble_radio_notification, radio_config, and nrf_radio.h but none of these have send/receive functions.

RE: Sending and receiving beacons on demand.

ilnadi — Tue, 14 Apr 2020 13:34:26 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/244456"][/quote]

ilnadi said:

unfortunately the customer has additional requirements for repeating the information asynchronously based on criteria outside BLE considerations.

I am not sure I understood what you meant here. Is the intervals for transmission changing? If so, the GPIO interrupt might solve this as well.

first,both radios are controlled by the 52840 so we can easily schedule both. the question was more about sending BLE packets on demand.

What I meant above is: although we have a periodic schedule and a specific 20ms window allocated to each device within that schedule, we cannot simply do a periodic beacon (even if we could synchronize). This is because in certain circumstances the customer wants us to re-broadcast in unused slots to increase the chance of reception.

Having said all that, being able to transmit and receive on demand will meet all our needs.

I will check the solar beacon example.

thank you

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Tue, 14 Apr 2020 13:25:09 GMT

Hello,

I understand.
This is demonstrated in the Solar Beacon example. Note how the sensor_handler is called at an interval, every time a reading is to be done and thereafter transferred, the rest of the time the device consumes very little power.
To make sure that the intervals are synchronized with your other device, could you for example use a GPIO interrupt? Would that be feasible?

[quote user="ilnadi"]unfortunately the beacon must fall in a specific 20ms window. Is there a way to make the advertising scheduled synchronized or start i at a particular time?[/quote]

Yes, this is possible. See the Solar Beacon example I linked above for an example on how to do this.

[quote user="ilnadi"]unfortunately the customer has additional requirements for repeating the information asynchronously based on criteria outside BLE considerations.[/quote]

I am not sure I understood what you meant here. Is the intervals for transmission changing? If so, the GPIO interrupt might solve this as well.

I would recommend using the Beacon examples as a basis for your application, instead of going the route with L2CAP.

Looking forward to solving this issue together!

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Fri, 10 Apr 2020 02:51:54 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/240931"]Please also see the short tutorial I linked, as it details how you can easily set up the broadcasting/beacon in the manufacturer specific data field of the advertisement packets.[/quote]

I have read the tutorial and run the example and they are both based on GAP/GATT-based scheduling (i.e. they use sd_ble_gap_adv_start() ).

I need to be able to send the beacon on my own schedule

fortunately the main schedule is divisible by 625usec.
unfortunately the beacon must fall in a specific 20ms window. Is there a way to make the advertising scheduled synchronized or start i at a particular time?
unfortunately the customer has additional requirements for repeating the information asynchronously based on criteria outside BLE considerations.

All of this leads me to think we need to go back to L2CAP so we can

on the sender "send this packet now" (see message flow)
on the receiver "turn on receiver" then after the window is over, "turn off receiver" (see message flow)

Are there any examples of L2CAP usage? The only thing I can fidn related to L2CAP in the SDK (15.3.0) is related to serialization.

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Fri, 20 Mar 2020 16:22:36 GMT

Based on your replies I think you will find the BLE Beacon example very helpful.
Please also see the short tutorial I linked, as it details how you can easily set up the broadcasting/beacon in the manufacturer specific data field of the advertisement packets.

[quote user="ilnadi"]thank you[/quote]

No problem at all, I am happy to help!
Let me know if you should encounter any issues or questions moving forward.

Best of luck with you development!

Best regards,
Karl

RE: Sending and receiving beacons on demand.

ilnadi — Fri, 20 Mar 2020 16:06:47 GMT

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/240782"]What size is the data that you are looking to broadcast on the BLE transmit?[/quote]

small, likely 2-3 bytes.

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/240782"]Since I do not know what other radio protocol you are using, I assume that you know you have sufficient time to switch between BLE and the other radio[/quote]

We have a 20ms window to switch, transmit, switch back. The receivers will be listening for as much of that 20ms as they can. My calculations say this is enough.

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/240782"]Have you seen the BLE Beacon example? If you are not familiar with advertising in BLE, I suggest reading this short tutorial.[/quote]

I have not, I have used nRF parts & SD in classical peripheral devices but learning about beacons now. I will read both of these and reply here if I have any questions.

[quote userid="87869" url="~/f/nordic-q-a/59313/sending-and-receiving-beacons-on-demand/240782"]Is this only because you want to have a non-connectable, broadcasting device?[/quote]

Correct.

thank you

RE: Sending and receiving beacons on demand.

Karl Ylvisaker — Fri, 20 Mar 2020 09:23:32 GMT

Hello,

What size is the data that you are looking to broadcast on the BLE transmit?
As you said, the beacon functionality might be useful for your application.
Beacons broadcast their data as part of the Manufacturer Specific Data field of their advertising packages.
Have you seen the BLE Beacon example? If you are not familiar with advertising in BLE, I suggest reading this short tutorial.
The main things for you to note here is the limited size of advertising packets, and that you may change your advertising interval period, to configure how often the transmits happen.

Since I do not know what other radio protocol you are using, I assume that you know you have sufficient time to switch between BLE and the other radio.

[quote user=""]We are assuming/hoping this will be possible using L2CAP functions instead of GAP/GATT functions and never starting any GATT scheduling. However the L2CAP message sequence charts in SD140 v7.0.1 all show two-way communication.[/quote]

Is this only because you want to have a non-connectable, broadcasting device?
If you, I think the beacon functionality might be what you are looking for.

Please have a look at the BLE Beacon & Advertising tutorial, and get back to me with how you think this might fit with your application.

Best regards,
Karl