• State Not Answered
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 156 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290240
Options

nRF5340 Shockburst compatibility to nRF2401

user112997

Dear DevZone,

our goal is to replace the RX side of an old system, which is using the nRF2401. For real-time capabilities, the Shockburst protocol was employed.

Reading through the DevZone and documentation we were under the impression, that the nRF5340 (or other new chips) are "Shockburst compatible". Adjusting the ESB sample including the NRF_RADIO parameters like PCNF0 to 0 0 0 seemed to be a workable solution.

But then, we stumbled across two topics.

1. The length of the payload can be defined in bits for the nRF2401, and in bytes ever since. Sadly our legacy TX solution is using 95 bits for the payload length. The CRC starts right after.

2.The length of the address can also be defined in bits for the nRF2401, and in bytes since. Our legacy TX solution is using 20 bits address.

For the payload topic, it may be an acceptable solution to

- receive more than 95 bits + 16 bits CRC (i.e. 14 bytes)

- disable NRF_RADIO in our RX, and calculate the CRC manually

An early proof of concept indicates this may work, and this also fits our understanding of the NRF_RADIO functionality: NRF_RADIO looks for the preamble and adress, and gives us the following 14 bits, with which we can do what we want.

The address topic is more bothersome. We are thinking of using only a 2 byte address, which leaves 4 bits of the legacy address which we will receive as payload, and eliminate going forward.

However, this seems to only  work in theory. Using a 2 byte address, we are receiving many too many pakets, and most of all, no correct one.

In our office environment, an address length of 4 and 5 bytes does not generate any faulty pakets. An address lenght of 3 very rarely does so, and at 2 it's not usable anymore.

Do you have got other ideas how to solve this, and is it common that an address length of 2 will lead to too many pakets?

Thank you!

Uli

Parents
  • 0

    Hi,

    An early proof of concept indicates this may work, and this also fits our understanding of the NRF_RADIO functionality: NRF_RADIO looks for the preamble and adress, and gives us the following 14 bits, with which we can do what we want.

    I assume you mean 16bit? In any case, a 16bit address without any crc will happen statistically every 65ms @ 1Mbps, since 2^16 = ~65k addresses, and with a random 1Mbps bit stream this will be found about every 65ms. I don't see any way of avoid this, but if you can't receive any address, then you should look at the order of address bits (e.g. MSB vs. LSB), it might be inverted to what you expect.

    Best regards,
    Kenneth

  • 0 in reply to user2111

    Hi Kenneth,

    thank you! I actually wanted to write 14 bytes*, referring to our need of 95 bits of data, + 16 bits CRC = 14 bytes. So I'm expecting the RX to always look for the preamble and the adress, and give me 14 (or another number of) bytes of data subsequently.

    Let me explain in more detail what I'm doing:

    - test setup HW is 2 nRF5340 DK devboard

    - SW is ESB PTX and PRX samples by Nordic

    - I'm setting the address length to 5, or 4, or 3, everything is fine, data are being transmitted. At an address length of 3 random faulty packets start to show up regularly, at 4 or 5 none of these occur.

    - I'm setting the address length to 2 and I don't receive correct packets anymore, but only random faulty packets. This is without any change to the base address or prefix, which are 0xE7 all along, as suggested by the sample.

    Do you have got an idea what may be going on here? MSB or LSB can't be the reason in my opinion, as I'm not changing the address, but only the length of the address that shall be used.

  • 0 in reply to user112997

    Hello,

    If you disable CRC and use 1Mbps on-air, then that means the radio front end will continously look for the address in a random demodulated white noise. 

    How often a false address will be found in the white noise depends really on the address length and the on-air datarate. For instance:

    16-bit address: 2^16 combinations = 65536 combinations, @1Mbps this will occur about every 65ms.
    24-bit address: 2^24 combinations = 16.7M combinations, @1Mbps this will occur about every 1.67seconds.
    32-bit address: 2^32 combinations = 4295M combinations, @1Mbps this will occur about every 72minutes.

    How often it really will occur depends slightly on the distribution of the white noise, but typically it will just be random patterns of 0101110101011011100101100101....

    And E7 for instance is 11100111

    So you can see it's not terribly unlikely a false address will be found with short addresses.

    Best regards,
    Kenneth

Reply
  • 0 in reply to user112997

    Hello,

    If you disable CRC and use 1Mbps on-air, then that means the radio front end will continously look for the address in a random demodulated white noise. 

    How often a false address will be found in the white noise depends really on the address length and the on-air datarate. For instance:

    16-bit address: 2^16 combinations = 65536 combinations, @1Mbps this will occur about every 65ms.
    24-bit address: 2^24 combinations = 16.7M combinations, @1Mbps this will occur about every 1.67seconds.
    32-bit address: 2^32 combinations = 4295M combinations, @1Mbps this will occur about every 72minutes.

    How often it really will occur depends slightly on the distribution of the white noise, but typically it will just be random patterns of 0101110101011011100101100101....

    And E7 for instance is 11100111

    So you can see it's not terribly unlikely a false address will be found with short addresses.

    Best regards,
    Kenneth

Children
No Data
Related
Terms of service