Added EdgeFastLow-settings for modem

[tekomula]

I've added EdgeFastLow -settings for LoRa-modem (BW 62, SF 8, CR 8). Cross-checked the new setting between different points/files in firmware, web and Android-application. Added to different language translations, too.

More info here: https://www.meshhubmids.com/edge.html

[petrisi]

Thanks for doing the work. In our area we are 100% EFL and surrounding areas are switching gradually as well. Having these settings available as a preset makes new user onboarding so much easier and helps discover other Meshers.

We had to move because of the meshnet usage in electric meters is growing and they are practically reserving the whole 869.525 to their usage only. Only super short messages can survive.

We did a coordinated change which was relatively easy to do, since the mesh in this area was relatively new.

So far we have not experienced any issues because of these settings, at least not during usage. Something we discovered was that the interfaces (apps, web ui, cli etc.) were not 100% ready for configuring these custom settings. iOS app was especially problematic, not accepting coding rate 8, but luckily cr7 is compatible. (This is understandable because custom settings is not one of the primary use cases and there are so many interfaces in the project.)

The waterflow below is 5-10min. Yellow "bar" is Aidon electronic meters. One meter or even 10 is not a problem, but when you have hundreds or thousands and they send using maximum allowed power it becomes problem fast. It can be seen as long hops not being possible to destinations where meters are present and super short and unreliable hops in urban areas.

[NomDeTom]

Hi, thanks for the submission. I have a similar setup already drafted out, but it's slightly different - we believe guard bands are needed to maintain compliance.

I'll try to find some time to finish the steps needed. Feel free to tag me on the discord, and we can have a chat about it.

[tekomula]

Hi, thanks for the submission. I have a similar setup already drafted out, but it's slightly different - we believe guard bands are needed to maintain compliance.

I'll try to find some time to finish the steps needed. Feel free to tag me on the discord, and we can have a chat about it.

Hi, and thanks for your message. Referring to standards "EN 300 220" and "ERC/REC/70-03" there are no separate guard bands defined between different channels. The only definition is maximum bandwidth 250 kHz for one carrier which operates on 869.400-869.650MHz frequency range. So comparing together a full 250kHz wide signal on middle frequency 869.525MHz and a 62.5 kHz signal on middle frequency 869.43125MHz there is no difference in legal band usage - both of those reach clearly the lower limit of that range to 869.400MHz and that's it. So there is absolutely no problem with EdgeFastLow -mode from legal view.

Since EdgeFastLow is already widely used here in Finland (and AFAIK in many other countries too) this is a great feature to include to Meshtastic firmware to ease it's configuration into action. Since it drastically improves communication in areas which has a lot of traffic in 869MHz band it is a great alternative for ie. LongFast which is also used quite much.

Please note also my other pull requests related to this - device-UI, Android, protobufs and web which all have now EdgeFastLow added to mode list.

Best,
Teemu 🙂

[phaseloop]

You may be interested in this: #8681

If you look at band 47b in EU directive, there is a bunch of free frequencies with 500 mW limit that may hold various modes using less than 125-150 kHz of bandwidth.

Caveat is duty cycle and it's worth having discussion about having "fixed node" delegation setting.

As for APC requirement this also seams feasible to achieve - I also strongly suspect that current meshtastic carrier access control sensing may meet APC "equivalent solution".

[NomDeTom]

@tekomula

So there is absolutely no problem with EdgeFastLow -mode from legal view.

I don't really want to get into the weeds of what the standard requires, but the draft that we put together a couple of weeks ago included using spacings, and only provided 3 slots in the 869 band. This is to avoid bad frequency correction ending up outside of the existing band. There are reasons for this.

For similar reasons, we need to limit selection of this preset to the EU region only, as the US has a different set of regulations regarding narrow band communication. This was the major stumbling block - this limitation needs to be kept within the firmware rather than injecting it into all of the clients, and expecting them to guard against unwanted combinations of regional presets.

Looking at the above, you can start to see why I had to put it down for a bit. If you're still interested in pursuing this rather than experimenting with the PR pointed out by @phaseloop then maybe we can have a discussion on Discord (or here!) about how to combine the work done so far.

I appreciate the need to make more options available, and I also appreciate the time you've put into this PR. However, there's a lot of work ahead of us to deliver this smoothly.

[oherrala]

@NomDeTom Is your draft available somewhere?

This EdgeFastLow based network is building really fast. People seem to be adapting it (e.g. most of Finland seem to be switching now). Having two different implementations competing is not productive.

And the current situation with everyone manually setting the radio and channel parameters is huge PITA.

[tekomula]

This EdgeFastLow based network is building really fast. People seem to be adapting it (e.g. most of Finland seem to be switching now). Having two different implementations competing is not productive.

@NomDeTom @phaseloop - Gotta agree with @oherrala that this EdgeFastLow is - already - in very wide use and it does not make sense to implement yet-another competing system in use albeit there is no doubt could there be techically good and well-working alternatives too. EFL is not invented by me. The idea is just make presets available to firmware/UI so everyone doesn't have to make manual configuration over BT/web to every device separately.

[phaseloop]

@tekomula - I personally don't have any preference or comment about modulation choices but I'm all for for spending some work and unlocking new free frequencies to be legally used by Meshtastic instead of cramming whole Europe on small 200 kHz wide band along with rest of thousands of different products and smart toasters living in that space.

Whole 47b section is reserved for data networks - we can't get any better and clean band than that. EFL seems to fit pretty well to that band regulations.

[j0uni]

Here is another view on the spectrum here in Finland. This has been captured inside house, the situation outside is far far more worse - the .525 is basically continously showing Aidon meters and some LoraWan too.

The upper part 62.5kHz transmission is Meshcore with the most popular mode in Europe. This is probably the reason why people have started switching to Meshcore as it provides a working radio configuration out of the box that works more reliably partly because of this - Meshtastic should copy this concept ASAP I think.

[phaseloop]

Make sense, I suppose once Meshcore will gain more popularity they will start seeing same problems that made people leave Meshtastic and go there 🤷

You can't fight broadcast domain theory and low bandwidth will get you only so far. So in few years they only solution is to have nodes on different frequencies and and have some higher level routing layer spanning multiple channels.

[NomDeTom]

@tekomula @petrisi @oherrala @j0uni do you have time later today to discuss this on discord? I'd like to run through this in a quicker forum.

[tekomula]

@tekomula @petrisi @oherrala @j0uni do you have time later today to discuss this on discord? I'd like to run through this in a quicker forum.

@NomDeTom Unfortunately busy the whole weekend (and not using Discord atm but maybe temporarily installable). How about others?

[j0uni]

I'm neither on Discord.

Did the PR got merged to development?