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]

Hi, I just checked this, but it doesn't seem related to my issue.

Edit: I also checked the original nRFgo implementation as you mentioned, there are no differences.

[Marcel]

When I add: 

NRF_LOG_INFO("Gazelle: transmission:, id_req_status: %x send_crypt_data: %x", id_req_status, send_crypt_data);

The result is:

<info> app: Gazelle: transmission:, id_req_status: 3 send_crypt_data: 0
<info> app: Gazelle: transmission:, id_req_status: 3 send_crypt_data: 1

3= GZP_ID_RESP_FAILED

For some reason there is a problem with "host ID" request. 

I can confirm that these params are equal on both, the host and device:

Factory preset parameters

For pairing and key exchange to occur, an unpaired Host and Device must share the following factory preset parameters in the following table:

Parameter	Secret?	Bytes	Purpose	Set
Secret Key	Yes	16	Encrypting Host ID when sent from Host to Device	Factory preset
Pairing Address	No	5	Sending of System Address from Host to Device	Factory preset
Packet Validation ID	No	3	Authentication of packets	Factory preset

[Kenneth]

My suggestion is to first use the nRFgo SDK from v2.3 on a nRF24LE1 DK, and find what changes you must do to make it work there. Is that possible?

I believe that gazell will give you "GZP_ID_RESP_FAILED" by default if no communication with host is detected. If host does not accept, you should first get a "GZP_ID_RESP_PENDING" response, then a failed response later. Maybe you can monitor the id_req_status for all attempts here (even failing).

[Marcel]

You are right, I receive the GZP_ID_RESP_PENDING response first before getting the GZP_ID_RESP_FAILED. The default value is: GZP_ID_RESP_NO_REQUEST. We only receive GZP_ID_RESP_NO_REQUEST if we turn off the host.

I will check if we can setup the nRFgo SDK for debugging, we need to order the hardware for that.

[Kenneth]

I was thinking you already had that. It may get a bit costly to get an nRFgo Starter Kit and an nRF24LE1 DK, though that may also be the only intermediate step that can solve this.

I was thinking a bit on the sequence GZP_ID_RESP_PENDING -> GZP_ID_RESP_FAILED. 

Maybe the problem here is not gazell pairing parameters, but the timing. What if the device send packets faster than the host can prepare the encryption key/ID. Not sure if you have measured any timing on the host, but for testing maybe you can add some 10ms delays in gzp_id_req_send() between packets to see if that have any impact on the issue you experience. But if that was the case, then that would not explain why also nRF24L01 device -> nRF52 host fails, so it still seems like a mismatch in parameters.

[Thomas]

Hello Marcel,

I'm trying to do a similar thing as you did. Did you manage to solve this issue? What was the solution?

Best regards

Thomas

[Marcel]

Hi Tomas,
unfortunately not, the topic has become active again and we are discussing directly with Nordic FAE atm.

When we come to the solution, maybe Nordic can also update this topic, I will ask them.

BR

[Marcel]

Strange, I received 90+ mails from nordic devzone after updating this topic...?