Is the device Tx Power available in the uplink information?
We are really trying to get a handle on battery life on the device end and there are two parameters that really affect this. One is sensor data rate (DR) and the other is Tx power. I can get spreading factor and bandwidth which in turn gives DR. I can also get RSSI, SNR, etc. However…I don’t see the device transmit power anywhere in the standard LoRaWAN uplink. Is it there?
No, this is not communicated during the uplink.
If uplink power is being tuned by MAC commands you should be able to get those, at least if you collect them historically.
But I’d question the basic assumption: for low power radios, transmit RF power isn’t all that drastic a component of power consumption. Likely what matters a lot more is radio on time - ie, transmitting at SF7 or SF10 even at the same RF power level is going to have a substantially different power cost, because SF10 will take 8 times as long. So SF and amount of traffic are probably a far more useful piece of information.
I’ve got a node on an integrating micro amp meter sitting on an Internet-reachable raspberry pi hiding behind enough urban obstacles that it counts as a distant but usefully workable range. Both the power meter and the node firmware output serial data streams that are combined into one log file you can ssh in and tail. It’s proved extremely informative to be able to watch what various firmware operations “cost” from wakeup to return to sleep, and to do so at a range where slower spreading factors are involved, vs. when the node is sitting a few meters from the gateway in the lab.
Edit: Variation is a little more than I’d expected, but providing you aren’t use the special +20dBm mode nor the very low one, I think transmit time is still the larger factor.
From SX1276 data sheet
- 20 dBm, on PA_BOOST RFOP = 120 mA
- 17 dBm, on PA_BOOST RFOP = 87 mA
- 13 dBm, on RFO_LF/HF pin RFOP = 29 mA
- 7 dBm, on RFO_LF/HF = 20 mA
(assuming decent matching)
Thank you so much for taking the time to give input here! Our end nodes (devices) are using the 20dBm power mode, so with overhead the current draw there is roughly 128mA. Then I see the devices throttle down to a current draw of roughly 45mA which appears to be 13dBm or 14dBm plus overhead. If I do a AAA lithium battery life calculation using a fixed DR3 (SF7/125kHz), 29 Byte Payload, 30s Update Rate, with a varying Tx power level, then I get the following:
So, it is fairly significant in my situation because of the 30 second update rate. We are transmitting quite often.
You make a good case, and your question opened my eye to the fact that the transmit power matters more than I’d been thinking it did, of course along with spreading factor and packet length.
If you can’t figure it out by tracking MAC commands, any chance you can spare a few bits somewhere in your payload to indicate the power utilized? Or if the “port” field is underutilized you can encode information in low bits there (within allowed ranges of course).