Most reliable "best" radio

NeverDie

Well, upon closer examination using some better software, I found that with a spreading factor of only 5 that I am, in fact, losing some packets along my worst-case transmission path. However, although increasing the spreading factor to 12 seems to guarantee that every packet arrives the first time, it's not the most energy efficient approach because the airtime is so much longer. Increasing spreading factor from 5 to 6 doubles the airtime, and from 6 to 7 doubles it again, and so on. So, from an energy perspective, it's better to accept even a 10% packet loss and retransmit than it is to increase the spreading factor. Keeping the airtime short also reduces the chances of collisions. This realization is a big change in my perspective on LoRa and what I should expect to get out of it. It puts LoRa more on par with other approaches to radio than I had originally thought.

Fortunately, the worst-case transmission path is exactly that, and for most things a spreading factor of 5 seems flawless, so I think that overall I'll stick with a SF of 5 and enjoy benefits of the very short transmission times. I can always do what LoRaWAN does and just insert one or more dumb hubs wherever needed, assuming it ever becomes necessary.

Larson

@NeverDie said in Most reliable "best" radio:

would last... ready for it?.... 1,537 years!

Have you considered comedy as a profession? I love your postings. The self-discharge of the human is another limitation. Unless, of course, you have a couple of Methuselahs in your progeny and a good set of instructions. And I know you can write good ones.
Thanks for the post.

NeverDie

A closer look at the datasheet explains why the transmission currents are dropping as I lowered the voltage: it's no longer able to to transmit at the full 22dBm!

If you all you care about is transmitting at 16dBm or less, then, yes, you can power the SX1262 all the way down to 2v. But if you want the full 22dBm transmit power, then the SX1262 needs no less than 3.3v (because the built-in LDO drops 200mv). Well, that's quite obviously a real bummer to find out this late in the game, because there is just no way 2xAA are going to source 3.3v on their own without help from a charge pump or a boost converter. Will running a boost converter during a transmission introduce unacceptable noise? How would I even measure for that effect or know how much noise is too much? Alternatively, how big a capacitor would one need if, instead, the idea is to charge up the capacitor and run from that, with the boost converter turned off, during a transmission? After all, in principle LoRa transmissions can be quite lengthy. Or does one need 3xAA or 4xAA batteries with a low noise LDO for a more viable option? Dang, this may turn out to be quite a nasty gotcha! :anguished:

Of course, one alternative is to accept the 16dBm max transmission power but rely on more LoRa spreading factor or narrower bandwidth to arrive at an equal or better link budget. I already know that SF12 is more than adequate, because I've already tested it. I just need to test a bit more to find out what the right Goldilocks spreading factor would be to ace my worst-case transmission path and then compute what effect the longer transmit time will have on battery life. Perhaps this story may yet have a happy ending. :-)

NeverDie

In principle, using the LoRa calculator, the trade-off isn't so bad. With just under a tripling of airtime, a SF of 7 would yield the same link budget at a transmission power of 16dBm as a SF of 5 would at a transmission power of 22dBm:

[Edit: Reporting back. Indeed, testing the worst case transmission path with a transmission power of 16dBm and an SF of 8 yields:

983 packets received. 17 missing packets.
,CRC,35BC,RSSI,-79dBm,SNR,10dB,Length,23,Packets,983,Errors,0,

i.e. 1.7% missing packets. I know this because I wrote some code to put an index number into each packet, such that the index increments on each transmission. The receiver thus knows what numbers to expect and tallies up the number of packets that are missing in the received sequence.

The airtime with SF8 is about 34ms, so the battery's transmission lifespan is still likely to exceed the battery's useful shelf life. I'll want to take some transmission current measurements with transmit power set to 16dBm and then re-run the numbers, but as a lower bound on battery capacity I could take 258 years and multiply 6.838 (the previously measured onair time with SF5) and divide by 33.408 (the calculated onair time with SF8), to get 52.8 years as a low-bound. It's lower bound because I had set a transmission power of 22dBm for the earlier measurement. Who knows what transmission power I actually got, but definitely lower than 22dBm based on the new information regarding supply voltage and transmit power. So, lower than 22dBm, but presumably higher than 16dBm. If that's right, then remeasuring the actual utilized current when the requested transmission power has been lowered to 16dBm should yield a longer expected transmission life than the 52.8 years arrived at here with these back-of-the-envelope conservative assumptions.

I'll try increasing the number of pre-amble symbols and see if that reduces the number of missed packets at all. According to Semtech's SX1262 LoRa calculator, increasing pre-amble symbols is relatively cheap in terms of airtime. ]

