Dear Members,
Can you let me know one thing, that is
CAD works only if it is called while a “packet preamble” is being transmitted, or works if called at “any time” during a packet transmission?
Thanks
Asif
For SX1272/1276 - yes, CAD works this way.
Thanks a lot.
From the datasheet;
Principle of Operation
The channel activity detection mode is designed to detect a LoRa preamble on the radio channel with the best possible power efficiency. Once in CAD mode, the SX1276/77/78/79 will perform a very quick scan of the band to detect a LoRa packet preamble.
But I have this paper: Investigating and experimenting CSMA channel access mechanisms for LoRa IoT networks claiming that
As can be seen the LoRa CAD procedure can correctly detect all the LoRa transmission, and not only the preamble.
What do you think @hobo @LoRaTracker?
Interesting, let us know what happens when you try it.
Guess the paper’s author put all his devices on the same desk and set TX power to maximum level. The problem is that LoRa modem sometime detects LoRa preamble even in strong enough noise 
and surely sometime is able to find a corellation between strong enough LoRa signal and ideal preamble waveform. As far as I can recall, Semtech’s name for false positive is “ghost decode”.
I have a personal knoledge of the guys who had observed the same behaviour and then invested a lot of money into developing “LoRa CSMA” w/out doing enough nmr of the field tests. Their activity ended up in epic fail…
I’m working through figuring this out now, but if CAD detects header or payload … you’ve kind of missed the point, haven’t you? It’s too late; you’ve missed the message. I’m admittedly just getting LoRa figured out and trying to optimize for low power receivers, but my understanding is the point is that CAD is very fast, so you can lengthen your preamble so that the preamble has a longer time on air, let’s say 4ms. Then you put your whole RX station in low power mode and do CAD every ~ 1ms; it takes a few microseconds to detect activity; if it sees it, you get an interrupt and wake up before the preamble is over and the header hits, otherwise you go back to nanoamperage sleep and wake up again at the next millisecond… or am I completely missing the point?
Unless you don’t care for a message, but just want to know if the channel is currently in use? Like maybe to implement Listen Before Talk, which is mandatory in some regions, and may be wanted by anyone?
(On the other hand I’d assume LBT regulations apply to any usage of the frequency, not just usage by LoRa signals. I’d also assume that LoRa’s CAD is meant to detect LoRa signals, not garage door openers. But I am not an expert at all.)
This seems to be the only reason to use CAD.
To inplement CSMA, as mentioned above.
If you need to receive a message, I should just start to receive a message 
That’s valid. I’d only been focused on CAD for power consumption in my own use case … I see that the paper @rizkyarlin referenced discusses an attempt to use CAD to do an LBT implementation for CSMA. All of the official documentation of CAD that I’ve reviewed (e.g., datasheets from HopeRF and Semtech) seem to speak of it in terms of power consumption … and indeed one of the Semtech docs specifically calls it out as designed for this use case: “The Channel Activity Detection mode is designed to detect a LoRa preamble on the radio channel with the best possible power efficiency.”
As I said, LBT isn’t really the use case I’d cared about, but I agree with you here. And I would think that this actually invalidates the argument in the whitepaper above about not using RSSI for activity detection, especially since the datasheets for the LoRa chips say that CAD does waveform matching specifically on the preamble (to the point @hobo makes above … it’s probably too optimistic to see CAD matching all parts of the transmission on the bench & think that it will translate to the field).
Well, not when power conservation matters. But, same argument for [regulatory] LBT, isn’t it – just listen & measure RSSI? Sure, it’s possible that there is a LoRa message currently on air below the noise floor … but would a message that weak, using CAD, falsely match the preamble waveform as in the whitepaper (if it was actually already beyond the preamble)? Totally guessing, but I suspect you can’t tell the difference between a clear channel and a weak LoRa message unless you were CAD’ing regularly for the preamble and/or RX long enough to get the header … then to approximate ToA, you’d need the sender to have the header configured to broadcast message size (optional) … then you could approximate a safe backoff time?
It depends… If there’s “heavy traffic” on the channel you use, CAD will do more harm than good from the power consumotion point of views. On a free channel, in may cause extra packet losses or you have to use longer preamble… And so on.
“Single Reception Operating Mode
In this mode, the modem searches for a preamble during a given period of time. If a preamble hasn’t been found at the end of the time window, the chip generates the RxTimeout interrupt and goes back to Standby mode. The length of the reception window (in symbols) is defined by the RegSymbTimeout register and should be in the range of 4 (minimum time for the modem to acquire lock on a preamble) up to 1023 symbols.
…
One of the advantages of the RxSingle mode is that the interrupt RxTimeout will not be triggered if the device is currently receiving data, thus giving the priority to the reception of the data over the timeout.”
So, for me it is better to just set RegSymbTimeout to 4
Surely it will not match. That’s why CAD-based CSMA works only if all the devices are installed in the academist office
They claim than newer SX126X chips are able to detect not only preamble, but any part of a packet. Hadn’t chance to play around enough with these chips yet…
On a second thought… This seems to be incorrect statement. Sorry, my mistake.
That’s what I figure based on all of the datasheets, although that’s a nice find on the SX1261/2; the datasheet does indeed say that CAD on those chips can pickup LoRa data and not just preamble, which should prove really nice for anyone trying to do LoRa-specific LBT or CSMA. I wonder if the more complex search would lengthen the waveform detection portion of the CAD cycle on these chips, or if it’s actually the same or less work to match any LoRa waveform vs preamble-only; the datasheet doesn’t go into detail.
1 Like
There’s SX216X-related group in Semtech’s LoRa community ( https://semtech.force.com/lora ). And it seems that Semtech guys are ready to answer almost any reasonable question.
Hi,
I can see on a scope that the CAD time is match for searching 1 symbol.
Is there a way to search for more the 1 symbol per CAD?
Tired to use the register PreambleDetectSize with no success