Hardware Contributor

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

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

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!

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.

Worth mentioning is that the SX1280 includes a FLRC (Fast Long Range Communications) modem that can, in theory, go as fast as 1.3mbps. When time allows it may be worth giving it a try.

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie You Rock. That looks like a great testing platform... and tiny. In my 5-minute review I have two points to add that your post(s) solicit: 1. To protect the battery gap, as it is, how about a thin piece of cardboard? It appears that the offsets in the machine pin headers have a little room to slip a small zip-tie to restrain the cardboard so that it does not interfere with the test rig on top. It is easier to hack it than redesign, resubmit, repay and all that. 2. Love to join you on this venture so you are not single handed. I'm guilty of leaching and not teaching. I can't do it now (excuses) but hope to join you and help contribute.

By all means! The more the merrier!

I posted some PPK2 screenshots on another thread that I recently started: https://forum.mysensors.org/topic/11954/most-reliable-best-radio

It does a nice job of measuring milliamps. I wouldn't say the PPK2 is good at measuring <1ua currents though, such as sleep currents. If that matters to you, you'll want a Current Ranger, or TinyCurrents or similar.

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.

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.

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.

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.

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.