Author Topic: ACK vs SEND with RETRY  (Read 1770 times)

KrisK

  • NewMember
  • *
  • Posts: 26
  • Country: us
ACK vs SEND with RETRY
« on: February 09, 2019, 02:13:14 PM »
Is there really a need to send an ACK between the Gateway and multiple nodes?       As I am refining code, I begin to wonder if the ACK command does anything other than learn there is a node out there ACKing back?   (And cluttering up the airway with ACK data)

Should I design my code so periodically ACK between nodes just to keep them fired up waiting for real data to come through?   Or as long as I send with retry I shouldn't worry about ACK.

My intent is to have increase the system with 1 to 64 nodes receiving data from the gateway(controller).   And, have 1 to 8 gateways(controllers) sending the data to the 1 to 64 nodes.

Anyway just thought I would pose this to the guru's and see if anybody feels the ACK is or isn't necessary.

Thanks
Kris 

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: ACK vs SEND with RETRY
« Reply #1 on: February 09, 2019, 02:17:06 PM »
Is there really a need to send an ACK between the Gateway and multiple nodes?       As I am refining code, I begin to wonder if the ACK command does anything other than learn there is a node out there ACKing back?   (And cluttering up the airway with ACK data)

Should I design my code so periodically ACK between nodes just to keep them fired up waiting for real data to come through?   Or as long as I send with retry I shouldn't worry about ACK.

My intent is to have increase the system with 1 to 64 nodes receiving data from the gateway(controller).   And, have 1 to 8 gateways(controllers) sending the data to the 1 to 64 nodes.

Anyway just thought I would pose this to the guru's and see if anybody feels the ACK is or isn't necessary.

Thanks
Kris
It sounds like you're confusing the purpose and timing of ACK.  ACK is sent in response to a message.  The sender of the message can request the ACK and the receiver sends it once the message was received reliably.  It is an ACKnowledgement that the message was received.


KrisK

  • NewMember
  • *
  • Posts: 26
  • Country: us
Re: ACK vs SEND with RETRY
« Reply #2 on: February 10, 2019, 12:29:10 AM »
Thanks Tom

I was confused.  I thought it was an independent function.     I am going to need to rethink some of my code.   Kris

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: ACK vs SEND with RETRY
« Reply #3 on: February 10, 2019, 09:34:06 AM »
I thought it was an independent function.
Sending the ACK is an independent function.  However, it's use is in response to receiving a message that was sent using sendWithRetry().

On the receiving side, you'll get a positive return from receiveDone() (meaning that you received a message) and you'll have to check to see if ACKrequested() is true.  If it is, then you send the ACK using sendACK() back to SENDERID.

Note that sendWithRetry() has two parameters related to ACK, 'retries' and 'retryWaitTime'.  The defaults for these are 2 and 40 respectively.  If you sendWithRetry() using the defaults, the sender will send the packet and then wait for an ACK.  As soon as an ACK is received, the sendWithRetry() returns true - the transmission was successful.  However, if no ack is returned within the wait time (40mS is default), then sendWithRetry() will try again, sending the message and waiting for ACK.  It will do this 2 more times or a total of three transmissions before it returns false;

Note if retries = 0 then sendWithRetry() will send and wait only one time, it will not retry, but it will wait for an ACK to the message that was sent.

Finally, note that the wait time defaults to 40mS so don't waste a lot of time returning the ACK.  Most of the examples in the RFM library, IMO, violate this rule.  There are print statements between the receiveDone() and the sendACK(), which I believe is a very bad practice and certainly a bad example.  A better example is to save all the received data, ACK immediately, and THEN print whatever stuff you want to print.

Tom


KrisK

  • NewMember
  • *
  • Posts: 26
  • Country: us
Re: ACK vs SEND with RETRY
« Reply #4 on: February 17, 2019, 01:12:25 AM »
Thanks again.. 

I did some tweeks to my code and changed its functionality based on your info.    With some bench testing I was able to get 0 failures in 75,000 transmits.    I used out of box parameters set to default.  promiscuous=false,  requestACK=true  and ACK_TIME=30 

I used the
   radio.sendWithRetry(RCVR, (const void*)(&theData), sizeof(theData), 6)

if this failed I would
     delay(50);                                                                                              // delay 50 and try again second time 
     radio.sendWithRetry(RCVR, (const void*)(&theData), sizeof(theData), 6) 

I did some parameter testing with retry counts from 2 by 2  up to the 6 by 6.   I landed on the 6 by 6 solution as it worked best with no failed attempts in the second try.   It was interesting to see the significant reduction of the second time transmit when I went from 4 retries to 6.  Turn around time was around 380 milliseconds when the second attempt was used.   I was actually ok if it even went to 500 but this will work for what I am building.    My next round of testing will be to test with multiple unique receiver ID's.


Anyway.. thanks again for the insight.

Kris