Gazell nrf24 host, nrf52 device compatibility

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Wed, 16 Sep 2020 20:00:25 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Wed, 16 Sep 2020 19:53:33 GMT

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.

RE: Gazell nrf24 host, nrf52 device compatibility

Thomas — Wed, 16 Sep 2020 19:36:36 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Wed, 23 Oct 2019 13:23:32 GMT

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.

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Wed, 23 Oct 2019 09:44:26 GMT

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.

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Tue, 15 Oct 2019 12:05:45 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Tue, 15 Oct 2019 11:43:31 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Tue, 01 Oct 2019 07:40:34 GMT

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.

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Tue, 01 Oct 2019 07:03:13 GMT

It's been a while since I worked on Gazell, but can it be related to;

https://devzone.nordicsemi.com/f/nordic-q-a/20823/gazell-pairing-library-only-support-one-encrypted-pipe/81331#81331

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Mon, 30 Sep 2019 20:57:55 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Mon, 30 Sep 2019 15:41:11 GMT

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?

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Mon, 30 Sep 2019 15:03:09 GMT

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?

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Mon, 30 Sep 2019 14:57:19 GMT

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

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Mon, 30 Sep 2019 14:36:38 GMT

Yes, they all match

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Mon, 30 Sep 2019 14:27:51 GMT

Have you tried to modify the defines in nrf_gzp_config.h:

#define GZP_ADDRESS 4, 6, 8, 10

Also see some Global variables in nrf_gzp.c

RE: Gazell nrf24 host, nrf52 device compatibility

Marcel — Mon, 30 Sep 2019 13:11:06 GMT

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.

RE: Gazell nrf24 host, nrf52 device compatibility

Kenneth — Mon, 30 Sep 2019 11:15:03 GMT

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