New Firmware Development release v1.19.0.b4

[RodgerG]

@ catalin

Found the problem

The example code was missing

# Make sure heartbeat is disabled before setting RGB LED
pycom.heartbeat(False)```

[iwahdan]

@harish-kumar yes it is possible, however you have to make sure that Arduino only use a single frequency, as Pycom devices can only listen on a single frequency, you should be implementing something like that
https://docs.pycom.io/chapter/tutorials/lora/lorawan-nano-gateway.html#otaa-over-the-air-activation
on Arduino.

[egimbernat]

@rodgerg When pycom.heartbeat is set to true (By default it is), creates a lock around led operations that's because the OSError. Even if you adquire a lock and iterate around led operations on main thread or an volatile thread pycom.heartbeat will have priority when turned on.

The solution as you found is to set:

pycom.heartbeat(False)

When you want to gain control over led, sometimes you may need a very small delay in order the heartbeat lock to release. For example:

pycom.heartbeat(False) #Assuming that it was True
time.delay(0.05)
mesh.led_state()

[cmisztur]

@iwahdan Thanks. Should importing uasyncio work in this release ?

[iwahdan]

@cmisztur, We've done some updates in this Dev release to support including the uasyncio lib from micropython.

The uasyncio library is provided by MicroPython under micropython-lib: https://github.com/micropython/micropython-lib/tree/master/uasyncio
Unlike CPython's asyncio library it is splitted into several parts:

• uasyncio.core
• uasyncio.queues
• uasyncio.synchro
• uasyncio.udp
• uasyncio.websocket.server

The uasyncio library relies on the micropython-lib/collections (defaultdict, deque) and logging libraries.

Note: I've updated my Release post as it was wrongly implying that the uasyncio already included in firmware

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