Pymesh updates

[robert-hh]

@catalin My question was more, what to do with the actual pymesh firmware images you pubished. They run and connect, but I see no path to use it for other purposes. There is a single > prompt. If I push Ctrl-D at it, I get the message:

Unhandled exception in thread started by <bound_method>
Traceback (most recent call last):
  File "cli.py", line 36, in process
EOFError: 

So there is a function cli.py, which seems to wait for commands. But which one?

[robert-hh]

@catalin Onother issue:
I had one LoPy4 with your pymesh image running over night. This morning it was in a reboot loop with messages like these:

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400966f0  PS      : 0x00060033  A0      : 0x80094c5a  A1      : 0x3ffc09c0  
A2      : 0x3ffc1910  A3      : 0x00000000  A4      : 0x3ffc56f4  A5      : 0x000005ab  
A6      : 0x3ffc5914  A7      : 0x00000000  A8      : 0x3ffe3964  A9      : 0x3ffc0990  
A10     : 0x00000001  A11     : 0x00060021  A12     : 0x3ffdc468  A13     : 0x00000001  
A14     : 0x000000fe  A15     : 0x00060023  SAR     : 0x0000001f  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000008  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  
Core 0 was running in ISR context:
EPC1    : 0x400966f0  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x4008b8b4

Backtrace: 0x400966f0:0x3ffc09c0 0x40094c57:0x3ffc09e0 0x40097675:0x3ffc0a00 0x40083b16:0x3ffc0a10 0x40201af3:0x3ffdc3b0 0x400965b5:0x3ffdc3d0

No clue what happened. Re-flashing it brought it back to normal operation. This is new, because normally these devices are very reliable.

[catalin]

@robert-hh, the micropython scripts which are frozen in those binaries is in the same repo: https://github.com/pycom/pymesh_apps/tree/master/pymesh_micropy_scripts

The cli commands can be seen in the code, sorry for not having then documented:
https://github.com/pycom/pymesh_apps/blob/0063271c910c78d0d4832286494eb49f96242eca/pymesh_micropy_scripts/lib/cli.py#L43
Nicer is to install the Android or iOS mobile app(link opened by TestFlight mobile app).

Regarding the crush, I've pushed the memory heap usage to the max in those binaries, this is solved by the newest IDF_v3.2 from development.

[robert-hh]

@catalin OK. Thanks. It looks like the LoPy4 devices crash all the time. The FiPy seems stable.

[robert-hh]

@catalin Two things about the crashes: as long as I have at least two devices in the local mesh, it seems stable. Having just one device running causes a crash each time after a few minutes. Normally, the device just reboots and it will start over. Nor perfect, but acceptable. But after a few hours it will end up with a corrupted flash firmware, causing core dumps like the one below. At that point I have to re-flash the firmware. The file system is not affected.

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:2156
ho 0 tail 12 room 4
load:0x4009fa00,len:19208
entry 0x400a05f4
Guru Meditation Error: Core  1 panic'ed (InstrFetchProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x00000000  PS      : 0x00060031  A0      : 0x40083b04  A1      : 0x3ffc13f0  
A2      : 0x3ffc5c6c  A3      : 0x00800000  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x3ffdd308  A7      : 0x000006f4  A8      : 0x8008456a  A9      : 0x0000018c  
A10     : 0x3ffda984  A11     : 0x3ffdda09  A12     : 0x80098d18  A13     : 0x3ffe32b0  
A14     : 0x3ffda974  A15     : 0x3ffdd304  SAR     : 0x00000013  EXCCAUSE: 0x00000014  
EXCVADDR: 0x00000000  LBEG    : 0x4009dc28  LEND    : 0x4009dc33  LCOUNT  : 0xffffffff  
Core 1 was running in ISR context:
EPC1    : 0x00000000  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x4008b78e

Backtrace: 0x00000000:0x3ffc13f0 0x40083b01:0x3ffc1410 0x4000bfed:0x3ffe3320 0x40095da3:0x3ffe3330 0x400d2f7b:0x3ffe3350 0x400d2fc1:0x3ffe33b0 0x4015edfd:0x3ffe33e0 0x400e2af1:0x3ffe3400 0x400ddd48:0x3ffe3420

================= CORE DUMP START =================
oB0AAAoAAABsAQAA
KND9P/Be/j8cYP4/
8F7+P7Bf/j+lpaWl9Fr8P5xX/D8o0P0/lFf8PxQAAAClpaWlpaWlpSjQ/T8AAAAA
BQAAACBQ/j9TZXJ2ZXJzAKWlpaWlpaUAAQAAABxg/j8AAAAApaWlpQUAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABA6v0/qOr9PxDr/T8AAAAAAAAAAAEAAAAAAAAA
W0VBPwAAAAC84glAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKWlpQ==
nDgIQKjhDUAwAAUAAAAAALBf/j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAANCT+j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAC8X/4/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

