Most reliable "best" radio

NeverDie

From time to time I'll try comparing different radios, and when I do I'll try to update this thread.

As a baseline, the first radio I'm trying that passes the test of reliably transmitting packets across the worst possible path in my house (namely, 5 feet below grade behind a concrete footer to the receiver, located on the diagonal of the house on the second story) is the DORJI DRF1262T LoRa radio, which includes a TCXO and operates at 915Mhz. It uses Semtech's SX1262 chip. First pass results over the "worst case" transmission path just described using mostly default library settings are quite encouraging:

12:34:34 May 20 2022
V1.1

104_LoRa_Receiver_Detailed_Setup Starting

LoRa Device found

SX1262,915000000hz,SF7,BW125000,CR4:5,LDRO_Off,SyncWord_0x1424,IQNormal,Preamble_8
SX1262,PacketMode_LoRa,Explicit,LNAgain_Boosted

Reg    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0x800  00 00 00 00 29 07 20 09 00 10 19 D4 10 52 10 16 
0x810  10 4F 10 19 10 4F 10 19 00 58 17 6B 89 00 00 00 
0x820  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x830  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x840  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x850  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x860  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x870  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x880  03 00 00 5F 10 08 00 00 08 04 00 39 30 00 00 0C 
0x890  00 00 00 10 BD 0F 0A 07 10 00 26 01 01 53 06 07 
0x8A0  10 00 AD 20 5A 04 F0 02 56 56 54 43 96 20 40 00 
0x8B0  00 83 11 00 01 04 0A 4C 14 0A 2F 01 6B FF FF 00 
0x8C0  00 A0 20 00 00 00 AC 00 1C 00 00 AB 05 30 12 13 
0x8D0  0C 15 16 40 06 00 00 10 E8 00 00 00 00 00 39 39 
0x8E0  90 39 0C 04 40 20 16 38 06 00 05 04 03 02 01 01 
0x8F0  03 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 
0x900  30 00 00 00 00 64 00 00 00 00 00 00 24 04 47 04 
0x910  00 2F 00 00 00 03 0A 00 15 35 09 00 02 2A 67 08 
0x920  07 04 05 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x930  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x940  00 07 00 03 02 00 10 00 0A 00 03 04 00 14 0C 00 
0x950  00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 
0x960  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x970  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x980  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x990  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


Receiver ready - RXBUFFER_SIZE 32

5s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,1,Errors,0,IRQreg,16
6s  Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,11dB,Length,23,Packets,2,Errors,0,IRQreg,16
7s  Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,12dB,Length,23,Packets,3,Errors,0,IRQreg,16
8s  Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,11dB,Length,23,Packets,4,Errors,0,IRQreg,16
9s  Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,11dB,Length,23,Packets,5,Errors,0,IRQreg,16
10s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,6,Errors,0,IRQreg,16
11s  Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,12dB,Length,23,Packets,7,Errors,0,IRQreg,16
12s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,4dB,Length,23,Packets,8,Errors,0,IRQreg,16
14s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,9,Errors,0,IRQreg,16
15s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,10,Errors,0,IRQreg,16
16s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,11,Errors,0,IRQreg,16
17s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,12,Errors,0,IRQreg,16
18s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,13,Errors,0,IRQreg,16
19s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,14,Errors,0,IRQreg,16
20s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,15,Errors,0,IRQreg,16
21s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,16,Errors,0,IRQreg,16
22s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,9dB,Length,23,Packets,17,Errors,0,IRQreg,16
23s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,18,Errors,0,IRQreg,16
25s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,19,Errors,0,IRQreg,16
26s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,20,Errors,0,IRQreg,16
27s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,21,Errors,0,IRQreg,16
28s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,22,Errors,0,IRQreg,16
29s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,23,Errors,0,IRQreg,16
30s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,24,Errors,0,IRQreg,16
31s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,25,Errors,0,IRQreg,16
32s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,7dB,Length,23,Packets,26,Errors,0,IRQreg,16
33s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,27,Errors,0,IRQreg,16
34s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,28,Errors,0,IRQreg,16
36s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,29,Errors,0,IRQreg,16
37s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,30,Errors,0,IRQreg,16
38s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,31,Errors,0,IRQreg,16
39s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,32,Errors,0,IRQreg,16
40s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,33,Errors,0,IRQreg,16
41s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,34,Errors,0,IRQreg,16
42s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,35,Errors,0,IRQreg,16
43s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,36,Errors,0,IRQreg,16
44s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,37,Errors,0,IRQreg,16
45s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,38,Errors,0,IRQreg,16
47s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,39,Errors,0,IRQreg,16
48s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,40,Errors,0,IRQreg,16
49s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,41,Errors,0,IRQreg,16
50s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,42,Errors,0,IRQreg,16
51s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,43,Errors,0,IRQreg,16
52s  Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,5dB,Length,23,Packets,44,Errors,0,IRQreg,16
53s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,45,Errors,0,IRQreg,16
54s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,46,Errors,0,IRQreg,16
55s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,47,Errors,0,IRQreg,16
56s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,48,Errors,0,IRQreg,16
58s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,49,Errors,0,IRQreg,16
59s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,50,Errors,0,IRQreg,16
60s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,51,Errors,0,IRQreg,16
61s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,52,Errors,0,IRQreg,16
62s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,6dB,Length,23,Packets,53,Errors,0,IRQreg,16
63s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,54,Errors,0,IRQreg,16
64s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,55,Errors,0,IRQreg,16
65s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,56,Errors,0,IRQreg,16
66s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,57,Errors,0,IRQreg,16
68s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,58,Errors,0,IRQreg,16
69s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,59,Errors,0,IRQreg,16
70s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,60,Errors,0,IRQreg,16
71s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,61,Errors,0,IRQreg,16
72s  Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,6dB,Length,23,Packets,62,Errors,0,IRQreg,16
73s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,63,Errors,0,IRQreg,16
74s  Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,11dB,Length,23,Packets,64,Errors,0,IRQreg,16
75s  Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,11dB,Length,23,Packets,65,Errors,0,IRQreg,16
76s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,66,Errors,0,IRQreg,16
77s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,67,Errors,0,IRQreg,16
79s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,68,Errors,0,IRQreg,16
80s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,69,Errors,0,IRQreg,16
81s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,70,Errors,0,IRQreg,16
82s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,8dB,Length,23,Packets,71,Errors,0,IRQreg,16
83s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,72,Errors,0,IRQreg,16
84s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,73,Errors,0,IRQreg,16
85s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,74,Errors,0,IRQreg,16
86s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,75,Errors,0,IRQreg,16
87s  Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,12dB,Length,23,Packets,76,Errors,0,IRQreg,16
88s  Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,12dB,Length,23,Packets,77,Errors,0,IRQreg,16
90s  Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,11dB,Length,23,Packets,78,Errors,0,IRQreg,16
91s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,79,Errors,0,IRQreg,16
92s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,80,Errors,0,IRQreg,16
93s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,81,Errors,0,IRQreg,16
94s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,82,Errors,0,IRQreg,16
95s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,83,Errors,0,IRQreg,16
96s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,84,Errors,0,IRQreg,16
97s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,85,Errors,0,IRQreg,16
98s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,86,Errors,0,IRQreg,16
99s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,87,Errors,0,IRQreg,16
101s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,88,Errors,0,IRQreg,16
102s  Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,89,Errors,0,IRQreg,16
103s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,90,Errors,0,IRQreg,16
104s  Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,91,Errors,0,IRQreg,16
105s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,92,Errors,0,IRQreg,16
106s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,93,Errors,0,IRQreg,16
107s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,94,Errors,0,IRQreg,16
108s  Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,95,Errors,0,IRQreg,16

