Proprietary protocol selection

RE: Proprietary protocol selection

Edvin — Wed, 27 Jan 2021 14:52:55 GMT

You have a few methods of separating connections which you can use in your case.

One is the rf channels, while another is the base addresses.

To be honest, I haven't played too much around with this, but perhaps the description of nrf_esb_address_t

typedef struct
{
    uint8_t base_addr_p0[4];        /**< Base address for pipe 0 encoded in big endian. */
    uint8_t base_addr_p1[4];        /**< Base address for pipe 1-7 encoded in big endian. */
    uint8_t pipe_prefixes[8];       /**< Address prefix for pipe 0 to 7. */
    uint8_t num_pipes;              /**< Number of pipes available. */
    uint8_t addr_length;            /**< Length of the address including the prefix. */
    uint8_t rx_pipes_enabled;       /**< Bitfield for enabled pipes. */
    uint8_t rf_channel;             /**< Channel to use (must be between 0 and 100). */
} nrf_esb_address_t;

So only messages that has a matching address and rf channel between the transmitter and receiver will be received. This is not encrypted, but perhaps there are plenty of variations, so you do not need to worry about picking up the wrong message.

What is a bit tricky here is that the softdevice (Bluetooth stack) will have control over the radio most of the time. What you need to do is to use something called timeslot API to request timeslots in between the BLE activity. Then you need to be listening on one device while the other is transmitting.

Listening and transmitting using the radio is quite equivalent power wise. It consumes roughly the same amount of current. So the clue here is to be able to time this correctly. Once you manage to pick up a message, you can e.g. know that the other device sends out a message every 5ms or so, so you can turn on the radio only when you expect a message. Of course, the transmitter may not be able to transmit every 5ms, because sometimes it may collide with BLE scheduled activity, so you need to consider how long you want to keep track of the 5ms intervals before you start to increase your scan windows again.

This can easily become a bit complicated, but that is something you need to consider. Of course, you can listen on ESB at all times (when not using BLE), but that will draw a significant amount of power. You can see the radio current consumption for the nRF52840 here.

BR,
Edvin

RE: Proprietary protocol selection

nrbrook — Wed, 27 Jan 2021 14:12:26 GMT

Thanks Edvin. I'm not sure of the exact latency, it would need to be determined experimentally. 7.5ms is probably fast enough, it just needs to be imperceptible to humans. Would it be more power efficient to just use Bluetooth if latency is "good enough"?

[quote userid="26071" url="~/f/nordic-q-a/70989/proprietary-protocol-selection/291516#291516"]Perhaps you can do this information flow via BLE[/quote]

Yes unique addresses can be assigned during setup. I just wanted to check that otherwise they won't interfere – does each pair need a unique channel? How many channels are there?

RE: Proprietary protocol selection

Edvin — Wed, 27 Jan 2021 13:54:48 GMT

Hello,

[quote user=""]Latency is important because the communication between devices is to sync their position in a sequence of audio and LED outputs[/quote]

What sort of latency do you require? As you may know, BLE uses a connection interval of minimum 7.5ms, so it is not possible to guarantee lower than this. In addition, you have retransmissions if you loose a packet.

If you require latency < 7.5ms, then I believe ESB is appropriate for your case. Your requirement:

[quote user=""]They will be in the same room as other pairs of devices, so should be able to talk directly to each other without interfering with other devices in range[/quote]

Is doable, but the devices needs to be aware of what devices to listen to. Perhaps you can do this information flow via BLE. I suggest you test the example SDK\examples\proprietary_rf\esb_p<tx/rx> and look at how they set up what device to listen to using the base addresses.

NB: It is not used in this example, so they are using channel 0, but you can set the channel using nrf_esb_set_rf_channel().

Since this is open, and you want two and two devices to communicate with one another, you need some way for them to only listen to each other. Perhaps you can use the BLE address, or you can make the devices decide on a base address over BLE.

Best regards,

Edvin