The LoRa Developer Forum is now in read-only mode and new content will not be added.
Semtech, in its commitment to enhance user experience and streamline content, has successfully integrated the LoRa Developer Portal content into Semtech.com. As a result of this consolidation effort, the LoRa® Developer Portal Forum will be discontinued on May 1st. After this date, you will be automatically redirected to Semtech.com.
For any technical support related to LoRa, please feel free to reach out to our experts here. If you have sales inquiries, please contact us here.

FORUM

SX126x: method of monitoring preamble whilst receiving?

Semtech Transceivers
#1

When the SX126x (or similar) is in receive, the initial detection of a LoRa preamble symbol results in a PreambleDetected interrupt.

The LoRa SetPacketParams command (when used prior to entering receive) sets the PreambleLength to indicate the maximum number of LoRa preamble symbols the receiver should receive (or is it just a timeout?) before expecting a header. If it is actually counting symbol receptions, that implies there is some sort of internal symbol detection counter.

Depending on the size of preamble length set by the transmitter, the time period between a PreambleDetected interrupt and the expiration of the LoRa SetPacketParams PreambleLength can be non-trivial, and there is an associated power consumption with this.

What mechanism exists for the host MCU to monitor the quantity and quality of the LoRa preamble symbols being receiving during this time period?

#2

Try checking the RSSI level whilst receiving the preamble. As long as you are in RX mode, it should be valid

Simon

#3

I toyed with that idea already, but for me it is a non-starter, as the whole point of the LoRa waveform is that it operates at low signal levels. At those low signal levels, the RSSI is indistinguishable from the noise floor.

Thanks for the suggestion, though.

#4

The use of CAD (channel activity detect) will tell you if the LoRa receiver has detected a valid preamble, which is either valid or its not, not sure how there could be an ‘almost valid’ state.

#5

Here’s a summary of symbols in a transmission:

Preamble symbol, preamble symbol, preamble symbol, preamble symbol, … preamble symbol, preamble symbol, syncword/header symbol, syncword/header symbol, syncword/header symbol, … syncword/header symbol, payload symbol, payload symbol, … payload symbol, crc symbol, … crc symbol

If the receiver decodes as little as one of the preamble symbols, it fires a preamble detection interrupt.

The receiver then proceeds to decode subsequent symbols. It counts up to PreambleLength symbols before aborting. Despite counting these internally, it does not, however, bother to tell the host MCU about this process.

If it never gets another recognizable symbol after the initial (false) detection, it never informs the host MCU. It just lets the host MCU twiddle its thumbs for no good reason.

After preamble symbols, there are syncword/header symbols. If those are recognized as failing syntax, there can be an interrupt. However, if they are good enough, there is nothing communicated to the host MCU to inform it that things are going on to plan.

(During the payload reception, I’ve noticed that it is possible to poll the receive buffer pointer register to see if it starts incrementing. That is the only obscure indication that reception has reached the payload stage.)

Only at the very end of the packet is there either an interrupt indicating a successful reception or a CRC failure.

Set_CAD does allow a parameter to detect a limited number of preamble symbols before (optionally) committing to reception, but it doesn’t solve any of above problems.

So, you said that you were not sure of how there could be a “almost valid” state. Hopefully, with the above you can see that all it takes is receiving a few early symbols and not managing to receive the rest.

#6

but it doesn’t solve any of above problems.

I’m not sure I understand what “the above problems” are? What is the top-level problem you’re trying to solve?