Most reliable "best" radio

[skywatch]

@NeverDie said in Most reliable "best" radio:

Is there a battery chemistry other than Energizer lithium primary cells that you think might be the best overall choice?

I don't know enough about battery chemistry to make an informed contribution.

I have some lithium cells with 2040 date on, but not using them yet (probably in the next few weeks)....

Also, in the US, the FCC allows for the legal use of higher transmit power if using spread spectrum or frequency hopping (though there do still exist restrictions relating to dwell time and duty cycle). I'm no lawyer, but I get the impression LoRa counts as spread spectrum as far as the FCC is concerned. Without either spread spectrum or frequency hopping, the allowed transmit power is pretty low--more or less reliable only if the receiver is both nearby and line-of-sight with the transmitter. In my book that's not very practical. An example of that would be a plain vanilla Nordic nRF24L01, or the first generation z-wave, both of which had a max transmit power of just 0dBm.

The NRF24L01+ has frequency hopping capability - I tried it by modifying the tmrh library before I came to mysensors. I only made a slow hop rate (4 hops/sec) but it seemed to work nicely. It would be cool if my sensors supported this, but there is probably a good reason why it doesn't.

[NeverDie]

@skywatch said in Most reliable "best" radio:

The NRF24L01+ has frequency hopping capability - I tried it by modifying the tmrh library before I came to mysensors. I only made a slow hop rate (4 hops/sec) but it seemed to work nicely. It would be cool if my sensors supported this, but there is probably a good reason why it doesn't.

There is some posted code on github that looks like it might do the business: https://github.com/search?q=hopping+nrf24l01 Not sure how energy efficient frequency hopping would be, but it would be fun to give it a try and reap the rewards of a 2mbps datarate. I wonder whether any of those AT-command type of modules might already implement it? That would sure make it easy.

On AliExpress I notice that the RF4463PRO radio modules claim to be able to do frequency hopping. Their on-air bitrate is theoretically as high as 1mbps.

[NeverDie]

