Reliability Issues with ESB

[AlbertoP]

Hi,

I am working on some prototypes with nRF52840 MCUs (custom PCBs) on the receiver and the transmitter using the ESB protocol. Our application needs a 3m range without losing any data. So, I tuned the PCBs with a vector analyzer and I got a RSSI of -25dBm at 70cm (better that the eval boards. which is normal since I am using a dipole antenna on one PCB and a chip antenna on the other). At approximately 1.2m (-42dBm), I am starting to lose data. If I understand well (www.metageek.com/.../) at -62dBm the system shouldn't lose any data. I am starting to think that there is something wrong in the configuration of the ESB or I am messing something important related to the hardware.

nRF5 SDK version 17.1.0

Here is a part of the configuration of the transmitter: 

Package are send every: 9600us

tx_payload.length = 220;

uint32_t esb_init( void )
{
uint32_t err_code;
uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};
uint8_t base_addr_1[4] = {0xC2, 0xC2, 0xC2, 0xC2};
uint8_t addr_prefix[8] = {0xE7, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8 };

nrf_esb_config_t nrf_esb_config = NRF_ESB_DEFAULT_CONFIG;
nrf_esb_config.protocol = NRF_ESB_PROTOCOL_ESB_DPL;
nrf_esb_config.retransmit_delay = 880;
nrf_esb_config.retransmit_count = 10;
nrf_esb_config.bitrate = NRF_ESB_BITRATE_2MBPS;
nrf_esb_config.event_handler = nrf_esb_event_handler;
nrf_esb_config.mode = NRF_ESB_MODE_PTX;
nrf_esb_config.selective_auto_ack = false;
nrf_esb_config.tx_output_power = NRF_ESB_TX_POWER_8DBM;

err_code = nrf_esb_init(&nrf_esb_config);
VERIFY_SUCCESS(err_code);

err_code = nrf_esb_set_base_address_0(base_addr_0);
VERIFY_SUCCESS(err_code);

err_code = nrf_esb_set_base_address_1(base_addr_1);
VERIFY_SUCCESS(err_code);

err_code = nrf_esb_set_prefixes(addr_prefix, NRF_ESB_PIPE_COUNT);
VERIFY_SUCCESS(err_code);

return err_code;
}

Here is a part of the configuration of the reciver:

uint32_t esb_init( void )
{
uint32_t err_code;
uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};
uint8_t base_addr_1[4] = {0xC2, 0xC2, 0xC2, 0xC2};
uint8_t addr_prefix[8] = {0xE7, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8 };
nrf_esb_config_t nrf_esb_config = NRF_ESB_DEFAULT_CONFIG;
nrf_esb_config.payload_length = 32;
nrf_esb_config.protocol = NRF_ESB_PROTOCOL_ESB_DPL;
nrf_esb_config.bitrate = NRF_ESB_BITRATE_2MBPS;
nrf_esb_config.mode = NRF_ESB_MODE_PRX;
nrf_esb_config.event_handler = nrf_esb_event_handler;
nrf_esb_config.tx_output_power = NRF_ESB_TX_POWER_8DBM;
nrf_esb_config.selective_auto_ack = false;

err_code = nrf_esb_init(&nrf_esb_config);
err_code = nrf_esb_set_base_address_0(base_addr_0);
err_code = nrf_esb_set_base_address_1(base_addr_1);
err_code = nrf_esb_set_prefixes(addr_prefix, 8);

return err_code;
}

[ovrebekk]

Hi

You mentioned you compared the RSSI to the eval boards. Did you also try to set up a similar test using the eval boards only to see if the range issue is the same? 

You should definitely not see heavy packet loss at 1.2m, unless you have a very high level of noise from other 2.4GHz sources on the selected frequency. Can you let me know which RF channel you are using? 

Looking at your RX configuration it seems you are setting payload_length = 32, but in your TX snippet you appear to send a 220 byte payload. Is this a typo? 
The payload_length on the receive side needs to be equal or larger than the size of the payload sent from the transmitter, and in order to support 220 byte payloads you need to increase the payload_length configuration on both sides. 

Best regards
Torbjørn

[AlbertoP]

Hi Ovrebekk,

 

1) I did some more tests today.

                *With the evaluation boards (as RX and TX) and, at -42bBm (2.6m), I have no data losses with the same code.

                *With my custom PCB for RX (dipole antenna) and the evaluation board as TX at the same distance of 2.6m, I got -32dBm with no data losses.

                *With my custom PCBs for RX (dipole antenna) and TX (Chip antenna) at the same distance of 2.6m, I got -39dBm with data losses (not many 1 every 10 sec).

 

