@aqi Can you use an https connection ? Can you show more code ?

Dear @kjm, @kjm said in lte.deinit(dettach=False) with machine.deepsleep: We've found it's not a good idea to routinely reset the modem in battery powered/deepsleep applications. If the modem is not reset attachments take only a second or two but after a modem reset they take 3-4 times longer. Sure. Sorry that I haven't told you that we are currently not using the modem at all and just want to turn it off as quickly and thoroughly as possible. When actually using the modem and going to deepsleep, it should probably not be reset and detached so it will keep its association with the cell infrastructure. Thanks and with kind regards, Andreas.

Dear @kjm, 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, Andreas. [1] https://community.hiveeyes.org/t/deep-sleep-with-fipy-esp32-on-micropython/1792 [2] https://community.hiveeyes.org/t/lte-modem-des-pycom-fipy-komplett-stilllegen/2161

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.

@daryln pressing the reset button or reinserting the USB cable will do exactly the same thing.

@jirkakrepl Thanks for the info.

@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.

@kjm 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 :)

@rskoniec Yeah, got there eventually https://forum.pycom.io/topic/4999/gpy-modem-upgrade-alternative

Thanks for the pointer, that worked.

If this is the case then I could publish a message to my main.py MQTT client to set flag in nvram or to file then reboot into "Pybytes mode". Probably worth trying because OTA firmware updates and code edits. Thanks for that.

@kjm This is indeed a major issue in debugging when using deepsleep. As soon as the system goes to sleep the USB connection and WiFi connection are gone. You then have to reconnect manuually first. As you describe, Atom is then also a major issue as the butons disappear and it thinks it is not fully connected while it is. This makes checking the functionality of a program using sleep very difficult. The only solution I found is using blinking LEDs of several colors to communicate with me the debugger. I am also busy with a logger which writes the state of the program to a file for later inspection. def blink(color, counts, intensity=0x1f, speed=0.5): colors = { "red": 0xFF0000, "green": 0x00FF00, "blue": 0x0000FF, "yellow": 0xFFFF00 } pycom.rgbled(0x000000) for i in range(counts): col = colors.get(color, 0xFFFFFF) col = int(col * intensity / 255.0) pycom.rgbled(col) time.sleep(speed) pycom.rgbled(0) # off time.sleep(speed) def blink_long(color): pycom.rgbled(color) time.sleep(4) pycom.rgbled(0)

I was able to successfully connect via HTTPS to google and do a simple GET request, so it seemed. Though I don't do dabble around to often in network protocols. Would you have any suggestion for a safer way to determine whether our carrier supports UDP. The name of the carrier is 1NCE, btw.

@vitalcc We will publish a roadmap here on the forum soon

@Lonefish Not at this moment, we will deploy a fix in the firmware to make this option configurable.

Removing the LTE.reconnect_uart() command that I was using previously to get the iccid() command to work seems to have fixed the problem with reading SMS messages. Before I was getting undocumented responses from the modem: +SYSSTART and +SHUTDOWN. These responses do not appear in the Sequans manual that I can find.