Coding Rate ever different than 4/5?

End Devices (Nodes)
1

Hello,

I am trying to calculate the “worst case” regarding EU868 1% Duty Cycle. Meaning: How often can I send a maximum sized payload (51 Bytes) at SF12. I use the Airtime Calculator.

One open question remains: I can select the coding rate which, of course, changes the time on air. Its quite hard to find information about the coding rate other than that 4/5 is the default for LoRaWAN.
Here comes my question: Is the coding rate ever changed, e.g. if the LNS finds a signal to be weak and frequently lost?

Depending on the coding rate, my results vary from 04:07 minutes to 05:55 minutes.

Thanks & best regards
Philipp

2

It’s always 4/5; see Payload with only 2 characters and coding rate 4/7? - #14 by arjanvanb

And note: SF12 is only allowed in combination with ADR.

Minutes?! How often are you sending? Beware that the TTN Fair Access Policy allows for at most 30 seconds time on air per device, per 24 hours. So, an airtime of 2,793.5 milliseconds for 64 bytes on SF12BW125 imposes a limit of 10.7 messages per day.

When transmitting all day, on average this needs a minimum of 134.1 minutes between the starts of two uplinks, or a maximum of 0.4 messages per hour.

3

Hi, thanks for your answer!
Regarding my results: I was only stating what the Airtime calculator outputs, I didnt break that down to the TTN Fair Access Policy.

Best Regards
Philipp

4

Beware that this calculator does not automatically include the minimum of 13 bytes of LoRaWAN overhead. The 51 bytes is the maximum application payload for EU868 SF10, SF11 and SF12 on 125 kHz, assuming the packet does not include any MAC commands (so: assuming the LoRaWAN overhead is 13 bytes). So, you’d need to enter 64 bytes to get proper results.

A bit of self-promotion: Airtime calculator for LoRaWAN will give you many more details.

5

Ok, I will use your calculator now, very nice! Thanks a lot!

6

A long time ago, I did an experiment where I modified the code of a RFM95 based node to send packets using error correction rate 4/8 (instead of 4/5). This did actually work, even though the LoRaWAN specification says to use 4/5. This is possible because the packet format used in LoRaWAN enables a specific LoRa header that tells the receiver what correction rate is used.

This was discussed in thread: Improve node performance by changing coding rate from 4/5 to 4/8?

Thomas @telkamp did a more advanced experiment, as described in the thread. The improvement was marginal.

1 Like
7

Aside, adding cr48 and the like to, e.g, https://avbentem.github.io/airtime-calculator/ttn/eu868/51,cr48 will also show a dropdown for coding rate. But it will disappear when one selects the LoRaWAN 4/5.