I just had a situation where this while statement went into an infinite loop. Seems to me that when the code got to this point, either LoRa.available() would be zero or positive, but if positive would eventually be zero and exit.
while (LoRa.available()) {
sync_byte = LoRa.read() ;
}
If the LoRa device is available, as in physically present and responding, you would expect that loop to repeat forever.
Maybe it depends on the library you are using, but you did not say (hint!!!).
Did not know there was more than one! It's this one #include <LoRa.h>
The code is running on an ESP32 and IDE 1.8.16
Yes, the device is there, but that's not what "available()" is defined to do. The reference says that it responds with 0 if there is no message/data available in the queue, or with a positive integer that counts the bytes in the queue. The problem is, I don't know what "state" the LoRa receiver is in when it gets to the "available()" statement. But once it is in the "while" loop, the "available()" response is an increasing negative number, ad infinitum.
Maybe the clue is in the rest of your code, but we have not seen that either (hint!!!!).
First try the standard sender and receiver library examples, they will be known to work, so if they dont you have something wrong with your hardware.
Nope (regarding "hint"), not that I haven't been bitten by that in other questions. But the "available()" method stands on its own. It looks at message buffer and reports either "none" or "some". It is not supposed to be able to report "less than none."
I suspect that this is a hardware issue, but not a failure. For example, I have been bitten by the fact that ESP32 integers are 4-bytes, not 2-bytes. So if you're not aware of that and don't do a proper sign extension, you wind up with big positives instead of small negatives. I think there is something like that that wasn't accounted for in the IDE module for ESP32.
The other possibility is that if the preceeding code has read one more byte from the packet than are available, the LoRa byte pointer is at -1, which is what the "available()" method is reporting, but that is an error in the "available()" method, not in the code.
Instead of while(LoRa.available()), maybe a workaround would be while(LoRa.available() > 0)? That seems like a kluge and doesn't comply with the "available()" method description.
In what way a 'hardware' issue, a hardware problem with the LoRa module ?
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.