Closing off a loose end: Regarding the Adafruit TPL5110 delay module for powering projects, I just now did an experiment where I used it to power a generic atmega328p platform (not that I would actually use it that way, but for convenience of testing) and then did a measurement of the current draw when it was in power-off mode, because, as pointed out in the other thread, Adafruit rather bizarrely reports that it consumes 20ua in that mode (https://www.adafruit.com/product/3435) according to Adafruit's "monsoon" measuring system. However, my measurement with a Current Ranger shows it settles at around 42na when feeding it 3.3v, which is close to the 35na at 2.5v reported by the tpl5110 datasheet(https://www.ti.com/lit/ds/symlink/tpl5110.pdf?ts=1653609291212&ref_url=https%253A%252F%252Fwww.google.com%252F).

So, if you wanted to use it as a kind of "triggerboard" for an esp8266 or esp32, I expect it would work quite well.

Worthy of note: I did have to connect a 10k resistor between the Done pin and ground. Adafruit uses just a 1M pulldown resistor, which is too weak. If left with only a 1M pulldown resistor, the mote effectively hits "Done" when it's in the process of powering up, which turns it back off before it finishes powering up. Not good. The 10k resistor fixes that, and my measurement shows that the quiescent current doesn't suffer because of it. Perhaps it is the weak pulldown resistor that Adafruit uses in its design which explains why some people report a fail in getting the Adafruit TPL5110 to control power to an ESP8266 or ESP32. With the 10K pulldown resistor added, I had no problem having the TPL5110 supply power cycles to my generic atmega328p platform, as per the intended design.

Given that this appears to work, it opens the door to testing current consumption of an ESP8266 that's programmed to operate in ESP-NOW mode. i.e. current consumed from the moment of power-on, through packet transmission, up to the point where the DONE pin on the TPL5110 is pulled high by the ESP8266, which kills power to the ESP8266 until the next cycle starts all over again. That's the kind of information that seems very hard to find and yet which is critical for anyone wanting to assess the battery life of such a setup.

On its face, though, one youtuber claims it takes 280ms for an ESP8266 to wake-up and transmit using ESP-NOW:

but that in itself doesn't really answer the question with any degree of accuracy. And would an ESP32 be any faster? As per usual, the important details gets glossed over, leaving one wondering.

[NeverDie]

As a first step I looked purely at the transmission interval of an ESP8266 running the demo "controller" sketch from the above youtube video. Quite impressive:

That's just a simple wemos D1 mini ESP8266, powered at 3.3v over its 3.3v pin, blasting out an 8 byte packet to the universe using ESP-NOW. No listening for an acknowledgement of any kind. So, using the same assumptions as before of a transmission of once every 5 minutes, and crunching the numbers are before, then if that were the only current drain (which we know is false, but for an initial calculation assume it were true) then the expected lifespan of the batteries would be an impressive 1,031 years. That does get my attention, and to me that warrants the effort of making a measurement over an entire power-on to power-off transmission cycle using an adafruit TPL5110, because we already know (from directly above) that the power-off current will be a trivial 43na. I haven't yet measured to see whether it can traverse my worst-case transmission path, or what the packet loss rate would be, but on the can it says it has a transmission power of 25dBm. On the other hand, it is 2.4Ghz, but maybe the shortness of the transmission will reduce its odds of collision with sporadic interference. The weakness is that the powerdraw on either side of the transmission is about 80ma, so that may turn out to be its fatal flaw, because if you simply assume an 80ma draw for a period of 280ms at 5 minute intervals (i.e. not even counting the transmission current itself), then the projected battery lifespan is 5.3 years.

Would an ESP32 do better than an ESP8266? I don't own any. Which of the many ESP32 flavors in particular would likely do the best in testing?

[NeverDie]

Well, the rumors were right: the ESP8266 doesn't seem to work with the TPL5110. I tried different pulldown resistors but no joy. Not sure why. Go figure.

[Edit: after some FAFing, I find that it does work after all if a 10k pulldown resistor is (as before) added to the DONE pin on the TPL5110, and a 470uF capacitor added between GND and 3.3v on the input power. Maybe other capacitor values would also work, that's just the first one I reached for. Without those two mods, though, a Wemos D1 Mini won't dance properly with an Adafruit TPL5110 breakout board. ]

I found that ESP8266 GPIO14 worked for pulling DONE to high without much drama. Apparently, some other ESP8266 pins (GPIO16, GPIO3, GPIO1, GPIO10, and GPIO9, as detailed here: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/) start out HIGH when the ESP8266 boots up, which is no bueno.

[NeverDie]

Bingo! Scored it. Captured below is a single transmission using the Adafruit TPL5110 to power up a Wemos D1 Mini ESP8266 from essentially nothing (43na) and then return to essentially nothing (43na) afterward. So, this screenshot captures the entire process for an ESP8266 that's in ESP-NOW mode.

Here is the sketch that I used:

/****************************************************************************************************************************************************
 *  TITLE: ESP-NOW Getting Started Examples
 *
 *  By Frenoy Osburn
 *  YouTube Video: https://youtu.be/_cNAsTB5JpM
 ****************************************************************************************************************************************************/

 /********************************************************************************************************************
  * Please make sure that you install the board support package for the ESP8266 boards.
  * You will need to add the following URL to your Arduino preferences.
  * Boards Manager URL: http://arduino.esp8266.com/stable/package_esp8266com_index.json
 ********************************************************************************************************************/
 
 /********************************************************************************************************************
 *  Board Settings:
 *  Board: "WeMos D1 R1 or Mini"
 *  Upload Speed: "921600"
 *  CPU Frequency: "80MHz"
 *  Flash Size: "4MB (FS:@MB OTA:~1019KB)"
 *  Debug Port: "Disabled"
 *  Debug Level: "None"
 *  VTables: "Flash"
 *  IwIP Variant: "v2 Lower Memory"
 *  Exception: "Legacy (new can return nullptr)"
 *  Erase Flash: "Only Sketch"
 *  SSL Support: "All SSL ciphers (most compatible)"
 *  COM Port: Depends *On Your System*
 *********************************************************************************************************************/
 #include<ESP8266WiFi.h>
#include<espnow.h>

#define MY_NAME         "CONTROLLER_NODE"
#define MY_ROLE         ESP_NOW_ROLE_CONTROLLER         // set the role of this device: CONTROLLER, SLAVE, COMBO
#define RECEIVER_ROLE   ESP_NOW_ROLE_SLAVE              // set the role of the receiver
#define WIFI_CHANNEL    1

uint8_t receiverAddress[] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};   // please update this with the MAC address of the receiver

struct __attribute__((packed)) dataPacket {
  int sensor1;
  int sensor2;
  float sensor3;
};

void transmissionComplete(uint8_t *receiver_mac, uint8_t transmissionStatus) {
  if(transmissionStatus == 0) {
    //Serial.println("Data sent successfully");
    digitalWrite(14,HIGH);
  } else {
    //Serial.print("Error code: ");
    //Serial.println(transmissionStatus);
  }
}
  dataPacket packet;
  
