Hi Joe.
 
There is no problem for you to be discussing that subject on our forum.
I think it’s a very interesting subject. At the moment, I’m focusing on other subjects, but I always learn a lot from those discussions. Even if I’m not participating in the discussion, I always read everything. Many times, I pick up discussions like that a couple of years later to create some new tutorials.
 
Additionally, those discussions may also benefit other users who are interested in the same subject.
 
You can, of course, discuss those subjects in other places, but there’s absolutely no problem in sharing your thoughts in our forum as long as its related to the content of our website.
 
I hope this is clear.
 
Regards,
Sara
 
 

As a starting point of this topic, let me mention that building a remote transmitter that wakes up a few times a day to measure temperature, etc., does not present a serious battery capacity problem (Sara and Rue have tutorials on this).  However, going the opposite direction – having a remote receiver accepting commands from a home station – is a battery capacity problem because the receiver needs to be on all the time.  Most RF receivers on the market are “always on” versions and suck the battery dry in no time (i.e days, not months).  However, from what I’ve been directed to and seen, some chip companies are developing circuitry which allow a receiver to come on for a very short time, then go to sleep, popping on/off with extremely low duty cycles, making the battery usage very very low.  Of course the homebase transmitter has to accommodate that and the receiver has to acknowledge that it in fact “got it”, by turning on its transmitter for a short time.  Here is a blurb I wrote about these receivers in another question that had to do with interrupts:
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. 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. …. I’m hoping others can add more here (William Lucid has a lot of good stuff to share :–)

Internet search found an interesting, very detailed discussion topic of interest:

Low power wake-up receiver for an ESP32 battery-powered project

Takes a different approach than I am developing; well worth the read, uses a modified car key remote.

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.

Ebyte E220-900T30D User Manual

Library for Ebyte E220 Series

Thank you Joe, for your knowledge and experience with transceivers.  Looking forward to trying xreef’s Ebyte Library example for “WOR”; wake on radio.

Renzo Mischianti (xreef) Ebyte Library WOR example

Couple of Renzo’s articles on the E220 Series from Ebyte:

Ebyte LoRa E220 device for Arduino, esp32 or esp8266: manage Wake On Radio and sends structured data – 5

Ebyte LoRa E220 LLCC68 device for Arduino, esp32 or esp8266: specs and basic use – 1

Thank you, Renzo Mischianti, for your detailed Ebyte E220 articles, your time, and your experience!

Taken from previous discussion:

How to wake-up ESP32 remotely on demand; using radio?

Regards,
William

… that’s an average sleep current.  Think about what needs to happen when a “command” is sent from the home-station: the receiver catches a transmission in its very very short awake period, then does filtering to figure out if it’s really something worth listening to (this probably happens almost every cycle in populated areas — power needed every cycle). If the filtering proves successful (which most cycles it doesn’t — wasted energy), the transmitter is turned on to send back an ack to the transmitter (which may be desperately trying to connect in the very very short time a receiver is listening – it needs to know to stop trying and continue), and then an interrupt is sent to the microcontroller to “do its thing” … in that scenario, it’s not 5uA, but definitely low current.  Of course, the “thing” could be very power-hungry, like turn on a light “until I tell you”, or very low power, like “unlock the gate 500 meters away to let someone in” …. that’s another issue (e.g. solar-assist; a different topic).

Have start working on code with guidance from Google’s Gemini; to add ESP32 deep Sleep to the Xreef, Ebyte, E22 Series library example:

Guidance from Google’s Gemini

William

Renzo’s articles in CATEGORY: ESP32 PRACTICAL POWER SAVING are a must read for complete details on power saving on the ESP32.  All categories of sleep and wakeup are covered.  Well done Renzo!

Renzo’s ESP32 practical power saving: preserve gpio status, external and ULP wake up – 5 fills the void of little information available, searching the internet for RTC_IO management in deep sleep.

Regards,
William

Thank you William for your continued source of info.  …. but I have to say that this is a blog about “ultra low-power long-range receivers”.  The ESP32 is not in this category (nor is solar or other important but extraneous issues). I’m fishing for comments from people with hands-on experience with these kinds of devices. … Let’s stay focused on this issue.  Thanks!

In the sprirt of RNTLabs forum helping forum readers, would be good to provide application information of “ultra low-power long-range receivers” in addition to comments from people with hands on experience.  Some readers of this topic may be just starting out their journey of using “ultra low-power long-range receivers”.

