It is a mistake to expect that today the Meshtastic network could be used as a regular communicator, which we know from our phones. In fact, in 99% of cases, it is still a user-hidden transmission of telemetry, location sharing and information about nearby nodes. Only a negligible fraction (per thousand) of packets are messages between users. From this perspective, the network appears “silent” most of the time. Do not expect to receive dozens of messages a day – some days not a single one appears. However, the network nodes still communicate with each other intensively – in many cases (due to inappropriate settings) disproportionately much, without any apparent benefit, to the detriment of the reliability of communication – i.e. message delivery.
Please note that in the following text I do not wish to question the possibility that some areas could not freely choose to operate MF or LF. This is an indisputable free choice of users in given locations and I would never dare to question it. The only thing I will argue about here is the fact that the decision whether to use MF or LF could have been made on the basis of erroneous assumptions.
So – it doesn’t work, it doesn’t work… it’s switched to MEDIUM-FAST
In the time I’ve been following Meshtastic and trying to find out from the main proponents of MF what problems such a transition from LF was supposed to solve, I’ve only encountered two problems: The first was the network breakdown due to moving nodes , the second was the low reliability of the network itself . After that, nothing more, and if you know of other problems, please tell me about them.
Couldn’t it be like this?
Could it be that the transition to MF was an ill-advised step due to ignorance of the problems? Or was it a step simply due to unfulfilled expectations, based on the idea of how similar networks work on the Internet? Could it all have gotten so complicated that today there are even voices calling for a transition to SF?
How is it today?
There is still no credible justification for switching to MF. Network reliability is still in the background – exactly like identifying the real advantages of MF. Let alone taking into account the indisputable limits of MF compared to LF. If the reliability of the network has changed in more than a year, it would certainly be useful to know the success rate of message delivery. If you have come across any current tests or updates, I would be happy to take a look at them. This is the result of a survey one year ago , when MF traffic began to be promoted in various parts of the Czech Republic. Today, of course, the result would not be so poor. I described the situation in experiences after one year . It seems that today’s situation of node density, at which the network begins to function across the board, is already captured there . However, this is only the LF network (Brno). The MF network has yet to find its minimum density, so logically it is waiting for significantly higher numbers of users.
How will we address the consequences of network fragmentation?
If you are an orthodox supporter of the MF, it is completely unnecessary for you to read further. This also applies to you, who are satisfied with the fact-free community “noise” on online channels. On the other hand, for others, if you are interested in the broader context of this issue, the summary may be useful for forming your own opinion.
Differences between MediumFast (MF) and LongFast (LF) modes
First of all, it is necessary to understand the differences between the MF and LF profiles. Both of these profiles have been “tuned” in advance by the developers. They represent, compared to experimenting with LoRa parameters, a significant convenience for the user. This means that for each profile (MF, LF, SF) an optimal mix of LoRa parameters has been selected, which sets the internal radio module for sending and receiving messages. The key LoRa parameters are:
Bandwidth: Set to 250 kHz in both modes.
Spreading factor (SF): Indicates the number of possible symbols used for transmission.
LF: Spreading factor 11 (longer range, but lower transmission speed).
MF: Spreading factor 9 (higher transmission speed, but lower range).
Coding rate: The ratio of redundant data used to correct errors during transmission. In both modes, it is set to 4/5. Redundancy helps with reliability but increases message sending times.
The LoRa parameters used in MF mode cause the packet to be sent in a significantly shorter time (about 3.5x faster ) than in LF mode (see figure below). At the same time, MF has a 5 dB lower Link Budget as a result , which is about 3x worse than under the same conditions for LF (in terms of signal strength and quality, not distance as is often mistakenly assumed). In a simplified view, this means that in MF mode you have less time to transmit the same information and at the same time you need better conditions to maintain the same level of transmission reliability as in LF.
However, it is fair to acknowledge to the proponents of MF mode that shorter packets allow more data to be transferred over the same amount of time. Messages are therefore sent in a shorter time at the cost of transmission reliability that decreases more rapidly with distance. This means that compared to LF mode, you will need more HOPs (nodes between the sender and the receiver). With a similar density of nodes, there will necessarily be fewer alternative paths (if any) to the receiver. If today 75% of messages go directly, with one HOP it will be about 60% of messages, and with two HOPs only 40%, then 30%, 20%, 17%, 13%, 8% (yes, with HOP = 7 the delivery reliability is a meager 8%) . The increased number of HOPs needed is a direct consequence of choosing MF. It always applies: a higher number of HOPs always means a sharp decrease in message delivery reliability. The same math (75/60/40…) also applies to LF, but it allows for direct connections over longer distances and thus does not require the same density of nodes in the vicinity (so many HOPs) as MF. LF can logically achieve connections with fewer HOPs at the same distance between non-adjacent nodes.
PS: I want to mention that I personally tried MF in Zlín and of course I know that it can still work.
Consequence for the user:
If you use the same antenna and the same device, simply changing the configuration to MF mode will significantly reduce the reliability of the transmission. Both on the “direct” connection and in the network itself when connecting between nodes. This is due to higher demands on the quality and conditions of the transmission, as well as significantly higher requirements on the density of the surrounding nodes in your area. This change therefore paradoxically worsens the situation in terms of the reliability of message delivery on your device.
No discussion – it makes it worse!
MF, assuming that you require network functionality and want to send messages reliably and not just see a node 5km away (which, however, you will not receive a response from it anyway when you send a message), is intended for operating a network in smaller areas! LF, it seems, according to the situation in Brno, is only starting to fulfill its function at a density starting at 1 node/10km2 and from the derived average node distance of ~2km (even if the condition of direct visibility between nodes is not met ) . What expectations can be had in this comparison in the case of MF? It has been proven that in several one-time experiments of switching to MF, nodes repeatedly failed to set up a network under the same conditions . Even some direct connections in many cases could not be implemented on MF (such nodes remained isolated from others).
If a device is to be a stable part of a mesh network, long-term personal observation at LF shows that the following conditions must be met:
At least 20 active and communicating nodes in the vicinity (verifiable, for example, by a NodeDB deletion test).
At least 3 nodes with direct connection (RSSI > -110 dBm, SNR > -4 dB).
These two conditions are likely to apply to both LF and MF networks in general . When they are met, the network seems to start to “somehow” work. The typical distance between LF nodes was 1.5 to 4 km , which in the case of node density corresponds to a value of, say, 1 node per 10 km² (according to map data, without direct visibility).
I base my statement on experience from the Brno-city area, where it was only with the increase in users at the end of 2025-02 that it was possible to observe that the network was only starting to function in LF mode. At the same time, it is evident that the number of HOPs more than 3 is the technical limit of the network, still having at least somewhat acceptable message delivery reliability.
Sufficient node density (the first and basic condition for the creation of a functional network) was achieved only after more than a year. For more details about the area – I refer to ” Situation in Brno “. If you project this reality into the MF, a much higher node density will be needed. It will also be necessary to work on the reliability of HOPs (i.e. remove/increase the 75/60/40 factor). And even so, the MF network will always be able to operate in a smaller rather than a larger geographical area until more intelligent routing is enabled.
So how can we understand that in some areas MF “runs” perfectly for tens of kilometers? The answer is: distinguish whether “runs” only means that such a remote node is loaded into NodeDB (see the phenomenon of “DX-Meshing” below), or whether it is actually possible to communicate with the remote node (a response is also received for the messages sent). The observed reality will give you the answer itself. A loaded node in NodeDB does not mean that it is possible to communicate with it at all . Try how many times a traceroute request is returned to you, how many responses are received back. Only then can we judge whether the network is really “running” and how reliable it is. A network where less than 50 percent of messages are returned cannot be a network for communication. However, there is still DX-Meshing, which is still “in play” even under such miserable conditions.
Moving Nodes: A Fallacious Argument About Network Impact
Often, when justifying the transition to MF, the claim that moving nodes negatively affect the stability of the Meshtastic network was made. However, based on my experience and experiments, I do not consider this argument to be justified. I usually travel around the JM by car and I do not notice any difference – quite the opposite. Outgoing messages should even be more reliable, since the device sends each message up to three times. By sending it while moving in the car from three different locations, the probability that at least one of these locations will have suitable conditions for sending increases.
Why moving nodes cannot “bring down” the network:
The Meshtastic network does not distinguish between packets transmitted from stationary and moving nodes. They are all processed in the same way.
If you share your location, and in addition, for example, you also use the Range module and send your position periodically, you will increase the load on the transmission channel (higher utilization), but even this increase is not significant enough to cause a network “collapse”.
When driving a car, keep the magnet outside on the hood or roof. Behind the front window, even with a good view, the signal will be significantly attenuated. This is enough for GPS reception, but definitely not for communication in the Meshtastic network! Placing the device inside on the dashboard compared to the hood means an approximate attenuation of -4 dB, so the signal is up to 2.5 times weaker inside. However, for about 200 CZK you can buy a magnet and place it on the roof, which will easily give you +10 dB, or 10 times better signal. A similar improvement can be achieved at home – just attach the magnet to an outdoor window sill.
Comparing MF vs. LF Operation: Why It’s Not Easy
Unfortunately, a truly relevant and definitive comparison of the advantages of operating in MediumFast (MF) and LongFast (LF) modes will not be easy. We will probably continue to argue about what is better and what is worse. At least until both networks operate side by side in the same location. Only then will an objective comparison be possible. However, I am afraid that we will pay for the fragmentation of the networks forever.
Regional differences in the operation of MF and LF: A possible path to coexistence of both regimes
Under normal conditions, establishing simultaneous operation of MF and LF in one location and on the same frequency is counterproductive. Both MF and LF packets are transmitted in the same frequency band. This necessarily causes mutual collisions. These collisions in principle further reduce the overall reliability of both networks. Please be aware, whoever is already doing this, that you are torpedoing an already functioning network with collisions.
IF POSSIBLE – LET’S AVOID SIMULTANEOUS OPERATION
OF MF AND LF ON THE SAME FREQUENCY
Possible solution for coexistence of both regimes – HYPOTHETICAL
One option could be to move the alternative (second) network to a higher frequency so that they do not overlap. In both cases (MF and LF) the bandwidth is 250 kHz, with the default center of the band being 869.525 MHz (not the “paper” 868 MHz). So if there are communities in some locations with a preference for both LF and MF modes, these two networks can be operated separately, right next to each other. The alternative network (the second one prevailing in the given location) could be moved to at least 869.775 MHz (due to the +250kHz bandwidth).
However, the use of alternative frequencies has its limitations. Stricter conditions must be met. It is essential to keep the airtime usage to only 0.1% (compared to the standard 10%) and reduce the transmission power to 25mW (14dBm – TX parameter=14).
So, if you are looking for alternative (parallel and collision-free) connection paths, whether in the form of a local micronetwork or in the form of a by-pass (HOP=0) directional connection with direct visibility to the other side of the city or a distant hill (lower transmission power and even more limited airtime do not represent any significant limits in such cases), this is an easily implementable and elegant solution for you.
Example 1: You are in an area where everyone uses MF and communicates on the primary network they have chosen there ( MediumFast with a frequency of 869.525 MHz ). If you want to test LF there alternatively , select LongFast and change the frequency to 869.775 MHz .
Example 2: You are in Brno, or in an area where most users use LF ( LongFast with frequency 869.525 MHz). If you want to test MF alternatively , select MediumFast and change the frequency to 869.775 MHz .
Important note about the antenna: The same antenna you are already using will work equally well for both MF and LF , even on frequencies 869.525 MHz and 869.775 MHz . No one has such a closely tuned and precisely tuned antenna. If anyone claims otherwise… they are lying. And if there were such a person, they certainly would not need to read this paragraph.
The DX-Meshing Phenomenon
The effort to achieve the most distant connections in the Meshtastic network, similar to DXers in the amateur radio world, could be called DX-Meshing. While the original idea of Meshtastic was to create a reliable local network that would work even if the usual infrastructure fails, reality shows that a significant part of users focus on maximizing range rather than optimizing the density and robustness of the network in the immediate vicinity. NodeDB is already a small file cabinet for QSL cards. 🙂
The phenomenon of connecting large areas
There are often efforts or expectations that Meshtastic networks could connect larger areas, such as Hodonín, Zlín, Přerov and other cities. However, it is important to emphasize that this goes directly against the principle of the network and what we are dealing with now! Meshtastic network is designed for communication in small areas. LF for the area of a city, several villages (<30km), MF for the campus area (<3km) and SF to the office or when you go paintballing (<300 m). A high number of nodes and the associated overhead load on the network will inevitably lead to its overload. The result would be that the network would not be able to perform even basic functions, even those that it already performs now.
Connecting over long distances and breaking records is the domain of other amateur radio groups. Try, experiment, but please, after testing the device either turn it off or set it to the recommended configuration to contribute to the reliability of communication in the vicinity. LET’S NOT LOAD THE AIR WITH TRANSMISSIONS FROM DISTANT NODES THAT NO ONE IN THE LOCATION NEEDS. This only harms local networks!
Meshtastic is currently in its development phase primarily as a local MESH network that requires reliable interconnection of nearby nodes . We have to wait for the possibility of reliable integration of remote networks. It will be necessary to either natively incorporate this option into the communication protocol, or create a specific part of the infrastructure for these purposes (see below). For example, improvements to “next-hop” or similar mechanisms look very promising, which could improve routing and eliminate some of the overhead in the near future (however, this typically concerns messages sent directly to specific users from the list). However, this will not eliminate unnecessary ballast in the form of redundant telemetry, nodeinfo, etc.
Alternative for experimenters
I’m happy to share the code and results that I’ve been working on in this area but haven’t finished. Using the Wireless Stick V3, all captured traffic (packets) is also broadcast unidirectionally to MF . What exactly is happening in the air is best observed using SDR . After the packet arrives, the device changes the spreading factor to MF and broadcasts it there. Immediately after that, it switches back to LF and waits for the next packet. I would like to warn you in advance that you need to know how to compile your own firmware and use PlatformIO SDK or GitLab . Even though it’s functional, it’s just a demonstrator for now – details still need to be worked out to make it usable in real operation ( especially the configuration that is now hard-wired in the code ). So no click configuration yet . 🙂 A sample of an attempt at LF → MF bridge looks like this (see below). The WS Stick board has a pigtail connector for the antenna , so the wire that is currently performing its function can of course be replaced with a proper antenna.
Leave a Reply