TTN Network Tester

Ich hatte euch ja bereits den M5Stack vorgestellt und das dazu passende LoRaWAN Modul. Zusammen mit dem GPS Modul habe ich mir daraus einen TTN Network Tester gebaut. Als Vorbilder haben dabei der Network Tester von Daniel Knox und das Field Teste Device von Adeunis hergehalten.

Aufbau des Network Tester

Ich verwende für meinen Aufbau einen M5Stack Fire, da dieser mit dem M5Go Base ausgestattet ist, in der bereits ein Akku verbaut ist. Ich nutze die dort verbauten NeoPixel LEDs um mir optisch den Status über GPS und LoRa zurückzugeben. Daneben verwende ich noch das LoRaWAN- und GPS-Modul.

Network Tester aufbau

Die LEDs auf der rechten Seite (von oben nach unten) informieren über HDOP, GPS-Fix und Anzahl der Satelliten. Auf der linken Seite wird der RSSI der empfangenen Pakete wiedergegeben, mit den Farben, wie man sie vom TTN Mapper her kennt.

Alles zusammen ergibt eine leistungsstarkes Werkzeug, mit dem ihr eure Umgebung ausleuchten könnt und um Standorte für neue Nodes beurteilen zu können. Dabei nutze ich auch den MicroSD-Kartenleser, um den GPS-Track aufzuzeichnen und Messdaten, im SSV-Modus, als GeoJSON abzulegen.

Funktionen des Network Tester

Der Tester verfügt über mehrere Betriebsarten, auf die ich hier nun eingehen werden.

NACK -> ACK -> MAN- > LCM -> SSV -> SET

Im Modus NACK (No Acknowledge), übermittelt der Node seine GPS-Daten in einem einstellbaren Intervall. Somit eignet sich dieser Modus perfekt um mit dem TTN Mapper zusammenzuarbeiten. Zusätzlich könnt ihr den Spreadingfactor anpassen und über die Dim Funktion, werden das Display und die LEDs abgeschaltet, bzw. wieder eingeschaltet.

NACK-Modus

Daneben gibt es noch den ACK Modus, in dem das TTN Backend aufgefordert wird, jedes Paket zu bestätigen. Der RSSI- und SNR-Wert des Empfangenen Paketes, wird auf dem Display wiedergegeben.

ACK-Modus

Im MAN Modus (manuell), kann über den Send-Button gezielt ein Paket übertragen werden. Hier erwartet der Node ebenfalls wieder ein ACK, dessen Empfangswerte der Node auf dem Display darstellt.

MAN-Modus

Der Modus LCM versendet einen LinkCheckRequest. In der Antwort des TTN Backends ist hierbei ebenfalls die Anzahl der Gateways enthalten, welche den Request empfangen haben.

LCM-Modus

Um Standorte für Nodes beurteilen zu können, gibt es den SSV Modus (SiteSurvey). Bei seiner Aktivierung wird jeweils ein LinkCheckRequest mit SF7 bis SF12 verschickt. Hierbei solltet ihr auch auf eine passende Antenne achten. Nutzt eine Antenne, wie sie auch am späteren Node Verwendung findet. Die Daten werden im GeoJSON-Format auf der SD-Karte abgelegt und können so z.B. über geojson.io oder QGIS ausgewertet werden. Auf dem Display wird danach ausgegeben, bei welcher DataRate (DR) ein Gateway erreicht wurde (DR5 = SF7, DR0 = SF12).

Über das SET Menü, kann das Sendeintervall festgelegt werden. Dabei stehen aktuell werte zwischen 15 und 120 Sekunden zur Auswahl. Zusätzlich kann den Stromsparmodus aktiviert werden. Dabei schläft der M5 immer für 15 Sekunden und schaut danach was es zu tun gibt. Im Stromsparmodus ist nur der NACK Modus aktiv und aktuell gibt es keine Displayanzeige mehr. Aktuell beendet nur ein Reset den Stromsparmodus. Hier muss ich noch nachbessern.

Settings Menü

Zusätzlich dient der Node auch als GPS-Tracker, da er die GPS Koordinaten in eine GPX-Datei schreibt. So könnt ihr später euren zurückgelegten Weg auswerten.

Die Software

Ich habe das gesamte Projekt auf GitHub abgelegt, somit könnt ihr euch den Sketch anpassen, wie ihr wollt. Sicherlich findet ihr auch noch Bugs und Verbesserungen. Leider bin ich kein Programmierer, daher seht es mir nach, wenn der Sketch an vielen Stellen wie Spaghetti aussieht und nicht gerade elegant daher kommt.

Wichtig für die Nutzer eines M5Stack Fires. In der Arduino IDE muss der PSRAM disabled werden, dieser kollidiert mit der UART2

