nRF24 Communication protocols

[last updated: 2020-04-13]
go to: nRF24
-----

On this page:

Acknowledgement/response:
radio.available:
Packet format:

-----------------------

• Acknowledgement/response:
  When one nRF24 module sends a message/data to a second module, the second module can be programmed to send an acknowledgement/reply, to let the first module know the message was received.
  There are two ways to do this:
  • The first way involves the automatic ack, what I call the handshake or HS response. This feature is enabled by default, but can be disabled in your sketch with:
    setAutoAck(false) ... or true to turn it back on; this sets AutoAck mode for all pipes
    setAutoAck(2, false) ... for example, sets AutoAck off for pipe 2
    • If auto-ack is enabled, then when you do a radio.write from a sender, a bool signal (ie. either true or false) will be sent back to the sender from the receiver (upon successful receipt of a message).
      Don't know how this works. Specifically, what pipe does the ack get sent on?.
    • eg. the command in your sketch might be:
      bool ok = radio.write(&textToSend, strlen(textToSend) );
      will return true if the write (or at least some part of it) was successfully received.
      That is, if you have opened pipes[0] for writing on your sender, and opened pipes[0] for reading on your receiver, then (assuming everything else is in order) when the receiver gets the message, it will return (on the same pipes[0]?) a true to the sender.
      In my example above, the handshake bool response from the receiver back to the sender goes into the "ok" variable of the sender's sketch, which you can then test.
      If you eg. unplug your receiver, the write will fail and return false.

    • Key disclaimer however is that receipt of the auto-ack/HS is no guarantee that your entire message was received intact. In my breadboarding trials, it has often happened that I receive a HS, indicating at least something was received, yet testing shows me that the entire message was Not received intact. So you have to follow up with the 'second way' below (or see radio.available below)

    • HOWEVER::
      from: tmrh20.blogspot:
      "Since auto-ack implies a bi-directional communication channel, each address/pipe can only support communication to a single radio using acknowledgements. If two or more devices send data to a single pipe/address, auto-ack should be disabled to prevent ACK spamming and erroneous acknowledgements."

  • The second way to get an ack/response is with a routine programmed in your sketch:
    • Immediately after the sender writes a message, it switches to receiving with a startListening() command (it must have a reading pipe open).
    • The receiver, upon receiving the message, will be programmed to do a write to send the message (or whatever acknowledgement desired) back to the sender (the receiver must have a pipe open for writing).
    • When the sender receives the ack/response from the receiver, if it matches what's expected, 'success' is declared.
    • If you then want the sender to go back to writing a message, you must do a stopListening() command.

  ---------------------------------------------

• radio.available:
  • Hope I can find the link I lost that had this info ...
  • It explained that radio.available does not behave like you might expect.
    Specifically, it goes high if a complete, correct message is received.

  ---------------------------------------------

• Packet format:
  Note: Lots of formats are possible, of course, this is just the way I am doing it at this moment.
  • Each packet of data is of the form:
    eg. "F:01T:02M:some message"
    where:
    F: [nodeID of sender]
    T: [nodeID of recipient]
    M: the message itself
    (followed by perhaps a checksum or other end-of-packet marker)

.

.

.

eof