LoRa-Joins dauern teilweise extrem lange

[clemens]

LoRa-Joins dauern sehr lange, hier gerade 2986 Sekunden, d.h. 50 Minuten, ich glaube der Post-Überwachungswaagen steht gleich vor der Türe, was kostet die airtime-Überschreitung eigentlich! ;-)

 2986.5217 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 2989.0442 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 2991.5686 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 2994.0920 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 2996.6146 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 2999.1386 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...

Keine Ahnung, ob wir firmware-technisch da was verändern können. @Thias empfiehlt in solchen Fällen – so man Zugriff hat – den TTN-Gateway neu zu starten.

[clemens]

Ich habe jetzt mal beim Hiveeyes / Terkin datalogger in der settings.py das aktiviert:

        'join_attempt_count': 42,
        'join_attempt_interval': 2.5,

Aber immer noch wird da munter hochgezählt,

   23.6719 [terkin.telemetry.core       ] INFO   : Telemetry transport: CayenneLPP over LoRaWAN/TTN
   25.5803 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
   28.1063 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...

 [...]

 1645.9433 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...
 1648.4684 [terkin.network.lora         ] INFO   : [LoRa] Not joined yet...

Und die Konfiguration wie @thias schon vermutet ignoriert.

@Thias

Ich glaub, dass stimmt so nicht. Die while Schleife testet nur alle 2.5s, ob der JOIN da ist. Wie lange dabei auf den JOIN innerhalb eines for Loops gewartet wird, wissen wir nicht. Unser Eindruck ist unendlich - und das 42 mal ;)

[Jan]

Hier klappt der Join aktuell sehr zuverlässig, meist beim ersten Mal, sonst beim 2.

[clemens]

Nochmal konkret, es geht bei mir hier um den ersten Join per OTAA, vielleicht sprechen wir gerade über andere Dinge und join_attempt_count bzw join_attempt_interval werden nur beim re-join berücksichtigt aber nicht inital bei OTAA?!

@Thias

Nach Aufwachen aus Deep Sleep erfolgt kein Rejoin, denn der Join-Status samt Packet Counter wird im NVRAM nach dem send() gespeichert. Nur ein RESET löscht den Status und erzwingt einen Rejoin. Also einmal gejoint jagt er nach jedem Deep Sleep den Payload in die Luft und hofft, dass ein Gateway ihn empfängt.

Ich überlege gerade, ob es Sinn macht den Join-Status auch nach einem Reset im NVRAM zu belassen aber dann bräuchten wir einen einfachen und intelligenten Mechanismus den wieder zu löschen falls es doch mal sein soll, da ist der reset schon transparent!

ABP wäre vermutlich die Alternative.

[Cle21]

Das Problem sehe ich auch manchmal.
Als ich zufällig in der TTN Konsole zuschaute wurde die Device Adress im letzten Byte immer wieder falsch übertragen.
Würde nicht vielleicht ein soft-reset nach x Sekunden Join-Versuch das Problem vielleicht lösen? Nach einem erneuten Hard-Reset Joint er immer schnell.

[clemens]

siehe auch Fragen / Schwierigkeiten Terkin-Release ab v0.7.1 - #23 by Thias

@Thias

Die Logs und die neue Settings-Option join_attempt_interval sind trügerisch. Ich wiederhole mich vielleicht, aber die “Not joined yet” Meldung suggeriert nur einen JOIN Versuch. In Wirklichkeit ist es nur ein pausierter while Loop der auf has_joined testet und die Meldung im (default) 2,5 Sekunden Takt ausspuckt. Die Join Versuche werden nur intern vom LoRa Modul nach dem lora.join() kontrolliert.

Internally the stack will automatically retry every 15 seconds until a Join Accept message is received.

mit 15 Sekunden Intervall geht es los und erhöht sich dann nach einigen Fehlversuchen bis hin zu mehreren Minuten, wenn kein JOIN ACK von einem Gateway sauber empfangen wurde. Terkin hat keine Kontrolle über Taktung und das Ergebnis. Die einhüllende for Schleife ist deshalb total überflüssig samt des attempts Konfig-Parameters. Sie bleibt einfach immer im ersten Loop bis zum JOIN und das kann schon mal ewig dauern. Die Schleife kann deshalb meines Erachtens > /dev/null .

Eine Alternative, die ohne die JOIN-Prozedur auskommt, wäre Aktivierung per APB. Hier findet keine Aushandlung der Verbindungssicherheit statt. Das Device sendet von Angang an seine Pakete los, ohne zu wissen, ob ein Gateway in der Nähe ist. Mit APB muss man allerdings auf den Frame Counter aufpassen .

[Thias]

ABP (Activation by Personalization) als alternative Aktivierung ohne JOIN Prozedur ist nun verfügbar.

Beide Verfahren sind hier ganz gut erklärt:

LoRaWAN - Device Activation Call Flow (Join-Verfahren) mit OTAA und ABP - IoT...