LoRa, reducing power

Hi!

I've been working on a back yard weather station, and trying to get power consumption way down. Currently my biggest power user is a RFM95 packet radio.

I've got my power consumption down to a very reasonable level, but I'm curious what can still be done. Changing Tx power reduces power consumption in nearly direct proportion to Tx power. Even for very short transmissions, e.g.,

    LoRa.idle();
    LoRa.beginPacket();
    LoRa.write(msgData,10);
    LoRa.endPacket();
    LoRa.sleep();

the transmission takes about 30 ms.

Before I go down a rabbit hole of trying things randomly and breaking the library with ill-conceived experiments: (i) Is there anything that can be done to shorten the time required for transmission? (ii) Are there better ways to think about reduce power consumption (e.g., optimising spreading factors to futher reduce transmission power, or something like that)?

Thanks!

Michael

Schematics could be helpful as we know nothing about the powering.

The whole thing is a bit involved, but the relevant parts for the LoRa part are:

  • Lora module is an Adafruit RFM95 breakout. However, I found the on-board regulator was wasting power, and since I'm supplying regulated 3.3V anyhow, I've removed it from the board and I've bypassed it by soldering a wire right to the RFM module's Vin

  • Power is supplied from the 3.3V regulated output on of these solar lithium supercapacitor charge control modules:
    https://www.tindie.com/products/jaspersikken/solar-harvesting-into-lithium-ion-capacitor/

I hope that is useful?

The best place to get support forvAdafruit products is the Adafruit forums; generally responsive to concerns.

Adafruit breakouts are sold at a premium and you pre-pay for support, use it.

3.3 volt to RFM Vin? Is that good? Not to RFM 3.3 volt?
Do You power down the RFM too? All stuff?

Hi Railroader,

You are right - I power the 3.3 volt pin of the RFM module within the adafruit breakout.

I don't power down the RFM module itself, at least not by cutting the power to it. It sleeps really well using using LoRa's sleep().

Michael

mrburnette: Indeed, the adafruit module is really just a stepping stone for me to ultimately make a design that uses the main radio module, without adafruit's additional voltage regulator and level shifters. Given I'm bypassing their extra hardware, I'm thinking here might be the best place to ask! And also, I think I'm probably at a point where it is more a software side of things (as per questions in my original post).

Michael

I think You've done well that way. Cutting power off sometimes creates start up problems for some circuitry.

I think You have done as much as can be done in order to save power.
Let's se if a more knowing helper adds any tip!

Hi Railroader - thanks for your thoughts. I'd of course been delighted if anyone could suggest something on the hardware/power side of things, but I had a feeling that any further savings were not to be found in that area.

I'm hoping someone who knows LoRa well will have some advice. I presume the 30 ms are necessary, but I wonder if there is something to be gained there... But since 30 mS of 80 mA once a minute is far and away the biggest part of my power budget, it is not critical, more just curiosity.

Michael

or on the software side..... Power saving is a quite common goal for members so just cross Your fingers.

I agree RFM95 sleeps real well, so do most of the temperature/RH sensors. Beware that not every RFM95 uses same Tx current when transmitting. The BW setting is directly proportional to Tx time, the SF is proportional to 2^n, other parameters do also effect the consumption. There is no "guideline" for some golden setting that is a good compromise. I chose mine based on my system psu characteristics, first thing I did was to measure Tx current, which was highly non-linear. So depending on your system, this can be a big problem. My equipment is very poor, very crude, but bellow are Tx currents from two devices. Note the big difference (current consumption during Tx vs. set Tx power). Maybe it is all wrong, but it is non-linear for sure. Also the antenna, and antenna variation, can have big impacts on RF amp consumption.

image

If you are not running directly from batteries, then the regulator used must be low quiescent current type. For such systems I use MCP1700, 1.6uA typical.

Another source of current consumption are voltage dividers measuring power supply, these should be switched off when not in use.
Since most low power devices sleep quite a lot, you can use an external nanoamp timer to wake you up while your device deep sleeps.

Another option is to use it to supply/cut-off the power to the entire circuit when sleeping, if you do not need to keep the state of the system (I can not do that, for instance, but a lot of systems can). Alternatively you can save variables you need to flash/eeprom, considering you manage that properly (beware memory wear out mechanisms).

The supercap you use, would also have considerable leakage current. In general choose a higher voltage unit and use it at lower voltages. This should reduce leakage current.

Beware of floating inputs. Each input buffer has a switch point, where consumption is briefly rather high. If you leave them flapping in the wind, you will be surprised how much dynamic current they consume. Tie them to either gnd or vcc or switch to output. Beware, some controllers consume small currents if set to output, for atmega devices this occurs if output is high. If it is output low, no consumption.

