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:

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

[ilnadi]

Karl Ylvisaker said:

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.

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.

[Karl Ylvisaker]

Hello,

ilnadi said:

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

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).

ilnadi said:

This is because in certain circumstances the customer wants us to re-broadcast in unused slots to increase the chance of reception. 

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.

ilnadi said:

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.

ilnadi said:

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.

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

[ilnadi]

Karl Ylvisaker said:

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.

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).

Karl Ylvisaker said:

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

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.

[Karl Ylvisaker]

Hello,

ilnadi said:

Please see attached drawing, this is the best I can do without violating NDA.

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?

ilnadi said:

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. 

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.

ilnadi said:

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).

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.
 

ilnadi said:

The "problem" slots are the striped ones that he devices may use asynchronously based on events beyond this discussion.

 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