Archiv der Kategorie: APRS

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:

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:

APRS: Telemetriedaten vom Raspberry Pi 2 mit pymultimonaprs übertragen

Im vorigen Artikel habe ich beschrieben, wie ich pymultimonaprs auf einem Raspberry Pi 2 konfiguriert habe.

Nun möchte ich in der Status-Zeile ein paar Telemetriedaten übermitteln, die vom Raspberry ausgelesen werden. Konkret sind das:

  • Core Temperatur
  • Core Spannung
  • Core Spannung der SDRAM_p
  • Clock Speeds von Core und ARM

Dazu habe ich ein Script erstellt, das alle 5 Minuten über cron gestartet wird und die vollständige Status-Zeile in der Datei /tmp/aprs-telemetrie.txt hinterlegt. pymultimonaprs versendet dann den Inhalt dieser Datei als Statusmeldung.

Dieses Script (abgelegt als /home/pi/aprs-telemetrie.sh) liest die Werte aus und erstellt die Datei:

#!/bin/bash
echo "Raspberry Pi 2 mit RTL Stick core_temp="`vcgencmd measure_temp | awk -F'=' '{print $2}'\
`" core_volt="`vcgencmd measure_volts core | awk -F'=' '{print $2}'`\
" sdram_p_volt="`vcgencmd measure_volts sdram_p | awk -F'=' '{print $2}'`\
" core_clock="`vcgencmd measure_clock core | awk -F'=' '{print $2}'`\
" arm_clock="`vcgencmd measure_clock arm | awk -F'=' '{print $2}'` > /tmp/aprs-telemetrie.txt

Die Datei sieht nun so aus:

pi@roofpi ~ $ cat /tmp/aprs-telemetrie.txt 
Raspberry Pi 2 mit RTL Stick core_temp=26.1'C core_volt=1.2000V sdram_p_volt=1.2250V core_clock=250000000 arm_clock=600000000

Den Cron-Job habe ich so erstellt:

*/5 * * * *   root    /home/pi/aprs-telemetrie.sh

Nun habe ich folgende Einträge in der mymultimonaprs-Konfigurationsdatei /etc/pymultimonaprs.json geändert:

        "status": {
            "text": false,
            "file": "/tmp/aprs-telemetrie.txt"
        },

Nach einem Neustart von pymultimonaprs mittels

/etc/init.d/pymultimonaprs restart

hat das sofort geklappt:

Jan  2 13:17:40 roofpi pymultimonaprs: connecting... 95.155.111.242:14580
Jan  2 13:17:40 roofpi pymultimonaprs: connected
Jan  2 13:17:40 roofpi pymultimonaprs: # aprsc 2.0.14-g28c5a6a
Jan  2 13:17:40 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan  2 13:17:40 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2KRAKOW
Jan  2 13:17:40 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan  2 13:17:40 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi 2 mit RTL Stick core_temp=25.6'C core_volt=1.2000V sdram_p_volt=1.2250V core_clock=250000000 arm_clock=600000000

 

APRS iGate über HAMnet mit pymultimonaprs

Seit kurzem habe ich bei mir im 3. Wiener Gemeindebezirk am Dach meines Wohnhauses (ca. 8. Stock) – unter anderem – folgendes Equipment installiert:

IMG_4834Der Raspberry und DVB-T-Stick sind in einem Outdoor-Gehäuse verbaut.

