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

@John-Baird Interesting observations/experience with IOT in Aus. I have been working with Vodafone and have found them very supportive.

@kjm Obviously yes.

Found my problem. I had commented the single line in a while statement, like so: while True: #someFunction()

It may be the case that I misunderstood the functionality of the Pygate. It looks like there's LoRa on the Pygate via the Semtech SX1257. If that's true, then my use-case would be resolved with GPy + Pygate. Can someone confirm that my original question had a flawed premise, and that GPy + Pygate would provide LoRaWAN gateway with cellular backhaul?

I ended up using Atom on my windows pc and was able to talk on the port no problem. I'm not sure why the port was closed on the fedora pc. Hopefully this helps someone in their setup.

That's the problem, I tried to use sockets but the wrong way. I think I should be trying for a UDP broadcast? So the diagnostics go out regardless of the phone being connected or not import socket; import time addr = socket.getaddrinfo('0.0.0.0', 80)[0][-1] s = socket.socket(); s.bind(addr); s.listen(1) print('listening on', addr) while 1: cl, addr = s.accept() print('client connected from', addr) cl.send('a diagnostic print \r') time.sleep(2) cl.send('another diagnostic print \r') time.sleep(2) cl.close() If the phone looses the adhoc wifi connection the program just sits there waiting for a client to connect.

@reidfo The issue is that an unsupported band is being used by the modem and causes it to crash and reboot. It's a bit more involved but that is the gist. I got a revised firmware that appears to have resolved it. I suppose I could PM the fw. Not sure if pycom would frown upon sharing. I would expect this is resolved in the next release after 1.18.2.r3.