void setup() {
  pinMode(14,OUTPUT);
  digitalWrite(14,LOW);
  //Serial.begin(115200);     // initialize serial port
  
  //Serial.println();
  //Serial.println();
  //Serial.println();
  //Serial.print("Initializing...");
  //Serial.println(MY_NAME);
  //Serial.print("My MAC address is: ");
  //Serial.println(WiFi.macAddress());

  WiFi.mode(WIFI_STA);
  WiFi.disconnect();        // we do not want to connect to a WiFi network

  if(esp_now_init() != 0) {
    //Serial.println("ESP-NOW initialization failed");
    return;
  }

  esp_now_set_self_role(MY_ROLE);   
  esp_now_register_send_cb(transmissionComplete);   // this function will get called once all data is sent
  esp_now_add_peer(receiverAddress, RECEIVER_ROLE, WIFI_CHANNEL, NULL, 0);
  packet.sensor1 = 123;
  //Serial.println("Initialized.");
}

void loop() {

  
  packet.sensor1++;
  packet.sensor2 = 456;
  packet.sensor3 = 3.14;

  esp_now_send(receiverAddress, (uint8_t *) &packet, sizeof(packet));
  delay(1000);
}

It is only slightly modified from the original. Essentially I commented-out all of the code relating to print statements, because that would drag out the time and is superfluous for present purposes, and I set GPIO14 to high as the "DONE" signal after the packet was finished sending and the related callback function was called, which instructed the TPL5110 to cut the power.

So, I finally have the data now to do the necessary battery calculation. Crunching the numbers, assuming a single transmission like this every 5 minutes, the batteries would last almost 19 years. That is just a pure packet transmission with no acknowledgement. Still, it is much better than what I had been expecting based on what others have reported.

It might be that this could be improved upon by removing the ESP8266 from its Wemos D1 Mini PCB, as the PCB contains components which may be soaking up power and simply aren't needed. Also, looking at the current graph, it looks as though maybe it's listening after the main transmission? Maybe someone knowledgeable about ESP-NOW can comment. Lastly, I'm not sure what datarate ESP-NOW defaults to. Maybe it would be possible to have it transmit faster and thereby use less current. So, lots to look into if anyone here has the interest.

Anyhow, I think that this proves the concept. Who knew? All this time the ESP8266 had been type-cast as impossibly power hungry. I guess the main downside is that anything in addition that one might do, such as measuring the battery voltage or doing an TH measurement, as examples, will be done at a fairly high current burnrate. Offsetting that might (?) be the prospect of getting it done sooner.

The real question, though, is whether it makes sense to do a similar measurement on an ESP32, and, if so, which one? Any chance it would be better? Or would it likely be worse?

[NeverDie]

For comparison, an nRF24L01 can, according to its datashet, cold-start from completely powered off to an idle state in 11.8ms. From there the remaining delay would mainly be the amount of time needed for the MCU to configure registers and load the transmit FIFO buffer. Not sure how long that takes. Anybody know? After that it would, in theory anyway, take just 130us to initiate the start of transmission.

For that reason I'm guessing an nRF24L01 could, if it were an apples-to-apples comparison, have a much shorter transmission cycle than the 181.6ms transmission cycle of the Wemos D1 Mini ESP8266 that I measured above.

Fun fact: the nrf5x modules have the advantage that they don't need to use SPI to load bytes into a transmission queue. Instead, when transmitting, an nRF5x can read the transmission bytes directly from memory via DMA.

In any case, comparing the SX1262 switching times, the SX1262 (LoRa) looks to be pretty fast:

Cold start to standby in 3.5ms, and then from standby to transmitting in 126us. As with the nrf24l01, the MCU will need to define registers and load the FIFO transmission queue before it can initiate the transmission, and that will take some amount of time because it happens over SPI.

[NeverDie]

CORRECTION: Earlier I said that Adafruit's TPL5110 breakout board appeared to use a 1M pulldown resistor on DONE. I remeasured today and that's wrong. It's actually a 10K resistor. So, since my adding a 10K resistor to that in parallel solved the issue of it not working, I today replaced Adafruit's 10K SMD resistor with a 5.1K SMD resistor. Afterward I retested, and I've confirmed that (not surprisingly) that works. So, with that modification to the Adafruit TPL5110 board, an external pulldown resistor is no longer needed. Not a big deal, but it keeps things a little tidier. As to what the optimal value should be, I don't know. I'm simply reporting that 5.1K seems to work and that Adafruit's choice of 10K didn't work in the two different test scenarios that I tried.

