This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF905 preamble

Hi everyone,

I am working on a project using nRF905 as an emitter and another Receiver(different than nRF905), the receiver is programmed in a way to perform some actions only when it received a specific frame(for example: 0x156666) but after reading the data sheet I found that in each data packet transmitted by the nRF905 a preamble is added automatically in addition to the TX address.

As a result, the frame at the output will be: [preamble][Address][0x156666][CRC]

I found that CRC can be disabled so the data frame will be :  [preamble][Address][0x156666]

My question is: it is possible to remove the preamble and the address and keep only the payload? If not, what does 10 bit of the preamble looks like?

I will be very grateful if anyone could help me to fix this problem.

Best regards

Parents
  • I also ran into this problem with no answers online. I needed an S2-LP device from STMicroelectronics to communicate with an NRF905 in a legacy system. After a few days of reverse-engineering multiple packets sent by an NRF905 device, I was able to decode the preamble and CRC algorithm:

    • Preamble: 01010101010110011001 (Manchester IEEE encoded) 1111110101 (bits)
    • CRC uses the CRC-16/CCITT-FALSE algorithm

    The raw bitstream you need to send then becomes 1111110101[Address][Payload][CRC]. Remember that the bitstream that is transmitted should first by Manchester IEEE encoded!

    Hope this helps!

Reply
  • I also ran into this problem with no answers online. I needed an S2-LP device from STMicroelectronics to communicate with an NRF905 in a legacy system. After a few days of reverse-engineering multiple packets sent by an NRF905 device, I was able to decode the preamble and CRC algorithm:

    • Preamble: 01010101010110011001 (Manchester IEEE encoded) 1111110101 (bits)
    • CRC uses the CRC-16/CCITT-FALSE algorithm

    The raw bitstream you need to send then becomes 1111110101[Address][Payload][CRC]. Remember that the bitstream that is transmitted should first by Manchester IEEE encoded!

    Hope this helps!

Children
  • Hello Inubot,

    It has been a while but thanks for sharing your experience.

    I am facing the same task as you did. Would you be able to share more info on how you set up the S2-LP chip to enable the two to communicate.

    Any info will be appreciated.

    Thanks

    Witek

  • Hi Witek,

    I have used the S2-LP DK GUI (https://www.st.com/en/embedded-software/stsw-s2lp-dk.html) to tinker with the register values of the S2-LP to match the RF parameters of the NRF905. 

    In my case the S2-LP was setup with the following radio settings (have a look at the above link for a screenshot of the DK):

    • 433 MHz freq base (assuming no channel offset on NRF905)
    • 100 ksps data rate (data transmission rate of the NRF905)
    • 50 kHz freq deviation (typical freq deviation of NRF905)
    • 250 kHz channel filter 
    • Max power ticked

    For the packet settings, you need to remove the preamble, sync word, length and CRC segments of the packet structure, and uncheck data whitening. You should only be left with the payload section of the packet.

    In order to transmit data from the S2-LP to an NRF905 device, you will have to build up the payload to include the NRF905 preamble and address before the actual transmission data, followed by the CRC:

    • 1111110101[Address][Data][CRC]

    This entire stream should be written to the TX buffer of the S2-LP.

    If done correctly, the NRF905 should pick up the transmission and an interrupt should be triggered on the DR pin. You can also use the AM pin to help with troubleshooting.

    Hope this helps!

    Regards

  • Hello Inubot,

    Been a while.

    Thanks for this info. It certainly helped... But I am not getting a reliable communication between the chips. If I am able to receive a message in nRF905 then it sometimes is correct and sometimes is mangled up depending on what I send in the message. For the time being I am not using CRC checking, just to keep it simple.

    Can you confirm that you were albe to get the two devices communicate reliably?

    Thanks

    Witek

Related