Once you end up on sub 1uA level, weird things start to happen. This is exacerbated by the fact you do not know exactly where the current is flowing as nanoamps are hard to measure.

Next pitfall is processing time. If you wait for sensors in a while loop, you are wasting power. Use sleep modes when waiting for sensors, adc conversions etc. Depending on your system, you might need to lower the clock speed to reduce mcu consumption in case your power supply is relatively high in impedance (coin cells, certain supercaps, cap drop supply etc.)..

Good luck!

EDIT: I remembered another thing. Some libraries cause too high consumptions and others will conflict with another library. I had to rewrite three of them, but this is highly project specific.

Hi aiggya,

Thanks for the advice on how transmit time is affected by bandwidth. Sorry, I'm being slow - what's SF and n? Your red line (though I don't quite understand what it is) is quite similar to what I've measured with all default settings, using a really basic whip antenna.

I use MCP1700, 1.6uA typical.

Yes - that's my favourite! But in this case the the Li-super cap module has a very efficient switching regulator on it. Also, the module is great at charging from very low light, so I think, details of the supercapacitor considered, I think it is a great solution for this sort of thing - or at least I'm hoping that with some more experience it will prove to be.

source of current consumption are voltage dividers measuring power supply

Yes - I've opted in this case to go wtih 2x 2M resistors to measure the supercap voltage. With a few tricks the ADC behave fine for this. My wind vane is resistance-based and I can't do the same trick, but it is pin-powered. My anemometer's switches are open half the time, so power loss through the pull-up resistors is a bit of a pain there -- any ideas in that area much appreciated!

Beware of floating inputs.

Yes, - I switch as many pins as possible in input with pullups before sleeping.

Next pitfall is processing time. If you wait for sensors in a while loop, you are wasting power.

Yup - for sure! as much as possible is interrupt-based, and it otherwise sleeps as much as possible with wakes from the watchdog timer.

EDIT: I remembered another thing. Some libraries cause too high consumptions and others will conflict with another library. I had to rewrite three of them, but this is highly project specific.

Yes! I've certainly been finding that. I've started re-writing as many functions as possible, especially reading sensors! It's been quite a learning curve, learing about avoiding analogRead() and digitalWrite(), etc, as well as i2c sensor libraries.

Michael

Oh, hello there, never got a notification for that response.

SF is a parameter configurable for LoRa, in steps of 2 to the power of n. This means it doubles for every time n is incremented by 1. This is what I ment.

I run of of coin cells, so this is why I use supercaps, a low leakage current one. For large nodes, I run from 2x AAA batteries.

I also have a LiPo version with on-board charger, I need the MCP1700 there.

For supply voltage measurements, I compare internal bandgap to ADC power supply. No dividers. For your anemometer switches, I do not understand why you consider the circuits
consume power when the switches are open? But no matter, you can always activate and deactivate this part of the circuit, I guess? Probably depends on how fast the signals are?

To get the best out of this forum, please provide the ALL the details, not what you think is "relevant". Full schematic, and the code.

Power saving is a project wide goal, not a radio goal.

Here is my attempt at a low power LoRa sensor node;

14 months from a 155mAhr battery. So about 20 years from a pair of AA Lithium Energizers.

You can cut the power used with LoRa devices by;

Reducing transmit power, SX127X can go as low as -1dBm, for modules using the high effieciency PA RF out. Most SX127X modules however use the PA boost pin for RF out, which is less power efficient and only goes down to 2dBm.

Reducing Spreading Factor (SF), you can go down to SF6.

Increase bandwidth, you can go up to 500khz.

Set coding rate to 4:5.

As for the comments about setting un-used pins to input pullup, on an Atmega328P, leave them alone, setting un-used pins to input pullup actually increases power consumption.

SX126X LoRa modules can go down to -17dBm if they have the low power PA connected up, and also down to SF5, for reduced air time.

My attempt at LoRa node (not using LoRaWAN):

  • 2450 coin cell (620mAh), theoretical life: 237 months
  • 2x AAA lithium (1100mAh): 382 months
  • LiPo rechargable (380mAh): 25 months
  • 2430 coin cell (280mAh): 115 months

For calculation, self discharge is adjusted to hit 10% self discharge in 10 years for lithium battery technology (all coin cells and the AAA batteries). For lipo, I use 5% self discharge per month.

I use constant relative discharge, e.g. for every month, I will take 5% of remaining charge. I am not sure this is right.

Calculation is checked against discharging a 0.1F supercap from 3V to 1.8V (takes almost 12h). A voltage somewhat higher than 1.8V is the measured supply voltage inside last received packet, beyond that the mcu resets.

I wake-up every 10 minutes, gather sensor data, send it via LoRa and go back to sleep. I do not have bidirectional comm, for now my nodes are talk-only.

Tx power is 4dBm.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.