blog/why-your-mesh-should-switch-from-longfast/

[giscus[bot]]

blog/why-your-mesh-should-switch-from-longfast/

Improve your local mesh network by moving away from the default LongFast preset to higher bandwidth options

https://meshtastic.org/blog/why-your-mesh-should-switch-from-longfast/

[violarulan]

Correct me if I'm wrong. I was told by people that preset names are used in MQTT topic hiddenly.

That means a LongFast node which is connected to MQTT cannot talk to/see another node other than LongFast even if under the same topic.

If I have to bridge two areas, A(LongFast) and B(MediumSlow), how to connect them via MQTT?

[madeofstown]

You won't be able to bridge 2 frequencies over MQTT unless they have the same channel name and key. Channel names are used as MQTT topics.

[violarulan]

@madeofstown Thanks for the info. Now get it.

Since the default channel name is related to the preset, I can't bridge different presets. But if it's a secondary channel, I can make it by setting the same name and PSK.

[madeofstown]

That is correct. What you can also do is make a secondary channel with the name LongFast on the MediumSlow node, and a secondary channel with the name MediumSlow on the LongFast node.

But I would definitely discuss with your local Meshtastic groups before you bridge the public channels.

[moored57]

Some friend and I in California have switched over to the longMod preset and have enjoyed the lack of message clutter. The one thing that we have had problems with is that mqtt does not seem to work with longMod. We can't get it to work. Any suggestions for a solution?

[typicalaimster]

I guess it's to much to ask for a node setting that can serve multiple roles. Have your long haul routers use Long. Which can in turn send Long to Medium client nodes. Then use Medium to Short for Client Mutes. The suck is you can't bounce things across MQTT between Long/Medium/Short because the topic is different.

[dzienisz]

In my opinion everything lay in good defaults and documentation. If user can easily understand in UI what any setup mean they could easily adjust.

[VilemR]

Hello from Brno, Czech Republic.
Let me share a few thoughts on the LongFast vs MediumFast discussion. I'm describing the situation as of February 2025.
In the city of Brno, the LongFast (LF) setting has been used from the beginning. In contrast, the rest of the Czech Republic (excluding Brno) has mostly adopted MediumFast (MF). After 1.5 years of actively using Meshtastic and continuously testing and monitoring the network, the LF network in Brno remains the only widespread deployment in the Czech Republic that has demonstrated a reasonably reliable mesh network — consistently delivering messages with a success rate of 95% or more. Here, Meshtastic is used for actual message exchange, not just as a DX exercise (trying to reach the most distant nodes).
From that perspective, I would be very cautious about any mass migration to MF.

As of February 2025, the Brno mesh network became reliable on LF under the following conditions:

• Node density of at least 1 node per 10 km²
• Average distance between nodes of 2–3 km
• Each node having at least 3 other active nodes in range with signal quality of RSSI > –110 dBm and SNR > –4 dB

I assume similar requirements will be necessary to achieve a reliable MediumFast network. This is supported by the experience in Brno, where MF node clusters that don't meet these conditions have shown poor performance and unreliable connectivity. Unless you have same conditions (...even better due to MF limits) do not migrate to MF.

You can find more details in my blog (in Czech), but Google Translate works well for it.
https://meshtastic--czbrno-blogspot-com.translate.goog/2025/01/kapitola-1-po-jednom-roce.html?_x_tr_sl=cs&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=wapp
https://meshtastic--czbrno-blogspot-com.translate.goog/2025/01/meshtastic-moznost-soucasne-existence.html?_x_tr_sl=cs&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=wapp
https://meshtastic--czbrno-blogspot-com.translate.goog/2025/02/meshtastic-ja-vybrat-antenu.html?_x_tr_sl=cs&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=wapp
https://meshtastic--czbrno-blogspot-com.translate.goog/2025/02/meshtastic-zakladni-troubleshooting.html?_x_tr_sl=cs&_x_tr_tl=en&_x_tr_hl=cs&_x_tr_pto=wapp

[TyIsI]

Will multi transceiver support be implemented for repeaters/routers so that they can be used to build an LF backbone with MF local presets? Or even local backhaul over MF with SF locals?

Or alternatively, will Meshtastic be supporting mesh IDs so that a mesh can run in parallel and be able to bypass existing meshes with sub-optimally configured presets?

[RealBenAnderson]

You can do this (bypass bad meshes) by leaving your preset the same but setting a different frequency slot.

[Stogas]

@RealBenAnderson What do you recommend for EU_868, where there's only one frequency slot?

[RealBenAnderson]

Set your nodes' rebroadcast modes to LOCAL_ONLY. Then they will only rebroadcast traffic they can decrypt, and any private meshes they don't recognize will be ignored.

[melroy89]

In my area, there aren't a lot of nodes.. So we are still using LongFast on all the nodes. Which is still the best default in this case.