paulww,
What have you actively tried besides SF 6/7?
no, no intention to go beyond SF7. There is a latency/bitrate requirement to meet. But based on every calculation and measurement, there is no reason to go beyond SF7 at all.
Our other comm link, based on OFDM, is still working well, at much wider bandwidth and higher bitrate. So no reason to go below.
No, no, that is not what I meant by the question.
Have you done any active experimentation or study to solve your problem?
In my experiments under the same conditions as yours, the SNR is positive up to an RSSI of -110 dBm. When the RSSI is below -110 dBm and the SNR is negative, the receiver can still receive without any problems. However, when the RSSI drops to around -115 dBm and the SNR begins to drop below -6 dB, the receiver is completely unable to receive packets.
I suspect that there is a problem with your reception environment or your code.
1 Like
Hi there,
Something doesn’t add up? I did some additional checking… AL agrees 
there is a Spreading Factor 6 (SF6) in the LoRa spec — but it’s a special case with strict limitations, and here’s the scoop:
Spreading Factor 6 (SF6) – Overview
| Property | Value |
|---|---|
| Spreading Factor | SF6 |
| Fastest SF |  Yes |
| Shortest air time | Very low latency |
| Range |  Very short |
| Sensitivity | Worst of all SF values |
| Support | Not supported in most libraries (e.g., RadioLib) |
Why SF6 Is Rarely Used
SF6 has some serious caveats:
- Requires implicit header mode only (no automatic payload length).
- Short preamble — which can affect detection sensitivity.
- Not supported in many LoRa chips unless you dive deep into manual register configuration.
- RadioLib does not currently support SF6, as of latest stable releases.
Use Cases (if any)
- Super short-range links.
- When you need ultra-low latency (like 5–10 ms airtime).
- Controlled environments (e.g., inter-chip comms or testing setups).
Example Air Times Comparison (Payload = 12 bytes, 125 kHz BW)
| SF | Air Time (approx) |
|---|---|
| 6 | ~20 ms (fast!) |
| 7 | ~41 ms |
| 8 | ~72 ms |
| 12 | ~987 ms |
Recommended Minimum SF
For most SX1262 and LoRa setups (and for RadioLib), the minimum valid and usable SF is SF7.
Bottom Line
- Yes, SF6 exists.
- But: Not supported in RadioLib or most normal configurations.
- Use SF7–SF12 for compatibility, reliability, and real-world range.
I thought initially you needed more delay, but your not doing HDX, most setups use it this way. and my Pong times improved a lot.
1. Spreading Factor (SF) Increases On-Air Time
The Spreading Factor (SF) defines how much time it takes to send a packet. Higher SF = slower transmission, but longer range and better sensitivity.
| SF | Approx. Air Time for 12 bytes (at BW 125 kHz, CR 4/5) |
|---|---|
| 7 | ~41 ms |
| 8 | ~72 ms |
| 9 | ~144 ms |
| 10 | ~246 ms |
| 11 | ~494 ms |
| 12 | ~987 ms (! almost 1 second) |
So if you’re using SF12, it can take nearly a second just to send one packet. And the same goes for the response (e.g. PONG).
2. Turnaround Time Between TX and RX
After transmitting (e.g., a “PING”), the module has to switch from TX mode to RX mode. While fast, there’s still some processing time:
- Some delay in exiting TX mode
- Switching the hardware into RX mode (plus RadioLib library logic)
- Receiver may not be immediately ready if you switch too quickly
If you start listening too soon, you might miss the response, especially at longer ranges and higher SF.
3. Propagation Delay (Distance)
LoRa is long-range, and the speed of radio waves is finite — though small, propagation delay becomes measurable over kilometers.
Example:
- Speed of light = ~300,000 km/s
- At 10 km: Delay = ~33 µs
- This is tiny, but combined with RX startup time and processing, it adds up.
- LoRa RX Timeout and Missed Windows I was thinking this, but only in HDX setups
In the receiver, you often define a timeout — how long it waits for a packet. If this window is too short, the response may arrive late and be ignored.
For example:
radio.receive(buffer, length, timeout_ms);
If the timeout is too small (say 50 ms) and you’re using SF11 or SF12, you’ll miss packets — because the air time is longer than your RX window.
Best Practice: Match Timing to SF
- Use longer timeouts for higher SF (longer range).
- Insert short delays after TX before RX to allow full air time.
- Log air times or pre-calculate them using formulas or LoRa calculators (like Semtech’s spreadsheet).
Pro Tip:
Some folks dynamically calculate the airtime using:
float airTime = radio.getTimeOnAir(payloadLength); // ms
Then wait that long (+ a margin) before enabling RX.
Maybe a dynamic timeout system based on SF and payload size — it can improve your PING/PONG reliability significantly
Sorry but I think if your using Radio Lib, You never did post any code so what your thinking probably isn’t going to work like you think.
HTH
GL 
PJ 
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! 
Based on your report, Thank You. At least it get me confirmation, that indeed SF7 can properly work, esp the RSSI/SNR reading are “real”.
If your condition is per ours, SF7, 250kHz, then:
Absolute Noise floor is -119.8dBm, you get SNR negative at -110dBm, meaning the front-end of your setup (Lora+ others), has a noise figure of 10dB. Not too bad.
we did quite a lot of additional experiment, but as per my pictures above, it all points to the hardware (more on this later). Thus we really hope to hear what can go wrong, as we almost at wit’s end. In terms of software, the whole setup is working perfectly, running one packet every 30ms on SF6 without a glitch. It is a PRBS data, and is AES-128 encrypted, and is cross-checked valid, so it is not just some random received packet. It is not code or other issue, except it is some “unknown” not per documentation.
Thanks PJ for the very detailed breakdown. Just to share again, we have gone thru many detailed testing and calculation. Myself has developed modems at FPGA level, and is very familar with modulation/demodulation.
Aware of SF6 issue, but ST’s documentation clearly stated that it is supported. Even the library clearly shows it is well supported. Except for the RSSI/SNR wrong reading, everything else is working. We can get perfect high speed comm, till when signal is weaker. The code compensated for preamble issues as per your point. But we will run more test on this later.
With SF6/250kHz, we are expecting a -7.5dB SNR capability, and thus, this can easily cover the 1.5km that we are expected to work, while keep enough margins for fading. Yet stopping at -70dBm indicate big problem.
And BTW, I did kept saying, that we do not have any Tx/Rx timing issue, or Ping-pong timing. This is a uni-directional comm, with Tx always in Tx, Rx always in Rx.No switching is involved.
1 Like
What I was really hoping to get, is if anyone here really familar with SX1261/2’s RF front-end and the post ADC processing.
We did not want to setup, as we believe this Lora should work well, given its been introduced quite a while back. No choice but to setup and run detailed lab test, via cables, and controlled noise source, we came to a conclusion that it is very sensitive to Cellular signal.
The test setup is a Tx and the Rx running in 869MHz, SF7/250kHz.
We can get perfect comms, down to -105dBm, with 5dB SNR. This is close to msfujino’s cited test. However, the moment we inject some very weak interference at about 760MHz or 920MHz, that’s when SNR will immediately drop down to -9dB. Definately only at specific frequency, aka image/IM/AGC issue here. As I only know its low-IF (at 125kHz), and do not know the exact ADC’s sampling speed/resolution, it is tough to know exact why. At other frequency, we do not even loss any thing with a weak interferer.
And exactly at these frequency, are 4G and 5G signal in my area, thus, we believe that’s the cause. We are in the process of building a filter, and verify this theory.
You should have written your last post first.
1 Like
I just got the result this morning…
Hi there,
Ok then, Sounds like you HAD a plan… but would also agree @msfujino, I say again the cell traffic or the 5G is an issue (filter) the noise you inject can you get more specific Freq. ? Being familiar with the Sx1262 front end in that depth is more a manufacture realm of questions anyway.
(-105dBm @ 5dB ) is pretty good at distance so I feel like the receiver being on/open always is doing something that makes it susceptible to what ever it is, I don’t at this point have a next thought. 
Keep at it though I think your in the right ballpark. 
HTH
GL PJ
Sorry I just did have a second one, Could you Sync everything timing wise and not leave receiver open always? “myllast noodle to the wall”
Here, cellular starts at 885, nothing near nor far to speak of.
What is receiver open or close? Sync what to what? In RF, the only way to improve is to sync to Cellular system.
Hola, tengo 2 placas Wio-E5 y quiero configurar un enlace p2p sin usar gateways pero no he podido con la configuracion del radio Sub-Ghz, me podrías compsrtir tu proyecto por favor?