[NeverDie]

I'd like to try one of these recently announced RFicient ultra low power receiver wake-up chips:
https://www.youtube.com/watch?v=bQINMRcoAsI

It claims a receive current of just 3 microamps and allegedly works in any of the 3 ISM bands.

Unfortunately, nothing yet on mouser or digikey. Who knows whether they'll actually deliver or whether they're just testing the market demand.

[NeverDie]

Well, some good news regarding the LoRa SX1262: in looking at the datasheet, I see that it says that " SX1261/2 supports the modulation underlying LR-FHSS (at present, GMSK
modulation)" that equates to LoRa SF12 sensitivity, but is presumably (?) faster given that it is GMSK and not LoRa. The chip handles the hopping, but it relies on the MCU to set everything up. The better news is that just 3 months ago Semtech posted a github library (https://github.com/Lora-net/SWDM001) that allegedly demos it.

Another nice thing I noticed in the datasheet is that unlike prior LoRa chips, the SX1262 has a Channel Activity Detector that can detect not just LoRa preamble bits (as earlier chips could) but data bits as well. That's good because it reduces the odds that a new transmission will start prematurely and result in a collision with a LoRa transmission that's already in progress. The bad news though is that, if using it for deciding whether to wake-up or not, it looks to takelonger than getting an RSSI measurement would.

[NeverDie]

For comparison, I just now measured the energy consumption of a generic key finder, such as what you can find for cheap on amazon.com or aliexpress:

So, the high level overview is this:

I feed it 3v from the PPK2, and this picture shows what happens before and after powering it on. When first powered on, it blinks the LED a couple of times, which explains the first two current pulses.

Zooming in a bit we can determine the length of the duty cycle:

This is perhaps the most revealing of the screenshots. As you can see, it wakes up roughly once a second to see if it can receive anything. According to PPK2, the average current draw is 34.71ua.

And out of that one second, it is active only about 8.764ms.

It was advertised as having a battery life of two years, but I can tell you from experience that it hasn't lasted even 6 months. Probably even less than that--I just haven't paid close enough attention as to when it actually fails because I almost never use it. Of the couple of times I did have a reason to use it, the batteries were already dead, and it didn't work at all. :angry: If nothing else, a meaningful improvement would be if it could at least occasionally call home and report what its remaining battery capacity is.

[ejlane]

@NeverDie They claim that it is already available in a QFN16 package. https://www.iis.fraunhofer.de/en/ff/sse/ic-design/rf-ic/wakeup.html

But they say you have to go through "EBV Chips" to get it, and everything I've seen makes it look like that's for large companies only. I can get to this page at Avnet, https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/ebvchips-overview/ but I can't seem to get past it to any chance to order or see a detailed datasheet or anything like that. A search just on regular Avnet for the part turns up empty with the things I can think of.

This is the best page I can come up with: https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/rficient/ which is cool and all, but still nothing orderable for normal people.

[NeverDie]

Curiously, this keyfinder does appear to function fairly decently all the way down to 1.9v:

and its current draw actually drops to 29ua:

I'm including this screenshot of the Rx interval for completeness:

By the time it reaches 1.8v, it dies rapidly because it spends most of the 1 second duty cycle listening:

What the PPK2 doesn't do is simulate the voltage droop that a CR2032 can experience. Not at all sure what happens under those conditions, but maybe (probably?) it contributes to the seemingly short battery life. If that's the case, maybe these keyfinder receivers could be rehabilitated to last longer before needing a battery replacement.

By the way, when I checked the voltage remaining on the coincell taken from this keyfinder receive, it measures about 3mv. So, it got drained practically all the way to zero.

