Archiv der Kategorie: Arduino

Übersicht über Power over Ethernet (PoE)

Bei vielen Anwendungen nutze ich Power over Ethernet (= PoE). Ist doch praktisch: ein Netzwerkabel wird für die Anwendung oft sowieso benötigt, dann kann man es auch gleich nutzen, um das Endgerät mit Strom zu versorgen. Außerdem ist oft keine Steckdose, wo man sie benötigen würde. Ich habe grundsätzlich nur gute Erfahrungen damit gemacht, teilweise entstehen durch die Nutzung von PoE auch neue Möglichkeiten. Es gibt jedoch verschiedene Standards und Varianten – und die müssen zusammenpassen. Hier also eine kleine Übersicht, die meinen Wissensstand und meine Erfahrungen widerspiegeln.

Im Wesentlichen sehe ich zwei große Varianten an PoE:

  • Passives PoE und
  • PoE nach 802.3af oder 802.3at (auch aktives PoE genannt, bzw. PoE+ bei 802.3at)

Beachtet, dass diese Varianten nicht miteinander kompatibel sind.

Passives PoE

Bei passivem PoE werden mehrere Adern des 8-poligen-Gigabit-Ethernet-Kabels für die Übertragung von Strom genutzt. Meist werden die Adern 4+5 für + und 7+8 für – genutzt. Hier wird einfach Strom von einem Netzteil (auch Injector genannt) durchgeschickt. Grundsätzlich sollte man hier vorsichtig sein, dass man (a) die richtige PoE-Variante einsetzt, (b) die korrekte Spannung überträgt und (c) das Endgerät das unterstützt. Sonst könnte es passieren, dass eine Netzwerkkarte defekt wird, wenn ihr einfach über diese PINs der Strom geschickt wird.

Es gibt viele gängige Varianten, die sich meist durch die Spannung unterscheiden. Bei Ubiquiti und Mikrotik findet man meist 24V passive PoE, in anderen Anwendungen (zB. Videokameras) kommt oft 12V zum Einsatz. Vereinzelt sieht man 5V, hier habe ich die Erfahrung gemacht, dass bei größeren Kabellängen (bereits so ab 10m) der Spannungsabfall relevant wird, von 5V würde ich also abraten bei passive PoE.

In den meisten Anwendungen sieht man, dass ca. 2,1 bis max. 2,5 Ampere übertragen werden. Je nach Spannung kann man also leicht ausrechnen, wieviel Leistung mit dieser Variante zur Verfügung gestellt werden kann. Bei 24V mit 2,1A sind das bereits gut 50 Watt, bei 12V die Hälfte.

Passives PoE heißt also so, weil es einfach Strom durchschickt, ohne weiterer Überprüfung oder Logik.

PoE & PoE+ nach 802.3af und 802.3at

Man sieht an der Überschrift: diese Variante ist genauer standardisiert. Die IEEE hat im Standard 802.3af und 802.3at genau spezifiziert, wie PoE durch das Netzwerkkabel geschickt wird und viele Hersteller nutzen diesen Standard. Das erhöht natürlich die Kompatibilität und so wird es möglich, einen PoE-fähigen-Switch mit beliebigen Endgeräten zu verbinden.

PoE und PoE+ orientieren sich an 48V (Nominalspannung), tatsächlich sieht der Standard 36V bis 57V vor. Das ist schon vernünftig aufgrund der Robustheit bei längeren Ethernet-Verbindungen.

Meines Wissens nach unterscheiden sich PoE (IEEE 802.3af) und PoE+ (IEEE 802.3at) vor allem aufgrund der maximal vorgesehenen Leistung. Diese wird beim Anschluss des Kabels „detektiert“, dafür gibt es einen ausgeklügelten Mechanismus, der den Widerstand des Engerätes misst und darüber erfährt, welchen Standard und welche Leistungsklasse das Endgerät unterstützt. Tolle Sache, va. ist hier auch abgesichert, dass ein Endgerät ohne PoE-Funktion keinen Schaden nimmt und nicht einfach Spannung durchgeschickt wird, wie bei der passiven Variante.

Grundsätzlich würde ich, wenn möglich, dieser Variante von PoE den Vorzug geben.

