2.4GHz: allow excluding specific wifi channels from fhss hopping list

[olliw42]

title says it

@jlpoltrack do you think this is ready to be merged?

it is a potentially breaking change

[jlpoltrack]

Haven't done any flying with this branch but tested alright for me on the bench. I think okay to merge.

[olliw42]

do you think you would have a chance to fly in the next days?

Edit: I try to coordinate the possible merging of this with the "remove spektrum rc scaling", since both are breaking and do a break only once sounds better than twice :D

Edit II: did you see the anticipated effect, i.e., that excluding the wifi channel of desire did reduce interference?

[jlpoltrack]

do you think you would have a chance to fly in the next days?

I will put in some time today and let you know if I see anything out of the norm.

Edit II: did you see the anticipated effect, i.e., that excluding the wifi channel of desire did reduce interference?

Hard to see any difference on the bench since I use E28 (not bare SX128x) so can't state anything here.

[jlpoltrack]

@olliw42 Any consideration to also expand frequency list to the same as ELRS (with 80 channels) since this would also be breaking?

I see this note in Design Decisions (https://github.com/olliw42/mLRS/blob/main/mLRS/Common/design_decissions.h#L68) but in US, 2.4 is allowed to be used up to 2.4835 GHz.

https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15/subpart-C/subject-group-ECFR2f2e5828339709e/section-15.247#p-15.247(a)(2)

[olliw42]

hm, interesting I did spend some time on the matter at the time I did it, but I must say that I can't fully understand my cocnlusions

I think the 2.473 limit for the US I inferred from the wifi usage as described on e.g. wikipedia. The 2.406 limit I can't understand anymore. Shouldn't this then actually be few more than 80 channels?

hmhmhm

[jlpoltrack]

Shouldn't this then actually be few more than 80 channels?

Could have 83 channels (2400.4 to 2482.4 MHz) not sure why ELRS stops at 2479.4 (2480 MHz accounting for 800 KHz LoRa bandwidth). Suggested because I saw some comments in the ortho code about number of channels.

[olliw42]

well, if my choice of the 68 channels happens to have been ill informed we may want to change it irrespective of other points :) I'm just a bit confused currently there the 2.406 comes from ... I mean, I do not tend to pull shuch things out of air

and if you say US doesn't stop at 2.473 we should use it

[jlpoltrack]

I couldn't understand the 2.406 either :). Let me know If you want to handle/think about further or I could submit a PR.

[olliw42]

let me think a bit more about it :)

[jlpoltrack]

Did about 30 minutes of flying with this branch + 'mlrs.4' as bind phrase to exclude channel 13. Nothing of note to share, seemed the same as my custom fhss.h which did the same thing.

[olliw42]

MANY THX !!!!

Q: you also like the concept of using the last char of the bindphrase to select? I initially had an extra parameter, but somehow didn't liked it...

[olliw42]

concerning the freq range: it seems that france and spain e.g. allow smaller bands only: https://www.itwissen.info/ISM-Band-industrial-scientific-and-medical-WLAN-ISM.html (not sure how competent that source is LOL) https://www.ipen.br/biblioteca/cd/ieee/1999/Proceed/00640.pdf still not sure where this 2.406 comes from LOL

[jlpoltrack]

Q: you also like the concept of using the last char of the bindphrase to select? I initially had an extra parameter, but somehow didn't liked it...

Yes, this works for me, especially as the Lua directly shows its impact.

[olliw42]

great so I'm going to merge later thx for your testing and evaluation

[olliw42]

@jlpoltrack concerning the 2.4ghz freq range. I'm a bit unsure what to do now. One hand, I'm kind in a "never change a running system" mode, on the other hand I'm in "why not, more freq sure sound better".

I guess we talk about adding channels 2.401-2.405 and 2.474-2.482, right. (I would not add 2.483 to stay away a bit better from that critical band starting at 2.4835), which would make it in total 82 channels.

I'm still puzzled at what I did at that time, I just remember that I spend quite some time at this, but I somehow seem to have come up with starnge conclusions. It seems there is really no reason to not include 2.401-2.405. Concerning 2.474-2.482 there seems to be this "don't use in wifi" regulation in the US, so it is maybe more questionable,

