LoRaWAN – Einen Sensor aktivieren

Hinzufügen von Drahtlos-Fernverbindungen mit niedriger Leistungsaufnahme zu einer bestehenden Sensorplattform.

Das Verbinden von Geräten war nie einfacher. Dank LoRaWAN und The Things Network ist es nun denkbar unkompliziert, Daten von Sensoren, die sich in großer Entfernung vom Gateway — einer LoRaWAN-Basisstation — befinden, in eine mit dem Internet verbundene Anwendung zu bekommen.

In diesem Beispiel verwenden wir eine mit SmartEverything LION (124-8830) Arduino-kompatible Platine mit LoRaWAN, GPS und mehr, zusammen mit einem Ardubat Shield für die Erkennung von Fledermäusen mittels Ultraschall. Es sollte jedoch möglich sein, dies für die zur Verwendung mit anderen Shields und angeschlossenen Sensoren problemlos anzupassen.

LoRaWAN

Eines der wirklich großartigen Dinge bei LoRaWAN ist, dass jeder damit ein Netzwerk aufbauen kann — die Gateways sind relativ kostengünstig und einfach genug zu konfigurieren. Es gibt verschiedene Optionen für das LoRaWAN Backend, die man sich als einen „Netzwerkkern“ vorstellen kann, der für die Weiterleitung von Daten zu/von Anwendungen und für die Geräteaktivierung etc. zuständig ist. Diese Optionen umfassen The Things Network (global), Things Connected (nur Großbritannien) und Standalone-/selbst gehostete Software-Lösungen. 

In dem Gebiet, in dem wir ansässig sind, befinden sich eine Reihe von an The Things Network (TTN) angeschlossenen Gateways, was bedeutet, dass wir keinerlei Anforderungen an die Infrastruktur haben und ganz einfach einen Knoten einfügen und dieses öffentlich verfügbare Netzwerk nutzen können. Wenn dies nicht der Fall wäre, könnte problemlos ein neues Gateway auf TTN eingerichtet werden, das außerdem den Vorteil hat, dass es gemeinsam mit der Community zwecks Erweiterung der Netzabdeckung genutzt werden kann.

Möglicherweise haben Sie bereits Zugriff auf ein Gateway. Um zu sehen, ob eines in der Nähe ist, können Sie auf der Kartenachsehen. Wenn Sie eine Sichtlinie zu einem Gateway haben oder vielleicht nur ein paar Bauwerke im Weg sind, können Sie mit hoher Wahrscheinlichkeit eine Verbindung mit dem Gateway herstellen.

Die von diesen Netzwerken verwendete Drahtlostechnologie (LoRa) ist ein modernes Wunder. Es kommt dasselbe Funkspektrum zum Einsatz, das viele drahtlose Schlüsselanhänger und Türklingeln nutzen: 868 MHz (in der EU und in anderen Teilen der Welt nutzt man andere Frequenzen). Ein Schlüsselanhänger funktioniert auf eine Entfernung von vielleicht 30 m, wohingegen LoRa leicht 3.000 oder sogar 15.000 m erreichen kann — Ja, das ist kein Tippfehler: eine Reichweite von 15 km ist möglich.

Diese extreme Reichweite wird durch die intelligente Nutzung physischer Gegebenheiten möglich, die bereits seit einiger Zeit bekannt sind, aber in der gewerblich genutzten Elektronik bis vor Kurzem nicht umgesetzt wurde. Anstatt eine einzige Frequenz zu nutzen, wie das bei den meisten Funkverbindungen der Fall ist, sind die LoRa-Wellenformen „gespreizt“, und zwar durch Modulieren eines FM-modulierten Chirps auf einen festen Signalpegel. Diese Methode wird als Chirp Spread Spectrum bezeichnet. Durch das Aufchirpen eines Signals wird es viel einfacher, Störer aus dem Hintergrundrauschen herauszufiltern oder sogar ein-/auszublenden. 

Die Art und Weise, auf die die Daten verschlüsselt werden, ist auch darauf ausgerichtet, so viel zusätzliche Reichweite wie möglich zu erzielen und es sind diese beiden Bestandteile, die diese grandiosen Entfernungen möglich machen.

Was ist mit dem WAN-Bestandteil?

