LoRaWAN (and TTN) supports adaptive datarate, where the server looks at RSSI/SNR information on received packets, and if there is sufficient margin, it sends a downlink message to let the node switch to a higer datarate (more bandwidth, less range). The node OTOH periodically requests an ack for a message, and if it receives none, switches to a lower datarate. Together, this should balance to find the highest datarate that works (which means the shortest airtime).
Currently, ADR is disabled, because this sketch was written when TTN did not support ADR yet, and because we cannot go slower than SF9 because of the TTN airtime fair usage policy. To enable DDR:
We need to enable it in the code (it is currently explicitly disable)
We must handle SF10+ by either dropping measurements or, better, when no airtime is available to send a measurement, queue it and send multiple measurements on the next cycle (which shares overhead, so it likely works if we send a few measurements in one packet, haven't done the calculations yet). We can also see if we can compress the measurements a bit (under the assumption that subsequent measurements are not too far apart).
It is likely good to cover this when also converting to the new packet format we are thinking about.
LoRaWAN (and TTN) supports adaptive datarate, where the server looks at RSSI/SNR information on received packets, and if there is sufficient margin, it sends a downlink message to let the node switch to a higer datarate (more bandwidth, less range). The node OTOH periodically requests an ack for a message, and if it receives none, switches to a lower datarate. Together, this should balance to find the highest datarate that works (which means the shortest airtime).
Currently, ADR is disabled, because this sketch was written when TTN did not support ADR yet, and because we cannot go slower than SF9 because of the TTN airtime fair usage policy. To enable DDR:
It is likely good to cover this when also converting to the new packet format we are thinking about.