Method for Increasing the Bandwidth to Link Budget Ratio

[Ryu945]

edit: After the discussion, the new conclusions are showed in edit2 . Also improvements to preset options that came out of this conversation mentioned in post below.

Note: I do not know any potential legal pitfalls so please point those out. Also note that this will be a breaking change so it can't come any sooner then version 3.

I ran a calculation of data rate vs link budget to see which methods of increasing the data rate for a given link budget work out the best. I found that reducing bandwidth and keeping Spread Factor (SF) smaller gives more bandwidth for a given link budget. This implies that the best way to maximize data rate for most settings would be to use the smallest bandwidth that every device`s oscillator can handle so that you can use the lowest SF needed to maintain that link budget. Someone I talked to earlier felt that 125 KHz bandwidth can be handled decently well by all devices. Thus the proposed settings would be the following.

DR = Data Rate
LB = Link Budget
BW = Bandwidth
SF = Spread Factor

Old : New

Short Turbo: Short Turbo
BW 500 KHz : BW 250 KHz
DR 21875 : DR 31250
SF 7 : SF 5
LB: 140 : LB 138

Short Fast: Short Fast
BW 250 KHz : BW 125 KHz
DR 10937.5 : DR 15625
SF 7 : SF 5
LB: 143 : LB 141

Short Slow : Short Moderate
BW 250 KHz : BW 125 KHz
DR 6250 : DR 9375
SF 8 : SF 6
LB: 145.5 : LB 143.5

Medium Fast: Short Slow
BW 250 KHz : BW 125 KHz
DR 3515.625 : DR 5468.75
SF 9 : SF 7
LB: 148 : LB 146

Medium Slow: Medium Fast
BW 250 KHz : BW 125 KHz
DR 1953.125: DR 3125
SF 10 : SF 8
LB: 150.5 : LB 148.5

Long Fast: Medium Moderate (This becomes the default channel)
BW 250 KHz : BW 125 KHz
DR 1074.218 : DR 1757.812
SF 11 : SF 9
LB: 153 : LB 151

It doesn't become an apples to apples comparison at this point so I will just list the new configuration. This will replace the existing Long Moderate and Long Slow

Medium Slow
BW 125 KHz
DR 976.562
SF 10
LB 153.5

Long Fast
BW 125 KHz
DR 537.109
SF 11
LB 156

Long Moderate
BW 125 KHz
DR 292.969
SF 12
LB 158.5

Long Slow
BW 125 KHz
DR 183.105
SF 12
LB 158.5
(Only one with Coding Rate of 4/8)

An interesting side effect is the fact that bandwidth is lower, there will likely be less noise issues in the real world so having a 2 dB lower link budget will not be as bad.

Addon Idea:

This is separate but it didn't feel right to separate it from the main idea.

I suspect that some devices have a good enough oscillator that they can use 62. Khz bandwidth. We can make enhanced version of channels. Enhanced channels will use 62 KHz bandwidth instead. This can be used in private networks where you know all devices have an accurate enough oscillator. This will allow better data rate to link budget ratios. It can also allow for a very long range channels without sacrificing to much bandwidth.

https://imgur.com/RN2A1Nd.png

https://imgur.com/4E43Pme.png

edit2:

1. If you have very few channels,this may be a factor in Europe, you can get larger total data throughput since halfing the bandwidth gives you twice as many channels and these smaller channels have the same data rate.

2. If you know what frequency noise is being broadcasted on, you can use smaller channels to avoid the noise and improve the performance at no effect on your data rate. Thus using less bandwidth can either improve range or improve data rate by reducing the noise floor.

3. You have more locations to do link budget vs data rate tradeoffs. Your not limited to every 2.5 dB by adjusting the spread factor. You can have intermediate points by halfing/doubling the bandwidth and using a different spread factor.

4. Change Short Fast to BW 500 KHz, SF 8. Your going to get more data rate for the 0.5 dB loss in the link budget.

https://imgur.com/dIhWHqm.png

edit3:

5. Assuming all devices can use 62.5 KHz, Long Slow can potentially be improved if you make it BW 62.5 KHz, SF 11 and Coding Rate 4/5

The 0.5 dB gain in link budget could be a better trade off then using the a code rate of 4/8. Error rate analysis would have to be done.

The original Long Slow data rate is 183.105 b/s. The new one would be 268.555 b/s . In short, see if dropping the bandwidth is a better tradeoff for Long Slow and Long Moderate then changing the coding rate.

There could even be an extremely long range mode made. It would actually simplify the GUI to have 9 presets anyway.

https://imgur.com/jj2Qkgj.png

[korbinianbauer]

If you don't sweep the 2 dB difference under the carpet and instead compare "old" and "new" presets that actually have a similar link budget, you'll see that the gains in data rate are pretty much exactly what one would expect by trading in 2 dB, independent of channel bandwidth.

Here's the findings from your tables (for the 4/5 coding rate) plotted directly against each other to compare.

In the regions (138+ dB) covered by the presets:
For 125...500 kHz bandwidths, lower bandwidths really don't change things significantly, Sometimes ever so slightly better, sometimes worse. Definitely not enough to warrant a breaking change ever.

According to your data, 62.5 kHz bandwidth would seem to provide significantly better trade-offs for when you optimize for link-budget, but as you said, not all radios can deal with that.

More importantly though, the LoRa Link Budget calculator from Semtech agrees with your values for 125...500 kHz bandwidth, but for 62.5 kHz bandwidth I get 3 dB less link budget, which would put those presets at the same trade-off frontier as the others.

If we zoom out to the whole range of spreading factors, we can see that when optimizing for data rate, higher bandwidths are actually clearly superior.

An interesting side effect is the fact that bandwidth is lower, there will likely be less noise issues in the real world so having a 2 dB lower link budget will not be as bad.

Quite the opposite, the wideband signal is what makes LoRa more resistant to narrowband interference. If just a small part of the channel width is disrupted, the demodulator can still guess the symbol right.

https://www.mokosmart.com/lora-frequency/

What you might refer to is that Noise Power = kTB for the receivers noise floor is proportional to the Bandwidth B, so a lower bandwidth means the receiver experiences a lower noise floor. But this advantage is already included in those Link-Budget figures, it's not an extra factor on top after that.

The argument for narrower bandwidth signals is not that it provides better Data-Rate vs. Link-Budget trade-offs (because that effect is miniscule), it's that you can fit more of those channels in the same slice of the spectrum. If you use the same amount of TX power per channel, the Link-Budget and Data-Rate per channel will stay about the same. Alternatively, you could also keep the wide bandwidth and use more TX power on that.

[Ryu945]

Another thought came to mind.

5. Assuming all devices can use 62.5 KHz, Long Slow can potentially be improved if you make it BW 62.5 KHz, SF 11 and Coding Rate 4/5

The 0.5 dB gain in link budget could be a better trade off then using the a code rate of 4/8. Error rate analysis would have to be done.

The original Long Slow data rate is 183.105 b/s. The new one would be 268.555 b/s . In short, see if dropping the bandwidth is a better tradeoff for Long Slow and Long Moderate then changing the coding rate.

There could even be an extremely long range mode made. It would actually simplify the GUI to have 9 presets anyway.

https://imgur.com/jj2Qkgj.png

[korbinianbauer]

The 0.5 dB gain in link budget could be a better trade off then using the a code rate of 4/8. Error rate analysis would have to be done.

Not worth testing.
Different coding rates are inter-operable, changing BW and SF on the other hand is a breaking change.

[Ryu945]

The 0.5 dB gain in link budget could be a better trade off then using the a code rate of 4/8. Error rate analysis would have to be done.

Not worth testing. Different coding rates are inter-operable, changing BW and SF on the other hand is a breaking change.

Devices can handle receiving packets at 4/5 and 4/8 at the same time?

Also, I guess it might be something to consider for version 3 then.

[korbinianbauer]

Devices can handle receiving packets at 4/5 and 4/8 at the same time?

Yes, because Meshtastic uses LoRa in explicit header mode, which contains information about the CR

might be something to consider for version 3 then.

Still don't see why it would be worth considering at all

[Ryu945]

Still don't see why it would be worth considering at all

The idea for the longer range change is to optimize every parameter. If reducing the bandwidth can achieve greater data rate at the same range then it is worth changing the longer range preset to be 4/5 and using smaller bandwidth. Mathematically, a 4/5 to 4/8 Coding Rate change is nothing more then reducing the data rate all the time to try to reduce the number of packets that have to be retransmitted. This can be calculated into an effective data rate.

The idea for changing Short Fast to 500 KHz bandwidth is because the graphs shows in that region, all bandwidths do not perform the same. 500 KHz doesn't have the same link budget to data rate tradeoff. It has a faster data rate. Though, I did calculate it scales only 3% better but that is 3% on top of the normal data rate to link budget tradeoff.

I put what I think the new scale should be in my other post. I also think a noise avoidance setting would also be useful so I put that in as the second part of the other post.

[Ryu945]

One possible naming scheme setup is to use two drop down menus. Short, Medium and Long and Fast, Moderate, Slow.

old:new

Short Turbo : Short Fast

It will use the same configuration it has now. In regions that don't have 500 KHz channels, it will instead have:

BW 250 KHz
SF 6

It stays the same in regions that do have it 500 KHz channels. Just the name is changing

Short Fast : Short Moderate
In regions with 500 KHz channels:
BW 500 KHz
SF 8
LB 142.5 dB
BW 12.5 Kb

In regions without 500 KHz channels, it is just a a name change.

Short Slow : Short Slow (nothing changes)

Medium Fast : Medium Fast (nothing changes)

Medium Slow: Medium Moderate ( name change)

Long Fast : Medium Slow (name change) [New Default Channel]

Long Moderate : Long Fast
In all regions:
CR 4/8 : CR 4/5
BW 125 KHz : BW 125 KHz
DR 335.693 : DR 537.109
SF 11 : SF 11
LB 156 dB : LB 156 dB

Long Slow : Long Moderate
CR 4/8 : CR 4/5
BW 125 KHz : 62.5 KHz
DR 183.105 : 268.555
SF 11 : SF 11
LB 158.5 : LB 159

New Long Slow
CR 4/8
BW 62.5 KHz
SF 12
LB 161.5
DR 91.553

Two drop down menus of three items will make it easier to set. Max range goes further.

Part II: Noise Avoidance Setting will let you drop down your bandwidth. SF will be updated appropiately. 500 KHz channels can be set to 0, 1, 2 or 3. 250 KHz channels can be set to 0, 1 or 2. 125 KHz channels can be set to 0 or 1 . When you take it off zero, the radio channel setting will now have many more possible channel values. The channel you set will determine where you are moving your smaller bandwidth to avoid some rather large environmental noise. In fact, the only purpose of this feature is to avoid environmental noise. Since this is an addon feature, you can actually implement it in Meshtastic version 2.X as it doesn't need to be backwards compatible. As of right now, people are just manually setting their radio channel, SF, Bandwidth to achieve this anyway.