Der Wide Area Network (WAN)-Teil des LoRaWAN ist die clevere IoT-Seite des Puzzles. Der Knoten-Teil wird zusammen mit dem LoRa-Protokoll vom Microchip-RN2483-Modul auf dem SmartEverything LION verarbeitet. Das Gateway transportiert Datenpakete zum/vom TTN und es besteht für uns wenig Notwendigkeit darin, etwas anderes zu tun, als unseren Knoten mit diesem Netzwerk zu verbinden; es kümmert sich um den Rest — De-Duplikation des Netzwerks, Gateway-Verwaltung, Datenweiterleitung, Verschlüsselung und Sicherheit, um nur einige der Aufgaben zu nennen.

Fledermaus-Erkennung

Die meisten Fledermausdetektoren funktionieren durch Abhören der Ultraschall-Pieptöne, die die Fledermäuse zur Echoortung verwenden. Von Länge und Frequenz dieser Pieptöne können wir ableiten, welche Fledermausart wir entdeckt haben. Während Fledermausdetektoren für die gewerbliche Nutzung bereits auf dem Markt sind, konnten wir keine LoRaWAN-fähigen finden, sodass dies möglicherweise eine komplette Neuheit ist! 

Der Ardubat-Detektor weist einige Einschränkungen im Vergleich zum gewerblichen Angebot auf. Es wird beispielsweise im hohen Kilohertzbereich ein wenig unempfindlich, was bedeutet, dass wir eventuell die Große/Kleine Hufeisennase (80-100 KHz) nicht entdecken können. Darüber hinaus zeichnen wir den Ton nicht auf — lediglich die Impulshäufigkeit und Dauer — womit die Unterscheidung einiger Spezies schwierig sein könnte.

In Anbetracht der Eigenarten eines Fledermausdetektors mussten wir Folgendes berücksichtigen:

• Er muss über einen längeren Zeitraum hinweg im Batteriebetrieb laufen.
• Eine fixe Montage erfolgt auf einem Feld oder in einer Scheune, fern von WLAN und Stromanschluss

Unser Gerät

Die Arrow SmartEverything LION-Entwicklungsplattform ist ein Arduino-kompatibles LoRaWAN-Gerät / ein komplettes IoT-Entwicklungs-Kit in einem kompakten Paket.

Zunächst müssen Sie (wie bei jedem LoRaWAN-Gerät) die HWEUI herausfinden. Hierbei handelt es sich um eine eindeutige Kennung für den Netzwerkzugriff. Am Nächsten kommt sie im Analogbereich der MAC-Adresse, die die Meisten von uns von früher kennen.

Das Ausfindigmachen dieser Kennung variiert von Gerät zu Gerät und für die LION gibt es einige Möglichkeiten. Die einfachste besteht jedoch darin, das Codebeispiel „getChipInformation“ zu laden, das die Kennung am seriellen Anschluss ausgibt. Eine weitere Möglichkeit ist die, den Code unten in Ihrer Hauptanwendung anzeigen zu lassen, was den Direktzugriff auf das RN2483-Modul ermöglicht und den wir über den Befehl „sys get hweui“ abrufen können.

    if (Serial.available()) 
    {
        c = Serial.read();    
        Serial.write(c); 
        buff[i++] = c;
        if (c == '\n') 
        {
            Serial.print(lora.sendRawCmdAndAnswer(buff));
            i = 0;
            memset(buff, 0, sizeof(buff));
        }
    }

Einrichten von The Things Network

Die Einrichtung eines Kontos bei The Things Network ist einfach. Nach einem normalen Konto-Einrichtungsverfahren werden Sie angemeldet und erhalten innerhalb von Minuten Zugriff auf das Netzwerk. Als Nächstes müssen wir die TTN-Konsoleeingeben und unseren Knoten einrichten.

In der Registerkarte „Anwendungen“ können wir zuerst eine neue Anwendung hinzufügen:

Danach müssen wir unser Gerät anmelden und uns wird eine Geräteübersicht angezeigt, die wie folgt aussieht:

Nach Vervollständigung dieses Teils ist unser LoRaWAN-Gerät konfiguriert und kann eine Verbindung zum Netzwerk die Dinge herstellen, sobald wir unseren Arduino-Code eingegeben haben.

