Can the power consumption of a RF receiver be lowered?

[Faranight]

Hey, I'm thinking about an outdoor hobby project of mine where I need a device to be listening on the 433,92 ISM band for occasional messages and process them on a microcontroller. I've been meaning to make my own PCB with a custom receiver circuit, and I've been looking at the MICRF211 IC to do the job. In the datasheet I noticed that it constantly draws about 6 mA of current when operating. This doesn't seem much at a first glance, but since the device is going to be powered by a battery and a small solar panel, it's a lot. The IC apparently **needs** this current to be able to listen at all times.

Is there a way to lower this consumption somehow without affecting the receiver's RF "attention"? A different RF IC maybe?
How are some other low-power receivers (BTLE?) designed so that they can reliably pickup messages, but don't constantly drain as much power?

[AndyC_772]

Does the message have a detectable preamble, or does it repeat for a period of time?

I did a design which had the exact same issue some years ago. I had the microcontroller periodically power up the receiver and listen for carrier. If it's quiet, turn off the receiver again and wait half a second or so. If there's a signal, leave the receiver on for long enough to find the start of the next repeat of the message, and decode from there.

The duty cycle ends up dominated by the start-up time of the receiver, ie. how long does it take to power it on and reliably detect carrier if it's there. The duration of the transmission tells you how often you need to switch on for a listen, to be sure you don't miss anything.

In my case the transmitter was a radio key fob, and people tend to hold down the button until they get a response. A half second delay caused by the radio being switched off most of the time didn't matter.

[nali]

6mA is not untypical for a 433MHz receiver. Some newer rx ICs have polling built-in which is woken by the preamble bit train. I used a MAX41473 in a recent design, although I didn't get the polling to work that reliably mainly because the legacy TX had a weird preamble.

BLE services advertise periodically, but only listen for a fixed period after an advertising packet is sent then the MCU returns to sleep. If you're actively receiving (i.e. scanning) power consumption is relatively high.

[jwet]

I think 6 mA for a UHF receiver sounds pretty good.  The general trick in these cases is to decide how much "latency" ie delay, you can handle and have your receiver powered only enough to meet your latency requirement- this can save enormous amounts of power.  i've worked on tracking system for animals where the requirement was to get a guaranteed update only every 100 hours- the power drain can get close to zero!   You can go through the arithmetic of what the probability of getting a given message, etc. and what your errors are- this sets the limits.   A powerful technique available these days is to have the timing provided by GPS- essentially perfect,  you can wake for 1 second per minute to listen , this take your 6 ma to 60 uA.  The trick is how precisely can you wake up and how short of a time can you stay awake- its all in the error budget of the timing.  Using a very low drift RTC like a DS3231 that you update daily can save power over having the GPS active continuously- this can make for some amazing low power links.

[selcuk]

You don't want to effect the receiver's RF "attention". Does it mean that you don't let the receiver sleep when idle? Below recommendations are based on sleeping when idle.

If the transmitter sends periodic keep alive packets, you can sync receiver's wake up times with the transmitter and sleep when idle. But if the transmitter is something like a garage door opener and sends only on keypress, then you may use a RTC as suggested to sync with time. But this adds complexity to both transmitter and receiver. Is the transmitter also battery operated?

A BLE peripheral occasionally wakes up and sends advertisement packets. It consumes transmission current at this time. Then it listens for a while to see whether there is a connection request. It consumes reception current at this stage. If a central device is listening and want to connect, it connects immediately after receiving an advertisement packet. After the connection is established, peripheral doesn't go into sleep until it disconnects. If there is no connection, peripheral sleeps again. If the peripheral is a door opener and the central has permanent power, peripheral can wake up when button is pressed then sleep for a long time. If the peripheral is a temperature sensor, it can wake up every 10 seconds and send new measurement. If it is a beacon, it sends more frequently.

[Faranight]

