Looking for a recommendation; have a USB powered webserver, two battery powered, remote senders. One sender is a BME280 sensor board. Other a remote receiver has a relay for controlling power to a video camera.
First thought was to use “ESP-Now, Many to One”; however, there is no wifi wake-up for deep sleep for the remote relay.
How can deep sleep be accomplished for the remote relay in this use case?
Remote relay will activate video camera on web server request. Video camera will be turn-off when a count down timer elapses.
Promted Google’s Bard:
Esp32 Arduino C++ code: How to have remote relay that will activate video camera on async web server request. Video camera will be turn-off when a count down timer ends.
Closer examination of Bard’s response; does not resolve deep sleeping of the ESP32 connected to the relay. Relay is to be operated on web server request; unknow request arrival time, maybe only a few times a day. Presently battery powers the camera 24/7 for about 24 hours before requiring a battery swap (10,000 mAH power bank).
Brain storming with Google’s Bard
We may have solution for on demand control of the relay; replace the ESP32 with a pair of nRF24L01 RF Transceivers. Have to order Transceivers; can not wait to try.
Rui and Sara have a tutorial on the nRF24L01:
Waiting on components to arrive to test code. Code uses two nRF24L01 transcievers to control a relay; for external deep sleep wake-up from transmission signal from an ESP32 web server. Relay is turned off by a Ticker interrupt that counts up to 120 seconds; adding an increment of one every second.
Thanks for sharing your observations.
Unfortunately, there is no way to wake up an ESP32 remotely. Because when it is in deep sleep state, it can’t receive signals.
However, I never tried that approach with nRF24L01 transceivers.
Then, let me know your results.
Some reason code does not populate the payload on the receiving Radio 1. Requesting a second set of eyes to look over the code. Suppose it could be a faulty nRF24L01+.
Making progress the nRF24L01+ and RF24 library. Getting response from radio 0 and radio in the RF24 Library example “Getting Started”. Using SPI defined pins MOSI = gpio 23, MISO = gpio 19 ,SCK = GPIO 18, CE = GPIO 5, CSN = GPIO 17; board is an ESP32 Devkit V1, 30 pin. Discovered pin 4 if I remove wire from breadboard; radio 0 transmits successfully if I keep hold of the wire (touch pin ?).
Working with ESP32 DevKIT V1 and nRF24L01+
Question about CE and CSN; does pinMode need to be used? Used RNT sketch for finding SPI pins.
Continuing the learning journey…
Have two nodes of nRF24L01+ both transmitting and both not receiving. Here is a short video of progress:
Another project that should only take a few minutes…
I’ve seen your video.
Are you using the exact same code for both modules?
Using the RF24 Library; copied and pasted code from GettingStarted example to Radio_0 and Radio_1. Changed code for radio_1 to radioNumber 1 and role 1. No receive. Both Radio_0 and Radio_1 can transmit.
Library RF24 is version 1.4.8.
Have nRF24L01 radios transmitting and receiving!
SPI pins for ESP32 DEVKIT V1: MOSI = GPIO23, CE = GPIO5, MISO = 19, SCK = GPIO18, and CSN = 17.
SPI Pins are correct for ESP32 DEVKIT V1; have it both transmitting and receiving now. Swapped out all Dupont wiring longer than 10 cm. Change channel with radio.setChannel function to 175 on both Transmitter and Receiver. Added 100 microfarad, 16 Volt, elctrolytic capacitor between 5 Volt rail and Ground.
Transmission successful! Time to transmit = 403 us. Sent: 5.96
Transmission successful! Time to transmit = 403 us. Sent: 5.97
Transmission successful! Time to transmit = 403 us. Sent: 5.98
Transmission successful! Time to transmit = 403 us. Sent: 5.99
Transmission successful! Time to transmit = 403 us. Sent: 6.00
Transmission successful! Time to transmit = 403 us. Sent: 6.01
Transmission successful! Time to transmit = 403 us. Sent: 6.02
Transmission successful! Time to transmit = 403 us. Sent: 6.03
Transmission successful! Time to transmit = 403 us. Sent: 6.04
Received 4 bytes on pipe 1: 6.25
Received 4 bytes on pipe 1: 6.26
Received 4 bytes on pipe 1: 6.27
Received 4 bytes on pipe 1: 6.28
Received 4 bytes on pipe 1: 6.29
Received 4 bytes on pipe 1: 6.30
I’m glad they are working.
Then, let us know if you can wake up the ESP32 with a signal from the module.
put the ESP32 into sleep, waiting for an interrupt. When the receiving Rp24 gets a packet, it can be programmed to generate an interrupt on one of its pins, and thus waking up the ESP32. The receiving ESP will thus be very low power consumption (but is probably inside somewhere connected to power, so probably not an issue anyway), but the transmitting device, along with the always-on camera will be power guzzlers. Even having the camera in a stand-by state, waiting for an “event” will be power consuming. …. you need a solar panel to keep things charged and not have to change out/recharge the batteries. … a solar panel is the answer to low-maintenance surveillance, in my opinion. Good luck ! (I know Random Nerd Tutorials has stuff on solar-based projects).
Using a pair of nRF24L01 transceivers, have coded a way to switch a battery remotely, put the ESP32 to deep sleep and wake-up using external 0, RTC_GPIO, and power up/power down the transceivers.
Thank you Joe for your input; have coded a way to accomplish task of remotely switching a battery, switching is by Async web server request. Request “control” variable, determines on/off option. “Control” variable selects one of two options. Each option has three tasks: task one, switches battery power, task two switches transceiver power mode, task three switches deep sleep state. Have not “field” tested project; tested with two multimeter monitoring curren of transceiver bus( only a pair of nRF24L01’s) checking voltages with the other multimeter. Performs functions as coded; works well.
Project is a work in progress.
Pair of nRF24L01 current draw; transmitting is 30.4 mA in non-standby mode, 6.6 mA in Standby I mode measured with multimeter. Trasnsmissions will only be a very small fraction of a second.
Less than ten dollars US; two, 2.4 GHz transceivers, can be purchased.
HiLetgo 2pcs NRF24L01+PA+LNA Wireless Transceiver
Couple of recommendations; identify ground pin using a multimeter, purchase a nRF24L01 piggyback voltage adapter; allows use of five volt power. Some boards have trouble supplying required transceiver current. Do not let early failures stop your project or ask to return defective transceivers. Fully explore reasons for failures. Mine turned out to be coding errors. If the code is not allowing transceiver to exchange data, check your code! Fault hardware last!
Have a working Webserver with a nRF24L01 controlled remote battery switch!
Prepared a under two minute video of processing web request for “Camera View.” Asyncwebserver request turns on switch by triggering a 60 second countdown timer and send data = 1 to the first nRF24L01. Second nRF24L01 recevies data = 1 and turns on switch, Wakes ESP32 from Deep Sleep (using External 0, RTC_GPIO wakeup pin.), and powers down the 2nd NRF24L01.
Still a work in progress. Will be linking to Github complete project when finished.
Thank you so much for sharing this.
Then, I’ll have to take a look at this subject too. Very interesting. Thank you for your contribution.
great work William, and well documented! I have been dealing with remote devices using LoRa, but now am working on something similar to your project involving a remote relay control and am looking into this NFR24 radio (which I hadn’t considered before). The main issue I’m struggling with is power consumption by the remote battery-operated device; (the “inside the home device” is a Raspberry Pi, so no problems there). I need accurate time (waking up and accessing the wifi outside then getting an NTP update; I don’t trust the internal RTCs), and keeping the relay on for hours (I’ve gone to a latchable relay that gets an impulse to change states, allowing the microcontroller to go back to sleep). This project will take a while for me to get to the level of sharing, but I hope to down the road. Thanks for your help with the radio especially.
Good Afternoon Joe,
Been dealing with an issue I missed when I did the video; a line of text from “void setup” was being printed to the Serial Monitor after going to sleep. I found a solution today; one of the fixes I had forgotten to code the bitmask for the wakeup pin. Other fixes involve a wiring change; added wire from CE (GPIO21) to a 4.7K resistor connected to GPIO26. Changed pinMode on the IRQ_PIN (GPIO26) as I recall… memory is not great.
Still have one remaining issue; on ESP32 DEVKIT V1 reset, I the Serial Monitor shows is the sketch title and the boot count. The battery switch is on; I do see the countdown timer expire with “Going to deep sleep” message. Will get this issue fixed.
Webserver is in the house; so NTP client is available for tasking code. My situation is different; I am using a Async web Server request to turn-on a video camera (that is a low demand option on the web server) over the air by RF (nRF24L01). The web server has a count down timer (Ticker, once method) to turn-off the video camera, again by RF to ESP32 that has RF wake-up capability.
Will edit this post later today; sharing the web server and the relay receiver code.
Thank you Joe for your positive, appreciative feedback.
William, do you have data on the battery consumption of the remote device? Having the nRF24 always in listen mode is basis of the question. Also, that’s a good idea to send NTP data from the AC powered server to the remote – I’ll be trying to incorporate that … I still need an MCU out there to do the proper timing of course.
High current readings may be due to “burden” resistance of the DMM.
Wake current 27 mA and Sleep Current 3.3 mA. These readings are much higher than the Nordic datasheet. May have inadvertly damaged the nRF24L01 power management system of the device by “handling” static discharge.
Ran into a “handling” issue with static discharge damaging nRF24L01; was working, suddenly it stopped. Device is “static sensitive.” Take proper precautions working with these device. Also, a 100 uF, 16 volt Tantium capacitor is recommended; soldered directly to the backside of the nRF24L01 pcb between Vcc and ground. Tantium capacitors are polarity senitive.
Have ordered another set of transceivers from Amazon.
That’s a lot of current in the Rx mode … the LoRa modems are spec’d at ~10ma by the way. I’m exploring the RF1212 which claims to operate at 3ma. I’m really trying to get very low power operation, and will be using a small solar collector to provide the 24/7 energy needed.
According to Nordic’s nRF24L01 datasheet from page 14 of the document linked above is their Power Compsumption table:
Supply current in power down mode is 900 nA
Supply current in standby I mode 22 uA
Supply current in Standby II mode 320 uA
Tranmit current ranges from 8 mA to 11 mA
Will recheck on the new nRF24L01’s once they arrive.
Sharing an Arduino.cc post on nRF24L01; that forum moderators refer queries about the device; as well as, Simple sketches to get started.
… it’s the Rx consumption that’s important. For remote operation, you can always put the Tx in sleep mode, awaken it to transmit and then go back to sleep – takes seconds. However, when the design is to receive instructions from an AC-powered server, the remote Rx is always on, and that’s a drain on the batteries (you could put it to sleep when you know you’re not going to tell it anything however). For a design where the battery lasts 1 year, every mA is significant. … of course it depends on what you do once you receive the instruction to turn on/off (a camera being on for 20 seconds and having the file transmitted will take some energy, for example). In my application, I want tell the radio to turn on the micro’s webServer, and then talk to it to tell it what to do, using latching relays that allow the micro to go back to sleep; there will be current drain on what I want it to do, but that’s part of the solar cell charging budget).
Good Evening Joe,
Have read that the nRF24L01 in power down mode (in my case~95% of the time, maybe higher). IRQ signal will be available while radio is powered down; to wakeup the ESP32. ESP32 DEVKIT V1 will be able to go deep sleep after turning off when the countdown timer expires. Tranmit only uses one byte of data.transmitted small, faction of a second transmit time. Camera will be on two minutes when it gets a web request turning on the camera. Camera is only a live video feed, no file transfers. Should be able to power down the radio right after battery switch has powered the camera.
I agree for the need of solar power; mounted a solar panel on the roof of the shed, have a “Harbor Freight” ammo box being turned into Solar management and battery box. Plus there will be volage conversion to five Volts and three point three Volts. Will be a good learning experience.
Hello William (I hope others are benefiting from this conversation ! ). I am confused about what you are trying to do. My understanding is that you want to control a remote relay from inside the house (or some place with AC power, whereas the remote device is all run on batteries). In this scenario, the Receiver of the remote relay is on all the time, waiting for instructions about the relay, and thus power consumption is a major concern. Yet you keep bringing up the Transmitter triggering a sleeping MCU, and as I’m assuming that’s in an AC powered place, I need correcting of your setup. Thanks.
Short answer regarding AC power; no AC power is available in the shed. Camera draws 180 mA when powered.
Project is a “learning experience”; just trying to see if a solution is available to remotely turn on and turn off, battery power for a Wyse Cam v3. Camera is only used at best three or four times a day by Internet website visitors. Camera will only be on for a couple of minutes. The idea is to use the n24L01, radio.powerDown() command to switch transeiver to lowest current comsumption; when a web request comes in, use radio,powerUp() to start the process of turning on power for the camera. Current consumption in powerDown() mode is typically 900 nA according to the Datasheet for the nRF24L01.
Several unknows about the “signaling” of the IRQ from the “master” nRF24L01 to the “slave” transceiver. Have been researching using Google’ Bard and ChatGPT; in the interest of those followning this discussion, will share a link to ChatGPT conversation today. Link will give non-AI users an insight to AI in action.
Hi William, thanks for more clarification … but how is the web request serviced? Always-on ESP-based WiFi in the shed? … if not, and instead it is in an AC-powered place, how does the relay-based system “hear about” the request? Is it the RF24 radio in always-on receive mode? On the other hand, if the WiFi unit is in the shed, presumably drawing current 24/7, why is another device needed to turn on a relay? … still confused. Thanks for continued clarification :–) – Joe
oh, and please, I too am in constant “learning mode”. But having been a design engineer for so long, now retired, I now do “silly” things, making solutions looking for problems, all the time … probably fantasizing about a great start-up idea for the next life :–) Sometimes, I make something worthwhile though. Sounds like you’re making something worthwhile :–)
Hi Joe, Appreciate your questions. Async Web Server is located in the house, there will be a bme680 sensor to be mounted outside in the yard, the third ESP32 will controll the power to the Wyse Cam 3. n24L01 has an IRQ pin available; this is an unknown, likely need to go down a few rabbit holes, this was todays ChatGPT conversation. Just getting more info than what I have available now. If the IRQ is available in powerDown(), idea is promising, if not will have to try another method to wake the ESP32 relay board.
Posting my in-the-works code for ESP32 webserver-transmitter, ESP32 Relay Controller-receiver, along with nRF24L01 Webserver notes/code snippets.
Good news regarding using nRF24L01’s, IRQ in radio.powerDown mode; the IRQ is available!
PDF: ChatGPT Discussing code and use of IRQ
Found very little information on using RTC_IO pin use; turned to Google’s Bard…
Here’s a guide on using RTC_GPIO pins on ESP32
Anyone with RTC_GPIO pins experence? Any corrections to Bard’s Guide?
HI William … glad you are find the interrupt pins helpful to manage sleeping. I built 10 LoRa boxes which used the interrupt to wake up after I had found in prototyping that the LoRa reset line glitched when the ESP woke up, putting the radio in the wrong (default) frequency and hanging. If interested, you can look here for a discussion. LoRa is better for distance, which you don’t need. I’m still designing with the RF1212 at the remote receiver outside, responding to a poke to then go and wake up the ESP and enable a web response to control something there. On paper, I’m preferring this device over the nRF24 due to constant-on current consumption issue (the RF1212 is suppose to be 10 ma lower current).
I looked at your Rx-web code, but unfortunately my eyes glaze over for code over 100 lines (us hardware people have to live with the curse of software ;-), but I have a question on the non-web Rx code: why do you start up the radio constantly in the loop? (it does so whenever !radio.available … it would seem better placed in the setup, putting it in listening mode once per wakeup, and then just run around in the loop() waiting for someone to say something … but I”m probably missing something. Good luck with your project!
Good Morning Joe,
Thank you for finding the issue with coding of “! radio.available”; will correct the issue.
Have the GPIO_IO interrupt working (sort of…) Serial monitor shows “IRQ pin is actively LOW,” then produces a panic core dump and stops responding. Just starting to investigate core dump. Learning to use the standalone Arduino IDE 2.0, ESPExceptionDecoder. Have not been able to get anything other than a zero byte output file; issue with a path, according to the error log. Another issue is the core dump did not complete on core zero.
Feel closer to goal than previously…
Okay on the “curse of software,” so many coding tasks that should take five minutes; take forever to be completed…
Most of the task goal completed!
Successfully using nRF24L01 IRQ to wake-up, ESP32 deep sleeping and remotely control a switch by web browser!
Gist log of ESP32 Booting, turning on battery power on and waking from deep sleep, turning battery power off and going to deep sleep. Code uses GPI_IO to keep RTC_GPIO pins powered during deep sleep.
No attempt to optmize current compsumption has been taken at this point of development.
Internet search found an interesting, very detailed discussion topic of interest:
Takes a different approach than I am developing; well worth the read, uses a modified car key remote.
excellent find William !! … similar to where I was heading with the RF1212, but this Anntem 433Mhz RF receiver has sub-mA consumption and meets my ~100 foot requirement. The only concern is that it may be triggered by others in the neighborhood. … it’ll take me a long while to explore, but a great direction (I’m using a Lithium cell to 3.3V buck/booster like this; also using a latched relay like this to turn on a Lithium cell to 12 volt supply like this). Good luck in your project.
Thank you Joe,
Another Internet search found this device:
SX1278 LoRA UART RF Module 433MHz
Ordered a pair for experimenting with lower current consumption and over-the-air device wake up.
Returned 433 Mhz devices; wrong frequeny for use in North America, need 915 Mhz devices. Need to be aware of what frequency is used in your region.
Thanks William. Let me know what the consumption is for “always on” receiver mode (is that the “air mode” they talk about?). I’m using LoRa in remote settings (> 500 meters) but only as wake-up transmitters 2x/day for a few seconds. The batteries (15Ahr lithium) last over 6 months. I know about the good encryption and security of the LoRa devices I’m using (RFM95W); one would hope these devices also have such security (I doubt the Anntem 433Mhz RF receiver have any, which makes them a no-starter for me).
We really should move the low power discussion to a different blog to be useful to people. (e.g. “How to design low power remote receivers for the 2_3_Outputs_Websockets module in Building Web Servers”) … Can you start that?or maybe Sara has a suggestion for reaching an audience more interested in remote battery operated always-on receiver wakeup of a web server).
Good Afternoon Joe,
Topic I posted on Espressif Systems, ESP32.com. Posted topic August 23, 2023; has been viewed over 9,000 times. Topic is not quite your suggestion; however, there seems to be a interested, large audience.
Might be the place to start a topic for designing low power remote receivers for web server applications.
Will hold off starting topic to see if Sara has suggestion; on where to post for a larger audience.
Plan to add this project to my presence on Hackster.io: My projects
Sara, are topics in this forum able to be linked outside of this forum or Facebook Group?
Posted this Topic thread to “Random Nerd Tutorials” Community, Facebook Goup.
Closer to completion; have a working wireless 2.4 Ghz.interrupt, driven by the IRQ pin on nRF24L01. Simulating a relay with an LED; I have control of turning on and off the LED, plus putting the ESP32 into deep sleep and wake by external 0, interrupt from the nRF24L01, IRQ pin. Have made no attempts to lower current consumption; I am using “piggyback” 5 V to 3.3 V, voltage regulator with LED. Current measurement is 27 mA. Have seen current drop to 3.1 mA; unfortunately, this “radio” has to be in listening mode to receive the IRQ “broadcast.”
Have another pair of transceivers on order; with over-the-air radio wake up. Will see how these versions work with this code.
Readme from my Github Project:
ESP32 DEVKIT V1: ESP32_nRF24L01_Remote_Relay
Uses external wake-up by 2.4 Ghz., RF Interrupt for a Deep Sleeping, ESP32. n24L01, transceiver; code uses two, nRF24L01 to remotely switch battery on or off for a low demand, video live stream. Web camera consumes 10,000 mAH every 24 hours; switching battery on/off by webserver, URL Request over the nRF24L01 should extend battery between battery charges
Thanks to Google’s Bard for answering my many prompts and Bard’s guidence; especially with RTC_IO, Bard helped make this project a reality!
02/03/2024 Files have been updated; supporting switching battery on/off, putting the ESP32 into Deep Sleep, and waking ESP32 from Deep Sleep; using external 0, RTC_GPIO pin.
SPI-ESP32 pin connections for ESP32 DEVKIT V1 board:
MOSI 23, MISO 19, SCK 18, CE 5 CSN 17 IRQ 33, Vcc, and GND. Pins were verified by successfully running RF24 library’s “Getting Started” example code.
Project is a work-in-progress… ..
… a solution looking for a problem? With huge remote load requirements (e.g. a camera, lights, irrigation, etc), what’s the point of minimizing something that takes only 10% of the energy (i.e the ESP/WiFi system; forcing it into sleep mode … why)?
I’m sure the next step is using solar charging, in which case all this may be mute. Just leave the webserver/WiFi on, and keep the batteries charged with the sun, with energy for the load as a focus. .. and maybe just leave it on during the day when it may be important, putting the whole thing into sleep at night…. focus on solar charging and forget about the complicated alternative RF wake-up scenarios.
We do love our DIY projects, and really, that is reason enough to continue (I enjoy this stuff). But from a practical point of view, is this more in the camp of “just something to do” ? I stand to be corrected !!! (having the same fight with myself over this very issue!). … signed: a retired product design engineer.
Like climbing a ladder; best to do a step at a time… might seem like a problem looking for a solution now; for now it is a proof of concept, Using a radio transceiver interrupt to wake up a deep sleeping ESP32 or to go into deep.
Is your plan to have the Tx part of the transceiver be in the house, connected to a web server so that you don’t need to be tied to a computer to send something to the proprietary Rx? … certainly doable, but complicates both the hardware and software. Sticking with just wiFi with heavy remote loads would seem a simpler and effective way (and lots less hardware – you seemed to like the idea that things are inexpensive, like the transceiver .. much less so without it and without the indoor hardware!). That said, I do like “proof of concepts” and sometimes they trigger other ideas.
02/07/2024 Updated project files to Github Repository. nRF24L01, transmitter and receiver have successfully turned “relay” LED on and off. Wakeup and Deep Sleep have been accomplished.
Feedback from anyone that tries this code is welcome and appreciated.
02/20/2024 Updated project files to Github Repository. nRF24L01, transmitter and receiver have successfully turned “relay” LED on and off. Wakeup and Deep Sleep have been accomplished.
Feedback is welcome and appreciated.
Fixed Wakeup issue of being unable to wakeup from deep sleep by simplifying sketch; removed GPIO_IO configuration and changed GPIO pin connections.
That is a nice project William, and I’m sure you learned a ton doing it. Congratulations in staying with it! I don’t have much more to comment about – seems it is working fine; if you post a hardware schematic, I’d have more to say ;–).
I know you will be eventually thinking about power consumption. Presently, I am focusing on low power receivers to do similar to what you’re doing with the following features: an AC-powered home web server (Raspberry Pi-base) connected to a transmitter which will communicate to an ultra-low receiver (an RC-WuTRx-XXX from Radio Controlli – not inexpensive, but initially labor and time are more my issues than component costs; an RF1212 in low duty-cycle mode is also a low-cost possibility if I make more than 10 of these). This RC-WuTRx is a 120 microamp receiver and will do switching and also wake up another web server (ESP32-based) when a router is available to allow more control. Solar power will keep this collection and the loads up for over 1 year on 10 to 20Ahr LiPoly cells (that’s the goal anyway). If I ever complete this, I’ll document it. (a previous post of yours led me to this, so thanks for that!).
So what change in particular cured the problem ?
Problem was resolved by removing all of the rtc_gpio statements; leaving just attaching the interrupt, wakeup method, and going to sleep. Followed this article SPI, GPIO pins were found by using Rui Santos’s code for finding default SPI pins for CLK, MOSI, MISO, and SS. CSN was chosen from Rui’s article on “Which GPIO should be used”. Chose GPIO17; since there was nothing noted of “special” conditons like “high on boot.” relayPin was by trial and error. Knew I wanted the LED ‘ON’ when the ESP32 was awake and ‘Off ‘ in deep sleep; GPIO17 (CSN) produced reaults I was looking to archive.
Schematic for nRF24L01+ Project; added to github project repository.
tried accessing the schematic but states “No preview available, file is in owner’s trash” … am I doing something wrong, or is it just not available?
ok, got it. Looks straightforward – no helpful comments for you, other than happy it works for you. For low power considerations, I had to go to the “bare modules” – WROOM-Sx, to avoid all the power grab by the 3.3V regulator and UART-USB converter. (using the S3 version since they recommend not using the S2 anymore).
Any thoughts on the EBYTE E220-900T30D transceivers; these devices have WOR (wake on radio), where the radio awakens from a special transmission from the master device. If I understand correctly; sleep current is 5 uA.
If we go any further on this topic of Receivers (not mentioned in the title of this blog), I will open a new question (i.e. a question to Sara and Rue: is this something you want discussed in your blogs? … in this blog … or another one?)
As far as I can see, there are 2 companies contending for the ultra-low power chip market (i.e. on/off Rx very low duty cycle) : TI (Phoenix AZ) and Semtech (Camarillo CA) – there could be more but I’m just not aware of them. TI has the CC13xx series and Semtech has the SX12xx series (and the LLCC68 chip). The TI chip is more than a modem – it’s a micro-controller with the sub-1Ghz modem (much like the ESP32 is a micro with a 2.4G WiFi modem). The Semtech devices are pretty much just sub-1Ghz modems (just like the NiceRF LoRa modems Sara and Rui have tutorials on, only these don’t support low duty-cycle on/off Receiving). (note that sub 1Ghz gives you long distance; stuff at 2.4Ghz (like the nRF24 and WiFi) don’t)
However, a chip one thing – we all look for modules that have these chips “glued down” with proper support components. I’ve only found 2 modules of interest: Radio Controlli (Italian company) RC-WuTRX-434 based on the TI chip, and that Ebyte (Chinese company) E22-900T30D based on the Semtech LLCC68 chip. Of the 2, I personally like TI as they have very good documentation and good devices (and have been designing with them since the 90’s). According to RadioControlli, they claim a duty cycle of 0.02% (250uS on, ~1sec off) which consumes ~10uA. The Ebyte device spec is so nebulous that it’s hard to know what it really does. It has a “mode 2”, which “supports wake-up over air”, but not details. Maybe someone else can fill in the blanks, but if I have to dig into the specs and software on how to figure out how to do “wake-up over air”, I’ll go to TI’s chip documentation 🙂 … In the meanwhile, I’ve got both on order and “someday” will be able to report results. Hope this helps.
Thank you for your knowledge and experience with transceivers. Looking forward to trying xreef’s Ebyte Library example for “WOR”; wake on radio.
Couple of Renzo’s articles on the E220 Series from Ebyte:
Thank you Renzo Mischianti for your detailed Ebyte E220 articles, your time, and your experience!
Thanks William … filling in the blanks you and Renzo! Were any current measurements made (not easy to do at uA levels, so probably not). Do you know what the duty cycle of the receiver in WOR mode is? Finally, is the code a demo code? … there’s an infinite loop that would imply the 8266 is not asleep (so a practical example would have it go to sleep and wait for the interrupt from the modem, correct?)
Will be coding a WOR with deep Sleep. Likely will need to have Google’s Gemini assistance and guidence. Xreef example is a good starting point. Will be modifing his code.
Hi William … I opened a new blog “ultra low-power long-range receivers”, and Sara responded … check it out, and please add your info on WOR (sleep interrupts and solar are interesting topics, but I really like the focus to be on low power long-range (i.e. not 2.4G stuff) receivers. (this blog on waking up remote Receivers has gotten too long and I believe many viewers aren’t interested in adding to the discussion given the title – thus a “new blog”). Thanks for your info so far!