I have a node working at a fixed SF of SF8, sending unconfirmed uplinks. In the TTN console, ADR is switched off, and also the ADR bit in the FCtrl byte is set to zero.
However, I find that the network keeps sending LinkADRReq downlink messages after every uplink. The first LinkADRReq after joining requests the device to go to DR0. The devices answers with a mac command 0x03 0x05, meaning it confirms power and channel settings, but it does not confirm DR settings. The next LinkADRReq requests the device to go to DR4 = (by coincidence?) SF8 = the fixed DR at which it is operating. So the device replies with a mac command 0x03 0x07, meaning it confirms power, DR and channel settings.
But even after this confirmation, the network keeps sending a downlink after each uplink with a LinkADRReq requesting to go to SF8 (which it already uses).
I experimented with setting the ACK bit in the FCtrl byte when replying with a confirmation to the LinkADRReq, but this does not work either.
How can I silence these LinkADRReq requests because I don’t want these unnecessary downlinks?
@kersing Thanks for the link. Although this mentions ABP and my device is OTAA. Specific behaviour for OTAA is still a bit up in the air I understand from this post?
Anyway, it’s not logical imho for the server to request the device to transmit at SF8, when it is already exactly doing that. Waste of spectrum.
I’ll tell my customer to try and use the CLI-option, as I have no control over the keys that will be rolled out for devices with this software.
A typical real-world bug - PitA for a niche case but with a work around available. And they did all that coding for us for free!
If you want to influence the updates to TTS then filing a GitHub issue will help.
I can see exactly same behavior: no way to stop it.
It is a clear waste of resources, as every packet send out by the device results in the reply from the network, which otherwise would not be the case.
There is if you read the thread and follow the link 3 posts above