we also dedicated ourselves to that topic and followed the suggestions from the forum to shut down the LTE modem before deep sleep. We are actually shutting it down shortly after boot already.
However, we have not conducted detailed measurements yet. As far as we can tell, the power consumption the FiPy draws still shows flaky behavior.
a) Do you have any news about that topic?
b) Maybe @robert-hh can also contribute something sensible?
With kind regards,
We have now discovered that even sending the "AT+CFUN=4" does not solve the problem. Yesterday we had a GPy stuck in a mode where it would not return the ICCID even after power on/off, modem reset command, and the AT+CFUN=4 command. The only thing that resolved the issue was to send a dummy attach command lte.attach(apn='unknown'). Then the lte.iccid() command worked from that point forward (even through power on/off and resets). We do not know what causes the GPy to get in this crazy mode; however, it seems to be related to low signal situations.
@tomstoffen I just briefly read your message. The first thing is TTN have their own fair use policy, so when sending a message every 5 seconds you will deplete your air time very soon. Depending on your payload size, you should be fine if you send a message every 15 minutes (that's what I've tested), maybe even every 5 minutes should be OK.
from this page: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
Finally, on The Things Network’s public community network, we have a Fair Access Policy that limits the uplink airtime to 30 seconds per day (24 hours) per node and the downlink messages to 10 messages per day (24 hours) per node. If you use a private network, these limits do not apply, but you still have to be compliant with the governmental and LoRaWAN limits.
I never worked with Gpy, but with LoPys the speed of the firmware is nearly the same. What changed are the windows when the i2c module is ready to communicate. So you can start some i2c stuff before the whole system was completly initialized. But these windows/frames moved between firmware versions and became larger or smaler. So it was not reliable to use them. Maybe pycom moved some of their internal i2c stuff into more reliable regions.
I do not recommend to stay on older firmware versions and optimise the timings for them. The ESP32 and the IDF cause too many problems. IMHO pycom is on the development branch too far behind the actual IDF version.
If you have huge scripts, you can save some time by using precompiled or frozen modules. If you have some complicated stuff to do, you can do this before the Modem is ready.
Yes, fast boot times will be fine, but I preferre signals, callback or variables which tell me, if the hardware is ready to use. I wasted too many time to find windows inbetween init states :)