Correct EU868 Coding Rate (4/7->4/5)

[nmaas87]

EU868 Coding Rate is not allowed to be 4/7, it is in truth 4/5 (see https://forum.chirpstack.io/t/error-unknown-data-rate-on-eu868-with-coding-rate-4-7/16109). Current Chirpstack 4.x actually throws away EU868 packets with 4/7 coding rate and will not even display them.

Solves one of the issues seen in #864

[jgromes]

@nmaas87 where is this information coming from? Try as I might I can not find this information anywhere in the 1.1 LoRaWAN specification or 1.1 regional parameters. The post you linked shows a screenshot from the specification but it doesn't say which version.

[nmaas87]

Hey @jgromes thanks for answering :)

If you look into any network specificiation e.g. 1.1.0 ( https://resources.lora-alliance.org/technical-specifications/lorawan-specification-v1-1
) it is only menitoned in the revision with LoRaWAN 1.0.1: "Introduced a requirement for using coding rate 4/5 in 7.2.2 to guarantee a maximum time on air < 400mSec" - but I guess this is because the network specficiation is too broad to discuss how the frequency band is actually used - please be aware that especially Europe this is strictly regulated and using a higher coding rate will result in more airtime used and can lead to legal issues.

However, if you directly look into the regional parameters, e.g.
1.1.0: https://resources.lora-alliance.org/technical-specifications/lorawan-regional-parameters-v1-1ra
1.0.4: https://resources.lora-alliance.org/technical-specifications/rp002-1-0-4-regional-parameters
1.0.3: https://resources.lora-alliance.org/technical-specifications/rp2-1-0-3-lorawan-regional-parameters
1.0.2: https://resources.lora-alliance.org/technical-specifications/rp2-1-0-2-lorawan-regional-parameters
1.0.1: https://resources.lora-alliance.org/technical-specifications/rp2-1-0-1-lorawan-regional-parameters
1.0.0: https://resources.lora-alliance.org/technical-specifications/rp002-1-0-0-lorawan-regional-parameters

you will find that actually all revisions and all bands use 4/5 as default coding rate, only specific usecases (e.g. LR-FHSS or similar) use other coding rates, but I guess these are outside of the LoRaWAN implementation needed. That said, I am not an expert in the area and with that just point to the above linked technical specification - which hopefully makes sense :)

[nmaas87]

This part is already included in #867 - so I am closing it here to make the PRs easier.
Dear @StevenCellist - you might also want to look into potentially changing the default coding rate to 4/5 on all bands to just make it a bit more standard compatible.
Thanks you all :)

[jgromes]

However, if you directly look into the regional parameters, e.g.
(...)
you will find that actually all revisions and all bands use 4/5 as default coding rate

Just for closure, I searched the rest of the regional parameter documents, and eventually realized that 1.0.x documents include a generic "LoRa description" chapter, which does specify the actual coding rate. However, this chapter is completely missing in the 1.1.0. regional parameters document. Perhaps naively, I based my initial implementation of LoRaWAN parameters on the 1.1.0 specification, as it seemed to be the latest one byed on numbering.

However, looking at the actual release dates, the last revision of 1.0.4 was released in September 2022, while the last published 1.1.0 was released in October 2017. Gotta say, great job with revision management on the LoRa Alliance side!

[nmaas87]

I agree, sadly it looks like the more paper some insitutes produce, the more uncertain stuff becomes... :/. And I can even tell you now why it did initial work with TTN but not with Chirpstack v4 - see this screenshot from my TTN gateway.

By default "Enforce Duty Cycle" is OFF on TTN. I guess if I were to turn it on, a test with coding rate 4/7 would probably just ignore my node as the Chirpstack v4 did (at least it wrote a info in the logs... which finally explained what was going on). So basically - at some point TTN might be pressured by local regulations to enforce those duty cycles and with that probably a lot of not "up to standard" devices will cease functioning. And thats why I made a buzz about the 4/5, I am sorry and hope you can understand :). Thanks a lot!