Location of CheckForWirelessHEX in a sketch loop seems to matter

[detroit_johnny]

I didn't know if I should post this in the Wireless Programming forum or here but wanted to make a note of it for everyone else in any case.  I was working on a sketch for a Moteino node in my home automation system.  In the past I always included the extra line of code to check for the wireless hex flag for wireless reprogramming.  For whatever reason this time my sketch had the "check" code as one of the first things in my loop section of the sketch.  After that I would do a " if radio.receiveDone()" routine to see if any messages are coming in from the gateway.

Well for whatever reason the sketch was not working right when it came to receiving incoming messages.  It would ACK but not decode what I was sending.  What I discovered was if I switched up the order of my code so that the "radio.receiveDone" part came first, and the "CheckForWirelessHEX(radio, flash, true);" came after the sketch worked fine.  Kind of odd but I thought I would bring it up if anyone else comes across issues with their wireless nodes receiving data.

[syrinxtech]

DJ:

The way I understand it, and the way I've always coded it, is as follows:

if (radio.receiveDone())
{
  CheckForWirelessHEX(radio, flash, false);      // last parm can be "true" if you want debug
....
}

The purpose of the receiveDone() function is to see if the radio has incoming packets queued up.  Once you know that, you check to see if those packets represent an OTA update.  IF not, process the packet depending on your code requirements.

If I'm wrong, somebody please correct me but this way has always worked for me.

[detroit_johnny]

Ah!  Thanks syrinxtech!!  That makes complete sense to me.  I'm going to do that in my code from now on too and include the CheckForWirelessHEX inside the if (radio.receiveDone()) statement.   Cheers!!

[syrinxtech]

Cool, glad that worked.