Regards,
William

… certainly true, but as this blog gets loaded with other issues …. and long, I think the audience I’m hoping for passes it over (there’s the other blog which you already referred to).  …. I’m looking for hands-on experiences with ultra low-power long range receivers.  Once yours is up and running, this is a good place to add something.  In the meanwhile, let’s be quiet and wait for others struggling or with experience in this specific topic.  Thanks.

Here are some notes on Ebyte, E220 Series WOR (Wake on Radio) Configuration settings:

Ebyte, E220 Series WOR Configuration notes

WOR Current meter readings

E220-900T30D Completed project code 

William

Thank you William for implementing with the Ebyte device – good work in getting this to work!!
 
I will say that “completed project code” is good for a tutorial (along with the tons of supporting info like Sara and Rui give), but before delving into the “devil’s in the details”, it’d be good to have an overview.   Can you give “an executive summary” of your configuration settings, current measurements and issues you may have had and solved?  Thanks! – JoeM

Good Morning,

Started E220 project by reading all eight Renzo Mischanti’s articles.  Only issue was being to eager to get it working; giving time for the articles to sink in helped greatly.

Documentation of E220-900T30D Project code

Regards,
William

Thanks William … that is helpful for getting a demo between Tx and Rx going.  I can see what you mean by all the info from Renzo!  I’m not clear what the video of current readings is showing.  Is that the Tx or Rx?  Spiking to ~15ma and otherwise at ~1ma and sometimes below?  Can you explain what is being shown there?  Thanks.

I do have a question about how this Wakeup Over Air works.  I understand the receiver being on ~0.05% of the time, waking up every 1 second for 1/4 mSec.  Given that this is such a long time asleep, what does the Tx do to eventually “make contact” ? … does it send a 1 second preamble that eventually gets the attention of the Rx?  … or if not, how does the Tx know that the Rx received the message?  (is there an ack/nack handshake being used?).  Thanks for any clarification.

Video of monitoring WOR current; meter was insert in the five volt input to the EByte E220-900T30D.  High reading WOR is transmiting; low reading WOR is inactive or sleeping. When device is in Mode 0; normal mode measured 11.540 mA, ESP32 awake receiving message (E220 device current).

WOR Cycle details:

WOR Cycle –from E220 library “Readme.md”

AUX Pin timing diagram

E220 library handles checking if messages are received and sends a reply back to sender.

Checkout this article for device specifications

William

Hi William … again, thanks for all the efforts in this area.  I now see that Ebyte designed the device to have a “long preamble” Tx mode, so the “mostly asleep” Rx will catch part of it when it wakes up, and then stay awake. 
 
I still am not clear about the video of the current.  Again, I assume this is on the Rx device, and maybe the Tx on that transceiver is kicking it to provide an ack back to the main station – can you confirm that?  Also, can you add a delay so that it becomes clearer about the Rx current in sleep mode, and then a delay so we can see the Rx’s Tx kick in momentarily?  That would require another short video.  Thanks!

Hi Joe,

Looking at the “E220_Transceiver_Videofeed_Receiver.ino” I am wondering where to insert or change delays before creating a new video; in setup there are Mode_2_WOR_Receiver (enables WOR), Mode_0_Normal, and Mode_2_Power_Saving (sleep).  Inside of loop there is Mode_0_Normal.  Delays are set to 1000 mS.

Current reading video the DMM is connected to the receiving E220-900T30D device.  Meter is in series with five volt from ESP32, Vin to Vcc of the receiving E220-900T30D.

William

… ok. Change the delay to 10 seconds or whatever – that will help.  Also, since the DMM is measuring transceiver current at the remote (Rx) site, it’s important to understand what the Tx is doing there.  At this point frankly, and it’s only me, I’m more interested in why and what are happening than code.  … I need the “big picture” to understand this system.  Code is the devil in the details, necessary and full of issues, but 1st things 1st – what is the sequence of events going on at both the remote and the “home” station.   Thanks for your time on this ! … it’s really helpful  :–)

Good Morning Joe,

Made changes in delay to all four delays of 10000 mS and 20000 mS; not sure if it is a limitation of my DMM, I did not see much of a difference in timing between high and low values.  Will create video later today.  I am thinking an oscilloscope or Nordic nRF-PPK2 – Power Profiler Kit II  is needed to really get the detail you are looking to find; equipmentI I do not have access to use.