Mit diesem Setup möchte ich einen APRS iGate realisieren, also eine Konfiguration, mit der APRS-Pakete auf der europäischen APRS-Frequenz 144.800 MHz empfangen und dann weitergeleitet werden. Die Weiterleitung soll primär über HAMnet erfolgen und nur im Fehlerfall oder bei nicht-Verfügbarkeit meiner HAMnet-Anbindung direkt ans einen APRS-IS-Tier2-Server (vgl. http://www.aprs2.net/)  ins Internet übertragen werden.

Voraussetzung

Als Voraussetzung sollte die RTL-SDR-Software und Treiber am Raspberry bereits installiert sein. Der Vorgang ist unter anderem hier beschrieben: http://thardes.de/raspberry-pi-als-sdr-server/
(Update 2020: hier ein neuer Link zur Beschreibung: https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/raspberry-headless-setup-rtl-sdr)

Weiters habe ich mittels GSM-Netz den Raspberry kalibriert und so die Ungenauigkeit meines Sticks festgestellt: 26 ppm. (vgl. ua. http://www.rtl-sdr.com/how-to-calibrate-rtl-sdr-using-kalibrate-rtl-on-linux/)

Da pymultimonaprs die Messages nicht selbst dekodiert, müssen wir noch multimon-ng installieren:

cd ~
sudo apt-get install cmake
git clone https://github.com/EliasOenal/multimon-ng.git
cd multimon-ng
mkdir build
cd build
cmake ..
make
sudo make install

Installation

Die iGate-Software pymultimonaprs installiere und hole ich von GIT:

cd ~
sudo apt-get install python2.7 python-pkg-resources
git clone https://github.com/asdil12/pymultimonaprs.git
cd pymultimonaprs
sudo python2 setup.py install

Ich erstelle ein Startscript:

sudo cp pymultimonaprs.init /etc/init.d/pymultimonaprs
sudo chmod +x /etc/init.d/pymultimonaprs
sudo update-rc.d pymultimonaprs defaults

Um in das APRS-IS-Netzwerk Pakete zu übertragen, ist ein Passwort erforderlich, das sich aus dem Call ableitet und errechnet werden muss:

cd ~/pymultimonaprs
./keygen.py CALLSIGN
Key for CALLSIGN: 31983

Konfiguration

Nun passe ich die Konfigurationsdatei /etc/pymultimonaprs.json an. Fertig konfiguriert sieht sie so aus:

{
        "callsign": "OE1SCS-10",
        "passcode": "20123",
        "gateway": [
                "aprs.oe2xzr.ampr.at:14580", "44.143.40.90:14580",
                "aprs.oe1.ampr.at:14580", "44.143.10.90:14580",
                "aprs.oe6xrr.at.ampr.org:14580", "44.143.153.50:14580",
                "aprs.oe7xgr.ampr.at:14580", "44.143.168.68:14580",
                "44.225.41.232:14580",
                "44.225.42.181:14580",
                "euro.aprs2.net:14580"],
        "append_callsign": true,
        "source": "rtl",
        "rtl": {
                "freq": 144.800,
                "ppm": 26,
                "gain": 46,
                "offset_tuning": false,
                "device_index": 0
        },
        "alsa": {
                "device": "default"
        },
        "beacon": {
                "lat": 48.19060,
                "lng": 16.38670,
                "table": "/",
                "symbol": "-",
                "comment": "RXonly APRS iGate",
                "status": {
                        "text": "Raspberry Pi mit RTL Stick",
                        "file": false
                },
                "weather": false,
                "send_every": 1800,
                "ambiguity": 1
        }
}

Ich habe für meinen Call OE1SCS den Suffix -10, auch SSID genannt, gewählt, der lt. APRS SSID-Erklärung für “internet, Igates, echolink, winlink, AVRS, APRN, etc” gedacht ist.

Im Eintrag “gateway” habe ich eine Liste an APRS-IS Gateways eingetragen. Die Liste wird bei jedem Neustart von pymultimonaprs vom ersten Eintrag neu abgearbeitet. Ich habe also die Gateways, die ich bevorzuge, an den Anfang geschrieben. Die meisten iGates besitzen sprechende DNS-Namen. Ich will jedoch nicht von einem funktionierenden DNS-Dienst abhängig sein, daher trage ich die IP-Adressen ein. Damit dort nicht nur kryptische HAMnet-IP-Adressen (beginnen mit 44.) stehen habe, habe ich in der gleichen Zeile den DNS-Namen zusätzlich hinterlegt, zB.:
“aprs.oe2xzr.ampr.at:14580”, “44.143.40.90:14580”

Der Dienst versucht 120 Sekunden die APRS-iGates zu erreichen. Nach 120 Sekunden meldet er ein Timeout und probiert den nächsten iGate. Sollte das Netzwerk nicht verfügbar sein oder der iGate-Server am eingestellten Port nicht antworten, wartet pymultimonaprs das Timeout nicht ab, sondern probiert unmittelbar den nächsten iGate in der Liste.

Hier ein Beispiel aus meinem Logfile:

Jan  2 10:53:42 roofpi pymultimonaprs: connecting... 44.225.42.181:14580
Jan  2 10:53:42 roofpi pymultimonaprs: Error when connecting to 44.225.42.181:14580: '[Errno 101] Network is unreachable'
Jan  2 10:53:51 roofpi pymultimonaprs: connecting... 78.47.75.201:14580
Jan  2 10:53:51 roofpi pymultimonaprs: connected
Jan  2 10:53:51 roofpi pymultimonaprs: # aprsc 2.0.18-ge7666c5
Jan  2 10:53:51 roofpi pymultimonaprs: login OE1SCS-10 (PyMultimonAPRS 1.2.0)
Jan  2 10:53:51 roofpi pymultimonaprs: # logresp OE1SCS-10 verified, server T2EISBERG
Jan  2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:=4811.4 N/01623.2 E-RXonly APRS iGate
Jan  2 10:53:51 roofpi pymultimonaprs: sending: OE1SCS-10>APRS,TCPIP*:>Raspberry Pi mit RTL Stick

Mittels “append_callsign”: true, gebe ich an, dass mein Call in den APRS-Pfad bei der Weiterleitung ans iGates dazugefügt werden soll.

im Abschnitt “rtl” wähle ich die Frequenz 144.800 MHz als europäische APRS-QRG, gebe meine Ungenauigkeit des Sticks (26 ppm) an, die ich vorher gemessen habe und wähle einen Gain von 46. Offset-Tuning lasse ich unbenutzt und da ich nur einen DVB-T-Stick am Raspberry habe, lasse ich den device-index bei 0.

im Abschnitt “beacon” konfiguriere ich die eigene, regelmäßige, Aussendung meiner “Station”:

Ich gebe die eigenen GPS-Koordinaten an, wähle als Darstellungssymbol ein Haus, gemäß dieser Tabelle:
http://www.aprs-dl.de/?APRS_Detailwissen:SSID%2BSymbole
Ganz unten bei diesem Link kann man die Symboltabelle als PDF runterladen!

Ich wähle einen statischen Text für “comment” und “status“, außerdem übertrage ich im Moment keine Wetter-Informationen. Ich möchte, dass meine Aussendung alle 30 Minuten übertragen wird (30 Minuten * 60 Sekunden = 1800 Sekunden).

Um meine Positionen nicht 100%ig genau im APRS darzustellen, habe ich die “ambiguity” auf “1” gesetzt. Das verringert die Genauigkeit meiner GPS-Position um 1/10 Grad-Minute. Dadurch wird meine APRS-Position auf aprs.fi mit dem Hinweis “Position ambiguous: Precision reduced at transmitter by 1 digits, position resolution approximately 185.2 m.” zB. so dargestellt:

aprs-ambiguous
meine Station wird bewusst mit einer Ungenauigkeit von ca. 185 Metern in dem violetten Feld angezeigt. Das Feld weist darauf hin, dass die Position nicht exakt ist.

Damit wäre alles konfiguriert und über das Kommando

/etc/init.d/pymultimonaprs start

habe ich den Dienst gestartet.

Die Funktion kann man über das Logfile /var/log/syslog rasch prüfen. Unmittelbar nach dem ersten Start war meine Station auf aprs.fi sichtbar: http://aprs.fi/info/a/OE1SCS-10

Erfahrungen, Tipps & Tricks

Zuverlässigkeit des USB-Sticks

Ich habe den Dienst einige Tage laufen gelassen. Nach zirka zwei Tagen habe ich folgende Fehlermeldung im Logfile gehabt. Auch über “dmesg” war das Problem sichtbar:

Dec 30 21:23:34 roofpi kernel: [ 2139.021653] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022123] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.022580] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023041] usb 1-1.3: usbfs: usb_submit_urb returned -121
Dec 30 21:23:34 roofpi kernel: [ 2139.023968] usb 1-1.3: USB disconnect, device number 4
Dec 30 21:23:34 roofpi kernel: [ 2139.260292] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
Dec 30 21:23:34 roofpi kernel: [ 2139.372309] usb 1-1.3: New USB device found, idVendor=0bda, idProduct=2832
Dec 30 21:23:34 roofpi kernel: [ 2139.372335] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 30 21:23:34 roofpi kernel: [ 2139.372353] usb 1-1.3: Product: RTL2832U
Dec 30 21:23:34 roofpi kernel: [ 2139.372369] usb 1-1.3: Manufacturer: Generic
Dec 30 21:23:34 roofpi kernel: [ 2139.372386] usb 1-1.3: SerialNumber: 77771111153705700

