I recently purchased a Wio Terminal LoRaWan Chassis that adds LoRa and GNSS capabilities to the Wio Terminal. I had read about a project done by Paul Pinault (disk91) - WioLoRaWANFieldTester that uses this setup to monitor LoRa gateway/hotspot performance. Since I already have a Wio Terminal and battery chassis I thought this might be a good way to monitor my Things Gateway performance and also see if I can find other gateways in my area. Also, since it has a standard LoRa-E5 transceiver and a GPS unit - I can reprogram it to make portable LoRa sensors (the Wio Terminal and Battery Chassis provide eight Grove connectors for I2C and GPIO, although the hardware UART Serial1 is used by the LoRa unit).
Because Paul has a prebuilt image and good documentation, I assumed that this was going to be easy. Assembly was easy - just snap together the 40 pin RPi connectors of the 3 chassis. The prebuilt image comes as a .uf2 file, so uploading was just drag and drop onto the Wio Terminal Mass Storage Device using File Manager. And getting the Device and App keys for the Things Network was easy since I do that all the time.
So, what could go wrong? The program doesn't start until you add the frequency zone information and the Device and App keys. That's done using a serial terminal (I used the Serial Monitor on the Arduino IDE).
08:48:03.213 -> ZONE: US915
08:48:03.213 -> OK
08:48:15.508 -> DEVEUI:70B3D57ED004EBE9
08:48:15.508 -> OK
08:48:28.183 -> APPEUI:0000000000000000
08:48:28.183 -> OK
08:48:40.845 -> APPKEY:XXXXXXXXXXXXXXXXXXXXX
08:48:40.845 -> OK
08:48:40.878 -> LoRaWan configuration OK
Looks good so far until the program restarts:
It doesn't see the LoRa-E5 module. This expansion chassis uses two UARTs - the hardware Serial1 for the LoRa and a SoftSerial one for the GPS. There are some comments in Paul's documentation about problems with the UART configurations, but I assume that should be fixed in the prebuilt binary.
I tried another version of the application modified by a Seeed engineer and got similar results.
Except in this case the program allowed me to continue and I saw the GPS was working.
I reached out to Seeed tech support, but they just had me try what I had already tried even though I had written precisely what steps I had taken (I guess tech support assumes you don't know what you are doing and probably doesn't read what you send them).
Anyway, I got frustrated and requested an RMA.
I got in touch with Paul through his github repo and he was helpful. I ended up compiling the program with debugging enabled and it basically told us what we already knew - the LoRa module wasn't responding.
So, what was the bad assumption that I made? I assumed that the new LoRaWAN chassis was broken.
It turns out that while I was waiting for the RMA approval, I decided to test the Serial1 port on the Wio Terminal. I hooked up to a UART on a Xiao board and determined that the Wio Terminal could receive what the Xiao was transmitting, but the Xiao could not receive what the Wio Terminal was transmitting.
I took a quick look with my USB scope at the Xiao TX line and saw what I expected:
Looking at the Wio Terminal TX line just showed a flat line offset by about 250mV. So, I have a bad Serial1 TX line.
I'll admit to never having tried Serial1 on this Wio Terminal before, so it could always have been broken.
I have another Wio Terminal that I've been using for a thermal camera and I swapped it for this one and now everything works as expected!
Below showing the RX RSSI from my gateway.
So, I've cancelled the RMA (admitted I was wrong). I've labeled the bad Wio Terminal. It's still useful if I don't need Serial1. I'll create SoftSerial ports if I need UARTs.
I need to remember to be more diligent in my troubleshooting and verify my assumptions are correct.