search

matthijskooijman / arduino-lmic

:warning: This library is deprecated, see the README for alternatives.
704 stars 651 forks source link

How to do error handling in general #275

Closed jens-234 closed 3 years ago

jens-234 commented 4 years ago

Hi everybody,

I think the device I intended to build is mostly complete. It wakes up upon the triggering event of a reed switch and send outs the lorawan message. Afterwards it goes to deep sleep again until the next reed switch interrupt.

That works practically always. However during testing I've come across this error once (out of maybe 200 messages):

Packet queued 5044: EV_JOINING 366053: EV_TXSTART FAILURE \.....Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\lmic\radio.c:1063

That is really not much of a deal, but since I can't easily get to the device once it's physically installed it made me think of error handling. It's running on battery and shouldn't be on longer than necessary.

I have the loop() routine called only once as done in the example. When I tried to actually let it loop (to have something to always jump back to in case errors occured) it would block the transmission. Then it usually doesn't go beyond "Packet queued".

After queuing the message my own program flow is over unless an event is triggered (which in case of errors like the above doesn't happen).

Does anybody have a suggestion on how to handle errors with this library?

Other types of errors are still handled by an automatic reboot. I had the program device by zero to provoke an exception. That caused a reboot. Here it doesn't unfortunately.

piisku78 commented 3 years ago

Hello @jens-234, I think I have very similar use-case as you. My device runs also on battery and is most of the time in deep sleep. I have noticed that after couple of days some error occurs. And I should have better error handling because the device cannot recover. I dont know yet which event but there seem to be several possibilities. The documentation of this library describes events but it does not really say which actions should be taken when event occur.

@jens-234 Could you share your error handling strategy in following cases? EV_LINK_DEAD EV_LOST_TSYNC EV_JOIN_FAILED EV_REJOIN_FAILED

Or do you think I might get some other error event than these?

jens-234 commented 3 years ago

Hello @piisku78 ,

probably not what you want to hear, but I never found a way to do error handling while using this library.

In my case the physical connection between ESP and the lorawan chip wasn't perfect. I disconnected all connections again and did the soldering from scratch. After that the errors and their reboots were gone.

matthijskooijman commented 3 years ago

One approach is to enable more debug output. Check out the hal config.h file (or some such) in the library, it has one define that tells LMIC to log to (e.g.) Serial (LMIC_PRINTF_TO IIRC) and I think two defines that enable logging and verbose logging. Enabling those should give you a lot more info.

However, reading your report more closely, it seems you're using the MCCI version of this library, so this advice might not apply (not sure how much of the error logging was done when they forked). Using MCCI is probably a good idea (it has seen more development), but if you do, this is the wrong place to look for support, so I'm closing this issue.