The best thing to do is not to modify the output power of the node or gateway but to look for a good position of the antenna.
Do not use high-gain antennas, 3dBi is sufficient but place this antenna as high and as free as possible. Not indoor, better outdoor on the top of a mast.
If you increase the power or use antennas with high gain, your devices can become illegal as already said.
Hi Jeff,
thanks for your reply, your objection is very valid, indeed.
In our case (see also my previous blog: Change TX_POWER via MQTT Client - #18 by ccatp) we need to lower the maxEIRP as the country in question deviates from the regional parameters. The Australian regional parameters permit 30 dbm, whilst Chile deviates from that allowing a max value of 13 dbm. Quite a difference. This is weird, as Chile is geared - according to their ministry of telecommunication - to Australian standards.
So I suppose, an alternative is to run our own TTN stack, right?
We have very short memory spans here!
Does the Kerlink allow you to reduce the power in it’s dashboard?
This is easy to solve: use 1m RG-174 cable between gateway and antenna. The attenuation at 868 MHz is abt. 1 dB.
not found in their manuals yet, separate from that their manuals are not very helpful…mildly speaking
wouldn’t you also attenuate the incoming signal?
Ah yes I recall the Attacama Desert observatories… per my comments at that time solution is cripple the antennas used as they is then symetric wrt node and gw reception behaviour…
Yes, that’s the point it keeps the respective link budgets symmetric wrt spec…
Max. 13 dBm EIRP means max. 11 dBm ERP. If you use a dipole-antenna with a gain of 2.1 dBi or 0 dBd then you have to reduce the output-power by 3 dB or use an antenna with less gain.
Can you tell your gateway, that it has an antenna with a gain of 5 dBi? Than the gateway should reduce it’s max. output-power to 11 dBm.
Once I get access to the network again, I can ssh to it and check. Thanx.
That was another suggestion I made on the previous Atacama thread…GW then automatically dials down the EIRP… problem is does still risk some asymmetry… but can be made to work.
Since it’s the servers responsible for commanding the power level, this really should be verified and submitted as a bug report against the infrastructure.
However, you could modify the packet forwarder with a local limit, so that even if commanded to do more, it will just emit the local maximum.
Keep in mind that normally, emitting less than expected would be detrimental to the network, so this should really be only a last resort for legal compliance in the face of a bug you can verify. LoRaWAN servers choose the gateway with the best received signal to transmit a downlink, but if that gateway is unusually weak in the transmit direction (for example the ST lab bench only board that lacks a power amplifier) then this in essence becomes a denial of service attack on the network, since it tricks the servers into allocating downlink transmissions to a weak transmitter rather than one slightly further away producing the expected power.
In this case, the gateway covers the middle third of South America, literally, it’s on top of a mountain on top of the Andes. Which is why they may be being asked to dial down the signal.
This really should have stayed a single thread with the history of the issue.
Here a reply from Kerlink’s helpdesk which I forward to the experts amongst you.
Tx Max Power has to be managed through the LNS. It’s not recommended to change the antenna gain into json file. In case of modification of antenna gain, Rx will be impacted too.
Kerlink is right: in the design of LoRaWAN, it’s the network server that’s tasked with issuing only allowable downlink requests.
In effect, the OP’s issue is that TTN does not properly support the regulatory environment of their country (it sounds like that may be a still evolving environment).
Realistic options would be working with TTN developers to support the evolving situation, a custom private server instance with experimental changes to support it, or temporary workarounds such as modifying the packet forwarder with a local hard limit, or even a man-in-the-middle server which modified the transmit commands from TTN before they reached the actual gateway.
Actually if I understand it TTN follows the L-A RP’s and they in turn are dictated by local in country regulations.
The problem here is a very local and specific deployent problem due to the location used for GW - both extreme height and proximity to the sensitive instrumaentation of the local observatories…come down to lower levels either side of the Andes and RP’s aren’t an issue as I understand it! This one is a bit of an exception and an eye popper! Might be good for setting some ground to ground range records 
! 
If they could run to putting in a FLARM base station that would be cool - then we can track record breaking distance flights in sailplanes in real-time! There’s ridge soaring and then there is the Andes …
That’s the idea. But it turns out that they do not reflect the applicable legal regulations.
The problem here is a very local and specific deployent problem due to the location used for GW
That’s an additional problem, not the only problem.
The OP reports that even apart from the specific install location, the system does not meet their country’s regulations for ordinary outdoor use to begin with.
So there are two issues:
-
TTN does not correctly model the country regulations, because its process of doing so is too indirect, following from guidance by a 3rd party that’s not actually written for the country in question, but merely one similar in some (but not all) respects.
-
The conventional design of LoRaWAN infrastructure doesn’t really have a way to model varying gateway location-unique concerns. This could be possible without breaking the LoRaWAN spec (since it doesn’t really limit what the server may consider in picking a downlink gateway) but it would require some new and creative thinking. In effect, this gateway should be treated as the “least preferable” choice for transmission when there’s any other alternative, and if it is used, then the transmit command needs to go out at a reduced power level.
I guess the other problem is RF does a Putin and doesnt respect geo-political/man made borders! A legal GW 10m from border with another country where limits/regulations different? 
I and am sure many others on the Forum dont fancy fines or jail time so if you have specific examples of
Such that we can mitigate would be good - specifics/facts please 
This is only the 3rd…ok maybe 4th… time in near 10 years with LoRa/LoRaWAN that I have seen a very geo specific local variance requested by a regulator, or other requestor with powers of influence/enforcement (or else!)
The non-compliance with the general RF regulations of Chile was already explained in OP’s original thread, where the applicable regulation is quoted as the first item, before getting into the additional location specific concern as a second, distinct issue.
Probably the two threads need to be merged.
Not sure how or where you determined that - I see no ref to general regulations only a regulator request to limit in their specific case (because of location etc as explained later on)
Perhaps OP can clarify.
Chile has a significant TTN Community based around Santiago with 14 GWs and 78 contributors and I’m not personally aware of any issues being raised wrt General Regulations previously. (And I believe there are historically around 35-45 TTN GWs in country)
BTW I agree with some of your application driven Downlink adjustments as being impractial and also not then addressing network initiated DL from prior to your post edit I said much the same earlier. Change power per application DL simply wont work/be practical!