|
Post by pitless on Jul 17, 2023 0:47:51 GMT
Hello,
Looking to deploy with this device for roughly 3 months. Initial testing with the module and the serial connection to the modem stops responding after ~6 hours. Thinking this is likely due to my code, I used AT command tester to publish MQTT messages every three seconds on a near infinite loop. This seemed to freeze after roughly 7 hours of operation.
To anyone who looks at this thread, or if Mr. Woo has insight, what's the longest continuous operation of the device you've maintained? Does software for longterm use need to software reset the module, close the serial connection, etc on a predefined interval to keep it running? Going through this and SIMComs documentation I haven't found anything regarding this yet, and have a hard time imagining this module should struggle with longer time intervals.
Thanks in advance.
|
|
|
Post by gwilde1 on Aug 2, 2023 1:11:42 GMT
I’m having the same issue. Today I ran for approximately 18 hours, but then the script just stalled out. I did a reset with a wire from ground manually to the reset pin, and the script was back up and running again. I even tried resetting the arduino via software every 5 minutes, to no avail. Any insight would be greatly appreciated.
|
|
|
Post by pitless on Aug 17, 2023 16:26:16 GMT
My system was crashing after ~6 to 12 hours. Fully resetting the network and modem connection seems to have fixed most of it. Since my system is using MQTT, when we observe SMSTATE returns 0 or error, the system now runs through the init procedure again (minus the power pin toggle) upon observing either {0 or error}. This has given us about 20 days runtime so far. When spamming messages as fast as possible another, this method wouldn't recover the system. Passing AT+CFUN=6 reset the modem and allowed reconnection to the internet. The Botletics SIM7000A doesn't have HW flow control pins available and I suspect this may be causing an issue with the faster transmission rate. Of note, we modified Botletics variant to have flow control pins connected, but it appears the microcontroller (Teensy) has a different paradigm of RTS/CTS alignment making it difficult to implement HW Flow Control. I've implemented both hardware and software power cycling of the system, though this eventually bricked one of my boards. I will note, it was bricked when power cycled via AT command, and not driving the hardware PWRKEY low per SIMCOM datasheet. Not saying that software power cycle WILL brick it as the system had done so fine previously, just a word of caution. I've attempted a firmware update which was not the smoothest experience and it appears even worse for wear. Will chalk it to operator error on that one. A bit of a ramble, but trying to leave any relevant information for people to find if similar errors sprout up.
|
|