I think that today the RF channel we are using was not as noise as the first time I did the tests. Also, my RX PCB is worse than the evaluation board. I think it could be improved but it might be difficult since the RX PCB is only 24mmX14mmX0.55mm.

 

2) We use channel 10. Since we use nrf_esb_set_rf_channel(channel) to set the channel, I think that we are using the default range of frequency [2400;2500] MHz. So, the frequency that I use for my test is 2410 MHz. Are there frequencies that should be voided?

 

3) nrf_esb_config.payload_length was at 32 on the RX and TX (Since we used the default configuration for the TX, nrf_esb_config.payload_length = 32). I change both to 250 since on the TX configuration tx_payload = NRF_ESB_CREATE_PAYLOAD(0, 0x250, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x00). This change didn't seem to change the data loses. tx_payload.length = 220 is the biggest payload length that we send. The payload length could variate between [11; 220] depending on the type of message send but for the continuous data transfer we always use 220.

 

I am not sure to understand the difference between tx_payload.length and nrf_esb_config.payload_length could you explain it to me?

 

Your help is highly appreciated.

Best regards,

Alberto Perez

[ovrebekk]

Hi Alberto

1) Thanks for sharing the test results, I had a feeling it was hardware related to an extent. I would strongly recommend sharing your hardware schematics and layout with us so we can do a proper hardware review, there might be some room for improvement even if your design is space constrained. 

If you do so please open a new ticket, hardware review is not my forte

AlbertoP said:

Are there frequencies that should be voided?

Technically any frequency between 2402-2482 is safe, providing you some margin to the edges of the ISM band. 

That said there have traditionally been some channels that have been less likely to get hit by Wi-Fi interference than others, because of the way Wi-Fi networks use the network. This is described in more detail here.  Essentially most Wi-Fi routers would use Wi-Fi channels 1, 6 and 11, which leave some frequencies relatively free from Wi-Fi interference. That being said this is not absolute, and Wi-Fi routers might choose to use different channels than these. Modern Wi-Fi routers running Wi-Fi 5 or 6 might use different frequencies altogether, or skip the 2.4GHz band to run at 5GHz or 6GHz instead, so I wouldn't put too much emphasis on selecting channels in between the standard Wi-Fi bands. 

For testing purposes you could try channels outside the ISM band, such as channel 90, to verify whether or not interference is the problem. Just be aware that you need to stay away from these channels once you want to qualify your product. 

AlbertoP said:

I am not sure to understand the difference between tx_payload.length and nrf_esb_config.payload_length could you explain it to me?

On second thought the critical parameter is the NRF_ESB_MAX_PAYLOAD_LENGTH define in nrf_esb.h. 

This defines the maximum payload length you are allowed to send, and changes the ESB header format slightly when set to values > 32 in order to make room for a larger length field (the length field is increased from 6 to 8 bits to allow packet lengths up to 252 bytes). 

This parameter also scales the FIFO buffers accordingly to make sure that there is room in the buffers for the larger payloads. 

The length field in the ESB payload is a dynamic configuration that allows you to change the payload length between packets, but it is important that this parameter is no larger than NRF_ESB_MAX_PAYLOAD_LENGTH. 

The nrf_esb_config.payload_length parameter is really only important when you use the legacy ESB mode (nrf_esbconfig.protocol = NRF_ESB_PROTOCOL_ESB). In this mode the payload length is static, and you need to ensure that both the transmitter and receiver is configured with the same payload length at all times. 

Best regards
Torbjørn

[AlbertoP]

Hi Ovrebekk,

 

1) I will share the design files on a private ticket. Any suggestion for improvement will be welcome.

 

2) I tested the system on channel 90 and it work well at 3.6m. Thank-you for the helpful information you provided.

 

3) Thank-you for the explanation. On TX and RX NRF_ESB_MAX_PAYLOAD_LENGTH is configured to 252 and nrf_esbconfig.protocol is set to NRF_ESB_PROTOCOL_ESB_DPL. So, we should be fine with the dynamic payload.

 

Best regards,

Alberto Perez

[ovrebekk]

Hi Alberto

Good luck with your project. I will consider this ticket resolved then, unless you have more questions? 

Best regards
Torbjørn

[AlbertoP]

No that is all Thank-you Ovrebekk

[ovrebekk]

Glad I could help

[AlbertoP]

If someone needs a chip 2.4GHz RF scanner to trouble shoot the wireless communication, you can use this: https://mode-zero.uk/viewtopic.php?f=9&t=17. It helps me to find the available channels to test my device.