Is it possible to customize the mesh routing algorithm for a linear topology?

General
1

Hello,

My network has a linear chain configuration where each station only has visibility to its immediate neighbors (previous and next nodes). Given this topology, the default mesh broadcasting seems unnecessary. Can I modify the routing algorithm or disable certain mesh features to optimize for this specific use case?

2

Have you considered using EasyMesh? This will give you a tree topology (i.e. AP→STA/AP→STA), which should resolve to a linear one in your case, and may deliver better performance.

3

Thanks james.haggerty! EasyMesh sounds like a good fit for my linear topology.

I’m using Heltec routers with Morse Micro firmware 2.6.6 and 2.7.3. Could you point me to:

  • How to enable/configure EasyMesh on these versions?

  • Any mesh features I should disable to optimize for this use case?

Config examples or documentation links would be really helpful. Thanks!

4

In addition, If there is a way to configure the MCS to 7, I’d like to know as well. I know how to do it on the heltec product (morsectrl -i mesh0 txrate enable -m 7), but I don’t have a similar option I find in the RPI with the heltec hat using morse_cli or something else.

5

I’m not familiar with the Heltec routers, but it looks like they’re similar to our EKH03 reference design. If they don’t provide EasyMesh (aka prplmesh) by default, I would recommend contacting them about this.

If you’re keen, it may be possible to build an image from GitHub - MorseMicro/openwrt with EasyMesh support, but:

  • ideally this would be based on Heltec’s OpenWrt board definition/device tree (which is not in our github repository); you may want to ask Heltec if they have a source release
  • you could build an ekh03 image, but if the GPIO wiring or the flash chip is different it may fail to boot (i.e. don’t do this unless you have UART access and are comfortable with recovering via tftp, unless the bootloader supports HTTP recovery)
  • you should be able to extract the current device tree from your working system, and add a new board definition, but again I would be reluctant to flash this to a device without UART access for recovery
6

I’m afraid this is one of those ‘we don’t support this and you really shouldn’t need to do it’, as the best rate should be automatically identified. Are you seeing a performance improvement from fixing the MCS?

7

Hello,

Thank you for your detailed response!

Regarding the EasyMesh, I entered the following commands:
uci set prplmesh.config=prplmesh

uci set prplmesh.config.enable=‘1’

uci set prplmesh.config.management_mode=‘Multi-AP-Controller-and-Agent’

uci set prplmesh.config.operating_mode=‘Gateway’

uci commit prplmesh
and now in my Heltec I can see that it recognizes the EasyMesh, but I’m not sure it’s configured properly, I can’t find any documentation for that.

image
image2454×1074 176 KB

You may see the comment in yellow.

The MCS - I do see better results when it’s always 7. I’m in an area that the RSSI changes all the time so I believe that keeping it at 7 is the best option, because otherwise it should switch modes all the time.

8

@james.haggerty If you have any insight (even if partial) it would be much appreciated, it will solve us a major problem.

Thanks again

9

Though you can enter those commands, and the UI knows something about them, that the config file doesn’t exist before you created it indicates that you don’t have the prplmesh package installed.

You can confirm this by going to the ‘software’ section in the UI or using opkg from the command line.

I would recommend contacting Heltec about their support for EasyMesh/prplmesh as a first step.

If that doesn’t result in anything straightforward, you can also look at manually configuring the intermediate ‘mesh’ nodes ; they should work with a bridged AP/STA setup on them, making sure to have WDS on. Let me know if that doesn’t make sense and I’ll make a sample uci config.