Anyhow, according to energizer, their CR2032 has 235mah of capacity when measured from fresh down to 2.0v (https://data.energizer.com/pdfs/cr2032.pdf). So, doing the math on that, assuming a 35ua burn rate, it should theoretically last 279 days, or about 9 months. That would be the lower bound. If one assumes 29ua as the burn rate, then it could last 11 months. That would be the upper bound. i.e. theoretically, it might last somewhere from 9-11 months. Definitely not two years. Also, I'm definitely got getting anything in that range on my keyfinder receiver tags--they die much sooner than that. I'm guessing it's CR2032 voltage droop that gets worse as the battery gets depleted which leads to premature failure. I wondering whether simply soldering in a suitably large value ceramic capacitor between VCC and GND might help it power through the droop and live up to its design potential? Better yet, I'd be willing to trade off responsiveness for much better battery life. Rather than checking once per second, maybe it could be modified to listen much less often than that.

[NeverDie]

Looking at the chips involved:

only one has markings on it:

and that seems to return a null google result. So, it's a deadend in terms of modifying the receiver duty cycle.

Maybe there are chips with actual datasheets for doing this kind of thing? The application is certainly nothing new.

[NeverDie]

This reminds me of an earlier tip that @mfalkvidd offered up here: https://forum.mysensors.org/topic/10806/how-is-this-receiver-able-to-continuously-rx-but-consume-only-90ua?_=1653861040283 for a chip that consumes only 1.37ua in listen mode.

That chip is now available (and in stock) via digikey: https://www.digikey.com/en/product-highlight/a/ams/as3930-low-frequency-wakeup-receiver?utm_adgroup=General&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic Search_EN_RLSA&utm_term=&utm_content=General&gclid=EAIaIQobChMIg5OvvNmF-AIVzhXUAR2AXwVNEAAYASAAEgJG3vD_BwE

One possible catch is that it operates in a low frequency band that I know nothing about. If lucky, maybe that's a clean band set aside for this type of thing? On the face of it, it might make for a very long battery life keyfinder tag receiver, and compared to a Bluetooth TILE, the chip price isn't bad.

Maybe now is a good time to revisit this? Still in a bit of a quandary as to an easy way to test drive it. The eval kit actually went up in price to $333. There is a github library though for connecting an arduino to a related chip: https://github.com/LieBtrau/arduino-as3933

Also, another guy here: https://forum.digikey.com/t/as3933/2604/8 offers up a schematic and pcb layouts for connecting an as3933 to an atmega32u4. So, maybe taken together that does the business....provided you can find/make a suitable transmitter to activate it. In any case, from that same thread, what it appears to be is some kind of RF power envelope detector, which maybe explains the weird 100uvrms for expressing its sensitivity:

In other words, it's a more maybe a more sensitive version of a $2 RF Power detector:
https://www.youtube.com/watch?v=vHVmJ5lD9jc

which is close range but is completely passive and so doesn't consume any power at all to "listen".

[NeverDie]

The listen mode I previously worked out on the nRF52832 pretty much blows away the performance of the cheap keyfinder receiver:
https://forum.mysensors.org/topic/6961/nrf5-action/1052?_=1653867854046
It had an Rx interval of just 30us and, aside from the startup time, the rest of the time, while sleeping, the current draw was <3ua. And it checked for packets once every 100ms, not once a second, so it was plenty responsive. If only the sleep current had been less. Perhaps in combination with a TPL5110 it would completely trump the battery life of the keyfinder tag. But, it's relatively expensive.

That leaves the nRF24L01P. It draws 900na in powerdown mode, from which it takes 1.5ms to startup into standby mode, and from there only 130us to enter Rx mode. I'd say it has a chance for beating the keyfinder tag, because it could have a much shorter receive window than the ~8ms Rx window that the keyfinder tag has, even though the keyfinder tag appears to have a sleep current of nearly zero. What's the shortest valid packet that an nRF24L01 can receive? It turns out sparkfun had a (now retired) nRF24L01P keyfob, though they used it as a transmitter rather than as a keyfinder: https://www.sparkfun.com/products/retired/8602

[NeverDie]

The SX1280 appears to have much faster transitions from sleep to idle than the SX1262, and practically an order of magnitude faster than the nRF24L01:


i.e. it can go from sleeping at a current of 1.2ua (maybe even 0.4ua?) with full data retention to Rx listening mode in 130+85 = 215us. That's pretty snappy.

[NeverDie]

One big difference I hadn't realized until just now between the 2.4Ghz SX1280 and the sub-gigahertz SX1262 is that the SX1280 can utilize a bandwidth as wide as 1625KHz, whereas the SX1262 is limited to at most 500KHz. Why does that matter? Speed. The SX1280 can have a symbol time as low as 0.0197ms, whereas the fastest symbol time on the SX1262 is 0.064ms. That means the SX1280 can transmit 3.25x faster than the SX1262.

I confirmed this with a measurement on the SX1280 transmitting one byte (along with CRC-32 and all the other overhead that the library defaults to):

Add to that the faster transition times of the SX1280, and I conclude that at normal distances and transmission paths, the SX1280 is better suited for a battery powered mote that needs to duty-cycle listen for a wake-up packet than the SX1262 is.

By the way, observe the relatively high current draw on this particular SX1280. That is because of the 27dBm transmit power afforded by the PA of the Ebyte E28-2G4M27S module that it's a part of. That's why I made my own overkill usb-to-serial converter with a low-noise LDO that's rated to deliver as much as 1.1a at 3.3v, in case I'm powering the module that way. :-) The current draw that's in evidence in this snapshot would completely swamp the 50ma limit on most 3.3v USB-to-serial adapters on the market. Even Sparkfun's Beefy 3 is limited to 200ma, which is less than 1/3 the amount being drawn by the Ebyte module.

