gazell host reply rate

[astella]

To the kind attention of Nordic support team,

We have got an nRF52833 gzll host that has to interact with multiple gzll devices. We empirically saw that (in our case and in our particular implementation) when multiple devices are communicating at once, and the host always tries to

preload  and ack in a very short time, the host is not able anymore to handle the communication properly: in particular host fifos flush routines are not working under high stress conditions so

that we can experience bad communication quality.

To solve this issue we thought to make use of a gazell ack queue, that is then dequeuing using a timer at a constant rate (about every 3 ms an ack is dequeued and preload in gzll internal tx

fifo). It seems that this is beneficial for the communication and, should be needed, flush routines host side are working well.

Could you please confirm if these observations are in line with your experience of gazell? Is it safer we take care of a proper host reply rate? What would be this physical radio limit at 1Mbps?

You need other configuration values or could just estimate? Is it true that flush routines may not work properly under high stress conditions (ack preloaded too frequently in the host, and

reception of multiple input streams)? In our case it is not so important that the ack is sent out immediately, as we deal with huge input streams sent by mice like devices. So that it is ok for us

to queue an ack and send it any moment a device starts communicating again.

Thank you for your kindness 

[Håkon Alseth]

Hi,

 

1. Can you share your gazell configuration on the host side?

2. How many devices are communicating with the host?

3. How often do each device send a payload to the host?

4. Do each device have a dedicated RF pipe?

 

Kind regards,

Håkon

[astella]

Thank you Hakon for replying.

This scenario is based on a legacy project. We have until 5 mice like devices on unencrypted pipes and then pipe 6 dedicated to encrypted gazell communication. That it is why we also use gzp.

1. Can you share your gazell configuration on the host side?

NRF_GZLL_MODE_HOST

PROTO_GZLL_DATARATE ---> NRF_GZLL_DATARATE_1MBIT
PROTO_GZLL_MAX_TX_ATTEMPTS ---> 250
PROTO_GZLL_CHANNEL_SELECTION_POLICY ---> NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_SUCCESSFUL
PROTO_GZLL_TIMESLOT_PERIOD ---> 800
PROTO_GZLL_SYNC_LIFETIME ---> GZLL_DEFAULT_PARAM_MAX_SYNC_PERIOD
PROTO_GZLL_TSLOTS_PER_CHANNEL ---> 2
PROTO_GZLL_POWER ---> NRF_GZLL_TX_POWER_0_DBM
PROTO_GZLL_CHANNEL_TAB_SIZE ---> 5

2. How many devices are communicating with the host?

In theory, until 5 plus the encrypted one: 6 devices. But after we connect 3 non encrypted ones we already get bad quality communication

3. How often do each device send a payload to the host?

About 10 ms each 

4. Do each device have a dedicated RF pipe?

Unfortunately yes, That is why we have often need to flush when changing device. But it is very interesting your question.

Basically if we try to always put acks in gzll tx internal fifos, following the rhythm at which we receive from multiple devices, we fail and try to flush repeatedly, until some gzll internal error appears like 

NRF_GZLL_ERROR_CODE_INTERNAL_ASSERT_OCCURRED.

After that we loose the chance to flush (flushing routine not working anymore) and either some device stuck, is not able to communicate, or the communication is affected by a degradation.

The only thing that seem to work is to try and not ack always. I mean not always trying to ack and put ack in internal gzll fifos, as this implies a flush (considering how legacy routines of our project are implemented) and gzll repeatedly disabled and enabled. It seems that having an external queue and dequeuing (trying to queue in internal gzll fifo) at a reasonable rate could be ok. Maybe you can help us understand theoretically the situation a little more deeply. Thank you for your efforts and kindness,

Best regard

[Håkon Alseth]

Hi,

 

astella said:

We have until 5 mice like devices on unencrypted pipes and then pipe 6 dedicated to encrypted gazell communication. That it is why we also use gzp.

GZP will claim the ACK payload for the encrypted pipe on the host side, which will flush any preloaded ACKs on other RF pipes

(See gzp_host.c -> gzp_process_encrypted_user_data -> gzp_preload_ack -> gzll_tx_fifo_flush)

 

Once you start to use the encrypted RF pipe, this will be in conflict with the other devices using preloaded ACK payloads.

   

astella said:

PROTO_GZLL_TIMESLOT_PERIOD ---> 800

This is a bit short wrt. 1 MBit on-air datarate if you use 32 byte payload:

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/group__gzll__02__api.html#ga3347094a64c07793c773c4fdf4bc4bff

 

What is the payload length, and ACK payload length used?

 

astella said:

Basically if we try to always put acks in gzll tx internal fifos, following the rhythm at which we receive from multiple devices, we fail and try to flush repeatedly, until some gzll internal error appears like 

NRF_GZLL_ERROR_CODE_INTERNAL_ASSERT_OCCURRED.

After that we loose the chance to flush (flushing routine not working anymore) and either some device stuck, is not able to communicate, or the communication is affected by a degradation.

The only thing that seem to work is to try and not ack always. I mean not always trying to ack and put ack in internal gzll fifos, as this implies a flush (considering how legacy routines of our project are implemented) and gzll repeatedly disabled and enabled. It seems that having an external queue and dequeuing (trying to queue in internal gzll fifo) at a reasonable rate could be ok. Maybe you can help us understand theoretically the situation a little more deeply. Thank you for your efforts and kindness,

The internal fifo is 6 entries deep:

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/gzll_02_user_guide.html?cp=7_1_5_4#FIFOs

If the TX FIFO is filled up on each different pipe, then there's no room for receiving any new payloads.

 

Do you mean that the gazell host still works, while some of the devices stops communicating? If yes, does the device recover if it is reset, or do you need to reset the gazell host only to resume communication?

Note in the above link, where ACK payloads are mentioned wrt. how its handled in the hosts FIFO; meaning that it is not popped off before the next incoming RF payload on that specific pipe:

Since the ACK will not always be successfully received by the Device, the data payload added to the ACK will not be removed from the TX FIFO immediately. This TX packet will be removed from the TX FIFO when a new packet (new packet ID or CRC) is received on the same pipe. In this case, the new packet sent from the Device serves as an acknowledgement of the ACK sent previously by the Host. ACKs sent in reply to retransmission attempts contain the same TX payload.

When the Host is handling packets on multiple pipes, care needs to be taken to ensure that ACK payloads in the TX FIFOs on pipes that are no longer in use, are not taking up space in the memory pool and consequently blocking communication on other pipes. To avoid such congestion, the application on the Host can flush the TX FIFOs on the pipes no longer in use.

 

This means that if you only send one RF payload to fetch the ACK from the host; it will still take place in the hosts FIFO. This could be the source of your issues.

 

Kind regards,

Håkon