New Firmware Development release v1.19.0.b4

[soulsurfer]

@iwahdan - Given the recent change in wording (and the fact that I'm a micropython noob!) are there explicit instructions anywhere on precisely how to "includ[e] uasyncio micropython module[s]" plus the required libraries?

[iwahdan]

@soulsurfer, using FTP or pymkr you can upload the uasyncio modules to your Pycom device with the following hierarchy :

• uasyncio sub-modules into /flash/lib/uasyncio
• websocket.server sub-module under: /flash/lib/uasyncio/websocket
• collections sub-modules into /flash/lib/collections
• logging sub-module into /flash/lib

And then you can import uasyncio library into your script and start using it

[Sympatron]

@iwahdan I think it would be nice to have this as frozen modules by default in the future.

[cmisztur]

@soulsurfer here, I documented the process https://medium.com/@chrismisztur/pycom-uasyncio-installation-94931fc71283

[tuftec]

It is good to see that RTC memory support has been added.
Is there a mechanism that can keep the RTC operational when the device is in deep sleep?
I need a way to maintain system time but require to deepsleep regularly to save power (battery operated).
My original solution for this was to implement a s/w RTC and to save its state every time I go into deepsleep. I would then use my knowledge of the time in deepsleep (set by the deepsleep timer) and measuring execution time of the start up code (using the chrono functions) to then update my s/w RTC upon waking.
Very messy but it sort of works. Not very accurate though.
If there was a way to keep the RTC running (power still applied) then I could hopefully have a much better solution. Using other ESP32 based devices running standard Micropyrhon, it would appear that the RTC function actually continues to operate during deepsleep.
Have I missed something???? Is there a suggested way to use the RTC when using deepsleep?

Peter.

[jcaron]

@tuftec you may want to let us know which hardware combination (module + board) and what deep sleep mode you are using.

If you are using one of the “older” boards (e.g LoPy, not LoPy 4) with a Pysense, Pytrack or the deep sleep shield, and the PIC-controlled deep sleep, then the ESP32 is indeed completely powered down during deep sleep.

If you are using one of the more recent boards (e.g LoPy) and machine.deepsleep, I believe the RTC keeps running during deep sleep.

[soulsurfer]

OK - Thanks @iwahdan.

[iwahdan]

Hi @tuftec, well as @jcaron mentioned if you are using a Pycom device with Deepsleep shield you cannot keep track of time using RTC as the device is completely powered Off, however if you are using the newer boards that don't require the Deepsleep shield you can keep track of time using the RTC module in Micropython, you would set the time once using RTC.init() and the RTC would keep counting from that time even in deepsleep , you can check time after wakeup using RTC.now()

[soulsurfer]

Triple thanks @cmisztur!

[tuftec]

Sorry about the scant information.
I am building custom hardware around the LoPy4 and FiPy devices.
So, based on the post by @iwahdan , does this imply that the RTC should keep going in DeepSleep for both the LoPy4 and FiPy modules? This is contrary to information I was given some time ago.
If the RTC keeps going that would be a big advantage for my application.

Peter.

[iwahdan]

@tuftec , Also you have to take into consideration the fact that if board resets or power is lost the Time is rested to unix epoch , you can use RTC.ntp_sync() to Sync time using an NTP server in case of hard resets.

[rcolistete]

Any measure of time (in ms) to wake up from light sleep mode ?

I'd like to know if a wake on pin (external signal) from light sleep mode would be fast enough for some signal frequencies : 10 Hz ? 50 Hz ? 100 Hz ? 1000 Hz ?

[rcolistete]

Measured using only software : about 16 ms to wake up from light sleep. Both using wake on pin (interrupt) or timed light sleep.

Need to confirm with external measurement : i(t) powering LoPy4 by using oscilloscope + shunt resistor.

[martijnthe]

@iwahdan or @Xykon what's the timeline for a non-beta release of v1.19.0?

Mostly interested in LittleFS (for robustness and wear-levelling) and the newer micropython.

[Xykon]

@martijnthe said in New Firmware Development release v1.19.0.b4:

what's the timeline for a non-beta release of v1.19.0?

We are hoping to publish the first release candidate next week.

[reidfo]

On both mac and linux I'm getting unexpected sha1 checksum when I try to install the latest development release on FiPy.

[Xykon]

@reidfo said in New Firmware Development release v1.19.0.b4:

On both mac and linux I'm getting unexpected sha1 checksum when I try to install the latest development release on FiPy.

Are you using the beta firmware updater?