Hello,
Is there any option to know from Server side or MAC command, that what Tx Power is used in Device?
Thank You
All the data we get is in the uplink JSON which you can see in the console & in the docs.
All the MAC commands are fully documented in the LoRaWAN specifications but may not be implemented in the firmware.
You’ve been prompted twice for the device make, model & firmware revision, we can comment further when you’ve answered.
Additionally there are extensive discussions on the forum about handling connection checks from using the LinkCheck MAC command as well as building it in to the firmware, so 
may reveal solutions.
1 Like
In JSON uplink there is no key for of Node’s Transmission Power.
I am using RAK3172 Module.
I am curious, are you suggesting that the power the node uses to transmit a packet is included in the packet sent ?
The LoRaWAN 1.0.4 standard describes a different mechanism (based on ADR) which is required for a node to pass the certification. For anyone starting out with the creation of a node I would suggest to base it on 1.0.4 and not older versions. Lora Alliance members learned a lot over the years and the best practices have (at least partially) made it into the specification.
2 Likes
I want to know this, but don’t think so, and I think this may be included in Lorawan header
What you get in the Application console JSON is what you get, no TX power of the node.
You need to get this via the debug port of the device.
Device is installed and not given option for print of Tx Power.
can we get Tx Power using any MAC Command? Or By ADR Server sets the power, So this power value is stored in server, can we can fetch it.
Please read the documentation on MAC and ADR, we can spoon feed it, but you will have a greater benefit if you read it.
If you read it then you would have seen what you can set, very clear.
How about answering the other questions?
“I think” could be “I know” if, as suggested by me and others, you read the docs so it’s not a constant game of filling in the gaps in your knowledge - make use of the Learn resources (menu at the top of the page) and the free to download LoRaWAN specifications (1.0.3 + 1.0.4 would be best) from the LoRa Alliance website.
It will also mean you stop asking if there is a MAC command for X or Y, because you will know.
And reading the learning docs & specs etc, you’ll know exactly when the power is reduced and understand who decides on the ADR algorithm that may or may not reduce the power. And then go on to read the code that implements the algorithm so you know precisely what it is doing.
Or you could commission someone to investigate & answer your questions in a formal report.
There’s absolutely no problem with answering highly focused questions to clarify what can be very intense descriptions in the docs & specifications. But the volunteers that are answering all learnt by reading & doing and it’s not a good use of their time if the topic is broad & the person asking clearly hasn’t visited the basic info or answered the questions to help clarify the situation.
Sorry, for wasting Time descartes, In another post, I give you all question reply, but from your side doesn’t get any comment after that.
I felt that this is simple question, any experienced person, can give quick answer, without knowing controller or firmware, as Lorawan is a public protocol, if it is not a custom protocol, and question is related to protocol.
and I am not able to find my statement issue specification. So, I posted here.
Thanks to @ Jeff-UK, kersing to give related answer to my issue statement.
Its not for the volunteers to stitch together responses across multiple threads, indeed we encourage complete discussion in a single thread to help those who find the thread after the fact, and as a corollary we also ask the users dont split their questions an hence the volunteers time, across multiple threads… we do not follow individuals as a general rule rather we react to each thread in turn… just a heads up! 
ORLY? Which bit of volunteer don’t you understand - no one is obliged to answer you and singling me out as the bad guy and thanking others doesn’t do anything to inspire me. Jac has asked about answers to the help he’s offering & Johan is directing you to the docs as well, so I’m not sure how you pick who to call out.
We can give “quick” answers but then we keep repeating those answers and quite often people don’t have the right context to them because they don’t have the background because they haven’t done the learning so they can’t action the answers.
FWIW, this is not a simple question by any stretch of the LoRaWAN imagination, which is why I was steering you to read the background materials.
As it happens, if you pick through Jeff’s answer, it gives you all the information, but then context / background / learning would be required to pick up on the details.
Perhaps to draw this to a close, how power is reduced is down to which version of the specification and the which LoRaWAN MAC and it’s version as many combinations of MAC & versions don’t implement that level of detail and, in some cases the radio doesn’t respond to documented requests to change the power level, so in fact knowing the device & firmware details is essential to giving you a quick answer.
The power is not in the header and there is no MAC command to request the transmission power. It is good practise to have such information built in to a housekeeping uplink, along with last downlink RSSI & SNR, so you can use tools to map out comms quality and perform any remedial actions.
And sometimes the point of asking many questions is to get the asker to explore the potential ramifications of the question, not to get a free answer to each bullet point.
That is an incorrect assumption as you are probably aware now.
This is just the needed answer dear. Thanks for this
And before anyone asks, at the LoRa physical level, there is no information in the received packet about the TX power used.
True as answer, send in pay load
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.