Open TEFEdotCC opened 2 years ago
If you uncomment LoRa.onReceive(onReceive)
you don't need onReceive
in the loop.
There's an issue with LoRa.onReceive(onReceive)
. It should be used only once, in setup()
, like you have it, commented out. But it should not be used in conjunction with LoRa.receive()
, as they are not the same. You see, LoRa.receive()
sets the LoRa chip in receive mode, but that's it. it's up to you to check whether there's data available, and if so to read it.
In asynchronous mode, LoRa.onReceive(onReceive)
defers the task to the library, and when a packet is ready, if calls your function, in this case void onReceive(int packetSize)
. So uncomment LoRa.onReceive(onReceive)
in setup()
(and that only) and remove onReceive(LoRa.parsePacket());
in loop()
.
Next, in onReceive
you are using very wasteful code:
// read packet
String loRaData;
loRaData.reserve(packetSize);
for (int i = 0; i < packetSize; i++) {
const char c = (char)LoRa.read();
loRaData += c;
Serial.print(c);
}
Avoid String
objects as much as you can, They're wasteful, and adding a character to a String means creating a new String. Every time. A much better way would be:
// read packet
char buf[i+1];
for (int i = 0; i < packetSize; i++) {
buf[i] = (char)LoRa.read();
}
buf[i] = 0;
// You have now a char array "buf", properly zero terminated.
This is the least resource intensive way. You can now parse the string, print it, etc. I usually have a fixed-length bufffer, 256 bytes, which I use with an index pointer of type uint8_t
, so that the pointer rolls back to zero (and the buffer doesn't overflow) should the index pointer go over 255 – and considering that it's LoRa, this should never happen, but who knows...
Switch the commentar of the last lines of setup and loop functions are not working on the HELTEC WiFi LoRa 32 V2 Link to Pin-Out: https://resource.heltec.cn/download/WiFi_LoRa_32/WIFI_LoRa_32_V2.pdf