New Firmware Development release v1.19.0.b4

[Sympatron]

As others have mentioned in the past it would be extremely helpful to have some kind of roadmap. I don't necessarily need fixed dates, but we are trying to use your device commercially and therefore we need to make business decisions.

If we had known you were working on an OpenThread implementation we could have saved a lot of time developing our own LoRa network protocol.

[iwahdan]

@sympatron , You can save up to 2KB of data in RTC memory

[gregcope]

@iwahdan

Hi. Any docs for this (rtc memory)

[Sympatron]

@gregcope https://docs.pycom.io/v/d0d9191ca2df10c6ca280de6fd2f11e7c5a18e6f/chapter/firmwareapi/pycom/machine/RTC.html#rtcmemorydata

[catalin]

hi @Sympatron, I can answer the Openthread questions:

• in this release openthread is compiled for FTD( though, no DNS, Commissioner/Joiner role, DTLS, Jam detection, here are include files)
  • you can (or I can provide) a MTD openthread library build, code is open-source at https://github.com/pycom/pycom-esp-idf/tree/idf_dev
• I've been investigating the Border Router issue:
  • for the moment the UDP packets are not transferred to Wifi
  • Solution A: (doable by you immediately in a micropy script) you could start and UDP server (bind a socket) on the designated Border Router device, propagate it's IPv6 (RLOC or ML_EID) thru multicast in the whole network, receive all UDP packages and manually take UDP payload to the Wifi socket
  • Solution B: you can also use lora.cli('prefix add xx::xx') to insert the prefix for out-mesh traffic, then use otIp6ReceiveCallback to filter on Border Router all the IP traffic having that prefix, unpack UDP packets, repack and send on wifi socket; basically some NAT64 needs to be implemented
  • I would try the solution B, but not sure if we can release sooner than 1 month
  • for implementing Solution A, take a look here for UDP sockets example: https://github.com/pycom/pycom-libraries/tree/master/lib/lora_mesh

[gregcope]

@sympatron thanks!

[Harish kumar]

Hi @iwahdan ! I am using Arduino as a device. And lopy4 as a repeater, where lopy4 has to fetch data from the device and it needs to send to the Gateway(only by lorawan). Is it possible with this ?
I am sending OTAA from Arduino to server.
Thank you in Advance !

[RodgerG]

Hi @catalin

This LoRaMesh is great and just what I have been looking for!

I tried downloading the example file and library and loaded them on to a LoPy4 on a PySense.

However, I get a strange error on start up (or reset) as below...

Initializing filesystem as LittleFS!
LoRa MAC: 70b3d5499625b58c
Traceback (most recent call last):
  File "main.py", line 23, in <module>
  File "/flash/lib/loramesh.py", line 98, in led_state
OSError: the requested operation is not possible
Pycom MicroPython 1.19.0.b4 [v1.9.4-50f84dd] on 2018-07-13; LoPy4 with ESP32
>>> mesh.led_state()
>>>

The call from main.py is as follows

while True:
    mesh.led_state()

and the code on line 98 of loramesh.py is the third line of the following method

    def led_state(self):
        """ Sets the LED according to the Thread role """
        pycom.rgbled(self.RGBLED[self.state()])

When I just call mesh.led_state() from the command line, there is no such error, as you can see from the console log.

I tried putting mesh.led_state() in a try-except clause, but still kept getting the same OS error.

As a workaround, I have copied RGBLED to main, and replaced

mesh.led_state()

with

pycom.rgbled(RGBLED[mesh.state()])

and this works.

I cannot see any obviouse reason for the error.

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