Archiv der Kategorie: APRS

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/

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/)

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.

 

 

 

erste Versuche mit dem GPS Repeater

Aufgrund der speziell gedämmten Scheiben im Auto funktionieren meine GPS-Anwendungen wie Navi oder APRS schon bei leichter Bewölkung nicht zuverlässig. Ich habe schon länger überlegt, mich mit einem GPS Verstärker zu beschäftigen.

Auf Ebay habe ich dann eine External Antenna Signal Repeater Amplifier GPS satellite Antenna for navigation um knapp € 25,- gefunden.

20150821_181113

Das Gerät besteht aus mehreren Teilen:

  • 20150821_181015einer externen Empfangs-Antenne, übrigens lt. Aufdruck für Glonass und GPS im Frequenzbereich 1575-1602 MHz geeignet,
  • einem USB-Stecker für die Stromversorgung,
  • einer Sendeantenne für GPS ist lt. Aufdruck für 1575.42 MHz ausgelegt
  • und einer SMA-„Kupplung“, damit das Kabel zB. zum Verlegen getrennt werden kann.

wpid-screenshot_2015-08-21-14-11-46.pngIch habe also bei mir zu Hause im Arbeitszimmer, in dem der GPS-Empfang bei geschlossenem Fenster auch fast unmöglich ist, einen ersten Test unternommen. Die Empfangsantenne habe ich auf den Fenstersims gelegt, das Fenster gekippt, um das durchgeführte Kabel nicht unnötig zu quetschen und den Sender am Tisch platziert. Bevor ich die USB-Verbindung hergestellt habe, habe ich mit der Android App „GPS Status & Toolbox“ getestet und keinen Fix zu einem Satellit erreicht.

wpid-screenshot_2015-08-21-14-16-13.pngNachdem ich den USB-Stecker angesteckt habe, hat man binnen Sekunden eine sanfte Verbesserung in der Empfangsleiste der Satelliten in der App gesehen. Aber die meisten waren immer noch zu schwach. Ich musste mit dem Gerät näher an die Sendeantenne kommen, ab ca. 20 cm wurden dann zahlreiche Satelliten grün angezeigt und es war binnen weniger Sekunden die Position bekannt und ein Fix auf 6/23 Satelliten. Das ist immer noch nicht viel, aber man muss vielleicht wissen, dass mein Fenster nur begrenzt Aussicht hat und der Ausschnitt am Himmel, in dem Satelliten gesehen werden, ist recht klein.

20150821_180959

20150821_181006Der Repeater scheint also wunderbar zu funktionieren, allerdings muss man sehr nahe zum Sender kommen. Für meine Anwendung ist das kein Problem, bei mehr als 50cm Abstand, zeigt der Sender keine Wirkung mehr.

Hier ein Foto mit technischen Daten zum Gerät:

gpsrep-specs