New v1.20.0 Release candidate v1.20.0.rc7

[iwahdan]

Re: New Firmware Release Candidate v1.20.0

Hello everyone, There is a new Firmware release candidate v1.20.0.rc7 released today the new release includes the following:

New Features

• Pymesh feature added from Pygo - docs here and examples here

Improvments

• Adding do_handshake for non-blocking sockets
• Gracefully handle EAGAIN return of Socket.write in AwsMQTT lib
• make openthread over lora a build-time configuration option (Author: @martijnthe)
• Added factory LTE modem reset option and method to check UE coverage
• New API in modusocket to get/set DNS servers
• Updated frozen Sequans modem upgrade scripts
• Improved PPP session suspend/resume mechanism with LTE modem
• Wifi AP mode on boot now is using only Default AP and SSID -> Initially the onboot wifi mode was using the ssid/pwd configured in pycom-config saved in flash which caused
  inconvenience for some users when switching between Pybytes FW and other Base FWs since the AP would be brought up with same ssid/pwd. This is now removed and in next releases wifi config saved in flash will be improved for more efficiency and relaiability.
• Updated Pybytes lib

Bug Fixes

• Fix an issue in cleaning up user threads during of soft-reset
• Fix issue causing Device crash when safe booting (CTRL-F) while BLE/Wlan enabled
• LTE module bug fixes
• Fix Makefile bug where SIPY FIPY and LOPY4 excluded secure boot
• Fixed crashinf Issue when LoRa/sigfox are initialized before LTE or Wlan
• Fixed Issue in SecureBoot mechanism that caused compilation error when Secure Boot is enabled

co-authored by: @xykon cehlers@pycom.io and @martijnthe

You can download the source code here
or you can flash it directly via the Firmware Updater tool as the latest development firmware.

[rcolistete]

Useful info, the firmware v1.20.0.rc7 is available for manual download :
https://github.com/pycom/pycom-micropython-sigfox/releases

[combaindeft]

@rcolistete said in New v1.20.0 Release candidate v1.20.0.rc7:

Useful info, the firmware v1.20.0.rc7 is available for manual download :
https://github.com/pycom/pycom-micropython-sigfox/releases

I noticed not every release is in github ... but they are here:
https://docs.pycom.io/advance/downgrade.html

[combaindeft]

@iwahdan said in New v1.20.0 Release candidate v1.20.0.rc7:

New API in modusocket to get/set DNS servers

usocket.dnsserver(0,'8.8.8.8')
usocket.dnsserver(1,'4.4.4.4')
usocket.dnsserver()
('8.8.8.8', '4.4.4.4')

[catalin]

Hi everyone,

Just added documentation for Pymesh: https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh.html
FYI, we'll add/update example scripts soon, for now, the previous example won't work We've updated example here: https://docs.pycom.io/tutorials/lora/lora-mesh.html
<Later edit>: moved docs into official docs.pycom.io

[tlanier]

When I try to upgrade a GPy to the latest development release of firmware I get the error "Firmware file has unexpected sha1 checksum".

Does the "Pycom Firmware Update" program automatically download the latest firmware or am I suppose to download the firmware separately? The program does not display a version when run; however, it was installed from "pycom_firmware_update_1.15.1.exe". Does the "sha1 checksum" error imply that the file is corrupt on your server?

[Paul Thornton]

@tlanier Please try using the Beta firmware updater to install the latest RC, Located here: https://forum.pycom.io/topic/3425/new-beta-firmware-updater-1-15-2-b0/1

Will solve the Sha1 hash issue.

[tlanier]

@paul-thornton
That fix it.

Thanks!

[Paul Thornton]

@tlanier Glad to help

[thinginnovations]

@catalin There seems to be differences in the documentation and what is actually implemented in the loramesh.py code, for example https://development.pycom.io/v/development_release/firmware-and-api-reference/pycom/network/lora/pymesh makes reference to the border_router function. This is not present.

Do you have a roadmap for when the rest of the loramesh implementation is to be completed and available?

Thanks

Andrew

[catalin]

hi @thinginnovations, in the development release the method network.LoRa.Mesh.border_router is here, in the code: https://github.com/pycom/pycom-micropython-sigfox/blob/b6dd78344c272002db70c2909a7cd72cff69c5e0/esp32/mods/modmesh.c#L1081

As for roadmap, I am waiting for suggestions :) Of course, meanwhile, working on stability, quicker joining Pymesh, power management...