Es hat sich also der USB-Stick verabschiedet “usb 1-1.3: USB disconnect, device number 4” und sofort wieder neu verbunden. Damit war natürlich ein Neustart des pymultimonaprs nötig, damit dieses wieder korrekt lauscht. Leider war es damit nicht getan und der Fehler ist wenige Minuten später wieder gekommen. Ich habe das ein paar Mal wiederholt und schon befürchtet, dass der Stick vielleicht kaputt ist. Ein Reboot hat die Situation aber entschärft und nun läuft der Stick wieder seit 2 Tagen stabil.

APRS-Meldungen der ISS

Mit einem einfachen Hack, der unter anderem hier beschrieben wird, soll es möglich sein, neben der primären APRS-Frequenz 144.800 MHz auch die APRS-Frequenz der Raumstation ISS zu empfangen. Diese sendet auf 145.825 MHz. Natürlich können diese Meldungen nur gehört werden, wenn sich die ISS in Reichweite befindet. Es gibt zahlreiche Webseiten im Internet, mit denen der Zeitpunkt der nächsten Überflüge der ISS am eigenen Standorts berechnet werden kann.

Leider hat sich dieser Hack bei mir nicht bewährt: mein Stick schafft es kaum noch APRS-Meldungen zu decoden, wenn er auf beide Frequenzen hört. Die Qualität nimmt rapide ab. Woran es genau liegt, kann ich schwer sagen. Ich habe aber die Vermutung, dass es am Squelch liegt, der bei dieser Konfiguration genutzt werden muss: das Programm rtl_fm, das dem Empfang der Pakete übernimmt, funktioniert ohne Squelch, sofern man nur auf einer QRG hört. Wenn man mehrere QRGs angibt (144.8, 145.825, …) muss ein Squelch-Wert angegeben werden. Ich habe zwar 1 als kleinsten möglichen Wert konfiguriert, vermute aber, dass der Squelch bei APRS-Paketen zu spät reagiert und daher viele Pakete nicht vollständig gehört werden. Sobald ich nur auf 144.8 ohne Squelch höre, empfange ich wieder viel mehr Pakete und alles scheint zu funktionieren.

