Replies: 10 comments 5 replies
-
What would be the situation where you would want lower transmit power but not say just turning the transmitter off completely when a certain battery threshold is met? Does the intermittent transmission or relay of messages significantly effect the battery life compared to the CPU and other peripherals running? I can see turning the transmission to off at say 10%, but 50% battery could still be 2 weeks of power on an NRF device. I guess my question is what is the use of a lower power transmit unless you are using one of the multi-watt station G2 edition devices. |
Beta Was this translation helpful? Give feedback.
-
Full TX power during sunrise until sunset as the device most likely can be directly powered from the solar panel - even while recharging the battery. Reduced during the nighttime. The LoRa transmitter of your NRF will also eat quite a bit of energy. The uC is not a relevant factor. Peak current according to Semtec (+20dB + PA-Boost) you can plan for ~120mA peak. With only +14dBm it's only ~30mA. |
Beta Was this translation helpful? Give feedback.
-
ok, then i ask is it good to have a node that may only be reachable at some times of the day knowing that further away nodes wouldnt be able to communicate with it at night? There would also be less traffic at night, meaning less packets transmitted and draining the battery. This is an interesting idea, i just trying to see the point of lowering power at all if you are not near a completely depleted battery and the next day it should charge up a bit. |
Beta Was this translation helpful? Give feedback.
-
During the summer it's most likely no problem to keep it running on full TX power the entire time as you going to reach 100% SoC every mid day. But during the winter and autumn it can give you a lot of margin to keep your node running when there's bad weather around. Also you can build stations with smaller solar cells and batteries if you can manage to reduce the power consumption dynamically. |
Beta Was this translation helpful? Give feedback.
-
would be interesting to run an experiment to see 2 identical nodes, one set for 10dbm transmit and one set for 22dbm and measure how much of a difference there is over a week. |
Beta Was this translation helpful? Give feedback.
-
I will start that experiment! Have to build two stations anyway and then will have to "burn them in" for 1-2 weeks. Going to set one to maximum power and one to +12dBm. Just waiting for the 18650 battery holders to arrive to solder them. They are already somewhere in a central post station. |
Beta Was this translation helpful? Give feedback.
-
First measurements:
Jumps >4.2V = pass-through mode, meaning battery is full Now switched to 10dBm TX power. |
Beta Was this translation helpful? Give feedback.
-
Measurements are still in progress. First reduction to +10dBm TX didn't show a major improvement.. looks like the ESP32 is still the biggest power drainer. Maybe somebody with a NRF (RAK, etc.) can test this. First do a run with full legal LoRa TX power and then a second one with only +10dBm. |
Beta Was this translation helpful? Give feedback.
-
TX power reduction to 10dBm doesn't reduce the power consumption enough to extend the lifetime of a device in an useable way. Maybe it's that idle RX power consumption of the LoRa chipset that we cannot get rid of. Closing this feature request. |
Beta Was this translation helpful? Give feedback.
-
Platform
NRF52, ESP32, RP2040, Linux Native, other
Description
A few solar charge controllers (TI BQ25185/etc.) support a Power Path'ing which means that the device can be powered directly from the solar panel as soon as the battery is fully charged. It also mixes (70% solar, 30% battery) the power during dusk/dawn or cloudy phases.
Example, I marked the spots where the device switches to direct pass through:
Feature Ideas: It would be great to have an automata which reduces the TX power to a defined level if a specific condition is met.
USB == 1 / 0 might be an indicator. A slowly following switching logic would work with the TI power path functionality.
As we introduced a system time lately we could even make this with calculated dusk/dawn times based on GPS coordinates
Or a threshold-driven approach: reduce TX power by -10dB if we are reaching 50% battery
Beta Was this translation helpful? Give feedback.
All reactions