Hello,
In our Nodes, ADR and Confirmed Mode is enabled. If for any reason, if the node doesn’t receive uplink Acknowledgement,
then the device changes its data rate to the next lower data rate(DR5 to DR4, and so on).
But TX Power remains the same, no change in Tx Power of Device.
So, Why did Tx Power not increase, Only Data Rate changed?
Thank You
Firstly that is generally to be avoided -especially on the community network 1) FUP limits you to 10 downlinks of all types per day….though recommendation is think of that as an option for per week or even per month…. because 2) each downlink renders the sending gw deaf to all uplinks from yours and everyone else’s nodes, if you have multiple node behaving same in area you are DDoSing yourself and all other community users in range of the gw doing the ack’ing. 3) That is just the way ADR works in its rawest form, a strong signal will allow a device to step down the SFs under NS control, only when on lowest SF…7 … will it then start to dial down Tx pwr if still strong and with enough link budget headroom…. Reducing SF reduces time on air to benefit of all users as well as reducing node power consumption over time, where reducing Tx power by an equivalent 2-3dbm would only really benefit other nodes at the edge of reception area wrt on air collisions/noise floor improvement and node per reductions is less effective due to device physics and integrated dI/dt over Tx period. Same in the other direction stepping up signal…… unless you have specifically coded as device will usually already be at max Tx.
I have relocated my gateway, so now Device is not able to communicate with gateway, after 2 days(due to confirmed mode) DR decreases, so SF increases and reached to DR0. That’s cool. but the changed Tx Power (TX Power = 10 by LNS ADR) didn’t changed to high power(TX Power=0) by node. node only changed SF.
So, why node not changed Tx Power but SF?
The node make & model number auto-detection service is down right now and is unlikely to come back on line before 2055. If you can tell us, along with the firmware version, we may be able to comment further.
Is that something you programmed? Because it’s not standard behavior to use confirmed mode for this purpose. The LoRaWAN specification contains other mechanisms to switch to higher spreading factors. (Check chapter 4.3.1.1 of the LoRaWAN 1.0.4 specification for the mechanism)
Because of faulty firmware? Or because of faulty assumptions?
As asked in other responses, please provide more details if you want the question answered. What firmware is being used? Who wrote it? What is it based on? Or in case of of the shelf hardware, what manufacturer, model, revision and firmware revision?
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.
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.
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.