NeverDie

Hmmm.... Not sure why, but the calculations from the new SX1262 transmission current measurements(see picture below) indicate the 2xAA batteriess would last 38 years using SF8 and transmission power set to 16dBm, which is obviously less than what I was predicting. I haven't yet increased the number of pre-amble symbols, so the reason isn't that. This time I did power the radio module with 2.8v instead of the 3.0v I used in the earlier measurement, so maybe that had something to do with it. Not sure at this point. Go figure:

Anyhow, regardless of the reason, that's enough battery capacity headroom that I'm not worried.

[Edit: I found the reason: I had lately increased the coding rate from 4/5 to 4/8, which increased the airtime over what it had been previously at 4/5, but I had forgotten to include that change in the Semtech LoRa calculator calculation.

If I use the 47.232ms Time on Air number shown in the LoRa calculator results here and redo the previous lower bound calculation, the answer is a lower bound of 37.35 years, which is indeed less than the 38 years calculated based on the new measurements above. :-) ]

[As an experiment, I tried powering the same SF8 mote with a solid 3.3v and a transmit power of 22dBm provided by 4xAA batteries and an LDO. The result was about 1% missing packets. Then, reverting to just 16dBm, it was a roughly 2% missing packet rate. Therefore, it's probably not worth the bother of powering the mote with 4xAA batteries and an LDO. Granted, it would be some improvement, but, IMHO, not really enough of an improvement to justify upgrading to a 3.3v supply source. ]

NeverDie

The library's default sleep mode for the SX1262 radio should consume 600na with the configuration retained. Measuring it when powered by 2xAA batteries, I can confirm that it does:

On the other hand, if it were put in deepest sleep, where it forgets everything, the datasheet says it would instead consumed 160na (see 3.5.1. Power Consumption table in the datasheet). Well, when I put it into deepest sleep, I measured a number reasonably close to 160na:

Lastly, we know from the atmega328p datasheet that in the atmega328p's deepest sleep, it will consume only 100na. Well, doing that and measuring, I get a number reasonably close to that:

I only just yesterday received this particular nanocurrent meter, and these were my very first mesurements with it. :-)

The last thing to measure will be the amount of energy consumed by the SX1262 during a wake up. We should then have all the data we need to calculate the mote's estimated battery life.

NeverDie

Reporting back: I measured the wake-up current that occurs in one of the library sleep examples, and, as you can see, it simply isn't significant relative to the transmission itself:

So, without getting into the numbers this time, I think it's safe to say that as a generic mote platform, this LoRa mote will function until its batteries completely die of old age, more than twenty years from now, provided that it has a suitable ultra low current way to wake up periodically. :+1: Of course, YMMV, depending on what else you want the mote to do.

skywatch

@NeverDie Interesting work and thanks for sharing it - I am sure it will interest many people trying to get the best out of their batteries.

The one thing I suggest is to also take measurements across the expected working temperature range. I don't pretend to know how much affect, but battery life is extended by storing them cool whilst in use a warmer temperature will allow more energy to be 'mined' from the battery (due to the chemical reaction).....

NeverDie

@skywatch said in Most reliable "best" radio:

The one thing I suggest is to also take measurements across the expected working temperature range. I don't pretend to know how much affect, but battery life is extended by storing them cool whilst in use a warmer temperature will allow more energy to be 'mined' from the battery (due to the chemical reaction).....

It's a fair point. Ideally the battery datasheet would cover the temperature range of interest.

Is there a battery chemistry other than Energizer lithium primary cells that you think might be the best overall choice? They claim to have a 20 year shelf life, and the price seems pretty reasonable. To your point, they also seem to have a pretty wide rating temperature range, certainly better than Alkaline. Also, much less likely to leak than Alkaline, which certainly matters if the goal is "as long as possible" between battery changes.

Anyhow, I'm glad I finally did the measurements and crunched the numbers. Prior to now I was under the impression that LoRa transmissions times were inevitably so long that battery life would be greatly diminished. This thread seems to prove that, on the contrary, for simple sensor measurements taken at 5 minute intervals, LoRa can be awesome.

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.

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:
Always ready to receive — RFicient chips for a sustaina-ble Internet of Things – 03:09
— Fraunhofer

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.

Most reliable "best" radio

16

11.7k

11.2k

113.0k