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

I;ve got the same problem trying to update for lte-m1. Got nothing to add, but wan to subscribe to this thread in case something comes up.

@pyoneer It's mostly a matter of timing. Too early and the device is not yet up. Too late and the Pysense has exited DFU mode and booted normally. IIRC the window is about 7 seconds.

I eventually resolved the issue, thanks!

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

Thank you @jcaron for your fast response. I am in US-915. I am not asking about limitations imposed by regulations. I am asking what limitations are programmed in LoRa modem (whatever reasons, including FCC restrictions). I know I can check LoRaWAN stack source code. But I would prefer to read documentation instead to try inverse engineering. With best regards Sebastian

@paul-thornton Thanks for your input, the probmlem was that we had connected some sensors on the pins that was shared with LTE.

Thanks. I assume that I run into one of the ESP32 bugs related to memory problems with multicore or reading multiple times the same address. But therefore it is strange that the returning value is always 6. As long as it fails mainly on initilazing pytrack and WDT helps, I am fine. I will be happy. if the *Py can be configured so that ctrl-c stops the watchdog or sets wait time to max.

@robert-hh Working ! Thank you 😊

@momentaj When using the pycom uploader 1.15.2, you have tghe option to erase the device on uploading a new firmware image.

@paul-thornton no it was something else. i don't remember what the exact problem was. one thing that is weird is that the WLAN SSID was never changed. i connected it to pybytes via the REPL and updated the main.py in there and i could connect again.

So I think I found my problem As I said in another post the problem wasn't in the software, but hardware. I don't use a expansion board, I use a ttl converter like this one https://www.ebay.com/itm/5V-3-3V-FTDI-FT232RL-USB-to-TTL-Serial-Converter-Adapter-Module-Arduino-Mini-Hot/182736917146 With this converter 3.3V is not enough to power on stably the board, so, I used it in 5V mode, but it seem that 5v for serial communication is ok for the python REPL, but have problem when flashing the modem or use the LTE modem. Finally, I changed my design by using another 5v power source, and use the ttl converter un 3v3 mode with common ground. And then it just works fine ;)

Hello @Paul-Thornton , Glad to here that, it's very important to me to have this possibility with Pycom. All my devices should be connected to Azure. I've done some researching and found out that your MQTT libs are sending bytes that Azure doesn't understand. Short description of this is on the link: https://www.youtube.com/watch?v=pRqpKZ7mO1s

@robert-hh Thanks for that. I really like the look of that new board! Hope it is released to market very soon.

I was having similar issues with Multitech gateways in combination with TheThingsNetwork's recommended packet forwarder (from kersing). Updating to the latest packet forwarder from Multitech the legacy UDP format solved the issue. Bytes past 66 seemed to be garbage and therefore the MIC/crc would fail

@crumble also, is it fine to use the utime.time() in the receiver as well or just use it in the sender? Also i tried running the code after removing time.sleep() in the receiver but for some reason i still experience the same issue.