These results are with the transmitter mote set to transmit at 22dBa. I haven't yet tried to optimize that to a lower number. Rather, at the moment, this is more of a quick existence proof that a radio module exists that, under worst case positioning, appears to be solidly reliable.

As time allows I'll do some energy measurements. According to Semtech's "Recommendations for Best Performance" ( https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HSRX/x.ZO11VNOR4sHFmdUe6NcnHdMHfAiTpsbEcINLKwDvE ) one way to save energy is to power the radio at minimal voltage. It turns out the SX1262 has only an LDO for transmission purposes, whereas the SX1261 also has a more efficient DCDC converter. However, I haven't yet found an SX1261 module in the marketplace that's anywhere near as low priced as the available SX1262 modules. Nonetheless, I reckon one could do one's own DCDC conversion for the SX1262 external to the module, if so desired. I won't know until I do some energy measurements whether it's worth the bother of doing that or whether it's good enough as is.

If I can find an nRF24L01 radio with PA and LNA that can pass the same worst-case transmission path challenge, I'd be interested in measuring how its energy efficiency compares. Because its over-the-air bitrate can be so much faster than what LoRa can deliver, maybe it would prove to be the winner. However, that's only a hypothesis. It will take collecting real measurements to know for sure.

Lastly, I'm aware that a different network topology might be both the lowest cost and most energy efficient of all. For example, using cheap nRF24L01/Si24R1 modules (or nRF52x modules for that matter) in conjunction with nearby powered hubs is probably the lowest cost and most energy efficient of all. So, I'll consider the tradeoffs of that approach also. Maybe the use case for LoRa will turn out to be solely those situations where having a powered hub nearby to backhaul the data is not a practical option.

NeverDie

Reporting back: to a first approximation, I may not even need to look at any other radios. Using the Nordic Power Profiler on the entire mote, not just the radio, shows that the library's default transmission at 22dBm--a transmission which delivers packets without problem over even the worst transmission path in my house--consumes just 94.81ma over a period of 67.33ms:

at 3.3v. i.e. without even any attempt at power optimization of any kind. Well, looking at just that transmit interval, and assuming it repeats once every 5 minutes (e.g. for a TH sensor), then, assuming it was powered by 2xAA lithium primary batteries with a capacity of 3500mah, then I calculate those batteries would last more than 18 years, ignoring self-discharge by the batteries. I deem that good enough for me!

I'll do a more careful calculation with a sharper pencil and more refined measurements, but on first blush it does not appear I need to look for a better radio after all--at least not if the mote is powered by 2xAA lithium batteries and transmitting no more frequently than once every 5 minutes. Of course, being powered by just a droopy coincell battery or the barest whisp of harvested energy would maybe point to a different solution.

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:
1.8v.png
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.

Most reliable "best" radio

14

11.7k

11.2k

113.0k