Update April 2017

Das unten beschriebene System ist seit dem 6. April 2017 auf dem Schilthorn installiert. Erste Erfahrungen sind eingeflossen.

Einleitung

Es besteht schon lange der Wunsch, im Berner Oberland die Abdeckung für APRS mit einem  Gateway (IGate) zu verbessern. Im Zusammenhang mit einem anderen Projekt (Stratospären-Ballons) stiess ich auf eine einfach einzusetzende Software mit fast pfannenfertiger Beschreibung. So habe ich  diese Idee wieder aufgegriffen.

Rekap: Was ist ein APRS IGate? Ein APRS IGate empfängt APRS Meldungen vom Funknetz (VHF, 2m Band) und schickt sie ins Internet zum APRS-IS Netzwerk (und optional umgekehrt). Das APRS-IS Netzwerk ist ein weltweit verteiltes mehrstufiges Servernetzwerk. Darauf aufbauend gibt es Applikationen wie z.B. http://aprs.fi, die Standorte und Messdaten anzeigen.

Ziel: Aufbau eines APRS IGate an einem geeigneten (Gebirgs-) standort. Dieses IGate soll nur HF empfangen, nicht senden. Die Bedingungen an den Standort sind:

• Internetanbindung muss vorhanden sein, insbesondere auch für Fernwartung
• funktechnisch gut sichtbarer, exponierter Standort
• limitierter Hardwareaufwand (Integration in bestehende Anlagen – Antennen, Kabel, Empfänger usw.)

Am geplanten Standort stehen heute bereits Antennen, Empfänger, Strom und Internet zur Verfügung. Ein 2m Bandpassfilter ist ebenfalls noch vorhanden. In diesem Beitrag beschränke ich mich auf den Software Aufbau des APRS Gateways per se und lasse die HF Technik für den Moment beiseite. Das System umfasst diese Hardware

1. Antenne: 2m VHF Groundplane Antenne
2. Bandpassfilter für 144.800MHz (mechanisches Filter, Topfkreis)
3. Professionneller 2m VHF Empfänger
4. USB Soundkarte: Maxxtro o.ä.
5. Raspberry Pi

Das APRS Signal (144.800 MHz, AFSK 1200 baud FM) wird mit einem selektiven Bandpassfiler von Störsignalen isoliert, im  Empfänger demoduliert und als hörbare Audiotöne an den Pi geschickt. Der Pi hat keinen Audioeingang, dazu ist ein USB Sound“karte“ nötig. Die SW im Pi dekodiert die Audiotöne in digitale Nutzdaten und schickt sie ins Internet.

Details zum mechanischen Aufbau und Bilder folgen später.

 

Aufbau des IGate

Das IGate wird mit der Software Direwolf auf einem Raspberry Pi V3 aufgebaut (siehe Links). Diese Software enthält eine fast vollständige Anleitung dafür. Bei meinen Prototypen habe ich primär diese Dokumente benützt:

• vom Pi-in-the-Sky Projekt das Manual (pits-manual.pdf)
• Raspberry-Pi-APRS.pdf Version 1.3 Februar 2016
• Direwolf-User-Guide.pdf
• APRS-Telemetry-Toolkit.pdf

Auf dem verwendeten PI ist bereits ein funktionierendes LoRa-Gateway aufgebaut. Die beiden Gateway Funktionen kommen sich nicht in die Quere. Für die Grundinstallation des Pi orientierte ich mich am Manual des Pi-in-the-Sky (PITS) Boards und hangelte mich dann durch Raspberry-Pi-APRS.pdf . Die Installation gelingt fast problemlos:

