@kjm That value is #defined in esp32/lte/lteppp.h, and the constant is used e.g. in esp32/mods/modlte.c.

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

I would try to monitor the length of the output queue. See _io_thread_func in MQTTMsgHandler.py - in there there's the transmit loop and you could add some signaling there to indicate the TX queue is empty. You'll probably need to modify the code and rename the function so you are not using the builtin frozen ones.

@dexter12 Our application is remote pump management in Australia. Currently using raspberry PIs with usb cell modems. The PI has full python & is a nice platform but usb modem choices are limited. The built in modem on the gpy is a nice idea but the limited repertoire of micropython makes code porting a pain but worth it to have another string to the bow.

@hayesey import network, machine wdt=machine.WDT(timeout 60000) #allow 60s per deepsleep cycle if 'lte' not in globals(): lte=network.lte() #new modem instance if previous is gone cause=machine.reset_cause() #check if previous cycle ended via watchdog if cause==2: lte.send_at_cmd('AT^RESET') #reset the modem if it did

@kjm I've just tested it through the REPL (PuTTY on COM with W10) on my LoPy and everything is OK: >>> os.uname() (sysname='LoPy', nodename='LoPy', release='1.20.0.rc11', version='v1.9.4-0a38f88 on 2019-05-14', machine='LoPy with ESP32', lorawan='1.0.2') >>> >>> v=input('Enter value -=> ') Enter value -=> test msg >>> >>> print(v) test msg >>>

@kjm For people using Atom the this is a possible approach. But not all people do, and this approach makes quite a few assumptions, like that the image fits into flash. And there a lot if threads about problems with Atom and syncing. Your approach is an alternative, but people will too have issues with it.

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

I think I might have a flash memory problem, something that has haunted me with GPYs from the getgo. If I upload then remove then upload boot.py & main.py several times I seem to get a more stable system. It's like the first write of new software is not enough.

@Bettina, @administrators Must be a deep one, I still waiting for a solution or at least and acknowledgment of my comunications

@robert-hh Unfortunately I don't have an sd card to try updating it that way. Here's my output when I run the update with debug set to True. >>> sqnsupgrade.run('/dev/ttyUSB0', 'NB1-41019.dup', debug=True) <<< Welcome to the SQN3330 firmware updater [1.2.5] >>> File NB1-41019.dup has size 5835531 mirror? False recover? False resume? False direct? False atneg_only? False bootrom? False load_fff? True baudrate: 921600 target_baudrate: 921600 Setting port /dev/ttyUSB0 Setting baudrate to 921600 Initial prepartion complete... Loading NB1-41019.dup Firmware file is too big to load via FFF method. Using ON_THE_FLY Attempting AT wakeup... [921600] b'\r\nOK\r\n' AT+BIND=AT returned b'\r\nOK\r\n' ATE0 returned b'\r\nOK\r\n' Entering upgrade mode... Sending AT+SMLOG? AT+SMLOG? returned b'\r\n+SMLOG: LOG_INHERIT\r\nOK\r\n' AT+SMOD? returned 2 Sending AT+FSRDFILE="/fs/crashdump" AT+FSRDFILE="/fs/crashdump" returned b'\r\n\x00\x00/V\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x0055.1.1.0 [33080] by robot-soft at 2017-10-27 07:49:11\x00\x00\x00\x00\x04\x00\x00\x03\xa8Assertion fai' AT+SQNSUPGRADENTF="started" returned b"ed\nFile: l1DspReset.c@96\n'LPU RIP: 00000000 00000003 00000000 (s->state ==ZSP_STATE_RUN || s->state "

@kjm The Pycom devices need between 1-2 seconds to start up. There is some analysis of that in the forum, based on the supply current analysis. LTE devices are slower than e.g. the WiPy. I do not know what's in your main.py script. But that one may take some time. LTE.attach() from power on for instance takes at my place 15 seconds and more. P.S.: Your formula above looks a little bit strange, because in the statement: sleep=600-diff you mix physical units. The unit of 600 is implicitly s (seconds), the unit of diff is ms (milliseconds).

@jcaron No the rtc.ntp_sync fails to connect to time.google.com a lot on wifi & the default 1970 timestamp is what the rtc defaults to when it's not synced. I have to resync the rtc after each wakeup on the gpy because it doesn't keep time during deepsleep.

@kjm Since main.py is executed on the target, it is accessing the files on the target. The GPY has no acces to the PC file system. The only thing that you can get is synchronizing the lib files form you Atom/PC library to GPY. I do not work with the pymakr plug-ins, so I cannot give you details, but there were threads of synchronizing a project directory with the target module.