SF5/SF6 links work but score 0 — packetScoreInt() bails below SF7, thresholds unsourceable

[ACETyr]

Summary

SF5 and SF6 links work on our hardware, but packetScoreInt() returns 0.0f for sf < 7, so every
packet received at those spreading factors scores zero.

src/helpers/radiolib/RadioLibWrappers.cpp:266:

if (sf < 7) return 0.0f;

The guard is necessary as written — snr_threshold[] holds only six entries (SF7…SF12) and is
indexed sf - 7, so SF5/SF6 would read out of bounds without it.

Measured on the bench (2026-08-10)

RAK4631 + Heltec V3, both SX1262, 869.618 MHz / 62.5 kHz / CR5, MESH_DEBUG=1 MESH_PACKET_LOGGING=1:

SF	decoded	SNR	score	airtime
8 (control)	8/8	11–13	1000	836 ms
6	8/8	9–10	0	267 ms
5	8/8	7–8	0	156 ms
5 (flood)	6/6	7–8	0	156 ms
8 (restore)	3/3	11	1000	836 ms

The links themselves are fine — no losses, healthy SNR. RadioLib allows SF5–12 on SX126x
(RADIOLIB_CHECK_RANGE(sf, 5, 12)), and our CLI already accepts sf >= 5 && sf <= 12.

Impact today: none by default

MyMesh::calcRxDelay (examples/simple_repeater/MyMesh.cpp:614) overrides the base Dispatcher and
short-circuits when rx_delay_base <= 0; MyMesh.cpp:1008 sets it to 0.0f by default
("turn off by default, was 10.0"). Measured: all six flood packets at SF5 logged
score delay below threshold (0) and were processed immediately.

It only bites if an operator sets rxdelay non-zero, where score 0 is the worst case:
(rxdelay^0.85 - 1) * airtime.

Why this is not fixed yet

Extending snr_threshold[] needs SF5/SF6 values we cannot currently source or measure:

• SX1261/2 datasheet Rev 1.2 Table 3-8 lists LoRa sensitivity for SF7 and SF12 only, no
  SNR-limit column.
• Semtech AN1200.22 Rev 2 contains exactly one table (FSK link budget) — no SNR-per-SF table.
• Not measurable on our bench: at minimum commandable TX power the signal is still ~51 dB above the
  noise floor, 22 dB of commanded power change yields only ~10 dB of RSSI change, and reported SNR
  rises as power falls (receiver compression). ~58 dB short.

A calibrated step attenuator (0–60 dB, ideally conducted with a fixed pad) would make this
measurable, and the measured value would be better than a datasheet figure: the code compares
getLastSNR(), so the radio's own reported SNR at the failure point is the correct quantity.

Also noted

• set radio replies OK - reboot to apply — persisted but not pushed live.
• Zero-hop adverts never reach the calcRxDelay branch (isRouteFlood() is false).
• Neither wrapper checks the return of setSpreadingFactor(), so on an SX127x board (SF6–12 only)
  set radio ...,5,... would be accepted and stored while the radio silently keeps its old SF.

Scripts: bench_sf_test.py, bench_sf_dynrange.py.

[ACETyr]

SF6 is sourceable after all — Semtech publishes it, just not in the SX126x datasheet

The issue looked in the SX1261/2 datasheet, which indeed has no SNR-limit column. The SX127x
datasheet does, and it is the table our snr_threshold[] was taken from — SF7…SF12 match it exactly.

Semtech SX1276/77/78/79 datasheet, Rev. 4 (March 2015), page 27, Table 13 "Range of Spreading Factors":

SpreadingFactor	Chips/symbol	LoRa Demodulator SNR
6	64	-5 dB
7	128	-7.5 dB
8	256	-10 dB
9	512	-12.5 dB
10	1024	-15 dB
11	2048	-17.5 dB
12	4096	-20 dB

The SNR limit is a property of the LoRa demodulator at a given spreading factor, not of the part, so
this applies to our SX1262 nodes as well. SF6 = -5 dB can therefore be added with a primary-source
citation, no extrapolation needed.

SF5 remains unsourced — three dead ends checked

• SX1276/77/78/79: the table above stops at SF6. The part has no SF5.
• SX1280/SX1281 Rev 3.2, Table 3-5 "LoRa Modem Specifications" (p.22-23): lists bitrate for
  SF5/SF6/SF7/SF12, receiver sensitivity in dBm for SF7 and SF12 only, and co-channel rejection for
  SF7 and SF12. No SNR-per-SF column at all.
• Meshtastic firmware: supports SF5/SF6 but carries no per-SF SNR table. Its only SNR constant is
  a UI signal-bar heuristic, getSnrLimit() in src/modules/CannedMessageModule.cpp, which returns
  three coarse values by modem preset (-6.0 / -5.5 / -4.5 dB) with no source comment and no SF
  dependence. Supporting a spreading factor needs no threshold — only our scoring heuristic does.

Suggested way forward

Extend snr_threshold[] downward by two entries and re-index, taking SF6 = -5 dB as datasheet
fact and SF5 = -2.5 dB as a documented extrapolation of the uniform 2.5 dB/SF ladder that
holds across every published row — marked as such in a comment, so the distinction is not lost the
next time someone reads the table. That removes the sf < 7 bail and the out-of-bounds hazard,
which is the actual defect.

