Reply To: Debug flags for modem comms

Doh!  I’m sorry, I was confusing you with Dan who was troubleshooting issues with the UBee last week.  They’re even worse than the LTE XBee3’s.

The power isn’t your problem testing in the lab.  That seems a hair low for being connected to USB, but not concerning.  On the last bypass output that you posted from over the weekend, you did connect and even got the time from NIST, so your SIM and XBee and Mayfly are all OK.  It’s just making them play nice.

Yes, I think your next step is to update TinyGSM and re-test.  You can try switching between the modes to see if it helps the connection.  Don’t bother waiting more than 1 cycle and you can drop your interval down to as low as 1 minute while your watching.  If NIST connection doesn’t work in any of the 5 attempts, you can almost give up right there and post the output.

If the XBee3 refuses to submit, try switching to the “bleeding edge” version of ModularSensors on the ModemLast branch.  To use that run pio lib uninstall EnviroDIY_ModularSensors or pio lib -g uninstall EnviroDIY_ModularSensors (case matters).  Then after the uninstall, modify your platformio.ini and remove EnviroDIY_ModularSensors from the lib_deps section and add https://github.com/EnviroDIY/ModularSensors.git#modemLast in its place.  The modem last branch (as you might guess) restructures the way the internet connection happens.  Instead of starting the modem first and waiting for it to connect as if it’s a sensor detecting the signal strength, the library keeps the modem off until all the other sensors are complete.  Once the other sensor data is saved, the modem comes on, sends data to the world, and makes note of the signal strength just before going back to sleep.  On the next sensor interval, the prior modem strength will be recorded.  On the surface, the changes to your code should be pretty trivial, but the library will be doing different things underneath.