DigiXBeeCellular possible timing issue

[neilh10]

While checking server response with AT debug stream enabled, there appears to be a potential tinyGSM lib timing issue.

I'm documenting it here, for discussion and possible thoughts about a solution.

When POSTING over LTE using class DigiXBeeCellularTransparent after the POST, it closes the UART connection, does some Modem configuration then reopens it to catch the response. This is all over a 9600baud connection, so about 1ms per character. Doing the AT stream debugging may also cause timing issues, making it easier to miss a fast response.

It would seem that if the server responds very fast (at this point its taking 10seconds to respond) the response might be lost in the LTE Modem.

I would expect that once the POST has been performed, the connection would be kept open until the response has been received or a timeout reached.

This issue may need to be fixed in the tinyGSM lib, but could impact testing systems here. from my test06 with Digi XBee3 Cellular LTE-M, the debug snippet

[2021-12-20 17:27:19] POST /api/data-stream/ HTTP/1.1
[2021-12-20 17:27:19] Host: monitormywatershed.org
[2021-12-20 17:27:19] TOKEN: e89538ae-7ff0-4897-a396-9b10c0fadfc3
[2021-12-20 17:27:19] Content-Length: 458
[2021-12-20 17:27:19] Content-Type: application/json
[2021-12-20 17:27:20] {....}
+++OKATCIFF
ATOD0.0.0.0
ATCNOK
[2021-12-20 17:27:20] +++OKATCI0
ATOD3.14.188.180
ATCN 

[2021-12-20 17:27:21] OK+++OKATTM64
ATTM64OK
ATCNOK-- Response Code -- 504 waited 7000 mS Timeout 7000

[SRGDamia1]

I don't know if the XBee does any internal buffering of whatever might have come in while the Bee was in command mode and returns to transparent mode; it might be in the documentation, but I suspect not.

I'm not sure the best work-around. Using the combination of transparent/command mode, you need to bump back and forth between the two a lot.

We're moving away from the XBee's because the lifespan and reliability of the 4G modules has been terrible for us. We've never used the WiFi or other modules much because most of our deployments are out of WiFi range. When we've done in-house stuff we've used much cheaper and more reliable Espressif ESP8266 or ESP32 based modules. We've built our own ESP32 based bee for testing, but I'm not sure when it will be ready for sale.

[neilh10]

@SRGDamia1 always appreciate your insights. tinyGSM is a complex set of AT drivers, and thanks for all your work in pushing it forward. Seems to me this is a refinement to the DigiXBeeCellularTransparent .

I've been testing the whole system and tweaking the startup code as LTE-CAT-M1 has rolled out, only been a year now. So far on my data set of tests, I've found the device Digi LTE-CAT-M1 XB3-C-A2-UT-001 largely reliable - but its all in the testing - and the modems are one component in that testing https://github.com/ODM2/ODM2DataSharingPortal/issues/524 https://github.com/ODM2/ODM2DataSharingPortal/issues/542

I would hazard a guess its there for other AT device drivers - but that would need decoding.

Thanks for the insights on communication devices, be interested in what reliability data you have on Digi 4G/LTE-CAT-M1 modules hardware. Though availability of the Digi LTE-CAT-M1 XB3-C-A2-UT-001 seems to be the challenge

The Digi WiFi S6 modules also had driver architecture to real device challenges - though I have one field location that uses it, with an external higher gain antenna to boost its range paired with an outdoor low cost WiFi gateway. Part of the value was trying for a 2nd hardware communication element, as its using WiFi to have a better reference for reliability testing.

I wonder if there shouldn't be a test status against supported modems - a bit painful, but incredibly helpful - https://github.com/EnviroDIY/ModularSensors#supported-cellularwifi-modules