Pymesh release v1.20.2.r1

[catalin]

Hello community 🙌,

The Pymesh v1.20.2.r1 is released and all the features of the included Pymesh micropython library are here

All the customers that already sent the license will receive the binary on email (for both Fipy and Lopy4). If you did not receive it, please personally message me here and I will get back to you.

Release Notes:

• rebased on generic firmware version v1.20.2.r1
• solved Border Router bug, where on-mesh prefix IPv6 did no show
• solved small bugs related with sending mesh-external messages
• excluded BLE-RPC module, so to use Pymesh mobile app, the individual scripts should be included manually: ble_rpc.py, ble_services.py and folder msgpack (from Pymesh lib repo)
• sample script for Border Router functionality is added in main_br.py

[johncass]

Thanks Catalin ;-)

[ricardolima]

Thank you Catalin. I will try :D

[PG]

Hi!

I am facing an issue when starting simultaneously 2 modules on the same mesh (using a script similar to the Pymesh example). They both switch to single leader and never connect. If the modules are started one by one everything works correctly: one of the modules becomes leader and the other router.

Am I missing something?

[catalin]

hi @PG,
I've seen this happening, sometimes could take 2-3 minutes until both get in the same Mesh.
A simple idea would be to try and use LoRa frequency not in the same band with LoRaWAN. For EU868 region, you could try 869.7Mhz, or for short periods maybe something in 863-866 Mhz. This can be done, downloading pymesh_config.py and updating this line: https://github.com/pycom/pycom-libraries/blob/f848adcfb937e7b7bbc5f78db95840fa26dabe11/pymesh/pymesh_frozen/lib/pymesh_config.py#L26
Of, course I will continue testing this scenario and find solutions to speed-up the process of Mesh merging.

[PG]

Thanks for your answer @catalin,

For now I am using 869,5MHz (500mW, 10% duty cycle). But if it converges within 3 minutes it is fine for my use case: I'll test that.

Edit: After 300s, both devices remain single leaders in my case. I'll try other frequencies and longer durations.

Other question: is there something specific to do to release buffer or similar things in message receive callback? The transceiver is emitting 1 short msg every 60s, but the receiver only gets the first message.

[PG]

Hi @catalin,

I have made 12 start up tests these last days (869,5MHz, SF7, 500kHz bandwidth, 10cm between antennas), and it appears that during 8 of them the 2 devices started simultaneously never connect, even after half an hour. When started at 10s interval they connect very quickly. I think it confirm there is an issue.

Is there anything I can do to help debugging it?

[catalin]

Thanks, @PG for reporting this issue.

Is there any message similar in format like:
[WARN]-MLE-----: Invalid settings - no saved parent...?

[rcolistete]

@PG Beware that LoRa devices can't be too close or else there is LoRa transceiver saturation.

Recommend distance >= 2m (the distance to have LoRa saturation depends on LoRa power, SF, BW, CR, antenna, etc).

[PG]

@rcolistete It seems you find the issue: with about 1m between the devices, it works well: it takes only about 1 minute to get the devices connected and communicating, which is perfect. Thanks!

@catalin It would be nice to add a note in the documentation: I don't remember to have seen anything about it.

[rcolistete]

@PG This issue of LoRa saturation is valid for any LoRa device, not only Pycom ones. But it isn't discussed/documented by the community as it should.