when the node joining,the tx power is full(23dbm) ,but after join success, the node recv a mac cmd from chirpstack,set datarate and tx power
i know reduce tx power can reduce battery useage, but my product is always 220V supply , so no need reduce tx power
i also see chirpstack V4 need js code to change adr rules
anyone can give me a js code example for change datarate but not reduce tx power
Most likely, you want to turn of ADR at the device-side. Each uplink has an adr bit which in case set to true means that the LNS can control its data-rate. If this bit is not set, then ChirpStack will not try to optimize the data-rate and tx-power of the device.
all end device is enabled adr bit, i want to use adr function(ADR is a good speciality),but i do not want chirpstack change tx power ,i want all end device always use full tx power to transmit msg
But, why does it matter whether it does or not? In fact, I think it’s worse without it. When you reduce transmission power of a node, its range may be reduced. But the intent can be interpreted to also limit its messages to only the “best” gateways.
Since LoRaWAN has no form of media access control, collisions may take place if multiple frames overlap with the same spreading factor and channel. If the range is reduced, this may bring it out of range of other gateways and devices, thus freeing up bandwidth.
The strategy of the default ADR algorithm within Chirpstack for minimizing message loss for unconfirmed uplinks, is by automatically adjusting the repetition count to keep the message loss rate < 5%. Not by adjusting the transmission power.
thanks for your reply
in fact in my test , after join success, chirpstack downlink adr req,reduce tx power to 14 dbm , then my gateway cant recv node uplink msg,that’s bad(14 dbm)
beside , reduce tx power will reduce range and free up bandwidth
if my end device is not so much(my product is smart lamp controller) ,spacing is usually 40m, and auto report uplink every 30 min
i donot care Signal collision so much , but i care uplink data lost percent
so i need adr not reduce tx power
What may be missing from Chirpstack, is an adjustable margin for each device. To compensate for RF environment issues.
I am familiar with the smart street lighting domain. A deployment will have many LCUs, one on each luminaire. Each one will send a report every x minutes. A good LCU will stagger. But there is just no guarantee that the message will be received. Whenever a LCU transmits, that period of time and the selected channel, cannot be used by another LCU. With an overly-high transmission power, I think it could possibly become a collision with another message from another LCU, even if the two LCUs are far apart. Which is why I do not think having a high transmission power is surely always a good idea.
On its own, I think 14dBm is okay. 14dBm is actually near the default for EU868. LoRaWAN is a LPWAN, so using low power is by design. What we may need to be concerned about, is the SNR and RSSI. Which may be indicators that your gateway/LCU placement is not optimal.
By the way, adjustment of the number of transmissions (nbtrans) only takes place after at least 20 uplinks have been received from the node. So if you find that your message loss rates are higher when you first switch on the LCU, you may need to wait until at least 20 uplinks have passed, before the default ADR algorithm will start adjusting the nbtrans setting to keep within the <5% message loss target. This only affects unconfirmed uplinks.
If you really need to adjust ADR, I suppose you can write your own ADR algorithm. Chirpstack allows you to write a script to change the behaviour of ADR. Maybe this will fit your requirements. I have not tried this before, but I know it exists because you can now select the ADR algorithm.
It can be seen that you have experience in the smart lighting industry，our puduct is every 30min report a status msg, if i need wait 20 * 0.5h = 10h then adr maybe change tx power to good one ,that’s cant be accept!!
too long lost connection.
beside,lorawan gateway can not be installed in the perfect position we think, subject to installation conditions, height, terrain, etc
i will write my own adr.js java script code to change data rate but do not reduce tx power