Packet loss when Preamble length is set to 32 in QM33100

Wireless Connectivity Ultra-Wideband
1

Hi All,

I am using the QM33100. I have set the preamble lenght to 32. However, I do get PHR Errors, PHR Rejection, RX Overrun errors.

What is the optimal preamble length that is supported by QM33100?

In case 32 length preamble is supported, what is the best way to Tx data and ensure the peer receives it without any errors.

Thanks in advance

2

Hi @Sunilks ,

Could you share the other radio configurations like PAC size, channel number etc. with us? So, we can try to reproduce this issue on our side.

Kind regards,
Emre

3

Hi@ Emre_Ozbas_Qorvo,
I have used following configurations:
dwt_config->chan = 9;
dwt_config->txPreambLength = DWT_PLEN_32;
dwt_config->rxPAC = DWT_PAC4;
dwt_config->txCode = 9;
dwt_config->rxCode = 9;
dwt_config->sfdType = 1;
dwt_config->dataRate = DWT_BR_6M8;
dwt_config->phrMode = DWT_PHRMODE_EXT;
dwt_config->phrRate = DWT_PHRRATE_STD;
dwt_config->sfdTO = (33 + 8 - 8);
dwt_config->stsMode = DWT_STS_MODE_OFF;
dwt_config->stsLength = DWT_STS_LEN_64;
dwt_config->pdoaMode = DWT_PDOA_M0;
With Regards
Sunil

4

Hi @Sunilks

The SFDTO formula is SFDTO=preamble length(32) + 1 – PAC size(4) + SFD length(8). So could you change your SFDTO to 37?

If you don’t use the long frame mode, I would recommend using standard phr mode.

Regards,
Emre

5

Hello, @Emre
I’m going to adjust the SFDTO to 37 and see if it helps.
The extended PHR mode option is necessary because I’m utilising the long frame mode.
With Regards
Sunil

6

Hello@Emre,
After testing with SFDTO set to 37, I saw no improvement. Do you have any recommendations?
With Regards
Sunil

7

Hi @Sunilks ,

Could you also share your payload size for us to reproduce this issue? Do you have enough time between two consecutive TX frames? What is your period of transmission?

8

In our use case, we have utilized three QM33120 devices (device A, B, and C). Devices “B” and “C” receive the 232 bytes of data (including header) that device “A” broadcasts. Once broadcast, device ‘A’ will enter receive mode and wait for a packet from device ‘B’. After receiving 232 bytes from device “A,” device “B” will immediately broadcast 116 bytes of data, which both device “A” and device “C” will receive. Device ‘C’ will now broadcast 116 bytes, which ‘A’ and ‘B’ will receive."
It appears as shown below:
broadcast 232 bytes
step1 (Tx)A-----------------------------------> B,C(RX Mode)

				         broadcast 116 bytes

step2 (Rx Mode)A,C <--------------------------------------- B(Tx)

				       broadcast 116 bytes

step3 (Rx Mode)A,B <---------------------------------------- C(Tx)

Since steps 1, 2, and 3 will continues till we give stop command from command prompt, we have not established a time interval between transmissions. As a result, every device will have its states shown below.
Device A–> TX,RX,RX
Device B–> RX,TX,RX
Device C–> RX,RX,TX

9

Hi @Sunilks ,

I think the behaviour that you observed is expected because if you have a longer PSDU then you have a higher probability of receiving signals. You can try to improve the robustness of the link by increasing the preamble length such as 1024 and reducing the data rate (850kbps).

Kind regards,
Emre