LoRaWAN , TTN und ADR. Was bedeutet ADR? Adaptive Data Rate

Gerhard Peter

Initiator of TTN Berlin and Community Happyness Manager

Posted on 28-04-2020

this text in all google supported languages

Über ADR

Ausgangslage war dieser, als Kritik an der Nutzung des ATTiny84 gemeinte Satz:
"Yes there is! ADR will also instruct the node to reduce transmission power when applicable, thar results in (potentially) less interference.Trying to to shoehorn a LoRaWAN stack into a too small processor is a nice intellectual exercise but hardly useful as it will never be compliant and the result will occasionally cause issues for LoRaWAN compliant networks.....represents users that take the technology seriously and do not want to cut corners just because they can get away with it. The current generation of microchip arm controllers (not those of 15 years ago) are far more capable and a better choice."
Google Translation:
"Ja da ist! ADR weist den Knoten außerdem an, die Sendeleistung gegebenenfalls zu reduzieren, was zu (möglicherweise) weniger Interferenzen führt. Der Versuch, einen LoRaWAN-Stack in einen zu kleinen Prozessor einzuschleusen, ist eine nette intellektuelle Übung, aber kaum nützlich, da er niemals konform sein wird. Das Ergebnis führt gelegentlich zu Problemen bei LoRaWAN-kompatiblen Netzwerken ..... repräsentiert Benutzer, die die Technologie ernst nehmen und keine Abstriche machen möchten, nur weil sie damit durchkommen können. Die aktuelle Generation von Mikrochip-Arm-Controllern (nicht die von vor 15 Jahren) ist weitaus leistungsfähiger und eine bessere Wahl."

Thesen darin:
1. - ADR reduziert bedarfsweise die Sendeleistung
2. - ATTinys sind eine intellektuelle Spielerei
3. - Non - Konformität des Ergebnisses bei Nutzung von ATTiny84
4. - Probleme mit LoRaWAN Netzwerk(!)
5. - wer einen TTiny84 nutzt, der nimmt die Technologie nicht ernst
6. - aktuellere Chips seien weit leistungsfähiger und deshalb "die bessere Wahl"

Frage:
Trifft das als Kritik berechtigter Weise zu? Ist zB das Kriterium "alt" stets auch gleichbedeutend mit "schlecht"?

Gehen wir die Analyse also schrittweise an.

Was ist ADR eigentlich?
Deutschsprachige Texte hierzu gibt es wenige. Björn bildet da mit seinem blog eine kleine, feine Ausnahme. Hier der Link.

Björn schreibt:
"ADR steht für Adaptive Data Rate und ermöglicht es dem Node seinen Spreading Factor (SF) automatisch zu ändern. Dieses ist für feste Nodes eher uninteressant, jedoch für sich bewegende Nodes schon eher (Anm. das ist aufgrund der eingesetzten zu trägen Methodik leider falsch). Nicht überall habt ihr optimalen Empfang. Ein Node, der fest mit SF7 sendet, verbraucht zwar minimal AirTime, wird aber eventuell nicht oft genug empfangen. ADR kann dies verbessern, da der Node damit in regelmäßigen Abständen eine Bestätigung vom Netzwerk verlangt. Bleibt diese aus, wird der SF angepasst und erhöht. Somit wird versucht, einen optimalen Empfang des Nodes zu erreichen. Wenn der Node besseren Empfang hat, wird er durch das Netzwerk aufgefordert seinen SF wieder zu verringern. ADR funktioniert nur mit OTAA Nodes, bei ABP wird alles fest eingestellt.

TTN selbst schreibt dazu, etwas modifiziert:
"Adaptive Data Rate (ADR) is a mechanism for optimizing data rates, airtime and energy consumption in the network. ADR should be enabled whenever an end device has sufficiently stable RF conditions. This means that it can generally be enabled for static devices. If the static end device can determine that RF conditions are unstable (for example, when a car is parked on top of a parking sensor), ADR should (temporarily) be disabled. Mobile end devices should be able to detect when they are stationary for a longer times, and enable ADR during those times. End devices decide if ADR should be used or not, not the application or the network."

Ganz so klar, wie es zunächst scheint, ist die Lage dennoch nicht.

ADR muss nämlich nodeseitig zunächst aktiviert werden. Verpflichtend ist das jedoch keineswegs; es hängt von den Umständen ab.

Eine eingeschaltete ADR reagiert auch frühestens nach 20 uploads des Nodes. Sendet Dein Node also nur alle 24 Std. einen Messwert, so erfolgt erst nach über 20 Tagen eine Adaption der Data Rate (also SF 7-12) durch den ADR - Klapparatismus.

Allenfalls ist ADR somit hinsichtlich der Reduktion der Sendeleistung, übrigens minimal bis - 2 dBm (!!), für festinstallierte Nodes von wesentlicher Relevanz. Und das auch nur für die Sendeleistung, welche in Stufen von jeweils 3 dB mittels 4 Bytes ferngesteuert reduziert werden kann - insofern SF7 nachweislich ausreichte.

Das hängt dann vom jeweiligen Usecase ab. Besonders im Großstadtgewusel mag das sicher hilfreich sein.

Messe ich jedoch zB die Heuballentemperatur auf dem Lande, aufmeinem Acker und erreiche locker meinen Bauernhof in der Umgebung mit SF7, so ist eine weitere Sendeleistungsminimierung eher eine theoretische Option. Es sei denn, ich habe 2000 Sender und natürlich ebenso viele Heuballen im Felde liegen. Nicht sehr wahrscheinlich.
TTN beschreibt das theoretisch richtig.
Für mobile Nodes wird das aber noch irrelevanter bzw. gar unmöglich, wenn ich einen wenig sendenden Node habe, zB zur Überwachung der Batteriespannung im eigenen Wohnmobil. Dann müsste ich mindestens 20 Tage auf einem Campingplatz stehen bleiben, bevor die Adaption greift. - Also: offensichtlich noch irrelevanter.