I see, these are some very good points. I might use these ideas in my own future transmitter designs.
The current ransmitter is a battery-powered keyfob and cannot be modified, so I'm a bit out of luck here.
I have no idea when the message is going to be transmitted, so the device has to listen constantly.

Does the message have a detectable preamble, or does it repeat for a period of time?

Yes, it has a preamble, but there is no guarantee that the message is going to repeat during a transmission. It may or may not.

You don't want to effect the receiver's RF "attention". Does it mean that you don't let the receiver sleep when idle?

I'm not sure, if I worded that correctly. I was under the impression that some circuit changes could be made to reduce the power consumption without degrading its sensitivity or the ability to receive too much. But apparently sleeping is the correct answer.

A BLE peripheral occasionally wakes up and sends advertisement packets. It consumes transmission current at this time. Then it listens for a while to see whether there is a connection request. It consumes reception current at this stage.

Out of curiosity, do you perhaps know what is the reception current drawn by the BLE receiver while receiving?

[selcuk]

Your receiver micrf211 has a typical supply current of 6mA and shut down current of 0.5uA. For example, if you listen half of each second, you can limit the average consumption to half (3mA). Let's assume your transmitter sends a packet about 50ms duration, and retries it while the key is pressed. As suggested before, if the users can hold the button for 1 seconds at worst this can work. 50ms is within 500ms.

This is from datasheet of nrf52810 which I use occasionally for BLE projects:

Radio transmitting @ 0 dBm output power, 1 Mbps BLE, Clock = HFXO, Regulator = DCDC  -->  5.8 mA
Radio receiving @ 1 Mbps BLE, Clock = HFXO, Regulator = DCDC  -->  6.1 mA
Sleeping, System ON, Full 24 kB RAM retention, Wake on RTC (running from LFRC clock)  -->  1.5 µA

The ratio between reception and sleeping is above 1000 so the key point is sleeping when idle.

[AndyC_772]

If the transmitter is a key fob, I would have expected it to transmit a repeating sequence for as long as the button is held down. Are you sure it doesn't? What if there's interference at the time when the one and only copy of a message happens to be sent?

IIRC I had the receiver wake every 500ms or so. The 'on' time was governed by how long the receiver took to start up and reliably determine the presence of the carrier, which wasn't long.

[Faranight]

Yes, I am not doubting the fact that the keyfob will transmit for as long as the button is held down. I do however fear that there is no certainty the user will hold down the button long enough for the message to be retransmitted (even once). Interference is also something I have no control over, so the only way to avoid this scenario would be to transmit for longer or retransmit at a later time. I'll do some experimenting and try to find a reliable tradeoff between power consumption and reception quality.

[mikerj]

Yes, I am not doubting the fact that the keyfob will transmit for as long as the button is held down. I do however fear that there is no certainty the user will hold down the button long enough for the message to be retransmitted (even once).

Does the user have no feedback that the signal has been received?

[TheUnnamedNewbie]

I think a lot of this ultra-low power stuff is handled on an IC level. Doing stuff with low-power modes on LNAs with much worse SNR but just good enough to trigger the wake-up when a signal is detected. Also I think you will find a lot of these low-energy protocols use some kind of frequency or phase keying. Since linearity is far less important, you can operate your amplifiers in far more power-efficient (but horribly non-linear) operating regimes. At these low frequencies, you can practically operate them as switching amplifiers with crazy power efficiency.

[Faranight]

Does the user have no feedback that the signal has been received?

Not directly, it's supposed to "listen in" on the communication between two other nearby devices. Think of it as a remote doorbell - there is a transmitter button outdoors, and a bell device indoors that listens for a transmission with a given packet identifier. When a user presses the ring button, the bell hopefully detects the transmission and plays a ring tone. My device is a custom 3rd party passive listener, and was not intended to be part of this network by the manufacturer.

Alright, I'll do a prototype and play around with the sleep functions to see how accurate I can get it to work. I noticed the MICRF211 IC does seem to have a RSSI pin, which could potentially be used (via analog comparator) to detect strong signals, presumably a transmission and wake up the MCU.