Most reliable "best" radio

[NeverDie]

Reporting back again: To greatly reduce the transmission time, I changed the bandwidth to 500 and the spreading factor to 5. The end result is that I still get flawless reception across the worst transmission path in the house. Under these assumptions energy consumption becomes even more manageable:

Using these new measurements and the same type of assumptions as before, I calculate the batteries would last more than 188 years! In reaity, of course, the batteries would fully self-discharge long before then.

Next up: In addition to the above, for further improvement reduce the transmit power itself.

[NeverDie]

Well, with a projected lifespan as long as that, I might as well have it listen for an ACK to confirm that its transmission was successful. Who cares if it shaves 100 years off its lifespan if it still has 88 years left afterward anyway? LOL. I'm guessing that the long tail pictured above is sx1262 simply idling after transmission before the default library code puts it to sleep.

I did try some lower transmission power levels, but apparently my worst-case path needs more or less the full 22dBm. 15dBm, which is the max power of an SX1261, was nowhere good enough. For that reason, I won't bother looking any more for an SX1261 module, since the chip can't natively go higher than 15dBm on transmit power. 18dBm tested better but also was not fully reliable the way 22dBm is. Of course, better antennas could improve upon this, but those are the results with a simple 3.25" quarter wavelength wire whip antenna on both transmitter and receiver.

The "next thing" on the horizon may be LR-FHSS, which stands for Long Range Frequency Hopping Spread Spectrum. According to Semtech, it has even better energy specs than LoRa and better range and better interference/coexistence. Not surprising that everything needs to be better, better, better, or else it won't get adopted. However, it's still early days, and so far there's nothing yet on Aliexpress. I'm guessing maybe in 5 years the LR1110 chip and related modules may start to show up in the marketplace at low prices, but right now development boards are pricey.

[NeverDie]

I was able to separate out the current going to just the SX1262 radio during a 22dBm transmission event:

As you can see, there is no appreciable tail after the transmission event, so in the earlier snapshot that must have been the atmega328p that was drawing that tail current.

So, ignoring the atmega328p, and using just the figures from a transmission interval, then it turns out the lifespan of the batteries (ignoring self-discharge) would be 258
years if assumes such a transmission event once every 5 minutes. I realize that sounds ludicrous, so if your math says differently, please post; perhaps I made a calculation error. Anyway, if the past is any guide, it's the sleep currents that dominate the energy consumption, and I haven't yet accounted for those. So, to tighten up the numbers further, I'll need to measure 1. the sleep current of the radio when it's powered down (though for now I could use the number in the datasheet as a proxy for that), and 2. the amount of energy consumed when waking up from a deep sleep prior to transmission. For #2, I'll definitely want a real measurement, just to be sure. Before that, I'll need to take a deeper look into the library to see how it is currently handling the SX1262 after a transmission event, so I can be sure it's being put into deep sleep. For #1, the equipment I need for accurately measuring nano-amp radio deep sleep current should be arriving on Monday.

It turns out that the purely ammeter function of the Nordic Power Profiler PPK2 seems to be hampered by burden voltage, so I had to use the PPK2 as a power source instead in order to get the SX1262 radio's current measurement. For that purpose I set the power source voltage to 3.0, which is a little closer to the voltage of the 2xAA batteries powering the atmega328p. If the voltages are different, one may backfeed the other.

[NeverDie]

For anyone interested, this is how I calculated the number of years of battery capacity from 2xAA lithium batteries (assuming 3500mah capacity for the pair):

Limitations of this calculation are 1. it considers only the currents involved in the actual radio transmission themselves, not any of the other currents also involved, including sleep currents that surround them, nor any of the currents that would be consumed by the atmega328p, 2. to keep the calculation simple, the batteries are assumed to have no self-discharge. Regarding #2, in reality the batteries would self-discharge long before the 258 years were up. Regarding #1, we'll get to a more complete picture that accounts for the missing drains once I have measurements on the sleep currents, startup currents, etc.

By the way, the above assumes a 23 byte payload per packet, because that is the hello world packet defined by the library that I measured.

Anyhow, the practical upshot is that I could trade-off some transmission power for greater spreading-factor to get the same range and reliability, even if it means giving up some number of years of battery capacity, because, well, with 258 years of capacity as a starting point, I can probably afford to give up a couple centuries. :-)

[NeverDie]

The radio can be powered on as little as 1.8v. If I use the PPK2 to supply the radio with 1.8v, then the current consumed appears to go down, even if transmission power is still set to 22dBm:

Supposedly it has a built-in LDO to down regulate to 1.8v, but I'm not entirely sure what's going on with that. If I power it at 2v, current consumed goes up, but is still less than when it was powered at 3v (see screen capture in earlier post above). Here's the 2.0 volt picture:

Anyhow, if all else turns out to be equal (?), it looks as though powering the radio at 1.8v would be the most energy efficient, and it will keep the module cooler as well because the built-in LDO won't need to burn off as much extra voltage as heat.

[NeverDie]

If both the atmega328p is held in deepest sleep (100na) and the SX1262 is held in deepest sleep (160na), then at the combined 260na for them both sleeping, then 2xAA batteries with 3500mah of capacity would last... ready for it?.... 1,537 years! If you can prove me wrong, then please do. Mind you, that is how long it would be with both simply sleeping and never waking up.

So, the only place left to look for meaningful energy consumption is during the wake-up-and-prepare-to-transmit phases for the atmega328p and the SX1262. The atmega328p can wake up in less than 4 microseconds, so that leaves the cold-start current draw of the SX1262 being the only place left to focus on. In simplest terms, it just needs to power up its TCXO and get it phase-locked-loop tuned to the proper frequency before it can transmit. So, however long that takes plus the (possibly overlapping) time to reprogram the SX1262 registers (because at 160na it will have forgotten everything), times the average current consumed while all of this happens will be the start-up energy draw. I'll see if I can find plug-numbers from the datasheet; otherwise, I'll just program it all and then measure it with the PPK2, which is perhaps the best way know for sure anyway. :-)

[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.