Don’t you think this requires the receiver to be operational? Last time I checked that required several mA.
1 Like
seems there are several ‘listen modes’, in one, the circuit wakes the receiver periodycally and polls for a preamble signal.
https://www.semtech.com/uploads/documents/DS_SX1276-7-8-9_W_APP_V5.pdf page 117
if you really save a lot of energy ?
BoRRoZ, I did notice the comment about establishing a Timer from my earlier readings but I then questioned the need because the datasheet seems to suggest that the SX1279’s software will go into Receive mode after a preamble is detected. Do I need to specify a Timer1 value for the SX1279 to begin detecting the preamble mode
Kersing, yes the thought of the receiver being operational with a small mA current would be needed but again my interpretation of CAD and preamble had me believe that the SX1279 would detect the preamble in the idle mode which I’m measuring at 3 mA.
Maybe I’m being overly hopeful that CAD can be used in the Idle mode to detect a preamble rather than relying on Receive mode which is pulling 13 mA for my project. Do you have an example of a simple sketch that implements CAD and preamble that I could review?
Thank you all again
I read ;
So YOU must take ‘appropriate’ action after detection preamble signal.
(also before I think setting the right times for the timers… finetuning reception!)
depending on the application and environment, there are several ways to implement Listen mode:
- Wake on a PreambleDetect interrupt
- Wake on a SyncAddress interrupt
- Wake on a PayloadReady interrupt
If that were true, why would anyone be using the standard 13mA receive mode ?
Do also appreciate that you may loose some sensitivity in CAD mode, which may not be an issue for you of course.
Edit: The datasheet seems clear;
The radio receiver captures LoRa preamble symbol of data from the channel. The radio current consumption during that phase corresponds to the specified Rx mode current
2 Likes
BoRRoZ. Ok I’m starting to understand the logic here but please correct me if I’m wrong. Is it correct to state that implementing CAD will result in the SX1279 briefly enter into Receive mode (as specified by Timer2) and then enter into Idle more for a time period defined by Timer1 upon which enters into a lower power consumption mode but is able to detect the preamble?
LoRaTracker. Totally agreed with your statement on why anyone would use the higher power mode if signal detection could be achieved in a lower power consumption mode. Again my interpretation of CAD and preamble caused me to believe that was possible. If that is not the case then under what conditions would entering Idle mode be useful?
When are you planning to enable the detection? In LoRaWAN Class A devices, the specific time frames for downlinks allow a node to very briefly enable detection at very specific times (being RX1, and possibly RX2, after an uplink). But when not using such timing (like when using Class C), shouldn’t your node be in detection mode all the time anyway?
…when the node knows it will not receive anything, like any time except RX1 and RX2 for a Class A device, or any time except the repetitive receive slots for Class B devices? Enabling detection outside of those specific times is just a waste of energy, as by definition no LoRaWAN downlink is even possible for that node then.
(Or actually, I guess that after RX2 one would switch off the thing altogether then?)
If the processor is in deepsleep and your SX12xx detect a valid preamble then and signals that to wake up the processor with an interrupt … it will be 'flipping a lot on a busy channel and you could get more timing problems with RX1/RX2.
Never tested that myself btw but like Arjan said, you won’t win a lot of energy that’s for sure.
The point thats made about CAD mode in the datasheet is that it turns the receiver off\on for periods of time and you still stand a reasonable chance of receiving a preamble and then packet. If the receiver is off 50% of the time say, then there should be a power saving.
Myself; whilst discussing the datasheet theory of potential power savings is slightly interesting, without a real world practical test you may learn very little of value. Despite a practical test being very easy to do, not sure I have seen any real world results, has anyone else ?
And as I mentioned you do loose some sensitivity, so expect a reduction in range. Not sure its mentioned in the manuals, but thats what I found in paractical experiements.
Is this for LoRaWAN ?
I can see a benefit of persuing CAD mode for simple point to point links.
1 Like
Thanks for sharing knowledge, but please stop promoting your products here, if only as it’s not open: one cannot even peek into the “open API” documentation without logging in, let alone read any documentation about the underlying protocol, and your network server software surely is very much closed source. All fine, but that doesn’t comply to the TTN manifesto, so has no place here.
1 Like
Happy New Year gentlemen.
LoRaTracker: Yes my endeavor is a simple point to point duplex using one SX1279 as a transmitter that is 0.25 Km from a second SX1279 that is serving as the receiver. I’m employing a LoRa duplex sketch developed by Tom Igoe and Sandeep Mistry from Github and it works great thus I’m not implementing LoRaWAN for the time being. What I am hoping to accomplish is to increase the amount of time that the receiver can operate using two AA batteries which is why I became so interested in the CAD option. I did read your site’s recent posting on whether there was much to gain from switching modes given that you measured large power draws just from switching between idle and full receive modes. But Semtech’s description about CAD and lower power consumption had me convinced that this was a valid approach for my effort to increase receiver’s battery lifetime.
Arjan: Totally follow your logic on the timing. Let’s assume that I “know” that the transmitter will issue a signal once every hour and that I want my receiver to go into single Receive mode to detect that signal. In that simple scenario, what would I use for Timer1? Would I need to connect an external clock to my receiver and specify values for Timer1? Or is Timer1 a function that is solely specific to LoRaWAN?
BoRRoZ: You stated earlier that I (" So YOU must take ‘appropriate’ action…") must specify the action when using a syncaddress, preamble, or payload ready interrupt. My duplex sketch (see highlighted text in attached PDF) does use a destination address to wake the SX1279. Does my use of the destination address to wake the receiver serve as the ‘appropriate’ action that you are referencing? If so does that mean that mean I could replace destination address with the preamble (aka Timer1)?
Duplex_Receiver_LoRa.pdf (75.1 KB)
Much appreciate the assistance from everyone on this.
and the same to you 
The most gain you will achieve imho , is when you put the arduino in deepsleep and set the SX MapPreambleDetect bit in the way that it responds (on DIOx) with an Wake on SyncAddress Interrupt
that wakes the processor. (see page 119 - 123) with that pin interrupt.
So not in a loop.
Check if you can build that… I’m even thinking of letting the transmitter send the same message 2 times if you’re have timing problems (detecting+waking arduino + processing)
I think 
, because I never did pure LoRa and this is of course a LoRaWAN forum 
Hope everyone is good.
I have a question about measuring ‘symbol time’ after doing CAD process, is this possible ?
in the above document they have written
“The figure 6 above highlights the symbol time measure through the power consumption of the device and the calculated symbol time”
Though i guess, power consumption can be measured externally and not internally?
Semtech probably can… sorry I don’t know.
The document makes clear that the measurement of current is done on a scope across a 10R resistor, presumably in series with VCC.
They then relate that measured current consumption profile (and its time) to the calculated symbol time.
I have implemented CAD using the RSSI in brief - using spiRead get the current RSSI and if >-128 assume channel is active - does a good job - but you also need o have a fail-safe logic - e.g. if for some period the RRSI is always > -128 then send (as the channel is free)
Hi to everybody…
I am new to this forum and i know that CAD mode is not so relevant for Lorawan applications.
I am trying to write a point to point Lora SW , possibly using Arduino Ide , that use CAD mode to save battery power.
I wrote some code that run on Atmega328 …
But i couldnt implement on other platform like Esp32 or Stm32 since there is a lack of libraries (only RadioHead works) and hw platforms to do that(i refer to multiple interrupts lines)
Since i could not find many places where this topic is discussed i will try to ask my questions here:
Can anybody share any code implementing CAD mode and using CAD detect interrupt?
No, this is not the right forum and we don’t start this discussion all over again… CAD don’t save battery power.