Will adaptive data rate help the end device determine the best max data rate if the gateway is a distance away? I.e. if certain data rates are not sufficient for a given range/distance of communication, will the end device + gateway be able to work this out? Thanks for the help.
Yes, that is what it is intended to do.
Worth noting however that the logic is in the network server, not the gateway (gateways have very minimal internal logic). The network server considers the signal reports from any and all gateways receiving each packet, and tells the node to adjust settings for those conditions - on average at least, the propagation path to the best gateway.
That’s in part why it’s problematic if a gateway suddenly vanishes, or receives on less than all of the channels, as those strong signal reports may lead nodes that were close to it to be told to use short-range settings which leave them no longer be able to reach more distant gateways that might still be in operation, and able to receive on all the channels that a proper gateway should.
Nodes also have some of their own fallback logic where they start moving towards longer range settings if they don’t receive any feedback from the network over an extended period of time, on the order of hours to days.
How does a gateway signal to a node that its packets are not reaching that gateway in the first place? I mean, if the node is using a higher data rate than it should and is thus not able to reach the gateway, then obviously the gateway cannot send a downlink message to the node to adjust its data rate since it doesn’t know that node even exists. Do nodes using ADR start with a high data rate and then send recurring packets with lower and lower data rates?
Again, gateways really don’t do anything. The Network server acts through gateways.
It cannot, of course
So nodes start in the most long range mode (high spreading factor, ie low data rate, and high RF power) and then may be commanded to go to a shorter range mode if the received signal indicators suggest that would be workable.
This would be a less effective strategy. However, this does happen when a short range mode that was previously working ceases working. Perhaps a nearest gateway has gone down, or perhaps the node has moved. Of a substantial period of time without response, it will start ramping to longer range modes.
Of course it’s possible that the network is dead entirely (server problems) or corrupted (sessions keys lost by server) in which case the longer range mode isn’t going to work either. But at least the node tried…
You may see this for OTAA. Like EU868 LMIC first tries the default channels at some initial data rate that is configured in the device. This may very well be the fastest data rate available (SF7BW125). When all default channels fail, LMIC will decrease the data rate one step, and try again.
This is fine for an OTAA Join, as for such the node knows it should always receive a downlink for each uplink, so it knows when things failed. But for ADR, it may take as many as 96 uplinks to detect that no downlink was received. According to the 1.0.2 specifications:
18.104.22.168 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)
If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (
ADRACKReq). The network is required to respond with a downlink frame within the next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the ADR_ACK_CNT counter.
In LoRaWAN 1.0.x, for most (if not all) regions, ADR_ACK_LIMIT is 64, and ADR_ACK_DELAY is 32. (In LoRaWAN 1.1, it’s a configuration.)
When a device detects it has missed an expected downlink then at worst it already had 96 uplinks not being received, or at best simply only missed the ADR-triggered downlink. It may want an aggressive strategy to ensure it might actually still be in range, or change its settings to get in range again. But according the the same specifications it seems that a certified device should only decrease its data rate by one step and wait another 32 uplinks:
If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device may try to regain connectivity by switching to the next lower data rate that provides a longer radio range. The end-device will further lower its data rate step by step every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range.
Aside: the above is also why ADR-enabled devices that have trouble receiving downlinks will eventually end up at DR0.
That is not necessarily true! Many devices start at SF7 - short range - especially for initial OTAA join requests and start requesting network access and config info. After a few attempts with no success the node then falls back to SF8 and tries cycle again, on no success SF10, and so on until SF12 attempts. There is much debate about which policy (Start at SF7 and back off or start at SF11 or 12 and ramp up - probably under ADR control) leads to the lowestest early life battery power consumption. It will depend on deployment scenarios and how fast any given network starts to adjust node settings under ADR control. I believe TTN (IIRC) waits for around 20 messages before adjusting under ADR. There is also some guidance/network policies that ‘ban’ (discourage?) network joins at e.g. SF12, and of course the RX2 back up window on TTN is set at SF9