re:nrf24l01p and nrf51822 esb communication

RE: re:nrf24l01p and nrf51822 esb communication

Kenneth — Mon, 19 Oct 2020 09:00:35 GMT

If you are setting EN_AA=0 then you are disabling the auto ack -> in other words you are disabling the "Enhanced" in the "E"SB protocol, and instead are using old SB protocol. This is not really supported by the ESB examples. In such case you likely will need to look at the \examples\peripheral\radio\receiver example.

Best regards,
Kenneth

RE: re:nrf24l01p and nrf51822 esb communication

JK5 — Fri, 16 Oct 2020 02:39:38 GMT

hi.

I did the test as you told me.

I tried nrf51(prx), nrf24(ptx) and it worked.
However, it was only possible when using the complete basic example.
Do not change the address strangely.
Only 0xE7E7E7E7E7 is possible, and if you change to 0xC2C2C2C2C2, 0xC3C3C3C3C3,0xA5A5A5A5A5, prx only receives once and does not receive.

The changed source code is
NRF51
esb_init()
{
...
uint8_t base_addr_0[4] = {0xA5, 0xA5, 0xA5, 0xA5};
uint8_t base_addr_1[4] = {0xC2, 0xC2, 0xC2, 0xC2};
uint8_t addr_prefix[8] = {0xA5, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8 };
...
}

NRF24
main()
{
unsigned char address[5] = {0xA5, 0xA5, 0xA5, 0xA5, 0xA5};
...
hal_nrf_set_address(HAL_NRF_TX, address);
...
while (1)
{
hal_nrf_write_tx_payload(payload, 3);
CE_PULSE();
}
}

------add

For the above problem, for nrf24 to nrf24, EN_AA should be 0.

If EN_AA is set to 0 in nrf24, how should it be set in NRF51?

RE: re:nrf24l01p and nrf51822 esb communication

Kenneth — Wed, 14 Oct 2020 09:15:03 GMT

In general we don't recommend using address fields with multiple 00 or FF, since that resemble noise, and may increase the packet error rate.

If you are unsure of the address is correct, just set all address bytes to the the same value, e.g. the default is all bytes are C2 or all E7. It is easier to find if that is the problem that way.

Best regards,
Kenneth

[quote user="JK5"]nrf_esb_set_address_length(3);
Then, the base address is 2 bytes and the prefix is 1 byte.[/quote]

Correct.

RE: re:nrf24l01p and nrf51822 esb communication

JK5 — Wed, 14 Oct 2020 00:10:49 GMT

thank you. I'll try.

In NRF51, we try to designate the address as 3 bytes.
nrf_esb_set_address_length(3);
Then, the base address is 2 bytes and the prefix is 1 byte.
Is that right?
S0,S1,LFLEN settings are S0, S1 = 1, LFLEN =0; Is it this way?

NRF51_RM(Page 82) "The base address is truncated from LSByte if the BALEN is less than 4. "
For example, when setting 3 bytes of the pipe 0 address to 0xABCDEF
1) uint8_t base_addr_0[4] = {0xAB, 0xCD, 0x00, 0x00};
2) uint8_t base_addr_0[4] = {0x00, 0x00, 0xAB, 0xCD};
uint8_t addr_prefix[8] = {0xEF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

How should I set it up?
The datasheet is too short to understand.

RE: re:nrf24l01p and nrf51822 esb communication

Kenneth — Tue, 13 Oct 2020 12:42:18 GMT

You should be able to use the ESB examples from nRFgo SDK v2.3 (nRF24L-series) with the nRF5 SDK (nRF51 or nRF52-series, the latest nRF5 SDK for the nRF51-series is v12.3). Please use the examples with no change as a start. The only thing you need to modify is the following for the nRF5 SDK:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v12.3.0/esb_users_guide.html#esb_backwards

The nRFgo SDK v2.3 is found here (see Development tools and download zip file):
https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF24-series

After installation you can find the ESB configuration here:
\nRFgo SDK 2.3.0.10040\source_code\projects\nrfgo_sdk\enhanced_shockburst_examples

As a start don't use W_TX_PAYLOAD_NOACK, but use the W_TX_PAYLOAD first, since that will work without any specific features enabled (because once you enable the FEATURE->EN_DYN_ACK bit, then the behavior of the NO_ACK bit is reversed; '0' means NOACK, '1' means ACK).

If you have any problem have in mind they may be due to byte order or length of the address field, so the best is to use the default as a starting point, and change one register at a time until you can find what may be causing your problems.

Best regards,
Kenneth