gazell backwards compatibility nRF24 gzll host and nRF52840 gzll host

[astella]

To the kind attention of Nordic support team,

I have got some legacy code running as a gazell host on a nRF2726 nRFgo Nordic platform. Right now, I would like to set a gazell host using nRF52840 development kit and the very same radio settings as they were used before in the legacy code so that new host is able to listen to radio communications the same way. Unfortunatelly I didn't succeed in doing so.

1. The legacy gazll host is basically set using default radio parameters inside the gzll_init routine (as it is defined in nRFgo SDK 2.3.0.10040 source_code gazell common gzll.c)

2. The host gazell for nRF52840 comes from the example provided in SDK 15.2 (gzll_ack_payload_host_pca10056 segger embedded studio)

We've also read in infocenter.nordicsemi.com user guides, gazell link layer user guide in section bacwards compatibility that examples are not fully out of the box compatible with legacy gazell examples.

It would be greatly appreciated a step by step guide (based on those projects I mentioned) about what to do in order to have an nRF52840 host set the same way as a nRF24 one and have a clear understanding of the subject. I think that nRF52840 is the natural evolution and replacement for nRF24. So it should be very clear how to migrate from one to the other in case of using the Nordic wireless proprietary rf protocol.

Thank you very much for your work and for helping us. 

[astella]

It seemed it was turning out to be very simple. In order to have the two host (see point 1 and point 2 as I mentioned in the previous part of my question) both receiving the very same packets I only had to set bitrate and address and put to the test various timeslot periods. Neverthless I think there is some instability left, because of some sort of radio init setting that is different. In particular I  have been reading in Nordic documentation that for nRF52840 NRF_GZLL_DEFAULT_TIMESLOT_PERIOD needs to be set 900 when using a 1M bitrate. In gzll_params.h for nRF24 we can see that:

#ifdef __C51__
#define GZLL_DEFAULT_PARAM_RX_PERIOD_MODIFIER 360 // [us]
#elif __ICC8051__
#define GZLL_DEFAULT_PARAM_RX_PERIOD_MODIFIER 600 // [us]
#endif

When sending gazell packets from a source that was built together with the nRF24 host, obviously the nRF24 host does receive perfectly everything. When the very same source is used to transmit to the host running using the nRF52840, after the reception of two three packets, this sort of errors comes out:

NRF_GZLL_ERROR_CODE_INTERNAL_ASSERT_OCCURRED or NRF_GZLL_ERROR_CODE_INVALID_PAYLOAD_LENGTH

Could different radio settings bring this kind of problems in nRF52840?

I have to say I have tried the nRF52840 host using a PCA10040 as a device using the SDK project host counterpart, and the host seems to be fine. It keeps receiving everything but I have to say that everything is fine only when sending a dynamic gazell packet that is shorter than the previous one.If the sending packet is larger than the previous one I have these errors:

NRF_GZLL_ERROR_CODE_INTERNAL_ASSERT_OCCURRED or NRF_GZLL_ERROR_CODE_INVALID_PAYLOAD_LENGTH too.

I think that I need Nordic help in order to better understand the compatibility issue between nRF24 and nRF52840 when building a gazell host.

Another question: is it feasible to have two host both listening at the same channels and addresses, and one of them used for debugging only in a silent way fashion so to only print on a serial monitor gazell packets travelling on air?

In legacy code I've got these instructions:

In legacy code I have got:

hal_nrf_enable_ack_payload(true);
hal_nrf_enable_dynamic_payload(true);
hal_nrf_setup_dynamic_payload(0xff);

Have I to enable dynamic payload for nRF52840 also? 

Thank you for you great work and for your help.

[astella]

.

[astella]

It is very strange indeed. I needed to do this:

void nrf_gzll_host_rx_data_ready(uint32_t pipe, nrf_gzll_host_rx_info_t rx_info)
{

...

data_payload_length2 = 32; <--- reset data_payload_length2 to the max value

// Pop packet and write first byte of the payload to the GPIO port.
bool result_value = nrf_gzll_fetch_packet_from_rx_fifo(pipe,
m_data_payload2,
&data_payload_length2);

...

Without 'resetting' that variable the host cannot read correctly when sending to it a gazell packet whose length is greater than that of the previous packet.