Ich muss wieder öfter SD-Karten backupen und kopieren, daher notiere ich mir hier ein für alle Mal die Kommandos unter Linux dazu. Vielleicht hilft’s noch wem.
Erstellen eines Backups
sudo dd bs=4M if=/dev/sdb | gzip > ./sd-card-img.gz
Zurückspielen eines Backups
sudo gzip -dc sd-card-ah2-rpi2-1ch-dragino.img.gz | sudo dd bs=4M of=/dev/sdb
Kopieren einer Karte
sudo dd bs=4M if=/dev/sdb of=/dev/sdc
Mittlerweile nutze ich für mehrere Projekte WordPress. Ich bin recht zufrieden, die Blogs laufen teilweise schon fast 3 Jahre und ich habe kaum Probleme.
Leider laufe ich immer wieder in Probleme beim Update über das Webinterface. Eine Alternative scheint zu sein, Updates per Kommandozeile auszuführen. Dazu gibt es das Werkzeug “wp-cli”, das ich hier kurz vorstellen möchte.
Das Werkzeug wird von dieser Adresse gedownloadet und getestet: https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ php wp-cli.phar --info
Wenn alles OK ist, installiere ich es als /bin/wp und setze das Execute-Bit:
$ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /bin/wp
Nun kann ich es systemweit als “wp” aufrufen. Für Aktionen sollte es als User laufen, mit dem auch WordPress betrieben wird. Dazu starte ich es über sudo und mit Hinweis auf den Installationspfad der WordPress-Dateien:
root@wp:~# sudo -u wp -i wp --path=/var/www/html --info PHP binary: /usr/bin/php5 PHP version: 5.5.9-1ubuntu4.22 php.ini used: /etc/php5/cli/php.ini WP-CLI root dir: phar://wp-cli.phar WP-CLI vendor dir: phar://wp-cli.phar/vendor WP_CLI phar path: /home/wp WP-CLI packages dir: WP-CLI global config: WP-CLI project config: WP-CLI version: 1.4.1
Updates spiele ich nun mit Hilfe von wp-cli ein. Damit lassen sich auch mehrere Updates über mehrere Installationen automatisieren. Mit dem Suffix “–all” muss man nicht einzeln die Plugins anführen, sondern kann alle Plugins in einem Durchgang aktualisieren.
Plugins kann man mit diesem Kommando auf einmal updaten:
sudo -u wp -i wp --path=/var/www/html plugin update --all
Themes werden auf diesem Weg alle aktualisiert:
sudo -u wp -i wp --path=/var/www/html theme update --all
Und die Core Version von WordPress wird mit diesem Kommando auf den neuesten Stand gehoben:
sudo -u wp -i wp --path=/var/www/html core update
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:
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.
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+):
Die Bauteile sind um gesamt € 42,- erhältlich, um weitere € 15,- gibt’s die Antennen für’s Autodach dazu:
Optional:
Obwohl ich der Meinung bin, dass vollwerte LoRaWAN-kompatible Gateway wirklich Sinn ergeben, beschäftige ich auch mit den preiswerten Single Channel (1ch) Gateways. Für Entwicklungen zu Hause ist das ja eine günstige Option.
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!
Hier habe ich eine Anleitung gefunden, mit der tatsächlich um € 13,90 für das LoRa-Modul ein Raspberry Pi supereinfach zu so einem 1ch-Gateway wird: https://www.hackster.io/ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36
Achtung, die Anleitung im Link oben empiehlt die Änderung zur amerikanischen Frequenz (902,3 MHz). In Europa bleiben wir bei 868,1 MHz! (Das ist eh der Standardwert) In meiner Anleitung ist auch die IP-Adresse der europäischen Server von TTN enthalten.
Die Schritte sind recht einfach:
7 davon lötet man an diese Position am Transceiver Modul: DI00, 3.3V, MISO, MOSI, SCK, RESET, NSS und GND (neben MISO)sudo apt install git wiringpi
git clone https://github.com/tftelkamp/single_chan_pkt_fwdsudo raspi-config
// Set location float lat=48.1906; float lon=16.3867; int alt=200; /* Informal status fields */ static char platform[24] = "1ch Gateway"; static char email[40] = "meine@email.adresse"; static char description[64] = "RFM95W directly wired"; // define servers #define SERVER1 "52.169.76.203"
make
./single_chan_pkt_fwd
Ich lege mir meist noch ein Startkommando zurecht, bei dem ich auch den Output in die Datei /var/log/ttn-single-chan-pkt-fwd.log schreibe. Dazu füge ich in der /etc/rc.local folgendes hinzu (am Ende, aber vor dem “exit 0”):
/home/stefan/single_chan_pkt_fwd/single_chan_pkt_fwd >> /var/log/ttn-single-chan-pkt-fwd.log 2>&1
Nach einem Reboot wird so die Software automatisch ausgeführt und ein Logfile angelegt.
Mit dem Dragino LoRa GPS HAT auf meinem Raspberry Pi 2 betreibe ich einen Single Channel Gateway, wie in meinem anderen Beitrag beschrieben.
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!
Nun möchte ich auch die GPS-Funktion ausprobieren! Vielleicht kann ich es zur Zeitsynchronisierung nutzen? Naja, vielleicht im Vergleich zu NTP für meine Anforderungen etwas viel Aufwand. Aber schauen wir mal…
Als Antenne verwende ich eine Magnetantenne (für zB. Autos) mit 3m Kabel.
Die serielle Schnittstelle ist am Raspberry mit der Console belegt und muss erst freigegeben werden, bevor wir GPS-Daten empfangen können:
In der Datei /boot/cmdline.txt entfernen wir den Eintrag für
console=/dev/ttyAMA0
Danach beenden und deaktivieren wir das Service für die serielle Ausgabe:
# systemctl stop serial-getty@ttyAMA0.service # systemctl disable serial-getty@ttyAMA0.service
Nun installieren wir gpsd & Co:
# apt-get install gpsd gpsd-clients python-gps
Folgende Zeilen bleiben in meiner /etc/default/gpsd als Konfiguration:
START_DAEMON="true" USBAUTO="true" DEVICES="" GPSD_OPTIONS="/dev/ttyAMA0" GPSD_SOCKET="/var/run/gpsd.sock"
Nach einem Reboot kann ich cgps aufrufen:
An diesen Anleitungen habe ich mich orientiert:
für Raspberry Pi 2
für Raspberry Pi 3 funktioniert es ein bißerl anders.
Mit Freunden baue ich einen Multi-Channel-Gateway, der auf sämtlichen LoRa-Kanälen empfangen und senden kann – und das mit allen SF (Spreading Factors). So ein Gateway kostet knapp 400 Euro in Summe – das ist mir zum Spielen für zu Hause zu teuer.
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!
Die günstige Variante, die streng genommen nicht LoRaWAN-kompatibel ist, weil sie nur eine Frequenz und einen Spreading Factor unterstützt, ist ein Single Channel Gateway. Dieses hört auf einen vordefinierten (aber konfigurierbaren) Kanal mit einem vordefinierten Spreading Factor (auch konfigurierbar) und sendet die Daten an The Things Network.
Als Basis nehme ich einen Raspberry Pi 2, der aktuell eh auf eine Aufgabe wartet. Das LoRa & GPS HAT von Dragino nutze ich für die LoRa-Übertragungen. Das HAT habe ich um € 29,- bei Tindie erstanden. In Summe bin ich bei Kosten von weniger als € 65,-.
Wie beschrieben ist ein Single Channel Gateway kein vollständig LoRaWAN-kompatibler Gateway. Er hört nur auf eine Frequenz (Kanal) und versteht nur einen SF. Nachdem meine Sensoren abwechselnd auf drei Frequenzen senden, stelle ich den Single Channel Gateway auf eine Frequenz ein – und ich stelle mich darauf ein, nur jedes dritte Paket zu empfangen. (Da bei LoRa ja ein Counter mitläuft, kann ich das leicht nachprüfen.)
Falls ich einmal einen Sensor permanent installieren möchte, würde ich ihn fix auf die eine Frequenz stellen, die der Gateway (oder mehrere?) auch nutzt. Damit wäre ein kleines LoRa-Netzwerk möglich, das aber nur auf einer Frequenz funktioniert.
Es ist ganz einfach:
apt-get update && apt-get dist-upgrade apt-get install wiringpi
3. in raspi-config das SPI Interface aktivieren & rebooten
4. die Single Channel Gateway Software von Github laden und installieren:
wget https://github.com/tftelkamp/single_chan_pkt_fwd/archive/master.zip
unzip master.zip
und ein paar Parameter in der main.cpp konfigurieren:
// SX1272 - Raspberry connections
int ssPin = 6;
int dio0 = 7;
int RST = 0;
// Set spreading factor (SF7 - SF12)
sf_t sf = SF7;
// Set center frequency
uint32_t freq = 868100000; // in Mhz! (868.1)
// Set location
float lat=48.0;
float lon=16.0;
int alt=200;
/* Informal status fields */
static char platform[24] = "Single Channel Gateway"; /* platform definition */
static char email[40] = "meine@email.at"; /* used for contact email */
static char description[64] = "Dragino LoRa GPS HAT Raspberry 2"; /* used for free form description */
// define servers
#define SERVER1 "52.169.76.203" // The Things Network: router.eu.thethings.network #define PORT 1700 // The port on which to send data
Danach mit “make” builden:
make
Und schon kann ich den Gateway starten:
./single_chan_pkt_fwd
Nun erstelle ich den Gateway in der TTN Console:
Das war’s! Bei “Data” kann ich zusehen, wie die Daten ankommen, und binnen kurzer Zeit bestätigt sich die Vermutung, dass ich jeden dritten Counter sehen werde:
Stückliste zum Nachbauen
Bei meinen Experimenten rund um das Thema LoRa haben wir natürlich mehrere Antennen probiert: die mitgelieferten Antennen sind total in Ordnung, auch die Magnetfußantennen für’s Auto haben sich bewährt, aber die größte Begeisterung habe ich für eine Außenantenne von WiMo entwickelt:
Die WiMo 18006.02 Groundplane für 800-1000 MHz um € 25,- hat es mir angetan.
Sämtliche Pakete kommen damit bis zum ca. 1km entfernten Gateway. Vorher waren es nur ca. 30%. Die Verbesserung ist damit ideal! Nach Herstellerangaben hat die Antenne 0 dBD (dBi?) Gewinn.
Ich habe sie über ein 1m Low Loss H-155 Kabel an eine Fensterdurchführung für GSM gehängt. Das 1m-Kabel hat SMA (für die Fensterdurchführung) und N-Stecker für die Antenne direkt drauf.
Am Foto ist sie mit einer Doppelkreuzschelle befestigt, so wie die Montage am Mast vorgesehen ist.
Stückliste zum Nachbestellen:
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 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!
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:
Ü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"
}
]
}
Ü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!
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:
Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!
Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.
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.
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.
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:
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.
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;