Ich verwende für das GPS-Modul UART2 mit GPIO 16 und 17 und für das LoRaWan-Modul habe ich UART1 mit GPIO 2 und 5 angepasst. Letzteres könnt ihr über die LoRaWan.cpp anpassen. Über die Lötpads am LoRaWan-Modul müsst ihr den Seriellen Port des Moduls noch auf GPIO 2 und 5 legen.

Aktuell ist das Projekt prinzipiell fertig, bedarf aber noch ein paar Verbesserungen:

  • Auswertung der Tastendrücke verbessern (ist noch recht träge)
  • Code aufräumen
  • Ordentlicher Stromsparmodus
  • Was mir/euch sonst noch so in den Sinn kommt

Verbesserungen die ich mir noch vorstellen kann:

  • Auswahl zwischen ABP und OTAA (momentan kennt die Software nur ABP)
  • Info über DutyCycle Begrenzung im Display (Aktuell gibt es nur einen Error Status)

Auswertung mit geojson.io

Wie oben bereits geschrieben, könnt ihr die Auswertungen des SSV-Modus später betrachten. Über die Webseite geojson.io könnt ihr die Files importieren und die Daten betrachten. Eine Auswertung mittels QGIS ist auch möglich oder eben manuell indem ihr die Datei in einem Editor betrachtet.

Laufleistung

Für einige ist sicherlich noch die Laufleistung interessant, daher habe ich mal nachgemessen. Der Tester ist leider ein Stromfresser und ihr solltet noch eine kleine Powerbank dabei haben. Es ließe sich sicherlich noch strom sparen, indem der GPS Chip schlafen gelegt wird. Ich denke ml in einer der nächsten Versionen werde die diese Option einbauen.

ModusLaufzeit
Normal1h44min
Dim (ohne LEDsund LCD)2h10min
Sleep2h46min

