Hi all,
Could anyone explain why an end nodes tx power is not available as metadata in the rxpk? I have looked through the source code of the semtec packet forwarder and can see that the txpk has a key/value for this “powe” but it is not present in the rxpk. For devices that support adaptive/configurable tx power, it would be great to be able to track this over time to correlate it with packet loss, rssi, snr etc
Many thanks
Sam
Everything on the uplink side has a cost. Put it into the packet structure somehow, and then everyone has to pay that cost, regardless if they find it useful or not.
The way things are right now, you’re free to send this information as part of the application level payload, if you’d find it useful - and others are free not to send it, if they wouldn’t.
Thanks for the quick response, many thank. What you suggest is reasonable and makes sense if you are building your own node and/or have access to modify the firmware, when you are buying a node and/or don’t have access to the firmware, this becomes more problematic. Surely TX power is a key component in both QoS and battery life, so isn’t it universally useful data to have?
To the degree that is true, it is part of why ADR actively manages uplink power and spreading factor.
But what you are wanting to do is not something that would directly alter node behavior, but rather something that could be used to study it.
To take your pre-made node argument, if you can’t change the firmware, then what’s the point of studying the behavior in hope of improving it? (Especially when some of that behavior is on the network server not the node)
Or in the opposite case, if you have access to alter the node firmware to improve the behavior, then you have access to add reporting in the uplinked applications packets so you can study the suitability of the existing behavior, or your new behavior.
(Note that with ADR, you can also get part of the picture from the server’s commands to the node to change settings, though if the network stops responding the node will eventually ramp up the effort on its own.)
So add it to you payload …
Cannot say I have seen much comment on here about it being so useful and dont most all people have it set to 14dBm anyway ?
You are correct that I want to study it but the result of that study would be to modify the tx power to attain the desired balance between QoS and battery life.
I do have the ability to set tx power, but it isn’t included in the payload on tx.
I guess the answer is to simply store to the configured tx power statically against the device in my db and then use this as part of my analysis. This is workable. Thanks very much for your insight, it does make sense what you’re saying, I was just surprised that tx power wasn’t considered on par with SF and BW in terms of usefulness as meta data, but I suppose you have to draw the line somewhere.
SF and BW are not transmitted as packet fields either, it just happens that they are discovered as an implicit part of how a LoRa concentrator card receives signals.
You get that meta data because knowing it at the gateway is free, and sharing known information over the Internet doesn’t cost much.
Perfect, that was the missing link! Thank you