[Phillip Beall (W5EBC)]

All,

Chris McDowra (KI5HSQ) buried a particularly important observation in his excellent recent testing report in our larger Meshtastic for EmComm discussion, and I think it deserves a post of its own.

If you have been experimenting with Meshtastic in the United States, you have probably seen LongFast used as the normal modem preset. LongFast uses a 250 kHz bandwidth and has been extremely popular because it provides a very useful combination of range and data rate.

There is now an important change taking place.

Under FCC Part 15.247, digitally modulated systems operating under these provisions in the 902–928 MHz band are required to have a minimum 6 dB bandwidth of at least 500 kHz. That FCC requirement itself is not new. What is new is that Meshtastic is now addressing the issue directly in its software. The Meshtastic 2.8 release changes newly configured U.S. nodes so that they default to LongTurbo rather than LongFast.

LongTurbo uses the required 500 kHz bandwidth.

That sounds like a simple configuration change until you look at what Chris actually measured here in Lamar County.

Chris installed a RAK4631-based node at approximately 33 feet AGL and then did actual drive testing rather than relying solely on propagation predictions. He ran the same route using both presets and used traceroute, SNR measurements and GPS route recording to compare them.

His result was striking:

LongFast consistently maintained the link from about nine miles away. LongTurbo fell short by almost two miles on the identical route.

That makes the change particularly interesting for those of us trying to develop Meshtastic infrastructure in a rural area. In a dense urban mesh, losing a mile or two may simply mean another node handles the traffic. Out here, where nodes may be separated by several miles, that difference can determine whether two parts of the network can communicate at all.

There is another wrinkle worth knowing about: LongFast and LongTurbo nodes cannot communicate directly with one another. So this isn’t simply one user choosing a slightly different performance setting. A local mesh ultimately needs some coordination regarding which preset everyone intends to use.

A clarification concerning our RRVARC ARDC project is important here.

Our proposed RRVARC Meshtastic project contemplates operation under both FCC Part 15 and amateur-radio Part 97, but they are explicitly being treated as separate networks. Our revised ARDC proposal does not propose bridging, gating or automatically forwarding traffic between the Part 15 network and the Part 97 amateur network.

Where we want both capabilities at the same site, the architecture calls for separate radios configured for their respective services. That distinction became an important part of our revised grant proposal after ARDC raised the regulatory question during its review of our original application.

So Chris’s testing is especially useful to us. It gives us actual local data showing what the Part 15 configuration change may mean for coverage instead of simply theorizing about it from a specification sheet.

If you have not been following the larger discussion, there is a great deal more information, experimentation and member input collected here:

Meshtastic for EmComm on VHF/UHF – Off-Grid Texting Mesh Networks

Chris’s recent field-testing posts are on page 3 of that discussion and are well worth reading in their entirety:

Chris McDowra (KI5HSQ) – Tower/Truck Buildout and Lessons Learned

FCC Part 15.247 information:
FCC – Section 15.247 Digital Modulation Requirements

Meshtastic 2.8 release information:
Meshtastic Firmware Releases

This is precisely why the experimentation going on among Club members is so valuable. Specifications tell us what something should do. Chris got in the truck and found out what it actually does in Lamar County. 😎👍🏼

73

Phillip Beall (W5EBC)

[Author]

Posts