Ein anderer Benutzer hat ähnliches erlebt: “I was unable to scan both 144.39 and 145.825 and decode the packets reliably.” (http://www.algissalys.com/amateur-radio/raspberry-pi-sdr-dongle-aprs-igate)

Wetter- & Telemetriedaten übertragen

(Edit: ich habe in einem separaten Artikel hier mittlerweile die Übertragung von Telemetriedaten beschrieben…)

pymultimonaprs kann auch Wetterdaten mitsenden. Ich habe leider keine Wetterstation, möchte aber Telemetriedaten meines Raspberry Pi 2 übermitteln. Dazu kann man ein JSON-File erstellen, das diesem Format entspricht (Quelle: https://github.com/asdil12/pymultimonaprs/blob/master/README.md):

You can set weather to a json-file. eg: "weather": "/path/to/weather.json",

If you don’t want do send weather date, just leave it on false.
This will be read in like the status-file and can look like that:

{
    "timestamp": 1366148418,
    "wind": {
        "speed": 10,
        "direction": 240,
        "gust": 200
    },
    "temperature": 18.5,
    "rain": {
        "rainlast1h": 10,
        "rainlast24h": 20,
        "rainmidnight": 15
    },
    "humidity": 20,
    "pressure": 1013.25
}
  • timestamp is seconds since epoch – must be included
  • wind
    • speed is in km/h
    • direction is in deg
    • gust is in km/h
  • temperature is in °C
  • rain
    • rainlast1h is in mm
    • rainlast24h is in mm
    • rainmidnight is in mm
  • humidity is in %
  • pressure is in hPa

The timestamp must be included – everything else is optional.

Meine Idee wäre, die Temperatur & Spannung des Raspberry Core zu übermitteln, die mittels des Kommandos “vcgencmd” ermittelt werden können. Details siehe hier: http://elinux.org/RPI_vcgencmd_usage

Ich müsste also ein JSON-File erstellen, in das ich

  • den aktuellen UNIX-Timestamp angebe,
  • bei temperature die Ausgabe von “vcgencmd measure_temp”
pi@roofpi ~ $ vcgencmd measure_temp
temp=27.2'C

Damit übertrage ich zwar nicht die Daten des Wetters, sondern die Temperatur der CPU, aber ich kann das zum Testen mal so machen.

Es würde sich auch anbieten, andere Telemetriedaten mitzusenden, wie zB. die Spannungen der Elemente des Raspberry:

pi@roofpi ~ $ vcgencmd measure_volts core
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_c
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_i
volt=1.2000V
pi@roofpi ~ $ vcgencmd measure_volts sdram_p
volt=1.2250V

Für die Spannungen ist kein Feld in den Wetterdaten vorgesehen. Man könnte diese Daten also über die “status“-Aussendung übermitteln. Dazu ändert man im Konfig file (/etc/pymultimonaprs.json) im Bereich “status” folgendes:

"status": {
 "text": false,
 "file": "/tmp/aprs-status.txt"
 },

In die Datei /tmp/aprs-status.txt schreibt man nun eine Zeile, die man als Status aussenden will, beispielsweise:

Raspberry Pi mit RTL Stick core_temp=27.2'C core_volt=1.2000V sdram_c_volt=1.2000V sdram_i_volt=1.2000V sdram_p_volt=1.2250V

Ideen für weitere Werte, die man aussenden könnte:

  • uptime
  • clock-speeds von core, arm und anderen Modulen im Raspberry
  • uvm…

Ich habe mittlerweile die Übertragung der Telemetriedaten in einem eigenen Artikel beschrieben.


	

APRS Smartbeaconing bewährt sich bei mir nicht

AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs
AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs

SmartBeaconing ist eine gute Idee: statt per APRS seine Position alle x Sekunden auszusenden und damit das APRS-Netz unnötig zu belasten, wird die Position nur gesendet, sobald es das System “smart” findet: bei Richtungsänderungen, wesentlichen Geschwindigkeitsänderungen, etc.

Das entlastet das Netz hinsichtlich der Anzahl an Meldungen, die direkt oder über Digipeating übertragen werden und erhöht die Wahrscheinlichkeit für andere Benutzer, dass Airtime für deren Aussendung frei ist.

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

Ich habe überall SmartBeaconing verwendet. Schließlich bin ich großteils im Stadtgebiet von Wien und in der näheren Umgebung unterwegs und dort ist die Dichte an APRS-Empfängern & -Digipeatern sehr hoch.

AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015
AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015

Leider hat sich SmartBeaconing für mich nicht bewährt: obwohl ich mit 5 Watt über eine externe Magnetfußantenne (Nagoya UT-106UV) vom Autodach aus sende, werden nur 30-40% meiner Meldungen aufgenommen. Und das reicht nicht, um die Strecke annähernd korrekt abzubilden. Vor allem, wenn eine Richtungsänderung nur alle 1-2 Minuten passiert, hinterlasse ich nur alle 5 Minuten einen Punkt auf der Map bei dieser schlechten Erfolgsquote der Übertragung.

Ich habe daher SmartBeaconing deaktiviert und sende im Moment stur alle 30 Sekunden. Damit bekomme ich ausreichend Übertragungen zusammen, um die Route gut abzubilden. Gleichzeitig ist mir bewusst, dass dadurch das Netz stärker belastet wird. Da ich aber nicht viel mit dem Auto unterwegs bin, denke ich, dass es zumutbar ist

APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconing
APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconin

 

SainSonic AP510

Vor einigen Monaten habe ich mir ein SainSonic AP510 um knapp € 100,- über eBay aus DL gekauft. Ich bin total begeistert! Vielleicht ausnahmsweise mal weniger, weil es etwas Bestimmtes so gut kann. Sondern diesmal weil es so viel kann.

Das Ding wird als “APRS Tracker VHF GPS Bluetooth Thermometer TF Card APRSdroid” angepriesen. Man sieht schon: da steckt viel drinnen.

Ursprünglich dachte ich, ich kaufe einen APRS Tracker. Ich war froh, dass ein leistungsfähiger Akku (angeblich 3.300mAh LiPo) drinnen ist, der auch wirklich 2 Tage hält, und dass ich kein separates Funkgerät brauche (mit komplizierten und herstellerspezifischen Adapterkabeln), sondern ein Transceiver mit 1 Watt (manche behaupten 1,5 Watt) für VHF (2 Meter-Band) mit drinnen ist.

Auspacken & Inbetriebnahme

Ich möchte da ja nicht zu sehr auf andere Blogger verweisen. Aber lest mal, was die alles erlebt haben! Ich kann das großteils auch bestätigen, aber die zentrale Aussage bleibt: auspacken und gleich mal ein Firmware Upgrade machen. Damit erspart ihr euch diese Erfahrungen und mit der Firmware aus Oktober 2014 funktioniert das Gerät bei mir sehr gut.

Meine Erfahrungen habe ich mit der Software vom 8.10.2014 (20141008) gemacht. Generell kann ich den Thread des Herstellers empfehlen. Die Seite ist zwar 95% chinesisch, aber die Downloads sind zu erkennen und selbsterklärend: http://www.y027.com/dvbbs8/dispbbs.asp?boardid=5&Id=829

Falls das Update-Programm nach dem Start alles chinesisch darstellt, habe ich einen einfachen Trick gefunden: im Verzeichnis des Programms gibt es eine Datei “avrubd.ini”. Öffnet diese mit einem Texteditor und sucht im obersten Block “[last]” nach “language” und ändert diese auf “English”:

language=English

Ein paar Dateien werden für den Start der Programme benötigt, zB. mscomm32.ocx oder msstdfmt.dll. Diese Dateien findet ihr im Internet oder auf der Seite eines anderen Bloggers.

In der Version von Oktober 2014 hat sich das Konfigurationsprogramm einwandfrei bedienen lassen.

20150612 - Konfig StefanDie Einstellungen sind weitgehend selbsterklärend. Folgende Punkte möchte ich kurz beschreiben:

  • MIC-E aktiviert die Komrimierung der APRS-Daten. Ich habe damit in OE, S5, HA und 9A keine Probleme gehabt. Die Übertragungsdauer wird durch diese Funktion reduziert.
  • Smart beaconing: das ist ein lobenswertes Feature, mit dem nicht ununterbrochen periodisch Nachrichten gesendet werden, sondern Meldungen erst dann geschickt werden, wenn sich meine Fahrtrichtung ändert.
  • Busy-control: damit hört der AP510 kurz in den Kanal, ob dieser frei ist, bevor die eigene APRS-Aussendung beginnt.

Erfahrungen

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

In den nächsten Tagen habe ich das Gerät überall mitgenommen. Zum Testen natürlich.

SainSonic AP510 im Zug mit Antenne Diamond RH951S
SainSonic AP510 im Zug mit Antenne Diamond RH951S

Meine Positionsmeldungen wurden großteils gut übertragen, ich habe allerdings in Gebäuden (auch direkt hinter (vmtl. bedampften) Fenstern) oft keinen GPS Fix bekommen.