Most reliable "best" radio

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:
https://www.youtube.com/watch?v=bQINMRcoAsI

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

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

NeverDie

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

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

NeverDie

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

So, the high level overview is this:

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

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

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

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

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

ejlane

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

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

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

NeverDie

Curiously, this keyfinder does appear to function fairly decently all the way down to 1.9v:
1.9v_overview.png
and its current draw actually drops to 29ua:
1.9v_dutyCycle.png
I'm including this screenshot of the Rx interval for completeness:
1.9v-RxTime.png

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

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

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

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

NeverDie

Looking at the chips involved:

only one has markings on it:

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

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

NeverDie

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

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

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

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

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

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

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

NeverDie

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

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

NeverDie

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

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

Most reliable "best" radio

5

11.7k

11.2k

113.0k