Acceptable packet loss specs nRF528XX

[Vagner Landskron]

Hello, 

We were middle way during the development when we found out that we had a higher packet loss than what is acceptable.

So we start to analyze this issue.

Scenario:

• We've 1x BL653 running an application
  • This application has ESB enabled and is set as PRX;
  • Once it gets an ESB packet, it parses the payload (which contains a unique sequential number)
  • Switch its role to PTX and reply a packet (broadcast on pipe 0) containing this sequential number as a size of 128 bytes (without auto ack);
  • TX power is 4dBm, DPL (dynamic packet length)
• 1x BL654 running a test application
  • This application listens to the UART port for commands via the HOST (PC)
  • ESB is set as PTX
  • Once it gets a command, it parses the message (which should contain a unique sequential number)
  • Then builds an ESB Packet of 8 bytes and sends it (broadcast on pipe 0) containing this unique number (without auto ack)
  • Gives enough time to broadcast this message (~1000us) and switch role to PRX
  • Wait for ~18000us for all devices to respond
  • Report statistics to HOST PC
• This BL654 is connected to a PC which runs a test application
  • This test application runs every 30ms and writes a sequential and unique number via UART
  • Collect statistics from BL654 via UART

Therefore, a packet loss could be a packet that couldn't be delivered to BL653 or either the reply packet that couldn't be delivered to BL654.

Assumptions:

We've verified the UART channel and we're getting 0% of packet loss here.

Questions:

1. We would like to know what is the "acceptable" packet loss according to Laird/Nordic measurements?
   1. Is 1% (according to the scenario detailed below) acceptable?
   2. Does Nordic provides some table of scenarios and expected packet loss ?
2. According to the BL653 specs (datasheet), we could get up to 8dBm for Tx Power, but the Nordic's SDK allows us up to 4dBm.
   1. If I "hack" the enum esb_tx_power and add the 8dBm option, will it work? (add there: ESB_TX_POWER_8DBM = RADIO_TXPOWER_TXPOWER_Pos8dBm)
   2. Cause I did it, but I've no evidence that it actually worked…
3. Is there a way to make the "serial" line work in parallel with the "RF" line?
   1. Example: If the BL654 starts writing via UART some payload and at the same time another device (BL653) starts sending data via ESB, will the BL654 be able to collect this ESB packet or we'll get a packet loss?
   2. Is there a way to guarantee that this communication will happen in parallel?
   3. We heard about UART DMA,  by your experience, will it solve this issue?
4. External oscillator could improve the RF performance (reduce packet loss)?

[Kenneth]

Hi again,

Vagner Landskron said:

Is there any measurements/statistics performed by Nordic?

As part of production test and qualification there are extensive tests performed on the radio, to ensure that all nR devices delivered perform according to the production specifications. If you want to perform tests yourself to for instance measure packet error rate or similar, you can do this using for instance DTM test:
https://infocenter.nordicsemi.com/topic/struct_appnotes/struct/appnotes_nan34.html

This test is following the BLE specification for testing the radio, but the same will verify any radio protocol and can for instance output the packet error rate.

Vagner Landskron said:

Another information is that certain "channels" are cleaner than others. At the moment, in our lab, channels 21-22 are super clean and gives me really good results:

I am not sure how your protocol is working, but it looks like you have one transmitter, and possible several devices that receive this and respond back. I assume you have ensure sufficient timing between the various devices such that they are not "talking" at the same time. If specific channels are performing better, it can be that there is less noise on the channels in specific, or that you are using an antenna that is very narrow banded, and thereby perform better on certain channels in the middle of the band for instance.

Vagner Landskron said:

Another question, if the packet fails the CRC (such as if I disable the CRC) - will I get a corrupted packet?
The way it's written here sounds like it's only for "identification" purposes.

I don't remember exactly the details here what happens if CRC fails, I would assume it should be possible to still check the packet in RAM (even if CRC failed):
https://infocenter.nordicsemi.com/topic/ps_nrf52833/radio.html#register.PACKETPTR 

Best regards,
Kenneth