LoRa - RX - TX - RX Times
By Jon Adams, N7UV
Semtech (Camarillo, CA, USA) has made upwards of a half-billion LoRa chips to date, and those chips find their way into much of the Internet of Things. LoRa is a pretty amazing technology, and it carries with it some things that the ham needs to know in order to use it to best advantage.
How long does it take a Semtech chip in LoRa mode to go from receive to transmit and back? It's pretty quick, depending on how you measure it! For this discussion, assume that the device is in continuous receive mode, awaiting a LoRa packet to appear.
Remember how this works on a FM 2 m AFSK APRS channel. It's important to factor in the time it takes the radio from PTT activation to when the transmitter is able to transmit. In a legacy TNC, tied to a 2m FM radio, that's the TXDELAY, usually recommended to be a value between 150-300 ms or more depending on the radio. That's dead-air time, transmitter still "warming up". No useful information being transmitted, all due to the reality that most 2 m FM radios take a long time to get going once the PTT switch is pushed. Once PTT is released, a typical transceiver takes as much as a hundred milliseconds or so to return to a stable receive state, no small part of which is due to the synthesizer settling and the receiver audio amplifier powering up. At 1200 baud, the transceiver internal state changes take nearly as long or longer than the length of a compressed position packet! That's some significant inefficiency. John WB2OSZ has a writeup that touches on why this is such a challenge. And, PLEASE, never use VOX to control radio PTT, it makes RX>TX and TX>RX times even worse, messing up the channel for all others.
With LoRa, most of us use the SX126x family. SX1261/2 Data Sheet Rev 2.2, DS.SX1261-2.W.APP Dec 2024, Table 8.2 Switching Time lists the transition from RX to TX at 92 us. When commanded to do so, transmitter A switches from RX to TX and immediately starts sending the preamble. The preamble is the opportunity for all receivers in range and in receive mode to begin synchronizing to the transmitter's timing. Preambles consist of an integer number of upchirp symbols; check the Semtech LoRa calculator and it shows 8 preamble symbols as the default. The preamble can be shorter or longer if desired, but the number of symbols needs to be enough for the distant receiver's FFT engine to first detect power in the channel, then determine that the power is a chirp with the expected slope (kHz/ms), and align its timing to that chirp. Remember that a single LoRa chirp is also a symbol encoding a certain number of bits, from SF5 = 5 bits to SF12 = 12 bits. I've written on this before.
The "Capture Effect": for LoRa and a system at a specific LoRa setting (BW/SF), if distant receiver B is currently receiving a packet from transmitter B, so long as receiver B hears transmitter B 6-10 dB stronger than transmitter A, receiver B will continue to stay locked on to transmitter B and complete reception. For FM AFSK receivers, so long as receiver B hears transmitter B at a received signal strength 1.5 to 3 dB better than transmitter A, receiver A can successfully complete reception. This has a lot to do with how LoRa is accumulating received energy over the entire symbol time and doing an FFT on the data, then looking at where the peak energy is, while FM AFSK is relying completely on the FM capture effect. This shows the LoRa channel is more sensitive to contention than the FM AFSK channel. On the other hand, LoRa packet reception is more resilient as each symbol is processed independently of every other. Even with the corruption of a received symbol, The data encoded is spread across multiple symbols, so the receiver has a good chance to recover the transmitted information even with the loss of a symbol or two. In an FM AFSK receiver, losing 1 bit can result in the loss of the entire transmitted frame. For legacy FM AFSK, there is WB2OSZ's FX.25 (AX.25 with FEC (forward error correction)) that can receive a frame successfully with errors of 8 to 32 BYTES(!), at the cost of lengthening the over-the-air packet to include the necessary FEC information. WB2OSZ's direwolf software TNC has FX.25 built in. It is completely interoperable with AX.25 frames, so one end can be capable of FX.25 while the other is not.
While transmitter A is sending its preamble, receiver A, in receive mode and not currently receiving another LoRa frame, detects the preamble and aligns itself to that preamble. While a LoRa receiver can do this in as little as 1 symbol time (plus some internal fixed delays), it's better to have receiver A collect between 2 and 4 symbols (dependent on the SF setting) before deciding that it's a valid LoRa frame. I can't find a copy of the Semtech paper on-line right now, but here's a snap of the front sheet of AN1200.48, published in November 2019. In any event, it states that the "best" receiver setting for BW125 SF7/SF8 is 2 symbols, while SF9/12 requires 4 symbols for the same success.
Since transmitter A is sending 8 preamble symbols, this gives receiver A plenty of opportunity to detect and synchronize on the preamble. And just because the receiver can get by on less than 8 symbols, giving it more time in terms of finding and locking on the preamble leads to more robust reception. Since at the Arizona network rates, a symbol is only a millisecond long, there doesn't seem to be a lot to be gained by reducing the preamble length.
A LoRa chip transitions from TX to RX (or standby) well under a hundred microseconds. All in all, a LoRa transceiver is very efficient in moving between states, with the greatest influence the internal processes that occur via the serial SPI bus interface.
--Cheers and 73 - Jon N7UV