Da wir bereits über Erfahrungen mit der SmartEverything LION verfügen, haben wir diesen Schritt übersprungen, jedoch ist dies ein guter Ausgangspunkt, um mit dem Beispiel „sendDataOTA_Console“ zu beginnen und Ihre Einstellungen und die Netzwerkverbindung zu testen. Der einzige Code, der in diesem Beispiel geändert werden muss, sind die unten stehenden Zeilen. Die Informationen finden Sie in der Registrierkarte „Geräteübersicht“ auf unserer TTN-Anwendung.

err = lora.macSetAppEUICmd("0000000000000001");

lora.macSetAppKeyCmd("ffffffffffffffffffffffffffff0000");

Netzwerkbeschränkungen

Ein wichtiger Punkt, den man bei der Nutzung von LoRaWAN beachten muss, ist die Tatsache, dass die Datenbandbreite niedrig ist — sehr niedrig!

Die zulässigen Grenzen betragen etwa 1 % pro Kanal, variieren jedoch. Dies ist vermutlich eine feste Grenze, die Ihr Modul — in unserem Fall das RN2483 — durchsetzen wird. Dies ist auch eine Grenze, die die Gateways einhalten müssen (mehr dazu später).

Zusätzlich haben TTN eine Fair Access Policy für Netzwerkknoten. Dadurch wird die Sendezeit auf 30 Sekunden Uplink pro 24 Stunden und 10 Downlink-Meldungen pro Tag begrenzt. Da Gateways diese TX-Grenzen einhalten müssen, ist eine Antwort vom Gateway nicht garantiert, insbesondere dann nicht, wenn jemand die „Fair Use“-Richtlinie auf Ihrem Gateway missachtet.

Es gibt zwei mit LoRaWAN zur Verfügung stehende Bereitstellungsarten: Over-the-Air-Aktivierung (OTAA) und die Aktivierung durch Personalisierung (ABP). Auf einer vereinfachten Ebene verwendet ABP eine fixe Taste und diese ändert sich niemals. Dies kann zu einem Sicherheitsproblem werden, da die Verschlüsselungs-Codes sich nie ändern und es über einen längeren Zeitraum hinweg leichter sein könnte, diese zu knacken.

OTAA weist bei jeder Verbindung einen neuen Verschlüsselungs-Code zu. Dieser kann somit erneuert werden, indem Ihr Gerät neu gestartet und ein neuer Verbindungsaufbau erzwungen wird. Diese zweite Bereitstellungsart ist etwas komplizierter zum Laufen zu bringen und stützt sich auf eine Antwort vom Gateway. Dies bedeutet, dass es möglicherweise einige Zeit dauert, eine funktionierende Verbindung aufzubauen, wenn das Gateway besetzt ist oder seine Zuweisung von TX verwendet hat.

Anpassung des Beispiels

Nachdem wir zuvor dieses Beispiel an andere Anwendungen angepasst hatten, haben wir ein paar Beschränkungen ausfindig gemacht:

• Die Hauptschleife verfügt über eine schlechte Zeitsteuerung und kann das Drahtlosmodul spammen.
• Das Hinzufügen des Codes kann wegen der oben erwähnten Anpassung der Zeitsteuerung ein Problem darstellen.
• Dies führt dazu, dass durch das RN2483, das TX-Anfragen ablehnt, Verbindungsprobleme verursacht werden.

Die Lösung dieses Problems ist die Implementierung einer präziseren Zeitplanungsschleife und die Begrenzung von TX-Ereignissen auf eine bestimmte Minutenzahl. Am Ende verwenden wir 60 Minuten in unserer Endanwendung. Beim Mindestausbreitungsfaktor (Mindestreichweite) von SF7BW125 verbrauchen 2 Byte Nutzdaten ca. 45 Millisekunden Sendezeit je Verbindung. Dies ergibt eine Gesamt-TX von 1 Sekunde Sendezeit pro Tag. Würden wir bis auf SF12 (längste Reichweite) gehen, hätten wir 27,6 Sekunden, was so ziemlich die gesamte an unserem Knoten zur Verfügung stehende Sendezeit ist, ohne Verletzung der „Fair Use“-Richtlinie.

