Further,
SF6 Limitations (Reality Check)
- Implicit header mode is required for SF6 —
(they mention this correctly). - Most LoRa libraries (like RadioLib, LMIC, etc.) do not support SF6 directly —
- Only specific LoRa chips (SX1272/1276/1262) support SF6 — but only with manual register configuration.
- LoRaWAN explicitly does not support SF6 —
- SF6 requires a very short preamble (e.g., 2 symbols) — making it unreliable unless both ends are precisely synchronized.
What’s Likely Happening in Their Case
- They might believe they’re using SF6, but the hardware or library likely defaulted to SF7, especially if they’re using a standard API.
- If they’re really using SF6, it had to be through manual register writes, and they must tightly control:
- Payload length
- Sync word
- Preamble length
- Timing (because SF6 is far less tolerant)
Signal Behavior at -70 dBm
They say:
“When RSSI drops to about -70dBm, SNR starts to drop to negative region randomly, and starts to lose packets.”
That contradicts real-world behavior. Here’s why:
- -70 dBm RSSI is very strong — most LoRa links survive down to -120 dBm or lower at SF12.
- At SF6, you might need higher SNR, but losing packets at -70 dBm with 19 bytes and 250 kHz BW is odd.
- This could indicate:
- Too short preamble for proper RX detection
- Inaccurate timing
- Mismatched settings or RF interference
Summary: You’re Right
| Claim | Verdict | Notes |
|---|---|---|
| SF6 used with implicit header | Plausible |
Must be manually configured |
| Works reliably up to 300m |  Unusual |
SF6 is short-range by nature |
| Loses packets at -70 dBm RSSI | Doubtful |
Indicates other problems, not just signal |
| BW = 250 kHz at SF6 | Valid |
Improves airtime, but reduces range potential |
TL;DR
- They’re likely NOT using SF6, unless deep config is happening.
- If they are, their setup is extremely fragile.
- You’re right to doubt — especially given the signal loss at -70 dBm.
- No code , Hmmmm… Deep config maybe
,LOL
HTH
GL 
PJ 
above all , Have FUN! 