First byte of payload interpreted as device address, changing BALEN has no effect

RE: First byte of payload interpreted as device address, changing BALEN has no effect

Kenneth — Mon, 27 Jan 2025 10:17:11 GMT

Hi,

The ESB library should be backwards compatible by following:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/esb/index.html#backward_compatibility

There are also some example projects (you need to set ESB_LEGACY_CONFIG=y in prj.conf for them to work with nRFgo SDK which use the nRF24L01+ radio):
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/esb/index.html#examples

You can find a description on the radio in the nRF52810 here:
https://docs.nordicsemi.com/bundle/ps_nrf52810/page/radio.html

If there is a radio interrupt with CRCERROR then the packet should be discarded yes, since the payload contain errors.

Best regards,
Kenneth

RE: First byte of payload interpreted as device address, changing BALEN has no effect

alex101 — Fri, 24 Jan 2025 05:25:46 GMT

If I add config.crc = ESB_CRC_OFF; to the ESB example, packets are no longer received.
Our nRF24 TX uses the default CRC 8 bit.

Speaking of CRC, I'm not sure what the difference between EVENTS_CRCOK and CRCSTATUS.
EVENTS_CRCOK does show it changes to 1 (EVENTS_CRCERROR also changes to 1)
CRCSTATUS always seems to stay at 0

RE: First byte of payload interpreted as device address, changing BALEN has no effect

Kenneth — Thu, 23 Jan 2025 15:40:52 GMT

Have you disabled CRC here?
https://docs.nordicsemi.com/bundle/ps_nrf52810/page/radio.html#ariaid-title55

Kenneth

RE: First byte of payload interpreted as device address, changing BALEN has no effect

alex101 — Thu, 23 Jan 2025 03:35:05 GMT

Hi Kenneth,

I enabled ADDR1:
NRF_RADIO->PREFIX0 = 0x00000000;
NRF_RADIO->RXADDRESSES = RADIO_RXADDRESSES_ADDR1_Enabled << RADIO_RXADDRESSES_ADDR1_Pos;

With the transmitter off, it is just receiving random data which is very strange and even stranger is that it says RXMATCH is 0x07 even though only ADDR1 is enabled as shown in the debugger.

I also tried going back to the ESB example and using the default addresses of the nRF24/52 for the nRF24 TX and nRF52 RX sides, no packets were being received which is odd. If I change the address back to my own one, it receives the data but same problem as before - missing first byte and like 95%+ of packets don't make it.

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};

struct esb_config config = ESB_LEGACY_CONFIG;

config.protocol = ESB_PROTOCOL_ESB;
config.bitrate = ESB_BITRATE_2MBPS;
config.mode = ESB_MODE_PRX;
config.event_handler = event_handler;
config.selective_auto_ack = false;
config.payload_length = 2;

We have a static payload of 2 bytes and no ACKs are sent back.

If I use 2 nRF52 DKs as the TX and RX then it works in the ESB example but we have hundreds of nRF24 TX/RX in the field so can't easily upgrade them. I have seen others being able to get the nRF24 TX to work with the nRF52 RX properly

RE: First byte of payload interpreted as device address, changing BALEN has no effect

Kenneth — Wed, 22 Jan 2025 13:19:15 GMT

Hi,

I think it may be somehow related to this: nRF5340 - sensitivity and ADDR0

Do you see the same if using pipe1 on the nRF52840?

Kenneth

RE: First byte of payload interpreted as device address, changing BALEN has no effect

alex101 — Wed, 22 Jan 2025 03:55:51 GMT

I have some nRF24 receivers that work with our nRF24 TX and if we change any byte of the 5 byte RX address on the RX side, I can confirm that those nRF24 receivers stop working so it does sound like we are indeed sending a 5 byte address.

On the nRF52, I can change some bits of the end byte of BASE0 address (4E) to another value and it still receives the packet but changing any of the first 3 bytes and it doesn't work. If I change PREFIX0 from 0x00 to 0x80 and send 0x01 as the first payload byte then receiving also works so I think my theory of what is happening might be correct.

Another thing I have just noticed when debugging is that RXMATCH is always 0x00000000 but packets are still received