Sending and receiving beacons on demand.

[ilnadi]

Our device using nRF52840 is running an external (non-BT) radio most of the time. We need to send and receive data In between operations of this other radio.  At any given time, there will be one sender and multiple receivers.  Since there will be no BLE connection or interaction, this is essentially a beacon operation except for the scheduling.  We are trying to understand if it is possible to manually send and receive without running a BLE schedule and without any interaction between sender and receiver.  

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.

Please clarify how the scheme described here can be accomplished.

The overall schedule will be something like

Receive-only devices:

1. Receive other radio
2. Receive BLE (20-40ms interval)
3. (repeat steps 1 & 2 indefinitely)

Receive/Transmit devices:

1. Receive other radio
2. Receive BLE (20-40ms interval)
3. (repeat steps 1 & 2 N times)
4. Transmit other radio
5. Transmit BLE
6. (repeat steps 1 - 5 indefinitely)

[ilnadi]

Karl Ylvisaker said:

What size is the data that you are looking to broadcast on the BLE transmit?

small, likely 2-3 bytes.

Karl Ylvisaker said:

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

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.

Karl Ylvisaker said:

Have you seen the BLE Beacon example? If you are not familiar with advertising in BLE, I suggest reading this short tutorial.

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.

Karl Ylvisaker said:

Is this only because you want to have a non-connectable, broadcasting device?

Correct.

thank you

[Karl Ylvisaker]

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.

ilnadi said:

thank you

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

[ilnadi]

Karl Ylvisaker said:

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

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?

[Karl Ylvisaker]

Hi again,

Thank you for your patience.

ilnadi said:

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

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

ilnadi said:

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

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.

ilnadi said:

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?

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 

[ilnadi]

Karl Ylvisaker said:

If this does not fit your application requirements, then I suggest making use of the Timeslot API to schedule proprietary radio communication window

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.

Karl Ylvisaker said:

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.

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.

[ilnadi]

Advertising_9600ms_20200422.zip

[Karl Ylvisaker]

Hello,

ilnadi said:

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.

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