Im LoRaWAN ist es sehr wichtig, diesen Unterschied beim Ausbreitungsfaktor auszugleichen und nicht zu erwarten, dass alles bei SF7 liegt, denn SF12 kann genauso wahrscheinlich sein. In diesem Sinne haben wir eine Menge des Codes aus dem Beispiel in eine Funktion namens „LoRa_TX“ übernommen, indem wir die gesendeten Daten durch unseren eigenen String ersetzen und zum bestätigten TX eine bedingte Prüfung hinzufügen. So können wir entscheiden, es regelmäßig zu verwenden.

if (MAC_JOINED(state)) 
{
     if (!joined) 
     {
          Serial.println("\nOTA Network JOINED! ");

          joined = true;
     }
          
     tx_cnt++;

     if(Confirmtx==true)
     {
          Serial.println("Sending Confirmed String and clearing count...");
                
          returned = lora.macTxCmd(String(s), 1, TX_ACK);  // Confirmed tx check received ok so we can clear the count
          if(Serialdebuglevel <=1)
          {
                Serial.println(returned);
          }
          if(returned == "RN_OK")
          {
                       
                BatsDetected =0;  // clear bat count
          }
                Confirmtx=false;
     }
     else
     {
                Serial.println("Sending UnConfirmed String ...");
                lora.macTxCmd(String(s), 1);   // Unconfirmed tx buffer if required
     }
                    
} 
else 
{   
     joined=false;// Network is not joined so try to join
     Serial.println("\nNot Joined Tying to Join");
     lora.macJoinCmd(OTAA); // wait a while after joining
     delay(4000);
}  

Wir haben eine Hauptschleife, die ziemlich leer aussieht:

void loop() 
{
    static bool joined = false;
   
    LoRa_management(); // in here we relay commands to the RN2483 and deal with RX.
    bat_detection_loop(); // bat related items get done here
    checktime();  // this keeps track of time (must be entered a few times per second to avoid loss of time)
    Time_to_tx(); // check the set the flag Go_Tx when we are ready to tx.
    
    if (Go_Tx) 
    { 
        Serial.println("\nTry to TX:\n");
        LoRa_TX(String(BatsDetected));  // this sends the Bat string
        Go_Tx=false;
    }
}

Hinzufügen der erforderlichen liberalen Verwendung globaler Variablen und Einrichtung. Das mag nicht optimal sein, ist aber hier um der Zweckmäßigkeit willen gerechtfertigt. Die Anwendung wird gestartet und stellt eine Verbindung mit The Things Network her.

Verbesserungen

Ab sofort speichert der Code eine kumulative Fledermausanzahl und überträgt diese unbestätigt alle 60 Minuten. Danach wird der Zähler nach einem bestätigten Uplink alle 12 Stunden zurückgesetzt (nur nach erfolgreichem Uplink).

Mögliche Verbesserungen:

• Idealerweise sollte dies eine gesteuerte Netzwerkanwendung sein und es könnte ein Downlink gesendet werden, um diese Zähler-Rücksetzfunktion zu realisieren.
• Die Fledermaus-Erkennung ist nicht sehr intelligent und sollte nach Häufigkeit und Dauer der empfangenen Impulse „klassifiziert“ werden. Dies ist lediglich eine Frage der Programmierung und des Experimentierens.
• Die Protokollierung sollte auf einer SD-Karte erfolgen.
• Das System verbraucht eine ganze Menge an Energie und könnte eine Hardware-Zeitsteuerungs- und Sleep-Routine gebrauchen, so dass praktischer für Akku-Anwendungen ist.
• Besonders wichtig ist schließlich, dass unsere Daten etwas „aufgebläht“ sind, da wir ASCII-codierte Zeichenfolgen verwenden. Idealerweise benötigen wir einen Handler zum Komprimieren und Entfernen überflüssiger Daten und um nur Binärdaten zu senden.

Abschließende Worte

Das Hinzufügen der LoRaWAN-Funktionalität zu einem beliebigen Sensor ist eine relativ triviale Angelegenheit. Wie bei allen Dingen, gibt es auch hier noch Raum für Verbesserungen. Die Kernfunktionen können jedoch mühelos erreicht werden.

Diese Technologie ermöglicht eine Funkverbindung mit niedriger Leistungsaufnahme und eignet sich ideal für langfristige Protokollierungsanwendungen. Sie weist einige Einschränkungen auf, aber wenn wir diese kennen und unseren Code entsprechend umsetzen können wir ein zuverlässiges, kostengünstiges System für so ziemlich jeden Sensor zu schaffen.

Karl Woodward