T
@Petteri-Salo The g.modem_state global variable is used in a timer interrupt routine to control the blinking and color of the LED on the GPY. This gives the user a visual indication of what state the modem is in. This variable is not critical to using the supplied code.
Unfortunately the code I have published is just snippets of my production code. It was not designed to be a general purpose library (although I believe it comes close). Without publishing the entire application, there will be pieces that are missing.
Your message has motivated me to add a few random notes.
We had production, shipping GPy based systems that were experiencing reliability issues. Upgrades to newer versions of the OS seemed to make the problems worse. There was considerable evidence that the problems were caused by the LTE module. For months I waited hoping that Pycom would make the existing product more robust. Instead they seemed to be going in all directions introducing new products but not improving the fundamental building blocks of the GPy. I was especially concerned when we purchased a new batch of chips and they came by default with a version of the OS which would not run our application for more than a few minutes without crashing. In addition Pycom seemed to be moving in a direction requiring our code in the future to be dependent on a cloud based system (Pybytes). This seemed to be making everything even more complex. We couldn't even get the simple things to work reliably.
In principle our application was not complex. We just needed to transmit a few packets of data to a web site periodically over the LTE network reliably without crashing the system. It was also desired that the communication would not interfere with the real time task of sampling data.
After looking at the C/C++ source code to the LTE module, it seemed way too complex. I had no good way to make changes, improvements, or bug fixes (assuming I could find the problem). If we moved the modem code to Python, we could bypass the usage of the LTE module and use the TCP/IP stack included in the Sequans modem. Maybe by pushing the communication load to the Sequans modem, the MicroPython would be more reliable and responsive to real time tasks. Maybe by publishing the code more people could observe and help to improve the code. We desperately needed a reliable method of communication.
Since converting our code to controlling the cell modem directly in Python code, I can now say the random crashes have been solved. The real time task is more responsive.
I hope that someday the LTE module will be improved so that it can be used again. Having a TCP/IP stack that is usable by both WIFI and LTE is certainly an advantage. Can it be made reliable? Can the ESP32 chip smoothly multitask while using LTE methods?
I wish I knew of a method to marry our higher level Python calls for modem management with the TCP/IP stack of MicroPython. I think such a technique could make the LTE module code simpler.
I think the dream of most application developers is to have simple reliable software methods to connect/disconnect to the network. The fact that we are connected using the cell network, WIFI, or whatever should be mostly transparent.
We all want Pycom to be successful. They have developed a good product. We did what we did because their priorities were not ours at the time.