Meanwhile, by the end of the week I am targeting:

1. example with Border Router (maybe add list and remove method)
2. multi-socket and bind on a specific ipv6 (not for :: as today) for socket

[thinginnovations]

@catalin Thanks , I'll lookout for code updates.

Cheers

Andrew

[tlanier]

At least a 750 msec delay is needed after lte.init(). Would it not make better sense for the init() method to do the delay internally?

Example:

lte = LTE()
lte.init()
sleep_ms(1500)
r = lte.iccid()    # delays less than about 750 msec will return None

[Eric Waai]

@tlanier
If clearly stated i have no problem with adding a manual delay.
there are plenty of case where this time can be used to initialize other stuf. if that already takes 750 ms. there are a 750 ms wasted.

[crumble]

@eric-waai said in New v1.20.0 Release candidate v1.20.0.rc7:

@tlanier
If clearly stated i have no problem with adding a manual delay.
there are plenty of case where this time can be used to initialize other stuf. if that already takes 750 ms. there are a 750 ms wasted.

There is another way to program this. Start each init in an own thread and wait until each one died.

Yes, it shall be optional, 'cause ensure order of execution will not be easy ans overhead maybe too slow. But there are at least two ways to deal with this problem.

If we have to implement the wait time, the min time shall be in the documentation and not in the forum ;)

[tlanier]

Is there any way in Pycom's MicroPython to get some sort of low latency periodic interrupt service routine that can do an I2C transfer?

What I have found is if I use the Timer.Alarm (set to 200 msec periodic interrupt), I get wide variations in the execution of the scheduled callback handler. Some of the code that causes large latency issues include: (1) calling the modem reset method which kills servicing the interrupt routine for seconds, (2) calling the modem initialization method, (3) calling modem AT commands for instance to read signal strength and SMS messages, and (4) calling flash disk i/o methods such as open, read, write, and close.

The idea to schedule the callback on a new thread which can run any Python code without restriction is nice, but it seems that the long latency issues make that technique prohibitive in some cases. Some of the Python commands block the interrupt handlers from being able to run for long periods. For instance in my case I need to sample an analog signal periodically at a rate of 200 msec. I can't afford to have the sample be 200 msec plus or minus 50-5000 msecs. I could live with plus or minus maybe 20-30 msecs.

Would it be possible to have two types of timers? Type #1 timers would schedule the handler to run in the future as it does now. Type #2 timers would allow executing restricted code immediately at the time of the interrupt.

Here's documentation from the MicroPython site:

Writing Interrupt Handlers

Any ideas on how this problem can be accomplished with Pycom's implementation of MicroPython without adding another micro-controller to the design just to do the analog sampling?

[protean]

@tlanier said in New v1.20.0 Release candidate v1.20.0.rc7:

lte = LTE()
lte.init()

Why init twice?

Either way, there is a method in the C source for the LTE code called: lte_check_init(). Seems like it would be trivial to expose that to the public class and then you can call it lte.is_init() and use it just like is_connected or is_attached

[tlanier]

@protean
In my production code the object instantiation lte = LTE() line is executed once at startup. The following code is executed whenever an error occurs that may require reinitializing the modem.

lte.reset()
LTE.reconnect_uart()
lte.init()
sleep_ms(1500)

That's what I have found to work with experimentation.

The problem I have discovered are many of the python commands are blocking other tasks from running for relatively long periods of time. For instance the lte.reset() command seems to block tasks for up to 5 secs. Unless Pycom provides some way to execute code when a timer interrupt occurs, I believe that all python commands should be rewritten to have some maximum time of execution (maybe 1-2 msecs) before they return to allow multitasking to run smoothly. For instance instead of lte.reset(), we would need lte.reset_start() and lte.reset_iscompleted() commands.

I would love for someone with more knowledge of this subject to jump in and explain how Pycom expects programmers to do any type of real-time code in the existing environment. Is work being done to solve this problem? Is there something I am missing which currently solves the problem?

One possibility is to rebuild the software from source as described on Github and to add new python commands to implement a true interrupt service routine using the Espressif ESP32 IDF to do the work required. A second possibility is to add another micro-controller to the design to do the real-time work. Neither option is appealing.

[tlanier]

Bug Report

machine.reset() does not zero the utime.ticks_ms() counter.

An actual button press reset does.

[3sotweb]

This post is deleted!