Renzo’s rely to my post about the varying sleep mode current:

Hi William,
It’s normal the device use a WOR cycle to check if some message is coming, you can find more information here.

WOR Cycle
A critical configuration parameter is WOR Cycle, for the sender is essential because It adds a long preamble to the message (long as wake time). The handset uses the wake-up time as the cadence for checking a wake-up message. So if the receiver checks every 2000ms (polling time) if there is a message, the sender adds a 2000ms preamble. The receiver intercepts the message preamble, waits for the actual message to read, and returns to power save mode.

So If you want to maximize the power save, you must put minimal WOR Cycle. If you want more efficiency, you must do the inverse.

Bye Renzo

WOR polling time can be set from 500 mS to 4000 mS.  Default polling time is 2000 mS.  I am using the default polling time. Both sender and receiver must be set to the same WOR polling timing.

Did you have a look at AUX Pin timing waveforms?

William

Hi William … it is tough to measure sub mA currents. I did it to find out sleep-mode currents by switching in a 1Kohm resistor in series with the supply when the unit went to sleep, making the measurement — 1 uA = 1 mV — then shorting the resistor so that when it came back on and needed many mA of current, it would properly work.  Given that the max time the Rx can sleep is 4 seconds, that might be a little tricky to do, but possible. 
I now understand what the current spikes are in your video: they are the Rx waking up, powering up the system.  They aren’t due to Tx activity.  I’m satisfied with the way it is working, and believe the specs that the Rx sleep mode current is low uA … no need to prove that.  What would be useful to know is how much energy (i.e. Amp-hrs) the system draws when you have, say, a 1 second cycle.  For example, that might be a 20mA surge for the 250uSec that the Rx is on, then back down to low uA.  The calculated Ahr would be 0.02A x 250uS x 3600 pulses in an hour = 0.018 Ahr rate … in 24 hours it would use 0.43 Ahr each day … so a 10Ahr Li battery would last ~23 days.  Thus it would need solar if it’s to last a year.  (I know energy is really watt-hrs. When I assume 10Ar Li battery, I’m assuming one is using ~3.7v , so a 10Ahr Li battery is really a 37 watt-hr battery.  It’s always confusing when phone cell backup batteries, running at 5 V from internal 3.7 V Li batteries, are spec’d at Ahr … which is it in watt-hrs?  3.7 x Ahr, or 5 x Ahr … makes for good marketing). Anyway, solar looks necessary with these Ebyte devices for long-term usage (of course, with a load, solar is mandatory anyway). 
 
Bottom line: I think I understand this device functionally now. Thanks for the support on this.  I won’t get to using this or the one I intend to try next (TI’s CC1310 chip in Rado Controlli’s RC-WuTRX-434 module) any time soon… I don’t have the time now – other projects and activities occupying me.  Good luck with your project !

Good Morning,

Changed the Ebyte E220-900T30D, WOR Cycle to WOR_4000_111 (4000 mS).  Best I am able to observe; current displayed, changes rapidly. I think it breaks down into the different Modes.

Mode 0     11.651 mA   Normal Mode
Mode 1     79-69 µA      WOR Sending Mode
Mode 2     60-59 µA       WOR Receiving Mode
Mode 3  1.01-.26 µA    Deep sleep (Configuration) Mode

William

Thanks William…. humm, I would have thought that the WOR Rx mode would just wake up the few components of the Receiver, and only if it detects some activity in the airways (i.e. with 2 or 3 components more) would it engage the entire system to try to figure out “is this for me?” … at least that’s the way I would have designed it ;–)  It would seem necessary, however, if it did detect something during that short awake period, that it would need to do some deeper filtering to separate out other Ebyte transmissions in the area, or similar preambles floating around.
 
I was very surprised to see so much LoRa detection in my LoRa receivers, and had to do 3-deep filtering to get my transmissions … that may be also an issue with this WOR concept. In a rural setting, it may be low-power, but in a more dense setting, it could be spending a lot of energy trying to figure out “is it really for me?”. 

New project is a remote battery monitor with NTP timestamp transmitted to E220 receiver. Have the project compeled.

