Firmware Release v1.20.1

iwahdan

Hello @berni , Thanks for reporting that issue, we will work on reproducing it, meanwhile regarding the exception you get when downgrading to rc13 , this should be due to the new formatting mechanism of NVS introduced in IDF_v3.2 (1.20.1) , so when you downgrade the FW to previous version of IDF, NVS might not be initialise successfully, to solve this issue you can erase the device and flash the Firmware again.

Thanks

robert-hh

@berni @iwahdan Setting the frequency and/or removing channels is a topic which anyhow does not seem to work. I have to look at it. Even when I set in the abp_node.py sample code the device to use a single frequency only, it transmits at the three default frequencies. That was different once.

oligauc

@berni Using a terminal / command prompt, please can you go to the pycom firmware updater folder (e.g "C:\Program Files (x86)\Pycom\Pycom Firmware Update" in windows) and type the following command:

pycom-fwtool-cli.exe -p "your com port" erase_all

After erasing please re-flash your device.

Please let us know how it goes, Thanks

oligauc

@robert-hh We carried out some tests with the abp node / RAK gateway in the EU region. If you add 3 channels with the same frequency and remove the others, it will send at 1 frequency.

If you do not add / remove channels manually, then the node uses frequency hopping.

robert-hh

@oligauc I think i did that in my code, which is the abp_node example. I'll repeat it.

robert-hh

@oligauc I just verified that, after a clean erase & upload. Then only one frequency is used. There may have been a modified set-up. I purchased a SDR recently, which allows to see the frequencies used. It's interesting to see all the different activities in the 868 band.

robert-hh

@oligauc I tried another device, a LoPy now, and that one was completely messy. After setting a Lora parameter wrong, I could not change that any more. Only erasing flash and re-installing the firmware made it working again. Besides that, below is a nice picture showing how a message with DR=0 looks in the waterfall diagram.

berni

Thank you @oligauc!

This fixed the issue with lora.nvram_erase(). Also, I was having troubles deleting the flash from the pycom firmware upgrade software (it will time out if I select that option, working fine if I just upgrade the FW).

I have observed that having pybytes active and doing my own LoRa OTTA (saving on nvram after joining the network) caused that the join flag was deleted and never connected again. I have disabled the pybytes in the pybytes_config.jsonfile adding {"pybytes_autostart": false} and that fixed the issue.

I have been running the program on v1.20.1.r1 without pybytes and haven't had any Guru Meditation errors for a while. I'll keep trying...

cmisztur

@robert-hh said in Firmware Release v1.20.1:

I build the image myself

Right.

pyexec_frozen_module("_main.py");

robert-hh

@cmisztur It's not that _main.py or _boot.py are executed, it's what is frozen into the image as _boot.py or _main.py.

serafimsaudade

I'm getting this error when compiling.
I clone the repo and try to compile.

robert-hh

@serafimsaudade IOt may be a problem with the pycom esp-idf.
in the folder pycom-esp-idf, execute the command:

git checkout idf_v3.2
git submodule sync
git submodule update --init

Also, in you pycom esp32 source directory, issue the commands:

git checkout Dev
git submodule sync
git submodule update --init

Then, a

make BOARD=WIPY clean
make BOARD=WIPY

serafimsaudade

@robert-hh Tks for the tip.

That was the idf submodules.
problem solve. :)

serafimsaudade

Hi again,
I'm trying to connect gpy to wireless, but when I do wlan.scan() get this error:

wlan = WLAN(mode=WLAN.STA_AP,ssid="teste", auth=(WLAN.WPA2, 'pass'))
nets = wlan.scan()
OSError: Scan operation Failed!

This work on others fw version.

robert-hh

@serafimsaudade The following sequence works for me:

from network import WLAN
wlan = WLAN(WLAN.STA_AP)
wlan.scan()

serafimsaudade

@robert-hh but I need to set a custom ssid and password.

robert-hh

@robert-hh This sequence works too, after setting the password to a length of 8 min.:

from network import WLAN
wlan=WLAN(mode=WLAN.STA_AP, ssid="teste", auth=(WLAN.WPA2, 'passpass'))
wlan.scan()

Pycom MicroPython 1.20.1.r1 [d4b4717] on 2019-10-09; LoPy4 with ESP32
Type "help()" for more information.

I do not expect that the GPY is different with respect to WiFi.

serafimsaudade

@robert-hh

from network import WLAN
import time
wlan=WLAN(mode=WLAN.STA_AP, ssid="teste", auth=(WLAN.WPA2, 'passpass'))
time.sleep(3)
wlan.scan()

If I put a delay >= 3 seconds, works as espected, strange.

crumble

Running 1.20.1r1 I am impressed of the boot performance.

But in combination with a pytrack there are a lot of i2c errors. I am not amused to figure out new timings which may result in less errors, but will never remove them all.

Additionally I run now into i2c that can only be resolved by cutting the power suply. Would be great, if the PIC has a watchpig function. So I can track down with less efford, if this is caused by the LoPy or the Pytrack.

andreas

Hi there,

@berni said in Firmware Release v1.20.1:

I have disabled the pybytes in the pybytes_config.json file by adding {"pybytes_autostart": false} and that fixed the issue.

We are able to confirm the new firmware obtained from [0] and bundled and flashed to a FiPy device through the process outlined on [1] works flawlessly. Before adding the pybytes_config.json file, we also experienced Guru Meditation errors like outlined above (bad00bad bad00bad bad00bad). We didn't even use LoRa, just WiFi.

@crumble said in Firmware Release v1.20.1:

Running 1.20.1r1 I am impressed of the boot performance.

We are running the Terkin Datalogger [2] and are also very happy about the performance improvements through the efficiency gains of the new mpy file format shipped with MicroPython 1.11 [3] when loading the py/mpy files into memory. On MicroPython 1.9.4, this took about 30(!) seconds and now we are down to 5 seconds [4].

Thanks to all people involved in this release, turtles all the way down to the MicroPython core maintainers - you know who you are!

With kind regards,
Andreas.

[0] https://github.com/pycom/pycom-micropython-sigfox/releases/tag/v1.20.1.r1
[1] https://forum.pycom.io/topic/4518/firmware-update-elf-vs-tar/13
[2] https://github.com/hiveeyes/hiveeyes-micropython-firmware
[3] https://github.com/micropython/micropython/releases/tag/v1.11
[4] https://community.hiveeyes.org/t/micropython-module-freezing/2445/10

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

Firmware Release v1.20.1

Pycom on Twitter