@protean Pymakr is indeed using the zlib.decompress() micropython function for this feature. Normal upload also still works of course, but this way is faster for large files. Let me give you some pointers on how to code it:
The zlib function on the micropython side is documented here. Pymakr is compressing the files before uploading (here using this python file), writing the compressed file to the board with os.write() like always, and then decompressing them right after that (here). It'll definitely make uploading bigger files faster. Just realise that for files under 4k, it's actually slower because the overhead of compressing/decompressing is bigger than the savings of compressing the file.
@rskoniec said in New Firmware release v1.18.1.r1:
@mfa2214 xPy module f/w and GPy/Fipy modem f/w are separate, so GPy/Fipy module f/w doesn't contain modem f/w.
Here http://stiny.webd.pl/PYCOM/ on my VPS you have collection of CATM1/NB1 *.dup files.
FiPy-1.18.1.r1
GPy-1.18.1.r1
Many thanks @rskoniec for sharing the files :)
@wghirakawa
The issue is that socket.connect() and SSL handshake will not timeout also in case the socket timeout is set and hang the application forever.
https://forum.pycom.io/topic/3985/new-lte-firmware-releases-v1-18-1-r4-stable-1-19-0-b5-development-nb-iot-firmware-40343/45
@mattliddle @Fred I discovered an important insight! When powering it through USB (I'm using the expansion board 2.1) there is an LED light that turns on and stays on even in deep sleep. I was measuring current draw and it was always at least 14 mA. I tried powering the device outside of the expansion board by a 3.7V source, and in deep sleep, sure enough it dropped into the microamp range. Even when it is on expansion board 2.1 and powered through battery instead of usb, the LED stays turned off, and therefore power consumption will drop into the micro amp range.
We could change the default sort order but I'm not sure this would affect existing users. I admit it throws me off too if I'm on the forum but not logged into my account. I'll see if our system admin can do some internal tests.
More simple procedure on Linux :
start from the Linux menu "Pycom Firmware tool", quote "include dev releases"
then just choice /dev/ttyACM0 in High transfert mode
the firmware is flashed in 1.18.1.r1
Wrote 1.19 MiB from sipy.bin in 1 minute and 13.88 seconds
@ricardo-m hola Ricardo, estoy intentado conectarme por sigfox en Cali, sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ4) pero no puedo ver el dispositivo en el backend, podrías darme alguna indicación, muchas gracias.
@xykon said in New Firmware Updater version 1.15.1:
@bmarkus Win32:Evo-gen [Susp] is a broad classification used by the Avast Behavior Monitor feature for software that exhibits suspicious behavior categorized as potentially malicious. The Behavior Monitoring feature observes the behavior of processes as they run programs.
The firmware updater connects to the Internet. That is considered "suspicious" for some anti-virus applications.
Thanks for the details. However it is a bit strange,a s I'm frequently installing programs connecting to the net during installation and have never seen such message from my AVAST.
Anyhow, I will ad it as an exception.
@robert-hh Because we only changed 3 lines of code and released only versions for GPy and FiPy. That didn't seem to warrant anything more than updating the release tag. In case you are wondering, 1.18.0 is considered a short form of 1.18.0.r0 as we consider r0 the default unless otherwise specified.
From a viewpoint of our internal versioning algorithm, we have 4 different types of versions:
1.18.0. a0 is an alpha version (only used internally), b0 is a beta (up until 1.18.0 everything was released as a beta even though the firmware updater treats them as stable), rc0 (release candidate, we never used this so far but we have the option for it) and r0 as stable release.