Project logs timestamp, adc reading, and voltage to LittleFS. Going to try and find out how long battery lasts compared to the number of requests made using an automated method of generating GET requests.. conditonal statement determine how often request are made to AsycWebServer. Server switches on live video camera for a predetermined period using a once Ticker timer method.

Plan to use a voltage divider of 1 meg ohm and 2 meg ohm; need to aquire the parts. Getting together a shopping list for Renzo’s shields too.

Updated project code: Remote-Relay-with-Battery-Monitor

Regards,
William

Good Morning,

Created a video of “Remote-Relay-with-Battery-Monitor project”:

Remote-Relay-with-Battery-Monitor –video:

Count down timer is set for two minutes; between “”ON” and “Off” message, making video `two and half minutes.  This is a pre-determined and adjustable time for the video camera to be “ON”.

William

Being an Amateur Radio, “Ham” for years, have aquired some new gear; have uses for  spectrum anaylzer.  There is now a low cost; compared to high-end SA’s.  TinySA Ultra Spectrum Anylzer sells for $150.

Wiki page for tinySA and tinySA Ultra

Used the SA to check transmiter RF output of the EByte E220 Transceiver, in my current project confirming it’s operation, looked at preamble and message.

E220 WOR Preamble and Message waveform

Waveform produced by tinySA Ultra (Frequency coverage 0.1 MHz. to 5.3 GHz).

tinySA, Erik Kaashoek: : 53 tinySA instructional videos

William,

Excellent William — a really great tool for my shop!  Thanks!  I’ve used a power meter, but doesn’t show time plot. thanks! 
(I’m really busy with other things these days and have little time for pursuing low-power receiver operation, but will get to it sooner or later :–)  … BTW, I got my Novice license at age 14 then general, but dropped out in college due to other priorities; I “burned out” my left ear while trying to decode Morse code beneath very loud receiver noise, and now am deaf as a post — probably will be joined by the Millenium generation who are burning their ears out with loud earbuds ;–)

Good Afternoon Joe,

Update 07/17/2024:

E220-Remote-Switch Project Update

“Transmit current of 620 mA is almost instantaneous at 30dbm to send; up to 200 bytes, before dropping to sleep current. Receiving current; for a message, 17.2 mA. Current values are from “Ebytes E220-900T30D User Manual”. Measured Standby current 11.8 mA. (E220, Always powered on). Ultilizing E220 Sleep Mode, Sleep current (E220, Always on) ranges from .54 uA to 97.33 uA measured! Transmit current and receive current are quicker start to finish; than I am able to switch ranges on the multimeter, microamp ramge all that is shown is “OL” for a few milliseconds.  Next version will support E220, Sleep Mode; currently in developement.

How to put E220 into sleep mode using sketch commands –ChatGPT

Respectfully,
William

Good Morning Joe,

Author of thr Ebyte, LoRa E220 Library asked that I do a guest article for his web site; includes answers to many of your past questions.

07/29/2024 is the latest GitHub update to my project code:  E220-Remote-Switch

Implementing E220 LoRa Remote Switch

Regards,
William

Hi William and others … I’ve been offline with this project, but have spent a little time recently on it.  I like the Texas Instruments chip (the CC1310) which is like the ESP32 (a microcontroller + Wifi), except it substitutes the power hungry Wifi with a simple 433Mhz radio (other frequencies available).  When programmed as a microcontroller, it can do the Wake On Receive function (something that the ESP32 really can’t do since Wifi is so cumbersome with handshaking and encryption support). However, instead of me doing all the programming, I’ve opted to use the Italian company Radio Controlli’s CC1310 + antenna + WOR program in flash (P/N RC-WuTRX-434).  It is on the order of $22 after shipping costs, so not in the category of “build 1000 units”, but for DIYers, that cost is swamped by the time and effort that goes into a project :–)   Anyway, I don’t have good data on this device yet (I’ve got it to implement a on/off remote switch, but there are some issues to work out).  Once I’m done this (may take a while as it’s still a back-burner project), I’ll have enough info for others to use.  The Ebyte (Semtech SX12xx chip) + microcontroller (e.g. ESP32) is well documented by you – I haven’t delved much into the details, but my gut says that a single chip micro+radio (i.e. TI’s CC1310) will be lower power than the 2 chip solution (i.e. separate radio of the Semtech SX12xx chips + a ESP32 micro).  Details to follow.