gazell host reply rate

Question

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 · Accepted Answer

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

gazell host reply rate

Top Replies