CR 4/5
How CR 4/5 Fits Into LoRa Physical-Layer Coding
In LoRa, the coding rate parameter selects how many parity bits the physical layer adds to each block of four payload data bits. The notation 4/5 means four data bits become five coded bits, so the effective code rate is 0.8. LoRa supports four discrete settings, CR 4/5, 4/6, 4/7, and 4/8, corresponding to one, two, three, or four parity bits per nibble. CR 4/5 is the lightest of the four and is the value most LoRaWAN network servers assign by default to balance reliability against the strict sub-GHz ISM-band duty-cycle rules in the EU868 and similar bands.
The coding works on nibbles using a shortened Hamming code. With a single parity bit, CR 4/5 mainly delivers error detection rather than strong correction, but combined with the diagonal interleaver and Gray mapping that LoRa applies before transmission, it spreads burst errors across symbols so that the demodulator can recover packets that would otherwise fail. The choice of coding rate is independent of the spreading factor and bandwidth, which gives a system designer two largely orthogonal knobs: spreading factor for raw sensitivity and processing gain, and coding rate for incremental error protection.
Because every additional parity bit lengthens the coded payload and therefore the time on air, CR 4/5 produces the shortest packets and the lowest energy per message. On battery-powered sensor nodes that transmit a few bytes every several minutes, this directly extends service life. When a link is operating near its sensitivity floor, network operators may step a node up to CR 4/6 or higher through adaptive data rate, but the starting point for a comfortable link is almost always CR 4/5.
CR 4/5 Coding and Airtime Equations
Rc = 4 / (4 + n) , with n = 1 for CR 4/5 ⇒ Rc = 4/5 = 0.8
Coding-rate index used in LoRa airtime:
CRidx = n = 1 (for 4/5) , range 1 to 4
Payload symbol count (per LoRa datasheet):
npayload = 8 + max( ⌈ (8PL − 4SF + 28 + 16 − 20H) / (4(SF − 2DE)) ⌉ × (CRidx + 4) , 0 )
Where PL = payload bytes, SF = spreading factor, H = 0 for explicit header, DE = 1 if low-data-rate optimize is on. With CRidx = 1, each block expands by a factor of (4+1)/4, the smallest expansion of any LoRa coding rate. Symbol time Tsym = 2SF / BW; total airtime ≈ (npreamble + 4.25 + npayload) × Tsym.
LoRa Coding Rate Comparison
| Setting | Parity bits / 4 data | Code rate Rc | Overhead | Relative airtime | Approx. coding gain |
|---|---|---|---|---|---|
| CR 4/5 | 1 | 0.80 | 25% | 1.00x (baseline) | ~1 to 2 dB |
| CR 4/6 | 2 | 0.67 | 50% | ~1.20x | ~2 to 3 dB |
| CR 4/7 | 3 | 0.57 | 75% | ~1.40x | ~3 dB |
| CR 4/8 | 4 | 0.50 | 100% | ~1.60x | ~3 to 4 dB |
| Header (always) | 4 | 0.50 | 100% | fixed 8 symbols | maximum robustness |
Frequently Asked Questions
How much extra airtime does CR 4/5 add compared to no coding?
LoRa always applies at least CR 4/5 to the payload, so there is no uncoded data mode. Each block expands by (4+1)/4, the smallest factor of any LoRa setting, so practical airtime grows only a few percent up to about 8% versus a hypothetical 4/4 baseline. Stepping up to CR 4/8 roughly doubles parity and can lengthen airtime 30 to 60%, which is why CR 4/5 is preferred under tight duty-cycle limits.
What error correction capability does CR 4/5 actually provide?
It applies a shortened Hamming-style code with one parity bit per four data bits, giving single-bit error detection but no guaranteed correction inside a block. The redundancy mostly helps the diagonal interleaver and Gray demapper recover isolated symbol errors, improving packet error rate near the margin by roughly 1 to 2 dB. CR 4/6 through CR 4/8 add Hamming distance for real correction and up to 3 to 4 dB of coding gain.
Does the gateway need to match the node's CR 4/5 setting?
In explicit-header mode the payload coding rate is carried in the header, which is itself always sent at CR 4/8, so the gateway reads it and decodes a CR 4/5 payload without a pre-shared setting. In implicit-header mode, used for fixed-format point-to-point links, both ends must be statically configured to the same coding rate, spreading factor, bandwidth, and preamble length because no header signals them.