I have been operating IMST end-devices close to 2 TTN gateways. ADR functions correctly and the end-devices start at SF9 and after about 30 uplinks ADR steps in and they change to run at SF7 and reduced TX power.
I have been testing a RisingHF USB modem and, after 7 days and over a thousand uplinks, it’s stuck at SF12 and full power.
The RisingHF configuration shows “+ADR: ON” and when I copy an uplink physical payload from the TTN web console and decode it using lora-packet-decode it shows “FCtrl.ADR = true”.
Hmmmm? Why is the RisingHF stuck on SF12? The LoRaWAN specification says “If the ADR bit is set, the network will control the data rate of the end-device through the appropriate MAC commands.” So why is the IMST working?
I watched a newly connected IMST end-device over several hours and, to my surprise, the IMST end-device is triggering the ADR by sending an uplink message with the FCtrl.ADRACKReq bit set to 1. This results in an immediate LinkADRReq from the network and the SF and power are set.
I have checked all the RisingHF documentation and the AT command set offers no way to control the MAC layer. I have tried downlink messages and confirmed uplink messages in case LinkADRReq needs to piggyback. Nothing.
Either RisingHF is wrong and it should be behaving like the IMST or TTN is wrong and it should be sending LinkADRReq commands.
Can anyone help to clarify this or suggest how to get the RisingHF modem to set the FCtrl.ADRACKReq bit to 1?
What SF was it using when doing that, and did TTN tell this specific node to make changes too? (SF9 to SF7 like the others you mentioned?)
If no changes are needed, or if no downlinks were available on which TTN could piggy-back the ADR settings, then the node won’t know if its uplinks even reached a gateway. In that case it will set ADRACKReq after a while (after 64 messages for LoRaWAN 1.0). So, this might be as expected.
That said, even without sending such ADRACKReq, a node that is on SF12 should be told to increase its data rate (assuming the link quality indicates it can do better): looking at the code I think TTN should force a downlink then. If you have access to a gateway: don’t you see any ADR downlinks in the gateway traffic (and the trace info such downlink) in TTN Console? Maybe the node is just not receiving the downlinks? And does it have the ADR bit set for all uplinks?
Thankyou @arjanvanb for your fast response.
I think you have identified the problem. I have just re-read the LoRaWAN specification section 4.3.1.1 - Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl).
I have watched a lot of traffic between TTN and the RisingHF. The RisingHF has never set the ADRACKReq bit. It appears that the RisingHF is not implementing the ADR_ACK_CNT and ADR_ACK_LIMIT mechanism. It appears that TTN is relying on receiving ADRACKReq on uplink to trigger the ADR system and is not forcing ADR.
Typical interoperability issue!
Thanks!
Any suggestions to fix are welcome.
Yes, and reading the specification, I think that’s okay… See also Does ADR require the use of confirmed uplinks? - #6 by arjanvanb
To mitigate this, you could make the node send a confirmed uplink every now and then…
I have tried sending confirmed uplink messages. They work correctly and are ack’d. The ADRACKReq bit is not set. These messages make no difference. They do not trigger ADR from the network.
Ah, @htdvisser indeed wrote on Slack in August 24th:
At the moment we only piggy-back ADR on application downlink, but we will indeed send the ADR command sooner. Even better, if the margin is really big, we might already send a first ADR command immediately after join. See Send device straight to a higher SF on join if possible · Issue #477 · TheThingsArchive/ttn · GitHub
Ah, and here on the forum, September 11th:
So you’d either need to wait a bit, or somehow set the ADRACKReq bit every now and then (what LoRa module is in the RisingHF USB modem?), or somehow make the application schedule a dummy downlink if it sees that the node is on a low data rate…? And maybe disabling link check can stop the node from going to SF12 to start with (I don’t know)?
(And file a bug with RisingHF.)
Thanks @arjanvanb for taking the time to pursue this.
I see this as an interoperability issue with RisingHF needing to fix their ADR_ACK_LIMIT mechanism.
End-device module is - I think - the RisingHF RHF76-52. Only access is via the USB & AT commands.
There is no way to set the end-device ADRACKReq unless there are undocumented AT commands that I don’t know.
I have sent downlinks from TTN web console but they don’t arrive with any ADR piggybacking.
I have raised the issue with ThingPark/Actility where I bought the modem. If no response I will try to raise it directly with RisingHF.
I’ll report any progress here.
At present I will disable ADR and manually control it. I could implement this as an over-the-top application-level downlink and then get the end-device to set it via AT.
This continues into: Vendor Support - not what I expected.
The RisingHF modem was purchased on market.thingpark.com which is operated by Actility.
I emailed a contact at Actility to get details for firmware updates. The response was:
“Unfortunately I don’t know where you can download the firmware and as this sensor is one of many we allow transactions via the marketplace the agreement is between yourself and the sensor supplier. So my advice is to email them direct and they should be able to advise where to get the firmware which may sort your issue out on the TTN.”
So, it’s on to RisingHF for support!