catalin last edited by catalin
Hi community 🙌
I want to share with you the Pymesh (LoRa Mesh) current development and plans; last release of Pymesh is in v1.20.0.rc7
For starting, this is my Pymesh presentation(workshop) done at TTN Conf Jan 2019 Amsterdam; if you have any questions 🗣
As I've said in a previous mail, currently I'm working on the Border Router feature, I try to explain in a nice micropy script, basically how Pymesh data can be exposed outside of mesh, on Wifi/BLE/Cellular to the ☁.
Not to forget the 📕 were copied here: https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh.html and https://docs.pycom.io/tutorials/lora/lora-mesh.html with a disclaimer, as Pymesh is included just in RC (development) releases.
But, no worries, 😅 we'll include it in the first official stable.
We're planning in releasing firmware releases with and without Pymesh, due to relatively large (~200KB) code-size.
I'm working at the road-plan for further Pymesh features.
Long-term plan is exposing more openthread features, make tons of tests (lots of nodes, distance); connect Pymesh with Pybytes, optimise power-consumption, security for private Pymesh, profile some KPI (data able to be sent over Pymesh), and of course share all plans with community (basically I will open-source the micropy scripts presented in workshop, have some articles to explain all use-cases).
Just let me know your thoughts, about the further projects, and we could include requirements into official development.
@catalin This is what comes back when pyMesh crashes with lopy and mesh that is running, it doesn't happen reliably, but it eventually crashes the entire system:
Guru Meditation Error: Core 1 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x00013ffe PS : 0x00050033 A0 : 0x00013ffe A1 : 0x3ffe12f0
A2 : 0x00230000 A3 : 0x00000006 A4 : 0x08700000 A5 : 0x00003ffb
A6 : 0xd2550000 A7 : 0xd26b4009 A8 : 0xfffb4009 A9 : 0x39a4ffff
A10 : 0x00014008 A11 : 0x69ac0000 A12 : 0x08704009 A13 : 0x00003ffb
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x00000000 EXCCAUSE: 0x00000014
EXCVADDR: 0x00013ffc LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Backtrace: 0x00013ffe:0x3ffe12f0 0x00013ffb:0x000000ff
Guru Meditation Error: Core 1 panic'ed (IntegerDivideByZero). Exception was unhandled.
Core 1 register dump:
PC : 0x40098f0b PS : 0x00060033 A0 : 0x80098822 A1 : 0x3ffe11b0
A2 : 0x3ffe1230 A3 : 0x00000000 A4 : 0x00002800 A5 : 0xc0051ff0
A6 : 0x00051fe0 A7 : 0x00000032 A8 : 0x00000000 A9 : 0x3ffe11a0
A10 : 0x2c42f5e1 A11 : 0x00000000 A12 : 0x00000018 A13 : 0x3ffe11c8
A14 : 0x3ffc3b00 A15 : 0x00000001 SAR : 0x00000017 EXCCAUSE: 0x00000006
EXCVADDR: 0x00013ffc LBEG : 0x4009cfd8 LEND : 0x4009cfe3 LCOUNT : 0x00000000
Backtrace: 0x40098f0b:0x3ffe11b0 0x4009881f:0x3ffe11f0 0x40098a5a:0x3ffe1210 0x4008378a:0x3ffe1230 0x40013ffb:0x3ffe12f0
Re-entered core dump! Exception happened during core dump!
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:1
Initializing filesystem as FatFS!
@catalin SF is 7, Bandwidth is 125. The RssI values were not being printed.
@jordan-reyes I did not properly tested Pymesh on Lopy1, mainly because the scripts that I use, occupy lots of RAM.
What LoRa params are you using, spreading-factor, bandwidth? I would start tests with fastest datarate (SF7, BW 250). Are you printing the RSSI values, if they are at the border (for that SF, for ex: lower than -115), there could be corrupted packets, that Node could exit/re-enter the Mesh.
10 seconds is a small waiting time; Mesh internally sends, every 32 seconds, sends a keepalive between each pair of neighbours (last communication is in the
@catalin deployed rc8 upon boot up nodes hit (outside With Line of sight ) and they are suppose to respond every ten seconds, some responsive more than others but after some time they do not send data anymore. Sometimes it lasts an hour sometimes a day but it is not reliable. What is environment you are running your set upon. We are covering about 2.25-2.5 km.
@catalin with both deployed is orignial lopy, not lopy4 would this be any difference with about 12 nodes. it was running for a bit and then would crash, but we weren't getting stable communication either, some were more consistent then others.
Yes, please try the RC8 release, I did not had any issue with RC7, either.
Now I am running the Pymesh with ~30 micropython scripts (sending data to the Cloud, using Wifi and BLE), also creating Pymesh with 20+ nodes(lopy4 and Fipy), no Error found.
@catalin had a lot of issues with 1.20.0.rc7 almost all nodes were corrupted with guru meditation error on lora.mesh. the mesh seemed to be the issue, The error did not seem to be on previous versions, (although it wasn't run very long on previous version prior to update), I am hoping with rc8 this problem is fixed....
@catalin ooo, interesting. Thanks for the update.
In the release 1.20.0.rc8 the Pymesh was updated, please check https://forum.pycom.io/topic/4499/firmware-release-candidate-v1-20-0-rc8
As usual, let me know what's not clear, the Border Router example a bit too simple.
Hi @jordan-reyes, announcing a stable release with Pymesh included, it's not a matter of Pymesh being not stable. There are some other features/improvements that need to be tested in whole firmware. Sorry, I don't know more details, probably the bugs/requests were raised on forum :)
Some new Pymesh features were just released internally (so they will be incorporated in the next RC, probably this Friday) plus some example scripting for Border Router:
- added socket binding to IP, add listing border_router
- BUG: src and dest port on BR should he Host Swapped
- Mesh.rx_cb() added argument, with the callback
- added Mesh.border_router_del(prefix) method, for erasing Border Router entry
- added multi-socckets (max 3)
- added Border Router socket with header IP and port destination
I did not forgot, we'll open-source some Pygo example scripts, as promised. I need to update/test for the new release.
Plus, working on some Pymesh Roadmap...
@catalin Awesome when do you think stable version to be released?
catalin last edited by catalin
For the Networks Engineers 🤓, this are the OSI Layers that are stacked into LoRa Mesh (Pymesh) feature:
So, @thinginnovations Andrew, the IPv6 routing is already handled at Transport level.
The router sends (routes) a packet to the destination, using the internal Thread routing(vector-distance algorithm). There could be some trouble, as the IPv6 of the destination should be known (either RLOC or ML-EID from here).
In the TTN conf scripts I've implemented some sort or ARP (MAC to IP resolution), so node with LoRa MAC 0xA can send a message to the node 0xB, without knowing B's IPv6 (internally node A interrogates Leader to find IP of node B).
I'll try to open-source them ASAP.
Thanks for the update.
When a node designated as a router receives a packet is this automatically sent out to the neighbours or does the application code need to resend to neighbours in the receiver callback function?
Thanks, trying to understand the process as I'm starting to build a larger mesh of nodes.