Gazell bi-directional communication between paired devices

[DonaldInspiro]

Hello,

We are developing a system in which a device controls a host and the device should receive status information about the host. In some use cases multiple hosts are in close proximity, so pairing is required to avoid incorrect behavior.

We have Gazell and pairing up and running and we can transmit secure messages over the encrypted data pipe. However, it seems that we can not set the ACK data for encrypted messages.

1. Is the Gazell stack capable of piggybacking user data on the ACK when using the encrypted data pipe?
2. If no user data can be piggybacked on an encrypted data pipe ACK, how can we make sure that an unencrypted message from a device is only answered by a paired host and not all other hosts in close proximity?

Both the host and the device are using the Gazell stack from the nRFgo SDK 2.3.0.10040 ported to run on an Atmel SAMD20J18 connected to an nRF24L01+.

Best regards,
Donald

[Håkon Alseth]

Hi,

 

When using the encrypted pipe (pipe 1), gazell will claim the ACK payload for AES counter updates.

You might get some data on the reverse from time-to-time (it'll look very unstable, and you'll see "garbage" values), but once the host receives data on encrypted pipe 1, it will flush the FIFO in order to ensure that the crypto-related data is sent back to the device.

In the case you are pairing a device to a specific host, and there are several hosts in close proximity, we recommend that you turn down the transmit power on both device and host, and on the host side, check if the "RPD" field (the "1 bit RSSI", detects if power level higher than -64 dBm) when initiating a pairing request.

Once a device is successfully paired, the base RF address for communication will be changed ("system address" as it's called in GZP), and each host will have its own random generated RF base address.

 

Best regards,

Håkon

[DonaldInspiro]

Thank you for your answer. We had seen both hosts react to a message, but this was due to incorrect initialization of gazell pairing (not calling gzp_init) which caused all hosts and devices to use the same addresses.