I'm also wondering about whether one should match the freq exactly with ELRS to minimize intereference with ELRS, i.e. do this 0.4 MHz shift too, but on the other hand other systems will do whatever they do anyway, so I actually tend to stick with the current alignment.

?

btw: it wouldn't really help very much with the ortho&except limitation you refered to in the above, if that was the main motivation

[jlpoltrack]

It seems there is really no reason to not include 2.401-2.405. Concerning 2.474-2.482 there seems to be this "don't use in wifi" regulation in the US, so it is maybe more questionable,

The WiFi regulation is different than this situation because WiFi is a 20 MHz wide channel and out of band emissions can cause interference above the 2483.5 MHz limit (at least that's how I read this):

The LoRa spectrum that is used is 'only' 800 KHz wide, so am thinking should be okay to get closer to 2483.5 MHz.

I'm also wondering about whether one should match the freq exactly with ELRS to minimize intereference with ELRS, i.e. do this 0.4 MHz shift too, but on the other hand other systems will do whatever they do anyway, so I actually tend to stick with the current alignment.

My guess is that the 0.4 MHz offset is to account for the 800 KHz bandwidth and still be okay on the lowest channel, e.g. 2400.4 would use the range 2400.0 to 2400.8 MHz.

2401 to 2482 makes sense to me and also has the benefit of providing 1 MHz of sideband buffer.

[olliw42]

So, the argument is, we assume LORA doesn't produce out-of band emissions, even not at levels of -30 dB or lower, so that moving close to the edge isn't a problem, right? 2401 to 2482 does make sense to me too. But, is there actually a real-world benefit we can expect from extending from 68 to 82 channels ... I mean, theoretically it is clear, but in real world what do we actually gain. Is it just about we can do it or to feel better. I would wish there would be an expert in both legislation and LORA off band emissions who just would tell us what to do LOL ...

[jlpoltrack]

So, the argument is, we assume LORA doesn't produce out-of band emissions, even not at levels of -30 dB or lower, so that moving close to the edge isn't a problem, right?

I can guess that maybe ELRS plays it safe and has the cutoff at ~2480 to avoid interfering in the higher range. Here's an image of how the LoRa bandwidth drops off (although this is for SX127x or SX126x):

But, is there actually a real-world benefit we can expect from extending from 68 to 82 channels ... I mean, theoretically it is clear, but in real world what do we actually gain. Is it just about we can do it or to feel better.

Since mLRS only uses 12-24 channels on 2.4, more channels should mean a better chance that an unlucky one with interference is not sleected. Selfishly for me, my antennas are tuned better towards the low end, so would want to use those frequencies (I exclude Channel 13 range as I use that for WiFi bridge).

[olliw42]

this was my thought too that maybe not going up to 2482 but just 2480, for a somewhat larger saftey marging

more channels should mean a better chance that an unlucky one with interference is not sleected.

yeah, that's the "theoretically it is clear" part of my text :D:D

I was wondering if there will be a single case there a user will really see a benefit, and be it only minor (but significant, like in statistically significant)

I'm so hesitant because we use that 68 channels since 2 years now with no real indication of an issue (I'm sometimes a bit this nevefr-change-a-running-system-unless-there-is-a-good-reason guy)

I'm trying to find this kick-ass argument for why we need to do this LOL

[jlpoltrack]

Okay with me to keep current situation if that's preferred, just figured the recent breaking changes would offer a time for consideration on the topic :).

Perhaps I can do some testing and submit a PR for consideration at a later date...

[olliw42]

ha ... I guess I found that kick-my-but argument LOL stumbled across this document https://www.ti.com/lit/an/swra670a/swra670a.pdf?ts=1688394332688&ref_url=https%253A%252F%252Fwww.google.com%252F it says on page 14 for FHSS that they must spread over >90% of the assigned frequency band, but the current 68 channels cover only 82% so our fhss never ever can fullfill that :) not that I would be so much concerned, but it implies that its better to really spread widely I'll make it 80 channels, from 2401 to 2480 :)

[olliw42]

except wifi channels done with commit https://github.com/olliw42/mLRS/commit/5194bba3c588a61164050bb685549db46140247e frequency range extended to 80 channels done in commit https://github.com/olliw42/mLRS/commit/c23e8af66c66237697d2a9e842d78f1b516deaf3 all done, thus closing

MANY THX again for teh discussion and testing etc. pp!