Gazell nrf24 host, nrf52 device compatibility

[Marcel]

Hi,

We have a product with nrf24L01p Gazell (LastChangedRevision: 133) that acts as a Host. At the moment I'm trying to pair with this host via a PCA10040 Devkit (nRF52832) that acts as a device. For this I'm using the SDK15.3 example: gzll_dynamic_pairing_device_pca10040

Should this setup pair out-of-the-box? Or can I expect some compatibility issues with this setup? At the moment it does not pair at all. Secret key, PIPE addresses and so on are equal.

[Kenneth]

It should be backwards compatible yes:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/gzll_02_user_guide.html?cp=5_1_5_3 
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/gzp_02_user_guide.html?cp=5_1_5_4 

Just make sure that they are in close proximity (you can try to move the on top of eachother):
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/gzp_02_user_guide.html?cp=5_1_5_4_2#gzpair_proximity 

[Marcel]

Thanks! I suspect that the issue can be in the pipe addresses, this part:

/*****************************************************************************/
/** @name Default Address configuration */
/*****************************************************************************/

/*
Corresponds to Legacy nRFgo SDK Gazell config:
#define GZLL_DEFAULT_ADDRESS_PIPE0 {0x01, 0x04, 0x07, 0x0A, 0x0D}
#define GZLL_DEFAULT_ADDRESS_PIPE1 {0x02, 0x05, 0x08, 0x0B, 0x0E}
#define GZLL_DEFAULT_ADDRESS_PIPE2 3
#define GZLL_DEFAULT_ADDRESS_PIPE3 4
#define GZLL_DEFAULT_ADDRESS_PIPE4 5
#define GZLL_DEFAULT_ADDRESS_PIPE5 6
*/

#define NRF_GZLL_DEFAULT_FULL_ADDRESS_PIPE0  {0x01, 0x04, 0x07, 0x0A, 0x0D}   ///< Corresponding legacy Gazell pipe 0 address.
#define NRF_GZLL_DEFAULT_BASE_ADDRESS_0      0x0D0A0704                       ///< Default base address 0.
#define NRF_GZLL_DEFAULT_BASE_ADDRESS_1      0x0E0B0805                       ///< Default base address 1.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_0       1                                ///< Default prefix address pipe 0.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_1       2                                ///< Default prefix address pipe 1.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_2       3                                ///< Default prefix address pipe 2.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_3       4                                ///< Default prefix address pipe 3.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_4       5                                ///< Default prefix address pipe 4.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_5       6                                ///< Default prefix address pipe 5.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_6       7                                ///< Default prefix address pipe 6.
#define NRF_GZLL_DEFAULT_PREFIX_BYTE_7       8                                ///< Default prefix address pipe 7.
#define NRF_GZLL_DEFAULT_BASE_ADDRESS_LENGTH NRF_GZLL_BASE_ADDRESS_LENGTH_4B  ///< Default on-air base address length.
#define NRF_GZLL_DEFAULT_RX_PIPES_ENABLED    0x000000FF                       ///< Enabled Rx pipes. See nrf_gzll_set_rx_pipes_enabled().
/** @} */

We are using the "legacy" pipe configuration, how should I modify this part to use the legacy addresses? During the pairing the host and device are on top of each other  Or should this part also be backwards compatible already?

Edit: I'm able to pair between 2 NRF52 dev kits, but that's obvious of course.

[Marcel]

Yes, they all match

[Kenneth]

Can you try to swap the order (MSB vs. LSB)?

[Marcel]

You mean like: #define GZP_ADDRESS 10, 8, 6, 4

I notice that if the nrf24 host is powered off, I receive this message on the nrf52 device: "<error> app: Gazelle: transmission failed" about every second, when I power on the nrf24 host, the frequency of receiving this message is increased. So there seems to be some kind of communication.

When I try: #define GZP_ADDRESS 10, 8, 6, 4, I don't see the effect.

edit 1: I also tried to pair with our nrf24 device product to pair with nrf52 devkit as host, this also doesn't work.

edit 2: If I modify the example to this:

if(send_crypt_data)
{	
    NRF_LOG_ERROR("Gazelle: encrypted transmission failed");
}
else
{
    NRF_LOG_ERROR("Gazelle: not crypted transmission failed");
}

I only receive error messages at the "not encrypted data", for some reason the encrypted messages do arrive? So this means I'm paired, can you elaborate?

[Kenneth]

Can you provide chip markings on the nRF24L01 you have there?

Any way you can compare your implementation with the nRFgo SDKv2.3 (the SDK for the nRF24-series) that the gzp is tested with?

[Marcel]

I have to correct previous post:
I only receive error messages at the "encrypted data". Because the VAR send_crypt_data was inverted just before, sorry.

Chip markings: NRF 0, 24L01+, 1716NH