23 Gedanken zu „TTN Network Tester“

  1. Cool dass du so viel über LoRaWAN machst, ich werde dein Blog auf jeden Fall im Auge behalten. Am liebsten würde ich damit einen Smarten Briefkasten realisieren. Hast du daran auch schon mal gedacht und kannst dir vorstellen ein für Jeden verständliches Tutorial zu machen? Hinter der heise Paywall gibt es gerade einen Artikel mit einem ATtiny84 und cr2032 Batterie, aber den find ich eher schlecht, unvollständig etc.

    Leider weiß ich nicht ob bei mir LoRaWAN überhaupt verfügbar ist.
    Im ttnmapper geht 1km von mir ein blauer Strahl vorbei, kommt aber wohl von einer 100km entfernten Stadt. Das heißt am Ende das Strahls hat einer gemessen und es wird angenommen dass es in einem Korridor zum Gateway entsprechend auch verfügbar ist oder? Kann man dann annehmen dass es links und rechts des Strahls auch gehen müsste da es sich mehr oder weniger kreisförmig ausbreitet? Ein paar einzelne Heatmap Punkte sind auch 700 Meter von mir.

    Antworten
    • Hi,
      zu dem Thema hatte ich auch mal was verfasst.

      Ich würde erst mal davon ausgehen, das du keinen Empfang bei dir zu Hause hast. 100km sind enorm und nur unter extrem guten Bedingungen zu erreichen. Da hat jemand auf einer Anhöhe oder einem Berg gemessen. Wenn also innerhalb von einem Kilometer kein Gateway bei dir steht, dann hast du vermutlich keinen Empfang. Je nach umliegender Bebauung können auch viel größere Distanzen überbrückt werden (10km), aber da kann man halt nur raten oder ausprobieren. Deine Annahmen zu dem Korridor sind jedenfalls richtig, aber das spiegelt halt leider oft nicht die Realität wieder.
      Beispiel: Das Gateway liegt hoch und der Messpunkt auch. Dadurch können wirklich enorme Entfernungen überbrückt werden, aber die dazwischen liegenden tieferen Punkte, empfangen trotzdem nichts.

      Grüße,
      Björn

      Antworten
  2. Okay danke, das hatte ich befürchtet. Dann warte ich besser noch ab ob sich da in ein paar Monaten was tut. Auch die nächsten Städte in 4-15km Entfernung haben kein Gateway und nichts gemappt.

    Antworten
  3. Klasse Projekt & danke fuer’s sharen!

    Mein Kommentar eher zur Verfuegbarkeit und zum TTNMapper:
    „Im ttnmapper geht 1km von mir ein blauer Strahl vorbei, kommt aber wohl von einer 100km entfernten Stadt. Das heißt am Ende das Strahls hat einer gemessen und es wird angenommen dass es in einem Korridor zum Gateway entsprechend auch verfügbar ist oder? Kann man dann annehmen dass es links und rechts des Strahls auch gehen müsste da es sich mehr oder weniger kreisförmig ausbreitet?“

    Wir diskutieren das gerade im TTN Slack mit den TTNMapper Leuten – dies is naemlich in der Tat irrefuehrend. Ein einzelner Messpunkt, evtl unter gluecklichen Umstaenden (oder auf einem hohen Turm) gemessen, erzeugt eine umso breiteren „Strahl“, je weiter er weg ist – und das gibt dann eine Pseudo-Deckung auf der Karte.

    Das als Bemerkung zum „mappen“.
    Bei freier Sicht sind aber 100 km nicht unrealistisch – wenn das Gateway schoen hoch ist, und von guter Qualitaet.

    Antworten
    • Hallo Sebastian,

      ich habe den Eintrag gelesen und gebe dir recht. Es macht mehr sinn eine Linie zu zeichnen als einen „Strahl“, der dann auch an seinem Ende eine große Breite hat.

      Grüße,
      Björn

      Antworten
  4. Hallo Björn,

    ein sehr interessantes Projekt. Ich bekomme es aber nicht kompiliert.
    Habe die erforderlichen Libraries installiert und die beiden LoraWAN-Dateien ersetzt, bekomme aber neben vielen anderen Meldungen zum Schluss folgende Fehlermeldung: „collect2: error: ld returned 1 exit status“ 🙁
    Und nun weiß ich auch nicht weiter…

    Antworten
      • Hallo Björn,

        danke für die schnelle Rückmeldung. Hab den Ordner gelöscht und jetzt wird der Sketch auch sauber kompiliert. Allerdings bekomme ich (auch nach längerer Wartezeit) keine Satelliten angezeigt.
        Wenn ich mit dem gleichen Aufbau den GPS-Beispielsketch lade, habe ich innerhalb kürzester Zeit einen Fix und bekomme alle Daten (Lat, Lon, Zeit…) angezeigt.
        Und nun weiß ich wieder nicht weiter… 😉
        Hast Du eine Idee, woran es liegen könnte?
        An deinem Code habe ich bis auf die Keys und die ID nichts verändert.
        Gruß
        Kurt

        Antworten
        • Hi Kurt,
          Ich teste den Sketch morgen auf meinem M5. Ich hatte Änderungen auf GitHub gemacht, die ich wohl vorher hätte testen sollen. Ich würde also erst mal nicht den Fehler bei dir suchen
          Grüße,
          Björn.

          Antworten
          • Hallo Kurt,

            ich habe nochmals alles mit dem Sketch von GitHub getestet. Dabei habe ich zwar einen Fehler gefunden, der hat aber damit nix zu tun.
            Hast du das den seriellen Port des LoRa Moduls geändert? Dieses benutzt normalerweise den gleichen Port.

  5. Hallo Björn,

    danke für den interessanten Artikel.
    Ich habe versucht Deinen Sketch für den TTN Tester zu kompilieren und scheitere dabei immer an dieser Fehlermeldung:

    ‚class LoRaWanClass‘ has no member named ’setDutyCycle‘

    Ich habe Deinen Lorawan M5 Stck habe ich installiert.

    Hast Du eine Idee, wo es klemmt?

    Danke und Gruß

    Antworten
    • Hallo Jens,

      du nimmst die beiden LoRaWAN Files aus networktester/src/ und verschiebst sie nach /Pfad zu deinen Arduino Librarys/M5Stack/src/ . Die Originale ersetzt du. Danach sollte es klappen. In der M5Stack-Variante fehlt der Befehlt setDutyCycle().

      Grüße,
      Björn

      Antworten
  6. Hallo Björn,

    Sehr schöner Artikel. Ich habe aber leider das Problem, dass ich keine Verbindung zum TTN bekomme. Kannst Du mir bitte sagen, wie ich die einzelen KEYS und die Deviceadresse eintragen muss. Ich glaube daran hapert es schon.

    Grüße

    Andreas

    Antworten
    • Hallo Andreas,

      die Keys komme so wie sie sind rein, also einfach auf „copy to clipboard“ drücken und so dann einfügen. Anführungsstriche nicht vergessen, also z.B. „47184712834781237897“

      Grüße,
      Björn

      Antworten
  7. Hallo Björn
    Du hast verschiedene Error’s definiert, welche aber nichts genaues über den Fehler aussagen.
    Hättest Du eine Erklärung zu den Fehlermeldungen ?
    Ich habe kein GPS, aber die Koordianten manuel eingetragen.
    Der RSSI-Balken ist immer grün bei -130db, müsste er bei -130 nicht blau sein ?
    Manchmal kommen pakete an aber meist nicht. Wenn sie dann aber kommen, kommen dann fast alle an.
    War schon beim Hub direkt vor der Haustüre aber nichts kam…
    Viele Grüsse
    Felix

    Antworten
    • Hallo Felix,
      welche Fehler meinst du genau? Bisher wird eigentlich nur zurück gemeldet ob eine Nachricht versendet wurde oder nicht. Wenn nicht gibt es einen Error. Das Warum werte ich, außer beim Duty Cycle Limit, nicht aus.
      GPS kannst du deaktivieren, du musst also nix faken.
      Die Farbe des Balken wird durch die dahinter liegende Library bestimmt und ist nicht wie die Farbskala das TTN Mappers. Wäre für die Zukunft aber ein Thema.
      Wenn keine Pakete ankommen, werden denn welche verschickt, also geht der Counter hoch?

      Viele Grüße,
      Björn

      Antworten
      • hallo Björn

        Vielen Dan für die rasche Antwort.

        Hatte bereits einige Rückmeldungen (siehe Bild)

        Das Wort „Error“ kommt im Code mehrmals vor. Ich habe jeweisl mal die Zeilennummer dahinter geschrieben, kann aber damit nicht wirklich etwas anfangen.
        Da die Nummern aber unterschiedlich sind, gibt es anscheinend für verschiedenen Ereignisse unterschiedliche Fehler.

        GPS: ich wollte halt einfach, dass es mich auf der TTN-Karte anzeigt.
        #ifdef M5gps
        //Write GPS-Data into variables, Fix angepasst,FBr
        void gpsdata() {
        year = 2020;
        month = 07;
        day = 05;
        hour = 12;
        minute = 00;
        second = 00;
        latitude = 47.11113;
        longitude = 7.12345;
        alt = 541.5;
        hdop = 500;
        }
        #endif

        Counter: ja, er geht hoch. Modus: NACK / SF8 / DIM

        Antenne: siehe Bild

        Nächster Hub: knapp 1000m von mir entfernt bei der Fachhochschule (ist aktiv)

        Zukunft: Ein Screen, mit dem aktuell gesendeten Wert und den Rückmeldungen (ohne Grafik, nur Zahlen / Buchstaben) in lesbarer Form (nicht hex oder so).

        Viele Grüsse
        Felix Brodmann

        Antworten
        • Hallo Felix,

          wie bereits gesagt, „Error“ sagt nur aus, das es bei dem Senden einen Fehler gab. Eine genaue Aussage bekommst du nur wenn du den Seriellen Monitor auf hast. Da es verschiedene Funktionen zum Senden gibt, ist auch die Error-Ausgabe mehrfach vorhanden.

          Der M5Stack produziert auch gerne mal einen Wackelkontakt, eventuell mal alles ordentlich zusammen drücken.

          Wenn der Counter hoch geht, dann sendet er jedenfalls erfolgreich. Je nach Lage, können 1000m ein Problem darstellen, du kannst ja den SF hoch drehen.

          Grüße,
          Björn

          Antworten
  8. Hallo Björn
    Ich habe nun ein AT6558-GPS an Port.C.UART angeschlossen. Ist dieses Kompatibel ?
    Nun bekomme ich die Fehlermeldung: „inactive“. Was bedeutet diese ?
    Die Device Address, Network Session Key und App Session Key für ABP meinte ich richtig erfasst zu haben.
    Einen funktionierenden GW (blau, von TTN voll akzeptiert) habe ich auf dem eigenen Dach.
    PS: weiss jemand, ob die Batterie-Module auch stapelbar sind (also das Original und noch weitere) ?
    Gruss
    Felix

    Antworten
    • Hallo Felix,

      der AT6558 sollte theoretisch funktionieren. Der Port C belegt die PINS 16 und 17 und ist somit gleich.
      Inactive bedeutet das kein GPS Fix vorhanden ist und daher kein Paket gesendet wird.
      Hast du am LoRaWAN Modul die Pinbelegung geändert, das musst du jedenfalls. Es belegt auch PIN 16 und 17.
      Ansonsten würde ich erst mal die Kommunikation mit dem GPS Modul überprüfen.

      Zu der Batterie:
      Eine frühere Aussage war das man sie nicht stapeln darf. Jetzt steht aber folgendes beim Battery Module:
      Since the Lipo batteries is parallelable, you can stack mutilple of them to maximum your power endurance.

      Als Zusatz das noch. Es btraf die Misch8jg Plus Modul und Batterie Modul (700 und 500 mAh):
      However, due to different battery capacity combinations, there will be a certain loss of total capacity due to mutual charging.

      Grüße,
      Björn

      Antworten
      • Beim LoRa habe ich die Pin’s auf 3 und 5 geändert.
        Es ging etwas lange bis der GPS-Fix kam und den Counter bei TTN musste ich zurücksetzen, nun läuft es.
        Danke

        Antworten

Schreibe einen Kommentar