Falls euch Details zu den Modi, Spannungen, der Detektion und den Leistungsklassen interessiert, möchte ich auf die Wikipedia-Seite verweisen, da diese sehr ausführlich darüber aufklärt: https://de.wikipedia.org/wiki/Power_over_Ethernet

Anmerken möchte ich noch, dass es auch bei IEEE 802.3af/at eine passive Variante gibt, dort werden die PINs 1+2 für + und 3+6 für – genutzt. Vor allem günstigere Injectoren und Splitter setzen darauf. Bisher habe ich keine Probleme damit gehabt. Splitter nach dem 802.3af/at-Standard haben in allen Kombinationen mit Injectoren & Switches funktioniert.

PoE bei Switches

Es gibt von verschiedenen Herstellern zahlreiche Switches, die PoE unterstützen. Die meisten setzen auch hier auf den 802.3af/at-Standard.

Ich finde es sehr praktisch, dass man von Switches aus direkt die Endgeräte mit Strom versorgen kann. Meistens sind diese Endgeräte WLAN Access Points oder IP Kameras. Ich nutze es aber auch gerne für Raspberry Pi oder Arduinos (und andere IoT-Geräte oder Sensoren).

Ein wesentlicher Vorteil hierbei ist, dass man am Switch (meist per Webinterface) den Port PoE-mäßig resetten kann. Wenn also eine IP Cam nicht mehr reagiert, kann ich bequem einen Restart auslösen. Das ist vor allem praktisch bei weit entfernten Standorten und erhöht die Betriebssicherheit immens. Manche Switches können auch Endgeräte per PING überwachen, und wenn diese ein paar Minuten nicht mehr erreichbar sind, resetten sie PoE am Port automatisch.

Bei einer Sache muss man jedoch achtgeben: PoE Switches haben meist ein „Power Budget“, also eine maximale Leistung (in Watt), die sie auf einzelnen Ports oder insgesamt(!) bedienen können. Es kann also sein, dass auf einem 24-Port-PoE-Switch, der zB. 70 Watt Power Budget unterstützt, nicht auf jedem Port eine Kamera mit PoE versorgt werden kann. Das sollte man sich vorher überlegen und danach den richtigen Switch mit der richtigen Leistung wählen.

PoE Adapter für DIY-Projekte

Ich werde oft gefragt, welche PoE-Injectoren (= führt die Spannung in das Netzwerkkabel und enthält manchmal direkt das Netzteil) ich verwende und wie ich die Endgeräte anschließe, zB. Raspberry PI.

Ich führe hier also ein paar Geräte an, die kostengünstig sind und mit denen ich gute Erfahrungen gemacht habe. Die Teile sind Großteils bei Amazon erhältlich oder – wenn man mehr Zeit für die Lieferung hat – auch bei Aliexpress.

PoE Injector & Splitter

zB. bei Amazon:


APRS über LoRa mit Dragino LoRa/GPS shield für 70cm-Band

In den letzten Monaten habe ich mich sehr viel mit LoRa und LoRaWAN beschäftigt. Bei den zahlreichen Treffen hat mir die Amateurfunk-Community erzählt, dass LoRa auch ein guter Ersatz für das FSK/AFSK basierte APRS sein könnte und an einer Implementierung arbeiten.

Das halte ich für eine tolle Idee! APRS hat mich – wie ihr an anderen Beiträgen meines Blogs erkennen könnt – schon immer sehr interessiert!

Es handelt sich also nur um den Ersatz der Modulation durch LoRa und nicht um eine vollwertige LoRaWAN-Implementierung, die ja auch das ganze Umfeld der Datenverarbeitung mit einschließen würde. Daher ist man auch hinsichtlich QRG (Frequenz) flexibel. Die Hardware für LoRa ist ja für 868 MHz, 433 MHz und 912 MHz erhältlich. Der Bereich um 912 MHz ist in der EU nicht frei nutzbar. Im „kommerziellen“ Einsatz (LoRaWAN) ist 868 MHz die Wahl für Europa.

Funkamateure sind sowieso im Bereich um 433 MHz „zu Hause“, das ja für viele Anwendungen als 70cm-Band bekannt ist und dort seitens Amateurfunk als Primärdienst genutzt werden kann.