ADR ist daher ein netter, wenngleich sehr komplizierter, Versuch - und meines Erachtens somit auch nicht mehr als eine intellektuelle Spielerei.

Die erste Eingangsbedingung lautet also:
ADR funktioniert mit OTAA Nodes. Unter ABP ist es nicht funktional, wenn komplett auf den Empfang von downlinks verzichtet wird ('ALOHA - Verfahren') und der Node seine Messwerte nur in die Welt hinaus schreit, natürlich regelbasiert und regulationskonform stets nur auf SF 7 und mit Minimum 3, besser 8, Frequenzen innerhalb des TTN Spektrums.

Merke: Es gibt kein "join" bei ABP!


Letztlich dient ADR dazu, und hierfür wurde es eingeführt, Sendeenergie beim Node einzusparen. Dies ist bei usecases mit low energy nodes, die auf Knopfzellenbasis bei SF7 eh schon Monate werkeln, nicht erforderlich und auch stets dann, wenn der Einsatzzeitraum, bedingt durch eben jenen Usecase, von vorne herein begrenzt ist.

Und zudem:
ATTiny84 nodes sind ABP nodes, daher entfällt die ADR Funktion hier schon einmal per se. Sie benötigen niemals einen downlink. Die Anzahl der downlinks ist nämlich durch die fair use policy von TTN auf 10 pro Tag begrenzt. Dazu zählen übrigens auch die joins, wenn man OTAA nutzt .

Dennoch verhält sich unser süsser kleiner ATTiny84 in jeder Hinsicht gesetzes- und regelkonform, was Airtime (SF7), Frequenzband und erlaubte Sendeleistung betreffen. Da wird dann auch nichts gestört.

These 1: : widerlegt. Berufung? Nicht zugelassen!

These 2: intellektuelle Spielereien
Gegenthese: So what?

Der 88 Euro-Cent Prozessor ATTiny84 ist eben gerade nicht "zu klein", wie behauptet. Er erfüllt genau die Anforderungen für einen sicheren Betrieb. Er ist so groß, wie er sein muss. Reicht doch aus! Das war es denn auch schon. Seniorenhandys erfüllen ihre Primäraufgabe ebenso gut wie ein Ei-FON zum Vielfachen des Preises. Man kann nämlich mit beiden telefonieren. Auch ein Arduino pico kostet übrigens stets weit mehr als ein ATTiny84.

These 3: Non Konformität des Ergebnisses: "niemals".
Eine wilde Vermutung, die durch nichts, aber auch gar nichts belegt ist. Das Funkmodul ist ein bewährtes RFM95W. Dieses sendet ausschliesslich regelkonfrom. Hier wird nichts gestört. Allenfalls durch den durchschimmernden Vollnarzissmus des kritisierenden Scribenten. Ja, in einen TTiny84 mit 8 kB passt nicht der gesamte Arduino Stack. Denn der hat eine Größe von ca. 30 kB. So what?

These 4: Probleme "gelegentlich" bei LoRaWAN kompatiblen Netzwerken.
Entspricht, nur mit anderen Worten, These 3 und führt sich damit selbst "ad absurdum". Es kommt eben stets auf den Usecase an. Gedankenbefreit darf man nicht sein. Das ist hier aber niemand.

These 5: ATTiny84 Nutzer nähmen die LoRa-Technologie nicht ernst.
Ein schaler Aufguss von These 3 +4. Und: eine Klatsche für all jene, die sich auf diese Weise intensiv mit eben dieser Technologie befassen. Besonders reizvoll wäre es ja noch, ein 1MB EEPROM zuzufügen....

These 6: Neuere Chips seien die "bessere Wahl.
Will ich von Punkt A nach Punkt B telefonieren, so kann ich das mit einem Seniorenhandy mit den Ziffern 1-9 ebenso gut wie mit einem Ei-Fon ,wenn ich die e-mail Funktion vorsorglich mal abschalte... passiert beim Seniorenhandy nicht).
Hier spricht entweder ein Verkäufer für einen ungenannten Vertrieb oder, alternativ, ein Jünger der absoluten Fortschrittsgläubigkeit. Eine Art LoRa Fundamentalist. Das treibt ihn an. Kann er gerne tun. Ist aber auch kein Dogma.

vorläufiges Fazit:
Diese Kritik ist, IMHO, nichts weiter als heisse Luft. Über die Motivation des Kritikers darf weiter gerätselt werden. Er muss nun mal stets Reacht haben.

update:
Mittlerweile wurde darauf hingewiesen, dass es Combi-Chips gibt, welche sowohl einen Microprozessor, als auch die LoRa Funkelektronik auf einem Chip vereinen. Natürlich beinhaltet dieser Chip dann den kompletten "LoRa stack". Nur Chips mit vollständigem Stack entsprächen den Vorgaben der LoRa Alliance. Kannte ich durchaus schon.
Eine geschickte Marketing Massnahme,diese Alliance. Deren Jünger der reinen Lehre verfechten als Fundis diese Strategie wie in einem virtuellen Kreuzzug..... Aber bitte, gerne doch! Bei rechthaberischer Rabulistik schalten meine Ohren jedoch stets auf Durchzug und: ab. - Daran halten und schon gar nicht sich beugen. das muss man jedoch keineswegs, wie ich begründend ausführte.

Ein Beispiel für einen Combi hierfür wäre beispielsweise der "CellCube". Wer sich also keiner Kritik aussetzen möchte, der greift gleich zu diesem Teil.

PS: