When should I select CR 4/6 instead of CR 4/5 or CR 4/8 in a LoRaWAN deployment?

CR 4/6 is a middle-ground choice for links with moderate interference where CR 4/5 drops too many packets but the full 100 percent overhead of CR 4/8 wastes too much air time and battery. It is well suited to urban or industrial sites with intermittent collisions on the shared sub-GHz ISM band. Because higher coding rates lengthen time on air, they raise the chance of collision in dense networks and increase duty-cycle consumption, so many production LoRaWAN networks default to CR 4/5 and reserve 4/6 or 4/8 for the lowest data-rate, longest-range channels. Field testing with packet error rate measurement at the target spreading factor is the reliable way to pick a coding rate.

Wireless Protocols

CR 4/6

Q: How much overhead does CR 4/6 add compared to CR 4/5?

LoRa coding rate notation 4/CR expresses the number of transmitted bits per four payload bits, so CR 4/6 sends six bits for every four data bits, a 50 percent overhead and an effective code rate of 2/3. CR 4/5 sends five bits per four, only 25 percent overhead and a 4/5 effective rate. Moving from 4/5 to 4/6 therefore increases on-air time by roughly 20 percent for the same payload because each LoRa symbol carries the same number of bits regardless of coding rate, so more coded bits require more symbols. The extra parity buys correction of one additional bit error per codeword and improved detection of burst errors caused by interference or fading.

Q: Does CR 4/6 change the LoRa preamble or only the payload?

The coding rate applies only to the explicit-header and payload portions of the LoRa frame, not the preamble. The preamble uses a fixed up-chirp sequence for synchronization and is not Hamming-coded. In explicit header mode the header itself is always protected with the most robust 4/8 coding regardless of the payload coding rate, so a CR 4/6 packet still carries a 4/8-coded header followed by a 4/6-coded payload. In implicit header mode the coding rate must be pre-agreed between transmitter and receiver because it is not signaled in the header. This matters for time-on-air budgeting because the header and payload contribute symbols at different effective rates.

/see-ar fawr siks/

One of four selectable forward error correction settings in LoRa chirp spread spectrum modulation, CR 4/6 transmits six coded bits for every four payload bits, an effective code rate of 2/3 with 50% overhead. The extra Hamming parity, applied through the same nibble interleaver used at other coding rates, corrects one bit error and detects two per codeword, improving robustness against burst interference on the shared sub-GHz ISM band. Compared with the default CR 4/5, it adds roughly 20% to time on air for the same payload, so it is chosen when link margin matters more than battery life or duty cycle. In explicit header mode the payload uses the selected 4/6 rate while the forward error correction protecting the header stays fixed at the most robust 4/8 setting.

Category: Wireless Protocols

Effective code rate: 2/3

Overhead: 50% (6 bits / 4 data)

How the LoRa Coding Rate Works

LoRa physical-layer packets carry a configurable forward error correction strength expressed as a coding rate of the form 4/(4+n), where n ranges from 1 to 4. The four legal values are CR 4/5, CR 4/6, CR 4/7, and CR 4/8. In each case four data bits are encoded into 4+n transmitted bits, so CR 4/6 maps every four data bits onto six bits on air. The encoding is a shortened Hamming code combined with a diagonal interleaver that spreads each codeword across multiple LoRa symbols. This interleaving is the reason LoRa tolerates burst errors well: a deep fade or a colliding transmission that corrupts several adjacent chirps damages only one or two bits in any given codeword, which the parity can then repair.

Because every LoRa symbol carries a fixed number of bits determined solely by the spreading factor, adding parity bits does not change symbol size; it increases the symbol count. A CR 4/6 payload therefore occupies more symbols and more time on air than the same payload sent at CR 4/5. The trade is direct and predictable: stronger error correction in exchange for longer transmissions, higher energy per packet, and greater duty-cycle consumption. Network operators weigh this against the regional duty-cycle limits enforced on bands such as the European 868 MHz allocation.

CR 4/6 sits between the lightweight default and the heaviest protection. It gives one additional correctable bit per codeword over CR 4/5 without doubling the overhead the way CR 4/8 does, which makes it a practical choice for moderately noisy LoRaWAN links where occasional collisions degrade an otherwise adequate signal.

Time-on-Air and Code-Rate Equations

Effective code rate:
R_c = 4 / (4 + n) = 4 / 6 ≈ 0.667 (n = 2)

Payload symbol count (LoRa):
n_sym = 8 + max( ⌈(8·PL − 4·SF + 28 + 16·CRC − 20·IH) / (4·(SF − 2·DE)) ⌉ × (4 + n), 0 )

Symbol duration:
T_sym = 2^SF / BW

Where PL = payload bytes, SF = spreading factor, BW = bandwidth, CRC and IH = header flags, DE = low-data-rate optimize, and n = 2 selects CR 4/6. Larger n raises (4 + n), so 4/6 produces more payload symbols than 4/5 for identical PL and SF.

Coding Rate Comparison

Coding Rate	Bits per 4 data	Effective rate R_c	Overhead	Burst error tolerance	Typical use
CR 4/5	5	0.80	25%	Lowest	Default; clean links, battery priority
CR 4/6	6	0.667	50%	Moderate	Intermittent interference, urban sites
CR 4/7	7	0.571	75%	High	Noisy channels, longer range
CR 4/8	8	0.50	100%	Highest	Worst-case links; fixed header coding

Common Questions

Frequently Asked Questions

How much overhead does CR 4/6 add compared to CR 4/5?

CR 4/6 sends six bits for every four data bits, a 50% overhead and an effective rate of 2/3, versus CR 4/5 at five bits per four (25% overhead, 4/5 rate). Because LoRa symbols carry a fixed number of bits set by the spreading factor, the extra coded bits require more symbols, so moving from 4/5 to 4/6 lengthens time on air by roughly 20% for the same payload. The reward is correction of one additional bit error per codeword and better burst-error detection.

Does CR 4/6 change the LoRa preamble or only the payload?

Only the explicit-header and payload portions use the selected coding rate. The preamble is a fixed up-chirp synchronization sequence and is never Hamming-coded. In explicit header mode the header itself is always protected at the most robust 4/8 rate, so a CR 4/6 packet carries a 4/8-coded header followed by a 4/6-coded payload. In implicit header mode the coding rate must be pre-agreed because it is not signaled in the frame.

When should I select CR 4/6 instead of CR 4/5 or CR 4/8?

CR 4/6 is the middle ground for links with moderate interference where CR 4/5 drops too many packets but CR 4/8 wastes too much air time and battery. It suits urban or industrial sites with intermittent collisions on the shared sub-GHz ISM band. Since higher coding rates lengthen time on air and raise collision odds in dense networks, many deployments default to CR 4/5 and reserve 4/6 for the lowest data-rate, longest-range channels. Validate with packet-error-rate testing at the target spreading factor.

Related Terms

← CR 4/5 CR 4/7 →