Field tester freezes

[AkosLukacs]

Hi,

Happened a couple of times, that the field tester did join, did get GPS lock, did transfer packets, so work as expected but after some time it looks completely frozen. No response to any of the buttons. In all occasions it's frozen displaying "TX 06" in the status area. Settings: +14dBm (or +8dBm, tried lower tx power to check if it might be some power supply glitch?), SF07, retry 1, max rate. Powered by power bank, or car's USB port. DIY version, PCB from Seeed, hand soldered, RFM & GPS populated, no battery charger circuit. No enclosure, so could be random ESD event, but it always hangs at the same state. Flashed with WioLoRaWANFieldTester_EU868_GPS.uf2 And does work again after manually resetting.

Any idea what might be wrong? Or how to troubleshoot? I see some debug statements (like LOGLN) in the code, would those log to USB serial?

[disk91]

Hello, I never has a such behavior and I assume I ran the project since a really long time. I would suggest it could be related to the hardware Wio or Board. If it is easy to reproduce, it would be great to compile with DEBUG activated in config.h

#define DEBUG

Eventually add a Serial.print("."); in the main loop to see if the Wio is freezing or just some pieces of software.

Then connect to computer USB and look at the serial port print.

[AkosLukacs]

Ok, got something, now during sending packet #11

EV_TXSTART
l.x               // my debug statement: loop end
l.0               // my debug statement: loop start
FAILURE     // from LMIC
Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\lmic\radio.c:1065

This line: https://github.com/mcci-catena/arduino-lmic/blob/master/src/lmic/radio.c#L1065 And that ASSERT just freezes the whole Wio. Either some timing issue, and the radio is not yet sleeping. But you haven't seen anything like that. Or a bad solder joint.

[disk91]

Looks like the SPI write failed and the assert kills the Wio (basically assert my while(true);) so it makes sense. The SPI write should not fail. So yes you can check the soldering. Potentially, the RFM95 could be defective (I had some with defects by the past). Possible other issues but I did not had the same experience. You could also remove this particular assert and just have the SPI write. not really a solution as you should have other assert failing elsewhere and RFM95 in a bad state but if really rare it could make the device running a bit more longer.

As much as I know currently, I can't make anything specific in the code related to this issue.

Please, before closing, can you give me some precision of you environment:

• Zone
• LMIC version
• Target helium console env (I saw multitple hotspot response, so it can be another console than the main one)

[AkosLukacs]

Will check solder joints when I have some time. For the record: on SF8 it worked for a couple of hours without any problem, SF7 failed pretty fast.

• Zone: EU, if that is what you meant?
• LMIC: https://github.com/mcci-catena/arduino-lmic, v.3.3.0
• Production and staging console, issue showed up in earlier testing. But now was testing multi-packet behavior, and staging has some improvements there.

[disk91]

Is this bug still appearing on your device ? I still not have a such problem on my side. Let me know. I'm most of the time SF9. I will make more try on SF7

[AkosLukacs]

Seems to work without problems after some resoldering + flux cleaning. Most likely soldering was the cluprit.