Downlink frequency is set at the Gateway and uses appropriate local (regulated) parameters, not something changed on the node
Regional parameters are set to meet local regulatory environment and it is not intended that users chop and change at will and whim - likely you are behaving illegally in your region, unless the region supports multiple/overlapped bands (e.g. Australia supports/allows AU915 & AS923, with various sub-bands)
Unless you are operating/testing in a faraday cage/appropriate/approved test set up you are likley interefering with other users in your area in an unregluated/illegal manner (please dont get TTN/LoRaWAN users a bad name/reputation! )
Often devices will be optimised for the given bands - e.g. with appropriate RF filters etc., so highly likely that devices may be operating sub-optimally in bands other than those for which they have been design/engineered/certified
Where in the world are you? I assume if you started with the IN865 band that you are on the Indian Subcontinent? Unless developing for wider market and needing to test for alternate deployments (under appropriate controlled and regulated conditions) there should be no need for you to switch regional parameters or router environments (operating across alternate TTN router regions often fails and introduces other strange interop issues and shoudl be avoided)
Yes, we must test our device for different regions.
We are aware of the need to comply with the requirements of the authorities. Therefore we use a direct cable connection (with an attenuator) and we additonally use a shielded box for the tests. So in this point everything is OK.
Thanks, for the hint, that the downlink frequency is set by the gateway and is not controlled by the server.
No, I don’t think that Jeff wanted to say that the gateway decides on its own. Reading the whole sentence, it’s just not related directly to whatever frequency the node uses for its uplink:
The gateway is told what frequency (and time†) to use by the network server.
What does “sometimes” mean?
† For the Basic Station LNS protocol, which your unspecified gateway is probably not using, the server might leave the actual choice for RX1 or RX2 to the gateway. But even then the server will be specific about the allowed choices.
thanks for the additional hint. The gateway is set to the appropriate region each time. If i understand it correctly the server controls in this case the used frequency.
To your question “What does “sometimes” mean?”: If i switch between the different regions, sometime the frequency are correct after a switch and sometime not. From what I’ve tried: If it fails, it always fails until I move to another region.
And you also changed the configuration in the gateway itself? (For example: only configuring TTN to use, say, an IN865 gateway as AU915 won’t work. That also needs the same changes in the configuration of the gateway†, and maybe a restart.)
I guess you’d better give us all the details of the changes you make, and what works and what not. And as the Router is also shown in your screenshot: are you always using the same (nearby) router?
† However: not changing the gateway’s configuration does not explain why TTN Console shows the wrong downlink frequency in your screenshot.
Yes, our test setup for the region test is always the same:
Set our device to the new region
Set the gateway to the new region (Router & Frequency)
Set gateway settings in TTN to the new region (Router & Frequency)
Perform a join
Another test procedure for example:
Starting with A923. Everything OK
Switching to KR920. Everything OK.
Switching to AU915. It fails. Join accept answers at 921.9MHz (korean downlink frequency)
“I guess it’s just not worth the trouble to re-use a single gateway and test-nodes for testing with multiple frequencies.”:
Maybe there is an easy explantion for this behaviour. If it is more complex, i also think that it is the easiest way to have different gateways for the different regions. If you do not have an explantion for this, we can close this thread.
as Gateway we use an indoor gateway type Dragino LPS8. As packet forwarder we use the LoRaWAN/RAW forwarder (a Semtech UDP Packet forwarder does not exist).
I cannot see, if local file sets are stored or flushed on change. I can only see in the log, that the uplink frequencies are correct for the set region.
As an OTAA Join Accept needs a downlink too, I don’t understand how that (apparently) has succeeded, while a downlink after a subsequent data uplink uses the wrong frequency. Also, your screenshot shows that the downlink counter is larger than the uplink counter? The community TTN network only supports class A, so downlinks can only happen after an uplink, so a downlink counter should be at most equal to the uplink counter? I wonder if TTN somehow thinks these are different devices.
Just a wild guess: maybe caching in the different router/handler regions is troublesome/outdated? What if you leave the gateway at the same (nearby) router (say ttn-router-eu), and use the same region for the application’s handler (say ttn-handler-eu), regardless which frequency plan you select in the device (hardware) and gateway (both hardware and TTN Console)?
@eduardopfeifer Exactly! This is the problem I had earlier this year with an AU-band gateway. I changed the config in the gateway to the proper router, but I may have made a mistake (not save the config or something) and it was still connected to the EU router. This caused the downlinks in RX2 to be sent in the EU frequency of 869.525 MHz, although the gateway was defined in the TTN portal as “Frequency Plan: Australia 915MHz”
This is not the cause of the problem. I have set the correct routers.
In the meantime I have seen that it is enough to wait a quarter of an hour. Then the correct frequency is used.
)