[ACETyr]

Second sweep: no Semtech part publishes an SNR limit for SF5

Checked every Semtech LoRa part that supports SF5, by full-text search of the datasheets rather than
by eye:

Part	SF range	SNR-per-SF table?
SX1276/77/78/79 Rev 4	SF6–SF12	yes — Table 13, p.27 (the source of our array; SF6 = -5 dB)
SX1261/62/68	SF5–SF12	no (Table 3-8: sensitivity for SF7 and SF12 only)
SX1280/81/82 Rev 3.2	SF5–SF12	no — full-text grep for "SNR" returns only the RSSI/SNR packet status register description (Table 11-66, p.93). No per-SF table anywhere.
LR1110 Rev 2.0	SF5–SF12	no — the string "SNR" does not occur in the document at all. Sub-GHz sensitivity table lists SF7 and SF12 only.
LR1121 Rev 2.0	SF5–SF12	no — "SNR" does not occur either. But see below.
LLCC68 Rev 1.0	SF5–SF11	not obtained (every mirror served HTML). Same-family derivative of the SX1262 datasheet, so expectation is low — flagged as unverified, not as checked.

The pattern is consistent: the LoRa Demodulator SNR column is an SX127x-generation artefact. It was
dropped from the SX126x datasheet onwards — which is exactly the generation that introduced SF5. So
there is likely nothing to find.

The one empirical anchor for SF5 in any Semtech document

LR1121 Rev 2.0, Table 3-6 (p.19), 2.4 GHz sensitivity, RxBoosted = 1:

Symbol	Condition	Typ
RXSLHF10	BW_L = 812 kHz, SF = 5	-108 dBm
RXSLHF9	BW_L = 812 kHz, SF = 7	-112 dBm

At a fixed bandwidth the noise floor is identical, so the sensitivity difference is the SNR-threshold
difference: SF5 sits 4 dB above SF7. With SF7 = -7.5 dB that puts SF5 ≈ -3.5 dB, against -2.5 dB
from the uniform 2.5 dB/SF ladder.

⚠️ Treat as corroboration, not as a source:

• The other pair in the same table is internally inconsistent — RXSLHF7 (406 kHz, SF5) = -111 dBm vs
  RXSLHF8 (406 kHz, SF7) = -129 dBm, an 18 dB gap. -129 dBm cannot be right when the same document
  gives SF7 as -118 / -116 / -112 dBm at 125 / 250 / 500 kHz. Almost certainly a typo.
• Sensitivity at 1% PER is not the same quantity as the demodulator SNR limit, and it is specified
  with a fixed payload, CR and preamble.
• Different band (2.4 GHz) and different silicon generation.

So it brackets SF5 between roughly -3.5 and -2.5 dB without settling it. The recommendation from the
previous comment stands: SF6 = -5 dB as datasheet fact, SF5 = -2.5 dB as a commented extrapolation.
Being conservative (-2.5) simply means SF5 packets score 0 slightly more readily, which is the safe
direction for a scoring heuristic.

[ACETyr]

Resolved: Semtech publishes SF5 — in a technical note, not a datasheet

Semtech TN1300.05 "Predicting LoRaWAN Capacity", Version 2.0, March 2024, §3.1, Table 1
"Data Rates and Required Signal-to-Noise Ratios":

Data Rate	SF5	SF6	SF7	SF8	SF9	SF10	SF11	SF12
Required SINR	-2.5 dB	-5 dB	-7.5 dB	-10 dB	-12.5 dB	-15 dB	-17.5 dB	-20 dB

Two sentences of context from the same section, both of which matter to us:

"These numbers correspond to first-generation LoRa demodulators, the second generation is 1dB better."

"This holds true when the coding rate is 4/5, normal interleaving, which is the LoRaWAN default LoRa PHY configuration."

So:

• SF5 = -2.5 dB is sourced, not extrapolated. The previous suggestion to mark it as an
  extrapolation can be dropped.
• SF6 = -5 dB is now doubly sourced — this table and SX1276/77/78/79 Rev 4 Table 13.
• The stated condition CR 4/5, normal interleaving is exactly our AT/EU-narrow preset.
• The whole existing snr_threshold[] (SF7…SF12) matches this table row for row, so extending it
  downward by two entries is consistent with its own origin, not a mixture of sources.
• ⚠️ Worth recording but not acting on here: our SX1262 is a second-generation demodulator, so
  by Semtech's own note the real thresholds are ~1 dB better than every value in the array. That is a
  uniform offset across all SFs and does not change the relative ordering the score depends on.
  Changing it would be a separate, deliberate decision.

How this was found, so the trail is not lost

Not in any datasheet. Every SF5-capable part was checked and none carries the table (see previous
comment). The lead came from chasing other manufacturers: ST's STM32WL integrates an SX126x-class
radio, and its documentation refers LoRa modulation detail back to Semtech — which surfaced the
TN1300 technical-note series. TN1300.05 is a LoRaWAN capacity-planning note; the SNR table appears
there only as an input to an orthogonality calculation, which is why no datasheet search would ever
have reached it.

Suggested change is now unambiguous: extend snr_threshold[] with SF5 = -2.5 and SF6 = -5, re-index
from sf - 5, and delete the if (sf < 7) return 0.0f; bail — citing TN1300.05 Table 1 in the
comment above the array.