Archiv der Kategorie: LoRa

OTA Firmware update für ESP32 LoRa APRS iGate von OE5BPA und andere…

Ich setze seit kurzem die ESP32 basierenden Gateways (PoE-fähig!) für LoRa APRS auf 70cm von OE5BPA ein. Nachdem ich diese iGates nicht nur zu Hause betreibe, sondern auch bei Relaisstationen an exponierten Standorten installiere, ist mir wichtig, dass auch neue Entwicklungen dort genutzt werden können – das setzt voraus, dass ich die Konfiguration von der Ferne anpassen kann (das funktioniert wunderbar über FTP und ist von Peter OE5BPA bereits gut beschrieben worden) und auch Firmware Updates mit neuen Features von der Ferne installiert werden können. Dieses Feature nennt sich Firmware Update over The Air (kurz: FOTA- oder OTA-Update).

iGate bei 73% des Over The Air Firmware Updates

Eine Beschreibung der Hardware findet ihr hier auf meinem Blog. Da ich die Geräte über PoE nutze, gibt es hier für Interessierte eine Übersicht über PoE, die früher mal geschrieben habe.

iGate im (Test-)Betrieb

Nachdem ich kein Programmierer bin und auch mit der Entwicklungsumgebung Platformio (siehe auch https://platformio.org) noch nicht viel Erfahrung habe, war mir am Anfang nicht ganz klar, wie das FOTA/OTA funktioniert. Daher möchte ich es hier kurz beschreiben.

Im Wesentlichen basiert die Funktion auf Bibliotheken, die hier in der Dokumentation von Platformio beschrieben sind: https://docs.platformio.org/en/latest/platforms/espressif32.html#over-the-air-ota-update
Es wird also in der Firmware die Funktion verpackt, die über Platformio genutzt wird, um die Updates von der Ferne durchzuführen.

Welche Schritte sind für uns Benutzer nun also nötig, um ein Update durchzuführen?
Die Voraussetzung ist, dass die Umgebung so aufgesetzt ist, dass der Code fehlerfrei kompiliert, also alle Bibliotheken vorhanden sind uä. Damit wäre ja das Update über USB machbar. Wenn das klappt, prüft man die Einstellungen bzw. Konfiguration, die befinden sich in der Datei is-cfg.json.

Auch wenn man bisher noch kein Update Over the Air durchgeführt hat, ist es dennoch auf den iGates auf der Firmware aktiv. Es ist also möglich, einen Gateway, den man vor ein paar Wochen installiert hat, künftig OTA zu aktualisieren.

Wie geht das nun?
Ein Blick in die Datei platformio.ini, im Anfangsverzeichnis des Projekts, zeigt uns die Konfiguration:

# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = OE1SCS-12.local

Im Beispiel oben möchte ich den iGate “OE1SCS-12” updaten, der sich bei mir im LAN befindet. Falls sich dein iGate auch im LAN befindet, brauchst du also nur ggf. die Kommentare rausnehmen und den Call deines iGates – gefolgt durch .local – ersetzen.

Peter hat die Konfiguration so gewählt, dass sich die Gateways mit dem mDNS-Namen (multicast DNS) unter dem Namen des iGate + .local registrieren. mDNS ist ein DNS-Dienst, der keine Server benötigt, sondern über Multicast (dafür nur im gleichen LAN) DNS-Namen ermöglicht. Ich kann also meinen Gateway auch über diese Adresse pingen:

mDNS im LAN funktioniert, ich kann mein iGate erreichen

Dazu muss natürlich die Konfiguration erstmal (vmtl. über USB) auf dem iGate aufgebracht sein, danach ist ein Update wie beschrieben möglich.

Wenn das klappt, kann ich in Platformio das “Alien”-Symobl auswählen und “Upload Filesystem Image”. Schon wird Platformio die aktuelle Version builden (quasi kompilieren) und über das Netzwerk upgraden:

OTA läuft

Im “Task” Fenster bei Platformio (auch Konsole) genannt kann man den Status verfolgen:

Wenn die Meldung “SUCCESS” auftaucht, war der Vorgang erfolgreich. Der iGate startet nun die neue Firmware und sollte in Kürze erreichbar sein.

Und wie funktioniert das über die Ferne?
Ganz einfach: man ersetzt in der platformio.ini den mDNS-Eintrag (in meinem Fall “OE1SCS-12.local” durch die IP-Adresse des in der Ferne installierten iGates, speichert die Änderung und kann nun genauso von der Ferne das Update einspielen!
In meinem Fall sieht das dann so aus:

# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = 192.168.132.146

LoRa APRS Tracker auf ESP32 Basis

In meinem Blog habe ich häufig Raspberry-basierte Lösungen und Anwendungen beschrieben. In letzter Zeit (in den letzten 1-2 Jahren) entstehen in der Community aber immer mehr Lösungen auf Basis von ESP8266 bzw. dem quasi-Nachfolger ESP32, also basierend auf einem “Mikroprozessor” und nicht einem vollständigen Linux-System, wie es beim Raspberry der Fall ist. Das finde ich sehr toll, weil damit die Pflege des vollständigen Linux-Systems hinfällig wird und ich leider auch schon viele SD-Karten tauschen musste, die mit der Zeit kaputt geworden sind. Immerhin sind die Rapsberrys oft im Außenbereich den Temperaturschwankungen und Änderungen der Luftfeuchtigkeit des Wetters und der Jahreszeiten ausgesetzt.

ESP32 basierter APRS LoRa iGate von OE5BPA

Als Client, Node, Tracker, Endgerät – wie auch immer man es nennen möchte – ist der ESP8266 schon länger im Einsatz. Neu ist, dass nun mit dem ESP32 Prozessor ein leistungsstarker Kern verfügbar ist, der auch Anwendungen ermöglicht, die früher einen Raspberry oder ähnliche Geräte erfordert hätten. Immerhin hat der im Jahr 2016 vorgsetellte ESP32 beeindruckende Leistungsdaten (für einen stromsparenden Mikroprozessor): 160 bis 240 MHz auf einer Dual-Core-Plattform mit 520 KB SRAM. Eingebaut sind WLAN (802.11 b/g/n) mit Bluetooth und zahlreiche Schnittstellen, auszugsweise zB.: GPIOs, 12bit ADC und 8bit DAC, SPI, I²S, I²C, UART, Unterstützung für SD/eMMC, Ethernet, CAN 2.0 uvm. Das Datenblatt gibt dazu mehr Auskunft.

Nachdem in diesem Leistungsbereich jetzt neue Anwendungen ermöglich werden, freut es mich besonders, dass Initiativen wie LoRa APRS davon profitieren und handfeste Lösungen auch für den Gateway-Einsatz (als iGate) verfügbar sind, aktiv entwickelt und laufend verbessert werden.

OM Andi OE1ROT stellt auf seinem Blog einerseits einen Tracker mit TTGO T-Beam (433 MHz!) vor, als auch die nun verfügbaren Gateways auf ESP32 Basis. Ich möchte hier in meinem Blog nicht nochmal alles beschreiben, Andi hat das bereits sehr ausführlich getan, daher verlinke ich diesmal nur zu seinem Eintrag:
https://www.aronaut.at/2020/11/lora-aprs-gateway-mit-esp32-boards/

Die Projekte werden auf Github in diesem Bereich gehostet: https://github.com/lora-aprs
Die iGate Software wird von Peter OE5BPA hier aktuell angeboten:
https://github.com/lora-aprs/LoRa_APRS_iGate

Die TTGO T-Beams sind zB. hier bei Amazon erhältlich: TTGO T-Beam ESP32 mit LoRa für 433 MHz (ggf. OLED Display nicht vergessen)

günstiger Raspberry Pi PoE HAT für 802.3af – Erfahrungen

In meinen Projekten betreibe ich viele Raspberries, die über PoE mit Strom versorgt werden. (Für eine Erklärung zu PoE siehe hier).

Ich nutze viele PoE Converter, um die nominal 48V von PoE bzw. PoE+ gemäß 802.3af / 802.3at auf 5V zu übersetzen und über Micro-USB dem Raspberry bereitzustellen. (Bei Raspi 4B ab jetzt natürlich häufiger mit USB-C).

Die neueren Raspberry-Modelle (3B+ und 4B) unterstützen ein offizielles Raspberry PoE HAT Modul. Dazu wurden 4 weitere PINs auf dem PCB des Raspberry Pi gesetzt und vom PoE HAT genutzt:

mitte/rechts: die 4 PINs für PoE

günstiges PoE HAT

Ich betrachte in diesem Blog nicht das offizielle PoE HAT, sondern eine günstige Alternative ohne Lüfter:

die günstige Alternative zum offiziellen PoE HAT

Im Gegensatz zum offiziellen PoE HAT gibt es hier zwar keine vorgesehene Position für einen Lüfter, allerdings sind die GPIO PINs verlängert bzw. werden durch das günstige PoE HAT durchgereicht. Ich kann also weitere HAT Aufsteckmodule nutzen.

Gekauft habe ich das Modul bei Aliexpress, es ist auch zB. über Amazon erhältlich:

Aufbau und Test

Ich habe es auf einen Raspberry 3B+ gesteckt und an ein Kabel, das von einem Ubiquiti EdgeSwitch 8 150W mit PoE+ versorgt wird.

Mein Ziel ist, einen LoRaWAN Gateway zu testen, der über PoE versorgt wird und LoRaWAN über ein IMST ic880a Board abwickelt. Um das ic880a Board am Raspberry GPIO zu betreiben ist ein Adapterboard nötig, das ich vom Verein OpenIoT erhalten habe.

Raspberry mit bereits aufgestecktem PoE HAT, OpenIoT Adapterboard und IMST ic880a (oben)

In Kombination sieht das “Sandwich” dann so aus:

Die Module sind halbwegs stabil, ein gutes Gehäuse sollte dennoch her. Es sind leider keine Bohrungen für Distanzhalter vorgesehen.

Ich habe das Board mit einem Ubiquiti EdgeSwitch getestet, der EdgeSwitch unterstützt den PoE+-Standard und gibt mir auch die aktuelle Leistung je Port an:
im Leerlauf zieht ein Raspberry 3 B+ mit Raspbian Lite (Buster) nach einer frischen Installation etwa angezeigt 3,6 Watt.

Wenn ich das LoRaWAN Concentrator Board aufsetze und neu starte, wechselt die Anzeige zwischen 6,1 und 6,5 Watt:

PoE Verbrauch mit IMST ic880a LoRaWAN concentrator board in Betrieb

Auch auf einem Raspberry 4B hat sich das günstige PoE HAT problemlos betreiben lassen.

Temperatur

Bemerkenswert ist, dass das Gerät sehr heiß wird, wenn das IMST Board, das ja die Leistungsaufnahme ggü. dem Raspberry verdoppelt, angeschlossen wird. Die Angabe auf dem PoE HAT sind 2,5A – also 12 Watt. Wir nutzen hier zirka die Hälfte und es geht schon heiß her. Die Core Temperatur zeigt etwa 60 Grad bei Nutzung mit dem IMST Board. Dabei ist natürlich auch der Prozessor unter mehreren Aufsteckmodulen versteckt und hat wenig Luftzirkulation. Ohne LoRaWAN-HATs hat es etwa 53 Grad im Bereich der CPU.

Die Werte frage ich über vcgencmd ab:

stefan@lorawangw:~ $ vcgencmd measure_temp
temp=59.6'C

Fazit

Einen Langzeittest habe ich noch nicht gemacht, ich werde den Artikel hier dann aber mit den Erkenntnissen erweitern.

Das Modul funktioniert sehr gut, erspart mir in Zukunft hoffentlich einen weiteren externen Adapter, um PoE über MikroUSB oder USB-C dem Raspi zu geben.

Beobachten möchte ich die Temperatur, weil als Nebenwirkung des Boards der Raspi auffällig heiß wird.

Links zu den Modulen

Hier eine Übersicht der im Beitrag vorgestellten Artikel/Produkte:

LoRa APRS Gateway mit Raspberry Pi Zero W

In einem anderen Beitrag habe ich darüber berichtet, dass wir erfolgreich über LoRa-Modulation APRS-Pakete gesendet haben und wie ein APRS-Tracker mit Arduino zu bauen und programmieren ist.

Nun habe ich von Sascha (www.iot4pi.com) ein fertiges, von ihm konstruiertes Board, für einen LoRa APRS Gateway bekommen. Wie er diese Boards erstellt und zusammenbaut, hat er übrigens auf seiner Seite näher beschrieben:
www.iot4pi.com/de/bau-des-lora-gateway-shield

Die Software, das Image für die SD-Karte (ich habe ein 8 GB-Karte zur Hand), findet ihr hier zum Download:
www.iot4pi.com/de/raspberry-pi-projekte-software/lora-aprs-gateway

Nachdem man die SD-Karte in den Raspberry gesteckt und das Gehäuse mit dem Raspberry darin geschlossen ist, bootet man den Raspberry zum ersten Mal.

Ich habe in der /etc/network/interfaces sofort eine statische IP-Adresse eingetragen.

Die Konfiguration des Gateways fwird in der Datei /home/pi/iot4pi/APRS.conf vorgenommen. Im Wesentlichen muss man nur folgende Zeilen anpassen:

APRS_IS_CALL:OE1SCS-10
APRS_IS_PASSCODE:12345
LATITUDE:4811.48N
LONGITUDE:01623.23E

Wichtig ist auch, dass man zur Netzwerkanbindung das WLAN am Raspberry Zero W konfigurieren muss. Dazu tragt man in der Datei /etc/wpa_supplicant/wpa_supplicant.conf folgende Zeilen ein:

country=AT
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="meinwlan"
    psk="meinpasswort"
}

Da der Gateway nicht für den Außeneinsatz geeignet ist, habe ich mir eine kleine flache Fensterdurchführung zugelegt, mit der ich die Antennenleitung ans Fensterbrett bekomme und dort mit einer 70cm-Magnetfußantenne für 433 MHz verbinde.

Einkaufsliste LoRa APRS Gateway auf Raspberry Pi Zero W

Optional, für den Anschluss an einen Monitor:

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:

günstiger 1ch LoRa Gateway: RFM95W direkt zu Raspberry verkabelt

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:

  • Man bestellt das LoRa RFM95W-868S2 Transceiver Modul.
  • man teilt 4 Jumper Wire Kabel in der Hälfte, sodass auf einer Seite eine Buchse (female) und auf der anderen Seite der blanke Draht ist.  7 davon lötet man an diese Position am Transceiver Modul: DI00, 3.3V, MISO, MOSI, SCK, RESET, NSS und GND (neben MISO)
  • Als Antenne verwenden wir hier zwei Drähte, die 83mm Länge haben und an die Positionen ANA und GND (neben ANA!) gelötet werden. Als Draht wird ein 18ga empfohlen, das ist in unseren Breiten ein 1mm Drahtstück.
  • Nun verbindet man diese mit den PINs am Raspberry GPIO:
    3.3V -> PIN1, GND -> PIN6, DI00 -> PIN7, RESET -> PIN11, NSS -> PIN22, MOSI -> PIN19, MISO -> PIN21 und SCK -> PIN23
  • jetzt kann auch schon die Software installiert werden. Es wird git, wiringpi und der Code für den Single Channel Gateway benötigt:
sudo apt install git wiringpi
git clone https://github.com/tftelkamp/single_chan_pkt_fwd
  • im raspi-config-Tool muss nun die SPI-Schnittstelle aktiviert werden (im Menü “Interfacing Options” -> “SPI”:
sudo raspi-config
  • nach einem Reboot (wird von raspi-config vorgeschlagen) konfiguriert man die Einstellungen in der main.cpp des single_chan_pkt_fwd Codes:
// 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"
  • Der Code kann nun mit make compiled werden:
make
  • Nun können wir den Gateway das erste Mal starten:
./single_chan_pkt_fwd
  • Die EUI, die hier gezeigt wird, müssen wir nun bei der Console von TheThingsNetwork als EUI eines neuen Gateways eintragen. Dieser wird sofort angezeigt und übermittelt auch auf Anhieb die Daten, die er empfangen hat.

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.

GPS am Dragino LoRA HAT

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.

LoRa Single Channel Gateway

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!

Single Channel Gateway = günstig

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,-.

Einsatzgebiet

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.

Installation

Es ist ganz einfach:

  1. aktuelle Raspian-Version installieren und Raspberry vorbereiten (resize disk, SSH-Zugriff für Fernzugriff aktivieren, Passwort und IP-Einstellungen ändern)
  2. alles aktualisieren und wiring-pi installieren:
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

Einrichten bei The Things Network

Nun erstelle ich den Gateway in der TTN Console:

  • Register Gateway
  • dann wähle ich “I’m using the legacy packet forwarder”. Somit kann ich die Gateway EUI eingeben, die mir beim Start meines Single Channel Gateways angezeigt wurde.
  • die Description kann frei gewählt werden
  • der Frequency Plan ist Europe in meinem Fall und der
  • Router EU. Das ist auch die IP-Adresse, die wir oben in der main.cpp definiert haben. (Details siehe hier: https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway)
  • mehr muss man nicht tun (natürlich ist es schön, die GPS-Position und Höhe einzugeben)

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

  1. Raspberry Pi (2 oder 3)
  2. Dragino LoRa GPS HAT, alternativ hier beim Hersteller mit längerer Lieferzeit zu erstehen: https://www.tindie.com/products/edwin/loragps-hat/
  3. ev. eine coole Antenne? (nicht unbedingt nötig, es ist eine beim LoRA GPS HAT dabei)

Empfehlung für eine LoRa Outdoor Antenne

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!

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: