RE: gazell backwards compatibility nRF24 gzll host and nRF52840 gzll host

astella — Mon, 03 Jun 2019 15:57:27 GMT

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.

RE: gazell backwards compatibility nRF24 gzll host and nRF52840 gzll host

astella — Mon, 03 Jun 2019 10:35:54 GMT

RE: gazell backwards compatibility nRF24 gzll host and nRF52840 gzll host

astella — Mon, 27 May 2019 12:45:34 GMT

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.