[catalin]

@robert-hh Thanks a lot, Robert, for highlighting this malfunction.
I will test this scenario on the latest firmware.

[robert-hh]

@catalin Two question:

1. I tried the Pymesh Android app, but it does not get any connections. Where and how does it search for a connection.
2. With these standard binary images, how can I change the WiFi settings, e.g. into STA mode and DHCP? The code seems to be executed from _boot.py. If I interrupt is, the normal boot process continues. Funny enough, some of the pymesh stuff continues to run.

[catalin]

@robert-hh

1. The Pymesh mobile app searches BLE Servers with name "PyGo*". I suppose pressing Restart scan button doesn't solve situation. Try to use another mobile app, like BLE Scanner(or nRF Connect) to check if the Lopy is discovered (it should have 2 services advertised). Sometimes Android+iOS have some caching of BLE connections.

2. Basically, you can't have your own main, as several threads are in the frozen scripts, hence the zombie threads.

Now I am working a frozen Pymesh scripts(as library) which can be used with a user main.py+ config file, hope to be done to be included in next Pymesh firmware release.

[robert-hh]

@catalin BLE Scanner finds both devices active at the moment, but the pymesh app does not connect.

[catalin]

@robert-hh, I'm not sure how it works in Android, rights for using Bluetooth and localisation should be given to the Pymesh app (iOS asks when app is first time started).
Localisation right is required as GPS coords are sent to the node when BLE connection is established; and somehow BLE usage is linked to localisation services, too; honestly I did not investigated this.

[robert-hh]

@catalin Thank. That was the trick.

[eranroll]

@catalin Hi,

I have being experiencing the same crashes as @robert-hh when using LoRa MESH with FiPy-1.20.0.rc8, and I know that LoRa MESH has been removed from new development builds such as FiPy-1.20.0.rc13.
I would like to know if a stable LoRa MESH version is planned anytime soon, or perhaps even a more stable development version?

[Danne]

First of all, let me thank you for this excellent project!
Pymesh paves way for many very interesting projects!

I have started on a project using a pymesh network, it's a simple network with LoPy4 nodes and WiFi access points with web-servers allowing people to find each other and then send encrypted messages over the Loramesh. I want to add batteries and solar-cells to the mesh nodes to make this project completely off-grid.

Cellphone  <- HTTP over WiFi -> LoPy4 <-> LoRa Mesh

Questions for @catalin:

• Which firmware would you recommend for the early development of products using mesh? Should I wait for the upcoming release?
• I would like a version of the firmware with source-code to be able to debug things like "InstrFetchProhibited". The latest version of the Firmware (https://github.com/pycom/pycom-micropython-sigfox) does not include the OpenThread in pycom-esp-idf https://github.com/pycom/pycom-esp-idf . Is there a developer branch that I can get access to, if so which? I don't mind it being under development or if it crashes as long as I can build it and investigate further :)

Sincerely,

Daniel

[catalin]

@Danne @eranroll
For the moment we have removed the open-source Pymesh components from the public repositories, and also from the binary releases.
We prepared a process to release binary Pymesh releases, but the licensing is not yet set.
Honestly, we're not sure if we'll release open-source, depends on the licensing process.

I intend next week to release here binaries for Lopy4 and Fipy, which would work with scripts from here.

[Danne]

@catalin Thanks for the reply!

Open-source would be nice!

Looking forward to the upcoming release!

Best,

Daniel

[robert-hh]

@catalin wouldn't it possible to put that closed stuff in a binary lib which will be linked when one builds the firmware?

[thinginnovations]

For Lopy4 release, will this work on the L01 modules as this has the same flash and ram as the Lopy4 or will it be only limited to the L04 OEM modules?

Thanks

Andrew

[robert-hh]

@thinginnovations You should expect that the LoPy4 firmware will only work on the L04 module (SX1276 chip) and the LoPy1 firmware will work on the L01 module, making however use of the larger RAM and flash. Similar to the WiPy firmware which works on both WiPy2 and WiPy3.

[thinginnovations]

@robert-hh That is providing Pycom build the firmware for the LoPy and include the LoRa Mesh functionality.

Andrew

[eranroll]

@catalin Thanks for the reply! I was able to load the tar files you had uploaded using the PyCom Firmware Updater.
However, I am not sure I follow its purpose. LoRa Mesh communication will start working on boot? From that point forward messaging over the LoRa Mesh network is done only using the Mesh CLI?

I am able to run a main.py file of lib/pymesh for example, but only after a few CTRL+C which stop the MESH THREAD.