[Feature Request]: LongModTurbo Preset

[kboxlabs]

Platform

Cross-Platform

Description

New LongModTurbo Radio Preset:

• Bandwidth = 500 kHz
• Spread Factor = 11
• Coding Rate = 8
• Frequency = 902.6875 MHz (or close to 902 as possible)

As various meshes are moving to different presets do distance themselves from saturated default LongFast traffic the 2 logical directions are MediumSlow (faster but lower SF) and LongModerate (more reliable but slower and increased airtime).

I’m proposing that those regions with the option have a new preset to choose from to leverage 500kHz bandwidth. I’m nicknaming it LongModTurbo because it’s essentially Long Range / Moderate settings with the bandwidth cranked up but call it whatever 🤣

Since 500kHz is only limited to certain regions, make the preset only available depending on set region.

While people can override presets, this makes it a lot simpler for less savvy folk to change mesh radio settings and join a new mesh. The setting proposed offer the following benefits:

• 33% increase in speed over LongFast reducing airtime.
• Same spread factor of LongFast/LongModerate for larger geographically spread-out meshes.
• Higher Coding Rate for longer/noisier links
• this speed has the option to be a 100% (double) increase (over default LongFast) if variable CR is introduced letting people start with higher reliability, and increasing speed if needed.
• A frequency that is far from the noisy 915mHz centre, but close enough to 906.875 that antennas tuned for LongFast won’t suffer a big hit.
• From limited testing, a side benefit seems to be reduced hops, as the more resilient paths means smart flooding isn’t forced to take less efficient routes
• A way to move from LongFast without making any sacrifices (with the exception of a slightly reduce Link Budget)

EDIT:
Since the default Frequency is calculated using the hash of the name, I propose the following.

Preset Name = ModFast
Calculated Frequency = 902.375
Frequency Slot = 3

Created an online calculator using the Meshtastic algorithm for hashing the preset name to frequency and channel slot:
https://meshradiocalc.yycmesh.com/

[Deuteranomalous1]

LongFaster?

[kboxlabs]

LongFaster?

https://youtu.be/gAjR4_CbPpQ

[korbinianbauer]

I propose the following.

Preset Name = ModFast

That would break the scheme that suggests Range+Speed and it's also very close to MedFast.

"Long Faster" and "Long Turbo" would compute.

"Long Turbo" would especially make sense if #8114 adaptive coding rate gets implemented, because then there's no reason to save "Turbo" for another potential preset that uses CR 4/5 and BW 500 kHz.

[kboxlabs]

I propose the following.

Preset Name = ModFast

That would break the scheme that suggests Range+Speed and it's also very close to MedFast.

"Long Faster" and "Long Turbo" would compute.

"Long Turbo" would especially make sense if #8114 adaptive coding rate gets implemented, because then there's no reason to save "Turbo" for another potential preset that uses CR 4/5 and BW 500 kHz.

What calculations are you using for those? I've tried different variations and the hash algorithm seems to put them all above 913 MHz except for one at 908 Mhz range. Other ones that do work and are 10 characters or less:

LongFast_X = Slot 0 = 902.000 MHz
LongModXX = Slot 11 = 903.375 MHz

Calculation should be:
(CRC32 of name) % 208 = S
902 + (S x 0.125) = F

EDIT:
Whipped up an online calculator
https://meshradiocalc.yycmesh.com/

[mrpatrick1991]

Just confirming some anecdotal evidence I saw last night. We have two RAK 4731 nodes with a clear line of sight. They communicate perfectly on LongFast, and the simulated link budget shows at least 10 dB of margin.

Switching to MediumSlow results in most packets being lost (communication in both directions is intermittent). This applies for traceroutes and direct messages.

The 2.5 dB sensitivity difference between the presets does not explain the behaviour.

So I'm thinking we could use a controlled experiment (fixed distance, clear LOS, across presets and many packets) in a real-world deployment to figure out why this occurs.

If anyone has ideas that might explain this I'd be very interested.

[kboxlabs]

Calculate the results of different preset names here:

https://meshradiocalc.yycmesh.com/

[korbinianbauer]

@mrpatrick1991 That seems like an issue that should be discussed entirely separate from this one here.

@kboxlabs gives a 404 for me

[mrpatrick1991]

@korbinianbauer agreed. I'll make a discussion (not necessarily an issue) when I have experimental data to base that off of.

I mentioned it here since it was the upstream cause for exploring @kboxlabs new presets (we work together on our local mesh in Calgary).