So, worst case, if I were to power the Ebyte module in Rx mode for 2ms per 1 second period, waiting for a 1 byte packet and all the overhead, that would translate into about 17ua average current draw, or a little over half of what my keyfinder fob draws.

However, by using the Channel Activity Detector (CAD), I should be able to reduce the wake-up detection window to about 4 symbol periods to reliably detect a LoRa transmission that overlaps its Rx window, which on an SX1280 would be 4*(0.0197ms)=0.0788ms. Let's round up and call that 0.1ms. Napkin math: that would maybe (?) translate into an average current draw that's under 4ua if one were to assume that, like the keyfinder fob, it listens only once per second and draws the worst-case 8.2ma while actively receiving in high-sensitivity mode and draws the worst-case 1.2ua while sleeping the rest of the time. Not bad! I say "maybe" because I'm not exactly sure how much it might draw while powering up and getting ready to receive. 0.1ms = 100us, so the current drawn during the 210us it takes for the SX1280 (and maybe longer for the Ebyte LNA?) to transition from sleep into Rx is going to affect the average current draw. With worst-case assumptions, the total shouldn't be more than an average current draw of 12ua, and I'd expect it to be much less than that. We know from the the SX1280 datasheet that Standby-RX mode draws 700ua, but clearly there must be some kind of ramping from the 1.2ua sleep current up to that amount, and between that amount and the 8.2ma when in receive mode. Therefore, I don't see a way to precisely calculate from just the datasheet alone. I could compute lower-bounds and upper-bounds or make some assumptions about the ramp rate, but to really remove the fog around this I think I'll write the duty-cycled listen code and then measure it with the PPK2.

Anyhow, this makes for yet another interesting point of comparison with the nRF24L01, or even the RFM69. The nRF24L01/RFM69 could maybe use RSSI threshold as a quick, short-hand way to judge whether a transmission might be occuring without having to go through a full packet receive cycle, but relying on RSSI alone for that purpose would tend to be sensitive to noise and interference, resulting in false positives. The CAD of the SX1280, in contrast, is designed to detect LoRa transmissions specifically, so hopefully it will filter out that kind of noise, or, at minimum, at least not false positive trigger on it. That's especially important for the SX1280, which operates in the crowded 2.4GHz band.

Another advantage of the SX1280, as compared to the SX1262, is that the SX1280 can run its DCDC converter in RX and TX modes, whereas the SX1262 is limited to LDO only, so that's another way the SX1280 can get longer battery life.

[NeverDie]

Using RadioLib on the SX1280 Ebyte module, I was able to get the CAD working at 1 second intervals:

I picked 1 second to make for an apples-to-apples comparison against the Keyfinder fob above.
Zooming in to the area of interest:

This screenshot shows the average current consumed while waking up, re-establishing the radio configuration, and then doing the CAD. I reduced the spreading factor to SF5, and I increased the bandwidth to 1625Mhz. Also, in the RadioLib library, DC-DC conversion on the SX1280 is turned on by default. I expect the results shown could be improved upon with more careful programming, but as a first-pass the results are: it could last 2.8 years on a CR2032 coincell. That is using RadioLib's default 8 symbols for judging a CAD. So, as a first-pass, not bad! It definitely beats the projected 9-11 month battery lifespan on the keyfinder fob from above. I'm reasonably sure that lifespan could be improved using more careful programming to reduce the SX1280 radio configuration time after waking up. In theory, the SX1280 is supposed to remember its configuration in one of the two sleep modes, but, in practice, it seems to be forgetting at least some of it, so for a quick first-pass workaround I do a full re-configuration each time it wakes up.

[NeverDie]

I'm getting no traction on this thread so I think I may move this topic to some other forum on some other website. Sorry. Maybe this is just the wrong place for it, or maybe the topic is of no interest to others here. Whatever the reason, monologging is no fun. There just isn't the feedback or comments or suggestions to make further posting on this topic worthwhile.

End of thread.