Bridging between different Meshtastic networks

Greetings from Christchurch, New Zealand.

Local ham radio operators are begining to build a region-wide Meshtastic Network primarily for emergency communications during a future disaster (most likely the probable Alpine Fault earthquake). We have experience from the Christchurch earthquake that saw cell towers fail after their battery backups died after the first 24 hours.

We have access to high points to give long range coverage over the entire region, plus easy coverage of the major population centres. To do this, one site will need to run both LongFast and LongSlow, and other will probably only run LongSlow.

How do we bridge between these 2 networks without using MQTT?

These networks will likely be running higher power via ham licences, thus with no encryption. Do these nodes mesh with existing non-ham nodes or would be we have to run more bridges to bring non-Ham nodes into the mesh?


1 Like

RPi between with MQTT? Or serial to serial with firmware mod …

I am trying to use two Heltec V3 devices tied together via the IO pins for this exact purpose, and not having success. Basically, it would bridge two Meshtastic networks that are on different frequencies (both in the 915 ISM band, also would require some antenna separation). If what I am trying to do is supported, I think it could be a great option for you since it won’t require servers or other infrastructure.

Here is my concept and maybe someone can help us figure this out.

Heltec pins connected…
45 - 45
46 - 46

Serial module is Enabled and below are the settings:

  • Baud: 115200
  • Timeout: 5 sec
  • Mode: Text Message
  • RX and TX pins… One is 45 and 46 and the other is 46 and 45

I only have one channel configured on each device and the LoRA configuration is set up for the frequency and modem settings for their respective networks.

I can not tell from the debug logs that anything is passing to or from the serial line. Although, I do see the following…

DEBUG Module “SerialModuleRadio” wantsPacket=1
DEBUG Module "SerialModuleRadio’ considered

I do not see anything show up on the debug of the other device.

From what I did see on the Meshtastic Month of Modules Serial video, it seems like the “Text” mode would be the best for our application. Although, if it worked like I expect it to work, this will reset the hop count and any message from the original network will look to originate from the bridge device on the second network and visa versa.

Please let me know if anyone has ideas or thoughts.

Yeah, it’s looking like MQTT would have to be the way to go. Serial might be able to be made to work, but only between 2 meshs?

Ideally, we would like to be able to combine all different potential public meshs (LongFast, LongSlow, HamLongFast, HamLongSlow, etc) into one mesh via a repeater station.

I think one of the problems is that when you send a text message via serial, you just send the message and it goes to the default channel (no control), whereas when you receive one, the node?/channel? shortname is appended to the string?

Ah, thanks. Reviewing the video I do see something in front of the message when it is received and sent over the serial line. Although, I am thinking it should still work, you just get that added to the front (which might be nice if it is the short name).

Sorry that I don’t have an answer for you on combining networks, but for cosite, you could run long-fast at 915 MHz and long-slow at 430 MHz. Better range with 430.

Woot. That’s a good point. Cheers!

Hey Andy,

I’ve built a bridge on custom hardware that does exactly what you are looking for. We’ve been dealing with congestion issues in Wellington and trialled moving to ShortFast since it requires much less airtime, but want to keep LongFast supported for those areas that struggle to connect on ShortFast, and to link across the the SI and further away regions.
My first prototype was actually bridging 900 to 433 MHz, simply because I had a board with 2 SX1276 on those 2 bands. It works fine, just one thing to keep in mind is that traffic from ‘faster’ modulations will blow up when bridged across, and you need to apply some rate limiting/filtering to prevent swamping it.
The firmware needs a bit more refinement, but the foundation is there and works well.


Long fast Node me and a mate put up in port hills has been going strong for over a month now 45 nodes found reaching from ashburton to Amberley so far but near zero traffic 24-7 so luckily we don’t have any congestion if something were the happen right now messages will land, have a second already built and ready to install which will be going up when we have some decent weather

1 Like

Which board has two Lora chips? Or is this a self-build?

Custom board with 2 E22M90030S and ESP32-C6

1 Like

Great! Did you write your own bridge firmware? Could you share this?

Yes, it’s custom Fw. Very much still work in progress and needs a bit more refinement around filtering and remote admin capabilities, but once it’s there and I find the time I’ll publish it somewhere


Hi! Is your Wellington work tied in with Branch 74? They have gear up Mt Victoria and elsewhere?

The work you are doing is excellent!

Hi JMDG, yes your node up on the hill is definitely helping the mesh. We have one going in up the top at the Marleys radio farm very shortly. We have one running at the Radio Club HQ now to get more members interested in the concept. It’s currently sitting inside with a stub antenna but will soon get a colinear and be put up one of the masts.

I got this to work. It was very simple (I just had to pay attention to the wiring!). I have found one limitation and that is that since it adds the original senders short name, any message that is sent on one side at the full 228 Bytes is blank on the other side. But, as long as you stay under say 222 Bytes, it sends a message with the original short name and then the message…

SHNM: Message

I didn’t need to modify anything, I just wired two Heltec devices together using IO 45 and 46 and ground.

Worth a try if you wanted to see it.

1 Like