• sudo rpi-update gibt es nicht und entfällt
• gpsd wurde nicht installiert, da das Gateway fest an einem Standort stehen wird (direwolf kann die statische Position schicken)
• die PTT Steuerung entfällt, hamlib wurde nicht installiert
• der DCD Indicator (LED wenn Signal vorhanden) wurde nicht eingerichtet
• direwolf  muss ausführbar gemacht werden: sudo chmod +x direwolf, ebenso das Startscript:  sudo chmod +x dw-start.sh
• in direwolf.conf: MYCALL: HB9TSS-10 (SSID 10 ist für Gateways)
• in direwolf.conf: LOGDIR = . legt tägliche Logdateien an
• in direwolf.conf: IGSERVER bern.aprs2.net (plus persönliches Login) statt der Server im PDF.
• ganz wichtig sind die Einstellungen im alsamixer. Dies geht auch mit SSH ohne grafischen Desktop

Man muss auch den Mic Level (rote Säule CAPTURE) kontrollieren. Er darf nicht 0 sein (Bemerkung im Kap. 8 im Raspberry-Pi-APRS.pdf ). Auf dem Schilthorn musste hier fast das Minimum eingestellt werden (nicht so wie unten im Bild).

Hier der Testaufbau mit meinem ICOM Handgerät. Alternativ habe ich auch den AOR 8600 Scanner verwendet. Für beide Geräte reicht es aus, den Audioausgang mit der Maxxtro Soundkarte zu verbinden (beim ICOM mit dem speziellen Y-Kabel). Auf dem PI ist auch das LoRa-Modul aus dem Pi-in-the-Sky Projekt montiert.

Start mit direwolf in /home/pi:

Mit der Option -di sieht man mehr Details (direwolf -di)

Mit der Option LOGDIR in direwolf.conf sehen wir die empfangenen Pakete in einer Log-Datei:

chan,utime,isotime,source,heard,level,error,dti,name,symbol,latitude,longitude,speed,course,altitude,frequency,offset,tone,system,status,comment
 0,1482313831,2016-12-21T09:50:31Z,HB9TSS-11,HB9TSS-11,75(33/17),0,:,HB9TSS-11,/O,,,,,,,,,Telemetry devices,,,
 0,1482314121,2016-12-21T09:55:21Z,HB9TSS-11,HB9TSS-11,72(35/17),0,!,HB9TSS-11,/O,46.690977,7.681376,,,583.7,,,,Telemetry devices,,"Seq=11, Satellites=9 Sats, Temperature=31 deg.C, Battery=4.321 Volts",http://www.pi-in-the-sky.com
 0,1482314122,2016-12-21T09:55:22Z,HB9TSS-11,HB9TSS-11,73(35/17),0,:,HB9TSS-11,/O,,,,,,,,,Telemetry devices,,,

 

Der Audiolevel (Pre-Emphasis)

Direwolf schreibt die Lautstärke der beiden Töne (1100Hz und 2200Hz), die zur AFSK-Modulation benutzt werden, in die Logzeile:

audiolevel = 75 (33/17)

bedeutet: der 1100Hz wird mit 33 „Einheiten“ empfangen, der höhere mit 17. Dies sollte so nicht sein: führt der Empfänger keine De-Emphasis durch, sollte die höhere Frequenz fast doppelt so laut sein (fast 6dB). Findet eine De-Emphasis statt, sollten beide gleich laut sein. Hier sollte also der APRS Sender justiert werden.

Die Messungen und Theorie dazu werde ich in einem kommenden Artikel beschreiben.

 

Kontrolle im APRS Netz

Auf dem IS Server taucht das IGate als Client auf (hier noch mit der SSID HB9TSS-3):

 

Kontrolle  auf APRS.FI

 

Positionsmeldungen des IGate

Die Position des IGate selber ist nicht auf der Karte sichtbar. Dazu muss das Gateway selber ein Client Meldung abschicken. Dies lässt sich mit einer Zeile in direwolf.conf erreichen:

PBEACON sendto=IG delay=0:30 every=60:00 symbol="igate" overlay=I lat=46^41.46N long=007^40.90W

 

Logmeldungen und Automatischer Start

