Spätestens seit einem der Vorträge auf dem 33C3 interessiere ich mich für Kommunikation in und mittels LoRa. Eng damit in Zusammenhang steht mein Interesse für The Things Network (TTN). Nunmehr habe ich erste praktische Versuche gestartet.

Ich habe bereits vor einiger Zeit festgestellt, dass ich nicht einfach so mit eigenen Sensoren am TTN teilnehmen kann - rund um meinen gewöhnlichen Aufenthaltsort ist auf der Abdeckungskarte des TTN ein großer weißer Fleck. Das bedeutet, dass ich ein eigenes Gateway aufstellen muss, um am TTN teilzunehmen. Diese Teile sind aber teuer - und aus meiner Sicht so teuer, das ich davor zurückschrecke, eines für einen kleinen Test anzuschaffen.

Nun gibt es aber im Internet Berichte und Anleitungen zur Erstellung eines simplen Packet-Forwarders, der im Prinzip aus einem Breakout-Board eines RFM95 und ein paar Drähten besteht.

In der vergangenen Woche habe ich Zeit gehabt, mich hinzusetzen und das einmal auszuprobieren. Bis auf einen kleinen Schluckauf bei der Registrierung des Gateways (oder treffender: Legacy Packet Forwarders) lief alles genau wie in den Aleitungen beschrieben: Ich konnte das Gateway in Betrieb nehmen und es hat sich mit dem TTN verbunden.

An dieser Stelle sei eine kleine Abschweifung erlaubt: Das, was ich da gebaut hatte, trägt "legacy" aus guten Gründen im Namen: Zunächst erst einmal wird davon nur ein Kanal von insgesamt 8 abgedeckt - das bedeutet, dass Geräte, die auf den 7 anderen senden mit meinem Forwarder nichts anfangen können. Beispielcode für ESP8826 und andere umgehen ein solches Problem, indem sie für jedes Paket ein anderes Band verwenden. Das würde aber im Bereich meines Forwarders bedeuten, dass nur jedes 8. Paket durchkommt. Ich habe das getestet und konnte genau dieses Resultat bestätigen.

Eine weitere wichtige Einschränkung ist die Tatsache, dass ein solcher Packet Forwarder eine Einbahnstraße ist: Ich kann darüber keine Informationen an die Node funken - es ist lediglich möglich, Signale der Node zu empfangen und an TTN weiterzuleiten. Es gibt natürlich viele Anwendungsfälle - und mein angestrebter ist einer davon - wo es nicht nötig ist, Daten an die Node zu senden und in solchen Fällen bedeutet dieser Fakt dann auch keine Einschränkung.

Den Packet Forwarder habe ich mit einem Raspberry Pi 3B realisiert und anschließend mit einem Wemos D1 Mini eine SensorNode aufgebaut. Die Software bestand aus Beispielcode, der der Bibliothek beilag und den ich geringfügig angepasst habe. Damit konnte ich auch die oben ausgeführte Tatsache validieren, dass im TTN nur jedes achte Paket ankam.

Wichtig dabei ist noch zu wissen, dass nach Einschalten die Pakete im FrameCounter wieder bei 0 beginnen zu zählen. TTN hat eine Sicherheitsmaßnahme, die verhindert, dass Pakete weitergeleitet werden, deren FrameCounter kleiner oder gleich ist als der des zuletzt weitergeleiteten Pakets. Das führte dazu, dass mir schien, dass nur der erste Test - dessen Pakete ich sehen konnte - erfolgreich war und alle weiteren nicht. Dieses Feature lässt sich glücklicherweise ausschalten, denn wenn man in meinem Beispiel den Deep Sleep des ESP nutzt beginnt das Programm wieder von vorn und zählt natürlich auch die PacketCounter wieder von 0.

Ich habe noch keine Möglichkeit gefunden, den Startwert dieses Zählers zu setzen - ginge das, könnte ich mir vor dem einschlafen den aktuellen Wert im Flash oder EEPROM merken und nach dem Aufwachen von dort holen und dann damit weiterarbeiten.

Ich habe mir die Nachrichten natürlich nicht nur in der Web-Konsole von TTN angesehen, sondern sie auch per MQTT empfangen - etwas, das ganz wunderbar und zuverlässig funktionierte.

Die nächsten Schritte sind jetzt die Bestimmung der Reichweite meines Packet Forwarders und ein Test (wahrscheinlich kombiniert mit einem GPS-Empfänger) des Übergangs zwischen mehreren Gateways.

Ich habe hier die Links zusammengestellt, die mir letztlich halfen, zu einem funktionierenden System zu kommen:

Links

Artikel, die hierher verlinken