New Firmware Development release v1.19.0.b4

[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()

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

[RodgerG]

@ catalin

Found the problem

The example code was missing

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

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

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

[gregcope]

@sympatron thanks!

[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

[Sympatron]

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

[gregcope]

@iwahdan

Hi. Any docs for this (rtc memory)

[iwahdan]

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

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

[catalin]

Regarding LoRa-Mesh (based on OpenThread) functionality a couple of docs:

• https://docs.pycom.io/v/development_release/chapter/tutorials/lora/lora-mesh.html <later edit>
• new Lora methods (.mesh() and .cli()), also the mesh sockets here: https://docs.pycom.io/v/development_release/chapter/firmwareapi/pycom/network/lora.html

As usual, we need community feedback: what interesting things you want to do with a Lora-Mesh network?

[Sympatron]

Interesting additions!

I have a few questions:

• The RTC-memory documentation is missing how much data can be saved.

• Is it a Full Thread Device or just an End Device?

• I have no experience with OpenThread. Can a LoPy be used as a Border Router to transparently send UDP packets to non-Thread devices e.g. via WiFi? If not at the moment will it be in the future or can this be implemented by oneself? This would be extremely interesting for us, because it would spare us of having to implement something similar.