Simple RF receiver current draw

[Faranight]

Hello, just checking...

I am thinking of adding some simple arduino-style short range one-way wireless functionality to a project of mine. The PCB is going to be custom-made with a Microchip AVR DD microcontroller, and I am looking for a decent RF receiver (or transciever) chip. The IC has to be low-power since the board will be powered by a solar panel. Generally, when transmitting, you can put the radio (and the cpu) to sleep after you are done to save power and only re-transmit when needed. But, with receivers (I checked some datasheets) there seems to be a constant power draw.

For example, the MICRF230 IC I was researching listens on 434MHz with ASK-OOK modulation, and the datasheet says it consumes a continuous current of 6 mA (typ.). Since I have never done RF radio design, I was wondering, if this is normal. Yes, I'm aware that, unlike transmitter,  we need to continuously listen for packets, but (considering I aim for low-power) does 6 mA seem a lot in this case? Are there IC's that consume less power and offer a similar performance or is 6 mA already plenty efficient?

Thanks in advance for any hints.

[nali]

I'd be interested what you find...

Some receivers have a low power polling mode to detect a preamble or sync to wake the CPU when a preset bit pattern is detected. I'm using a MAX41473 at the moment although polling mode hasn't proven too reliable for me due to the legacy transmitter's slightly odd preamble/sync pattern (of which I have no control), and I can live with the 6mA although lower would be better.

[radiolistener]

I think it's a good power consumption, because good quality receiver can consume up to 50-100 mA and more, especially if it's SDR receiver. In order to reduce power consumption you can disable receiver and enable it periodically to check for a signal.

[jwet]

These 6-10 mA numbers are pretty typical.  The MAX41473 has several modes- idle at .3 mA with oscillator running, sleep at 1 uA with registers retained and some SPI (but no RF or Osc) and Coma 10 nA- off really.  Generally you have to build a protocol (if you have control over it) that keeps the receiver sleeping and wakes every 2 seconds or so, your transmitter has a long preamble at the beginning of a session to get by the 2 second sleep cycle-( it will have to be at least 2 seconds).  The trick is to build the LO on the receiver so it will start very quickly- this can be a challenge especially over temp, tec.  There are some fixed timings you have to wait out for internal logic of about 2 ms, so if you get your XO up in 10 mS, you can be off 98% of the time taking your 10 mA down to 200 uA average.  You can play with the numbers depending on the latency you can handle and your use case. If you almost never talk to it, you could stretch it to 30 seconds even- you'll just have to wait that on first use. You can also base the wakeup time on past history or system activity or time of day, etc.  Bluetooth low energy is very low power and does these things transparent to you but the modules are a bit pricier- they need a processor (usually an embedded Arm M0) to handle the protocol and  draw more active power.

Back 20 years ago, a lot of the receivers were super regens vs. today's low or zero IF superhets.  Super regens can be very low power but they're kind of a mess, don't meet modern ETSI emission requirements (the receivers radiate) and aren't crystal controlled- the receivers were kind of a barn door selectivity wise and the transmitters were somewhat tighter.  I designed car alarms back in the late 80's as a consultant in So. California (hot market) and this is how this stuff worked back then.  The transmitter of that time often use a saw resonator (315, 433, 492) with a 1 transistor oscillator connected to a small PIC.  Linear Industries- one of the pioneers in the garage door openers (made Craftsmen and others, etc) have some old patents that you could likely dig through.  You might be able to buy these little receiver modules from China still.  Continuous current could be 100 uA on the best ones.  Fun to play with.

[switchabl]

You usually don't keep the receiver on all the time. For a one-way channel you basically have two different ways to avoid that:
- asynchronous: turn the receiver on for a short time at regular intervals (or in a regular pattern); and either have sufficiently long preambles or repeat each packet often enough so it will eventually be received
- synchronous: have the transmitter send regular beacons and after initial synchronisation, only turn the receiver on for those. You can only send data at those regular time-slots.

If you have a two-way channel, there are more options. For example, the low-power node can signal the central node (which is assumed to be less power-constrained and has its receiver on all the time) when it is ready to receive. Or you could maintain a synchronous network where all nodes can keep their radios off most of the time and only initiate re-synchronisation when a link fails (e.g. missing ACK).

There are a lot of different trade-offs you can make, depending on latency and reliability requirements and power budgets for different nodes. You don't necessarily have to re-invent the wheel. There are A LOT of different protocol stacks with different approaches as well, from relatively lightweight ones like Nordic Gazell to kitchen-sink solutions like Contiki (which does IPv6 over large mesh networks).