gazell host reply rate

RE: gazell host reply rate

astella — Fri, 21 May 2021 10:48:27 GMT

Thank you Hakon. I think at a first glance I under estimated the importance of the dummy packet in gzll. We could also call it like a "flush packet", because it naturally flushes tx host fifos, without any need to force or impose tx host fifo flushes from code running in the host itself (at least in the best case scenario). It sounds the best thing so to avoid host congestion. I'm confident will be making a good usage of these info you shared. Thank you again

RE: gazell host reply rate

Håkon Alseth — Fri, 21 May 2021 08:32:10 GMT

Hi,

[quote user="astella"]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.[/quote]

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.

[quote user="astella"]PROTO_GZLL_TIMESLOT_PERIOD ---> 800[/quote]

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?

[quote user="astella"]

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,

[/quote]

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

RE: gazell host reply rate

astella — Thu, 20 May 2021 14:35:49 GMT

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.

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.

Best regard

RE: gazell host reply rate

Håkon Alseth — Thu, 20 May 2021 14:07:55 GMT

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