Die Konfiguration der Logdateien und des automatischen Startes wurde nach dem ersten erfolgreichen Setup geändert und neu gemäss APRS Box -Einsatz von Direwolf mit Details für den Gateway Betrieb eingerichtet (siehe auch das Direwolf Manual 9.13 / 9.14). Dies scheint mir eher das übliche für einen daemon zu sein (der nicht interaktiv gestartet wird, sondern im root-Kontext im Hintergrund). Das ursprünglich vorgesehene Script dw-start.sh wird evtl. noch eingebaut, da es direwolf überwacht und nötigenfalls erneut startet.

Die Schritte im einzelnen:

• • Verschieben von direwolf.conf nach /etc/direwolf/direwolf.conf
  • Konfiguration von syslog und logrotate mit den neuen Dateien /etc/logrotate.d/direwolf und /etc/rsyslog.d/direwolf.conf
  • neues Startscript /etc/init.d/direwolf (der Teil zum „Audio Cape“ wurde auskommentiert)
  • Anbinden des Scripts an den runlevel 2 (Runlevel 2 = headless mode, default in Jessie Lite). Achtung Bug: S01direwolf, nicht S001direwolf

    pi@skygate1:/etc/init.d $ sudo update-rc.d direwolf defaults
    insserv: warning: current start runlevel(s) (2) of script `direwolf' overrides LSB defaults (2 3 4 5).
    insserv: warning: current stop runlevel(s) (empty) of script `direwolf' overrides LSB defaults (0 1 6).

    

Das IGate start damit automatisch als daemon. Manuell kann das Script mit cd /etc/init.d und direwolf start gestartet werden (evtl. noch laufende Prozess stoppen sudo killall direwolf).  Kontrolle mit ps aux | grep direwolf oder mit top:

Die Textausgaben können in der Logdatei verfolgt werden: tail -f /var/log/direwolf.log oder können vom Service mit sudo service direwolf status erfragt werden:

Der Service kennt eine Reihe von Kommandos: sudo service direwolf start / stop /status / force-reload / restart. Die restart / force-reload Optionen können nicht ohne weiteres genutzt werden, da der direwolf Prozess noch läuft und die Soundkarte blockiert. Ob dem so ist, sieht man mit ps:

Die Option stop legt den Prozess nur schlafen (wird also nicht abgeräumt). Bei einem Neu-Start beim Boot funktioniert das schon, einmalig. Ich habe die Konfiguration force-reload entfernt und beim stop alle Prozesse gekillt. So kann jederzeit stop / start / restart genutzt werden, ohne dass ein Prozess die Soundkarte blockiert (und somit direwolf nutzlos ist, was man nicht einfach so feststellen kann). Hier mein ini.d/direwolf Script (nicht vergessen, nach Änderungen: sudo systemctl daemon-reload):

#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
 set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides: direwolf
# Required-Start: $network $local_fs $time
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO

# Author: Ed Lafargue <ed@wizkers.io>

PATH=$PATH:/usr/local/bin
DESC="Direwolf APRS Daemon"
DAEMON=/usr/local/bin/direwolf
CONF=/etc/direwolf/direwolf.conf

test -x $DAEMON || exit 0

case "$1" in
 start)
 log_begin_msg "Starting Direwolf"
 sudo $DAEMON -c $CONF -t 0 | logger -p local0.info -t direwolf 2>&1 &
 log_end_msg 0
 ;;
 stop)
 log_begin_msg "Stopping Direwolf"
 sudo killall direwolf
 log_end_msg 0
 ;;
 restart)
 $0 stop
 $0 start
 ;;
 status)
 $PROGRAM –show
 ;;
 *)
 log_failure_msg "Usage: $PROGRAM {start|stop|restart|status}"
 exit 1
esac
exit 0

 

Alternative Einrichtung eines Service (für Scripts)

