RADIOLIB_ERR_UPLINK_UNAVAILABLE (-1108) on TIG stack sensor in the field (LoraWan/TTN/InfluxDB/Grafana)

[davidsaintruby]

Good day friends! I am working on a hobby project with my neighborhood. We have placed a remote sensor with ultrasonic ranger to monitor a lake in our neighborhood that is prone to flooding. Using a Heltec WS V3 with RadioLib for the LoraWan support. Thanks to all of you that have helped with this library.

I ran into an interesting issue where the field sensor just stopped sending data. It had been in the field running 2-3 months without issue. 5 minutes between sends of data, as the water depth can increase rapidly during rain.

It just stopped. I know power looks good (solar and battery) because i grab that in the telemetry. On a whim, I hooked the board up to a serial monitor and I am getting some of my debug outputs. The board never died. I am getting -1108 and I am seeing some really unusual values in some of the output.

Example here.

Ping: 206cm
OK, 59.5, 22.7, 4979, 22
Voltage = 3.57
Error in sendReceive(-1108)
[LoRaWAN] RSSI: -75.00 dBm
[LoRaWAN] SNR: 13.00 dB
[LoRaWAN] Frequency error: -713.00 Hz
[LoRaWAN] Event information:
[LoRaWAN] Confirmed: 0
[LoRaWAN] Confirming: 0
[LoRaWAN] Datarate: 0
[LoRaWAN] Frequency: 0.000 MHz
[LoRaWAN] Output power: -20072 dBm
[LoRaWAN] Frame count: 1070514304
[LoRaWAN] Port: 19
[LoRaWAN] Next uplink in 3831107s

The frame count and next uplink are not making sense (it should be a 5 minute cycle).

With some unusual values there, I am wondering if i have basically hit an overflow on some of the state variables that has confused the duty cycle logic from being up so long. I am wondering if a periodic programmed reboot might help to keep some of the variables reasonable.

I have noticed the send pops about every hour or so, which aligns to the above ms value.

I do a sleep between sends to help manage power draw.

Thanks for any thoughts or ideas. It has been a learning adventure.

Dave

[StevenCellist]

Hi Dave, this looks like a really interesting topic. Before we proceed at a guessing game, do you happen to know for (quite) sure which version of RadioLib is running on your board? As the stack has been under continuous development, stuff may have changed since then.
Also, do you happen to know if you configured any additional flags or #defines? Anything that is available can be useful, also the sketch running on your board, even if slightly changed. There aren't many reports of people running on highly extended sessions without reboots, so cases like these are valuable :)

(And yes, it may be a valid solution to do an ESP.restart() and rejoin the network, but that's giving a fish, not learning how to fish!)

[HeadBoffin]

I do a sleep between sends to help manage power draw.

How have you implemented sleep?

As @StevenCellist says above, there's been a few core changes over the last couple of months. Consequently we don't have a test device running from that far back so we don't know if this is a bug.

I'd strongly recommend bringing up your code to v6.6.0 and use the persistence for ESP32 that we created. If you are lite sleeping then please share you code so we can spot any issues with keeping LW state.

[davidsaintruby]

Thanks for the feedback. I am on 6.5. One more clue, I looked through my debug serial output and see that the stack thinks there is a long message returned TO the device from TTN/LoraWan. I don't send anything back through TTN. I am thinking less that this is a variable overflow and more from a buffer / array overflow writing into the variable space.

Namely....

Its based on the github example -> master/examples/LoRaWAN/LoRaWAN_Reference
and this variable is clearly getting blown out

uint8_t downlinkPayload[10]; // Make sure this fits your plans!
size_t downlinkSize; // To hold the actual payload size received

The board THINKS it is sitting on a 15 KB return which clearly makes no sense.
Anyway, thanks for your feedback - I will rebuild with the new library and see how it behaves.

As far as sleep goes, I am on ESP32 but also have access to a cubecell which is a lot lower power consumption. I have thought about going that route to see how it behaves.

Again thanks for all you are doing here - i am getting a lot further than the legacy LMIC libraries.

Dave k8zk

[StevenCellist]

The board THINKS it is sitting on a 15 KB return which clearly makes no sense.

Interesting, how did you get to this number of 15kB?

[davidsaintruby]

The debug print is roughly 30K characters of the hex representation of the downLink "payload." I jammed the output into CyberChef to see if i could get any clues (e.g. strings) but nothing of note.

[StevenCellist]

Do you still have the output? Can you show what the few lines after the hex debug print look like?