Damit ist für mich die Trennung der Anwendungen und Frequenzen auch schlüssig umsetzbar:

  • LoRaWAN nutzen wir (kommerziell) auf 868 MHz und
  • LoRa für APRS im 430-439 MHz Bereich als Amateurfunkdienst!

APRS Tracker

Das Ziel ist also, einen APRS-Tracker zB. für’s Auto mit LoRa-Modulation im70cm-Band zu schaffen. Die Daten sollen dann wie andere APRS-Anwendungen über zB. aprs.fi zur Verfügung stehen.

Auf der Webseite von DJ7OO (http://www.kh-gps.de/lora.htm) wird sehr viel zu dem Thema erklärt. Die Software basiert auf Codeteilen, die von Stuart Robinson (ua. auf dieser Website https://www.rcgroups.com/forums/showthread.php?2454546-Arduino-LoRa-Long-Range-Lost-Model-Tracker) veröffentlicht wurden. Bitte beachtet die Lizenz, die hier kommerzielle Nutzung auch von Codeteilen ohne ausdrücklicher Zustimmung von Stuart untersagt.

Die meisten OMs haben ihre Sender auf Basis von Arduino Pro Mini erstellt. Dazu benötigt man noch ein paar Kleinteile, ua. ein GPS-Modul und den RFM98W LoRa-Chip.  Ich gestehe, das Löten vermeide ich, wenn es leicht möglich ist – daher habe ich nach einer andere Hardware-Lösung gesucht.

ohne löten: Dragino LoRa/GPS shield

Mit den LoRa/GPS-Shields von Dragino habe ich ja bereits in anderen Projekten gute Erfolge erzielt. Diese Shields sind natürlich auch für 433 MHz erhältlich. Ich kaufe übrigens meistens über Tindie. Es funktioniert zuverlässig, die Lieferung dauert ca. 3 Wochen:
https://www.tindie.com/products/edwin/loragps-shield-for-arduino/

Das Tolle ist, dass man dazu nur noch einen Arduino Uno benötigt, zusammensteckt und für viele Anwendungen eine fertige Lösung hat!

Als Basis für meinen Code habe ich die Version von Sascha (iot4pi.com) und Karl OE1KEB gewählt, die für den Arduino Pro Mini geschrieben ist:
https://github.com/IoT4pi/LoRa-APRS-Sender
(Den Link zu meinem Fork für’s Dragino LoRa/GPS findet ihr  unten.)

Die Software benutzt SoftSerial, um auf die GPS-Daten zuzugreifen. Dazu benötigt man zwei Jumper Wire Kabel (M-F). Am Dragino LoRa/GPS Shield werden die Jumper bei TX_GPS und RX_GPS entfernt und mit den digitalen Eingängen 3 und 4 verbunden werden.

Bitte beachtet, dass nur lizenzierte Funkamateure diesen Funkdienst benutzen dürfen, es wird auch ein Funkrufzeichen (Call) benötigt, das eingestellt werden muss!

Die von mir für das Dragino LoRa/GPS Shield abgeänderte Software findet ihr hier:

https://github.com/schulti/LoRa-APRS-Sender

Bitte ändert euren Call und ggf. die SSID („-12“)  in dieser Variable:

String Tcall="OE1SCS-12"; //your Call Sign

Die Software muss nun nur noch auf den Arduino raufgeladen werden und schon kann man testen. Der erste GPS-Fix dauert leider ein bißerl – da muss man etwas Geduld haben. An einer blinkenden LED sieht man, dass ein GPS-Fix vorhanden ist.

Ein Blick auf die Webseite https://aprs.fi hat den Tracker sofort gezeigt:

Auch die Rohdaten sehen vernünftig aus. Meine Pakete wurden von OE1XBR-10 empfangen:

Nun bin ich also zusätzlich zur 2m APRS Antenne über 70cm LoRa APRS unterwegs. Zusätzlich habe ich einen GPS Mapper für LoRaWAN (868 MHz):

Für’s Autodach habe ich eine Magnetfußantenne für 433 MHz und einen aktiven GPS-Empfänger bestellt. Das Shield hat eine GPS-Antenne eingebaut. Es schaltet von selbst um, sobald es erkennt, dass eine externe Antenne angesteckt wird.

Damit lassen sich ganz einfach Vergleichsfahrten zwischen den Technologien durchführen, zB: unten links LoRa-APRS-70cm mit APRS-2m im Vergleich (Argent Data OpenTracker+):

Einkaufsliste für den LoRa/GPS APRS Tracker

Die Bauteile sind um gesamt € 42,- erhältlich, um weitere €  15,- gibt’s die Antennen für’s Autodach dazu:

Optional:

LoRa Reichweite mit TTNmapper abschätzen

Nachdem wir jetzt auch einen Gateway fertig haben (ich werde in einem eigenen Beitrag berichten) und mehrere Sensoren funktionieren, wäre es doch mal interessant, die Reichweite der Signale kennenzulernen.

Grundsätzlich senden meine Sensoren bisher nur Messdaten, im Moment aber noch eher statische kurze Textmitteilungen. Was mir fehlt sind die GPS-Positionsdaten, damit ich feststellen kann, von welcher Position mit welcher Signalstärke Pakete empfangen wurden (RSSI).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Bevor ich mich damit beschäftige, mit dem LoRa/GPS Shield auch die GPS-Daten mitzusenden, möchte ich mit ttnmapper.org mal die GPS-Daten dazuschummeln. TTNmapper hat einen super Ansatz dafür gewählt: in der Annahme, dass ich mein Smartphone (Android) und meinen Sensor bei mir habe (mit mir herumtrage oder in meinem Fall beides mit dem selben Auto unterwegs ist), ergänzt TTNmapper mit einer eigenen App einfach die GPS-Position vom Smartphone. Clever!

Funktionsweise

Klarerweise muss ich auf meinem Android Smartphone die App aus dem Play Store installieren. Danach melde ich mich in der App mit meinen Login-Daten bei The Things Network an und wähle aus meinen Applikationen und Devices den Sensor aus, mit dem ich aktuell messen möchte. (Falls jemand seine Logindaten nicht bekanntgeben möchte, kann man auch direkt die Zugangsdaten für den MQTT-Zugang des Device eingeben, das ist natürlich viel umständlicher, aber man muss die Zugangsdaten nicht eingeben).

Ab sofort höre ich jedesmal, wenn ein Paket angekommen ist (die App erfährt das über MQTT wirklich sofort) einen Ton.

Also habe ich eine kleine Magnetfußantenne für 868 MHz neben meine APRS-Antenne auf’s Auto montiert und die App bei meiner heutigen Ausfahrt mitlaufen lassen. Die Stromversorgung über 12V Anschluss auf einen Verteiler mit USB-Hub war zum Glück für Amateurfunkzwecke schon vorhanden und musste ich nur mehr dazustecken.

Es hat super funktioniert! Beim Starten des Motors ist sofort das erste Klingeln am Smartphone hörbar gewesen.

Nach einer kurzen Ausfahrt hat sich folgendes Bild ergeben:

An die Farbgebung muss man sich noch gewöhnen, zum Glück ist eine Legende dabei. Die besten Signalstärken sind rot, die schlechtesten grün und türkis/blau.

Erfreulicher Weise hat mich auch der Gateway von Peter im 2. Bezirk ein paar Mal empfangen.

Zum Vergleich: links die heutige Route über APRS protokolliert und rechts die Punkte, an denen LoRa-Pakete angekommen sind:

LoRa TTN Gateway Pakete mit tcpdump mitprotokollieren

Über die Schnittstellen bei TTN (The Things Network) kann man eine Menge Daten auslesen – natürlich die Inhalte (Payload) der Applikationen und einige technische Werte.

Konkret interessiert mich zB. der RSSI (Eingangssignalstärke) der vom LoRa Gateway empfangenen Pakete. Im Webinterface kann man in der TTN Console im Bereich Gateway mitschauen und erhält hübsche JSON-Objekte, in denen alles enthalten ist. Ich habe aber keine Schnittstelle gefunden, mit der ich es auslesen kann – weder live noch nachträglich (als gespeicherte Werte).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Nachdem ich mir das Protokoll schon angeschaut habe, war mir klar, dass es die Daten unverschlüsselt überträgt. Es nutzt übrigens UDP für die Kommunikation zu den TTN Network Servern auf Port 1700.

Also habe ich meiner /etc/rc.local (vor dem „exit 0“!) folgenden Eintrag hinzugefügt:

/usr/sbin/tcpdump -Aq port 1700 >> /var/log/ttn-tcpdump-gateway.asc &

Damit wird nach jedem Reboot in die Datei /var/log/ttn-tcpdump-gateway.asc per tcpdump in ASCII die Inhalte aller Verbindungen zu Port 1700 gespeichert:

Mich interessieren eigentlich nur Übertragungen und Statusmeldungen. In beiden kommt „rx“ vor:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx

Die Meldungen beginnen immer mit 41 Zeichen (Byte) Header, die kann man wegschneiden:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx | cut -c 41-

Wenn nach „rxpk“, der Meldung für ein empfangenes Paket suche, erhalte ich nur Meldungen, die der Gateway über LoRa empfangen hat:

cat /var/log/ttn-tcpdump-gateway.asc | grep rxpk | cut -c 41-

Hier hat man nun je Zeile ein JSON-Objekt mit sämtlichen Details zur Kommunikation:

{"rxpk":[{"tmst":4242060820,"time":"2017-04-15T14:55:05.977557Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-10.5,"rssi":-115,"size":24,"data":"QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"}]}

wird zB. mit http://jsonviewer.stack.hu/ zu

{
  "rxpk": [
    {
      "tmst": 4242060820,
      "time": "2017-04-15T14:55:05.977557Z",
      "chan": 1,
      "rfch": 1,
      "freq": 868.300000,
      "stat": 1,
      "modu": "LORA",
      "datr": "SF9BW125",
      "codr": "4/5",
      "lsnr": -10.5,
      "rssi": -115,
      "size": 24,
      "data": "QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"
    }
  ]
}

LoRa Sensor mittels Arduino und LoRa Shield

Über einen Freund bin ich vor ein paar Wochen auf das Thema LoRa bzw. LoRaWAN aufmerksam geworden.

Vor allem seit ich The Things Network (https://www.thethingsnetwork.org) kenne und somit über die Community eine Möglichkeit besteht, die Technologie sinnvoll zu nutzen, bin ich interessiert mich damit mehr zu beschäftigen.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Ein LoRa Sensor ist ein Endgerät, das über das LoRa-Protokoll in ein Netzwerk Informationen funkt. Empfangen werden die Pakete üblicherweise von einem Gateway. Bis zur Auswertung der Pakete sind noch Network Server und Application Server nötig, die in meinem Fall über TTN (The Things Network) bereitgestellt werden.

Da ich auch mit Freunden einen Gateway bauen möchte, brauchen wir natürlich einen LoRa Sensor, um unseren Gateway zu testen. Als günstige Variante habe ich Arduino + LoRa Shield für Arduino gefunden.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt und auf Twitter (@TTN_Vienna) für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Zutaten

Falls jemand entspannt an das Projekt herangeht und mit 5-6 Wochen Lieferzeit aus Shenzhen (China) kein Problem hat, gibt es das LoRa Shield auch kostengünstiger (€ 18,70 am 1.4.2017) über Tindie zu kaufen. Hier beachtet bitte, dass Shipping (+ € 6,12 nach Österreich) und ggf. Zoll dazukommen.

Bitte beachtet bei Bestellungen immer, dass ihr die 868 MHz-Variante auswählt! Nur diese darf in der EU betrieben werden bzw. wird hier funktionieren!

Von der Vorgehensweise halte ich mich an diese Anleitungen:

  1. ein tolles Youtube-Video, das genau den hier beschriebenen Aufbau erklärt: LoRa Node with Arduino and Dragino Shield connected to TTN LoRaWAN von Andreas Spiess
  2. Software (Arduino Sketch) „Hello World“ von https://github.com/SensorsIot/LoRa
  3. LMIC library von IBM, angepasst für Arduino: wird vom Arduino Sketch benötigt

Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!

Zusammenbau

Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.

Konfiguration

Nun lädt man den Arduino Sketch („Hello World“, siehe Link oben) ins Arduino IDE und muss ein paar Werte anpassen. Dazu erstellt man eine „Application“ in der Console von TTN und legt ein Gerät („Device“) an. Eine Over-The-Air-Activation (OTAA) ist nicht möglich, daher muss man manuell ABP wählen und die Werte vom Webinterface abschreiben. Diese werden von TTN automatisch generiert.

  1. NWKSKEY: der Network Session Key muss im korrekten Format in die geschwungenden Klammern { } eingefügt werden.
  2. APPSKEY: ebenso der Application Session Key und zum Schluss die
  3. DEVADDR, also die Geräteadresse im korrekten Format.

TTN bietet im Webinterface übrigens die Werte bereits im richtigen Format an. Im Zweifelsfall muss man auf „< >“ klicken, dann werden die Werte in anderen Formaten dargestellt und können mit copy & paste übernommen werden. Das gewünschte Format ist „msb“.

Ansonsten musste ich keine weiteren Änderungen am Code durchführen.

Trotzdem habe ich den zu übertragenden Text von „HI“ auf „stefan test“ geändert: dazu habe ich die Payload in der Variable „message[]“ in Zeile 57 angepasst:

  // Payload to send (uplink)
  static uint8_t message[] = "stefan test";

Nun habe ich den Sketch kompiliert und auf den Arduino übertragen. Unmittelbar darauf hat er begonnen, alle 20 Sekunden kurz zu blinken, wodurch ich mich bestätigt gefühlt habe, dass es funktioniert und nun alle 20 Sekunden die Meldung „stefan test“ mittels LoRa übertragen wird.

Überprüfen am Gateway

Einen Gateway hatten wir parat und er hat sofort die Pakete empfangen. Über die „Traffic“ Funktion in der TTN Console kann man die ankommenden Pakete gleich sehen.

Man sieht hier mehrere Pakete, die im Abstand von ca. 25 Sekunden ankommen. Die Frequenz wechselt bei jedem Paket, weil mehrere Kanäle genutzt werden: 868,1 – 868,5 – 868,3 usw.

Folgendes JSON Objekt mit allen Details erhält man aus der TTN Console beim Gateway Traffic:

{
  "gw_id": "eui-b827ebfffe6f377d",
  "payload": "QI4cASaAaAABhVJosx+GBwUwHBqp4DGG",
  "f_cnt": 104,
  "lora": {
    "spreading_factor": 9,
    "bandwidth": 125,
    "air_time": 205824000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-03-29T05:57:06.352Z",
  "rssi": -25,
  "snr": 11.2,
  "dev_addr": "26011C8E",
  "frequency": 868100000
}

Es enthält sämtliche Details zur Übertragung. Ein paar Werte möchte ich kurz hervorheben:

  • gw_id: zeigt die ID des Gateways, der das Paket empfangen hat
  • payload: sind die übertragenen Daten in verschlüsselter Form
  • f_cnt: ist der Counter und gibt die Anzahl der Pakete wider
  • lora.spreading_factor: zeigt hier den Spreading Factor 9, der im Sketch eingestellt ist
  • rssi: zeigt die Signalstärke des empfangenen Pakets am Gateway an (hier: -25 dbm)
  • snr: das Signal/Rausch-Verhältnis
  • dev_addr: die Geräteadresse, die von TTN vergeben wurde und ich als DEVADDR im Sketch hinterlegt habe.
  • frequency gibt die Frequenz in Hertz an

Wir sehen, dass das Paket einwandfrei übertragen wurde und sogar sehr gut (-25 dbm) empfangen wurde. Bei diesem Test war der Abstand vom Sensor zum Gateway aber auch im Bereich von 5 Metern.

Optimierungen

Als Spreading Factor ist 9 eingestellt. Um die Reichweite zu erhöhen, kann man auch zB. SF12 einstellen. Das geht im Arduino Sketch auf Zeile 90:

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF9, 14);

Falls man die Pakete weniger oft übertragen möchte (alle 20 Sekunden ist zum Testen super, aber dauerhaft verbraucht es zu viel Airtime), kann das in Zeile 39 anpassen:

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 20;