• State Not Answered
  • Replies 5 replies
  • Subscribers 85 subscribers
  • Views 2174 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 221008
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF24L01+ design running on batteries - Standby-I question

KentR

I have a design, using the NRF24L01+, that I would like to run from batteries.  The Transmitting device is not a problem, because it can turn off when not transmitting.

For the Receiving device, I would like to use the Standby-I mode, and periodically switch over to Active Receive mode to listen for messages.

Has anyone done anything like this?  I am finding that I miss most of the messages, by going into Standby.  This is what I would like to do:

1) Transmitter sends out an 11-byte packet every 5mS, for 500mS, when a button is pressed.

2) Receiver is in standby for 400mS, then switched to active receiving for 50mS, and then back to Standby.

I have tested this, and I only get maybe 1 correct reception, out of 10 button presses.

When I keep the Receiver in Active Receive, I get a correct reception upon each button press on the Transmitter.

If anyone has any advice for a low power receiving strategy, I would appreciate it.  Thanks! 

Parents
  • 0

    Hi Kent

    It is odd that you would receive so few packets with the timing parameters you mention. If you send the same packet at 5ms intervals for 500ms you should have around 10 attempts to get through, regardless of how the TX and RX have drifted timing wise. 

    Are you sending the same payload over and over again?
    This can some times lead to issues where the packet is discarded in the receiver because it is assumed to be a retransmit of an older packet. 

    If this is the case can you try to include a rolling counter in the payload and see if the performance improves?

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hello,

    I am indeed sending the same payload over and over again.  I did not realize that this would cause any issues like you mention.  I will add a counter into the payload, as you suggest, & see what happens.

    Thank you for the help!

  • 0 in reply to KentR

    Hi 

    In some cases this can be a problem, but it is a bit situation dependent. 

    Just let me know as soon as you have tested it.  

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Ok, I think I have this figured out now.  It was not related to sending the same payload message.  Although, adding the counter into the payload was a handy troubleshooting tool.

    It turned out to be an issue on the Transmitter side, and not the Receiver side.  The very last byte of my packet is a checksum byte.  It turns out that the first packet sent, had the correct checksum value, but every packet after that had a wrong value transmitted, for some reason.  With the original software, this wasn't noticed, because the first packet was always received.  But with the Standby Mode added to the software, you would only occasionally receive the very first (correct) packet.

    So, Nordic is working fine, it was just my own software screw-up.  :)

Reply
  • 0 in reply to ovrebekk

    Ok, I think I have this figured out now.  It was not related to sending the same payload message.  Although, adding the counter into the payload was a handy troubleshooting tool.

    It turned out to be an issue on the Transmitter side, and not the Receiver side.  The very last byte of my packet is a checksum byte.  It turns out that the first packet sent, had the correct checksum value, but every packet after that had a wrong value transmitted, for some reason.  With the original software, this wasn't noticed, because the first packet was always received.  But with the Standby Mode added to the software, you would only occasionally receive the very first (correct) packet.

    So, Nordic is working fine, it was just my own software screw-up.  :)

Children
Related
Terms of service