Hier bin ich auf eine alternative Anleitung für die Erstellung eines automatisch ablaufenden  Services/daemons gestossen (am Beispiel eines Python Scripts):

HOW TO RUN A SCRIPT AS A SERVICE IN RASPBERRY PI – RASPBIAN JESSIE

 

Erfahrungen

• Empfang mit einem AOR 8600 Breitbandempfänger hat meistens geklappt.
• Empfang mit dem ICOM IC-E92D Handfunkgerät ist tadellos.
• Es braucht bei diesen generell ein hohes Audiolevel zur Dekodierung (in alsamixer mind. 60 eher 80).
• Man muss den Mic Level (in alsamixer) kontrollieren. insbesondere wenn die USB Soundcard umgesteckt worden ist.  In der Regel reicht ein sehr niedriger Mic Level, wenn das Signal von einem LineOut Ausgang herkommt (Mic Level ist minimal auf dem Schilthorn).
• Natürlich darf man die Einstellungen am Funkgerät nicht vergessen: Attenuator, Mode (Narrow FM plus evtl. richtige Filter), Squelch, Audio Level…übrigens ist das Ohr ist ein gutes Messinstrument.
• Die Frequenz am ICOM Gerät verändert selbstständig in 25kHz Schritten nach unten. Es sieht fast nach einem Bandscan des Geräts aus (Scan nach geschlossenem Squelch). Warum?
• Warum wird das Gateway manchmal nicht berückichtigt, sondern ein anderes? Bei aufgeschraubter SDR Magnetfussantenne kommt immer HB9CZV-4. Reagiert es zu langsam? Mit einer Stummelantenne kommt das Pi Gateway zum Zug.
• Warum erscheint beim APRS T2 Server mein IGate (HB9TSS-3), aber auf aprs.fi das Gateway von HB9CZV?

 

Offene Punkte

• Konfiguration Gateway prüfen
• Logging von APRS Paketen, mit -a für Audiostatistiken oder für Debugging

 

Fernwartung / Remote Access

Für die Fernwartung des Gateways am Zielort ist putty von einem lokalen PC dort im internen Netz vorgesehen. Auf den PC wird mit Teamviewer zugegriffen (dies erübrigt eine Portöffnung). Alternativ könnte man direkt mit Teamviewer Host Linux auf den Pi zugreifen wie hier beschrieben: TV Host auf RPi installieren. Das ha sich allerdings nicht bewährt.

Schliesslich gibt es den modernen IoT Weg: eine Verbindung via weaved (neu: remot3.it). Dies funktioniert ähnlich wie ein Teamviewer mit einem Broker im Internet – damit entfällt eine Portöffnung ebenfalls.

Der Erfahrungsbericht zum Remote Access ist als  eigenständiger Blog hier nachzulesen.

 

 

---

Links und Referenzen

Direwolf

• Blog direwolf on RPI Kurzform vom obigen
• Github Seite Direwolf Source vn direwolf
• Github Seite direwolf-init Scripte
• Yahoo Group Direwolf Diskussionen
• Github Seite Pi-in-the-sky
• APRS Box -Einsatz von Direwolf mit Details für den Gateway Betrieb ähnliches Projekt
• A PRE-BUILT RASPBERRY PI IMAGE FOR USING AN RTL-SDR AS AN APRS RX IGATE

Linux

• Raspberry Pi: Dienste starten, stoppen, neustarten, aktivieren und deaktivieren Erklärung zu init.d System
• Simon Monk, Raspberry Pi Cookbook, O’Reilly, Recipe 3.20 Running a Program or Script automatically on Startup
• Mirco Lang: Prozessbeobachter, c’t 2015/1, pp. 163
• SSH Ubuntu Wiki gründliche Übersicht zu SSH

Aprs

• APRS Detailwissen
• TAPR
• APRS Pfad für Ballons
• ARS Tier 2 Network
• APRS q Constructs
• APRS IGate Design

---

Update 20170411/20170714