Schlagwort-Archive: antenne

Empfehlung: externe RP-SMA-Antennen

Ich habe mit den mitgelieferten Antennen bei Access Points mit verschiedenen Herstellern sehr unterschiedliche (und oft schlechte) Erfahrungen gemacht.

RP-SMA Buchse

Da zum Glück die meisten Hersteller RP-SMA-Anschlüsse verbauen, habe ich mir folgende Antennen in größerer Stückzahl zugelegt und tausche sie nun regelmäßig gegen die ursprünglich mitgelieferten. Auch im Outdoor-Bereich habe ich damit seit zwei Wintern keine Probleme gehabt, obwohl die Antennen nur für indoor designed sind:

2,4 GHz und 5 GHz 8 dbi RP SMA Antenne

Die Modellbezeichnung ist bei Amazon Huacom HCM82. Eigentlich habe ich die Antenne ursprünglich auf Aliexpress gefunden und getestet. Sie ist quasi baugleich mit dem Modell, das auf Amazon angeboten wird, mittlerweile ist sie auf Aliexpress sogar teurer.

Die Antenne ist für 2,4 GHz und 5 GHz WLAN geeignet und verfügt über ein Gelenk, über das sie 45° oder 90° „geknickt“ werden kann.

Der Antennengewinn ist mit 8 dbi angegeben. Damit ist auch guter Empfang von weiter entfernten Stationen möglich.

Blick ins Innere: Antennendraht beim Gelenk

Übrigens: in Österreich (ich glaube überall in der EU) ist die maximal zulässige Leistung als e.i.r.p. definiert. EIRP bedeutet, dass die Leistung des Geräts zum Antennengewinn addiert werden muss und dann einen gewissen Wert nicht überschreiten darf. Wenn man jetzt eine stärkere Antenne montiert, sollte man darüber nachdenken, die Leistungsstufe des Geräts zu reduzieren um im gesetzlichen Rahmen zu bleiben.

Lösungsvorschläge für den Ubiquiti AirOS AiRMAX Hack vom Mai 2016 im Netz von Funkfeuer Wien

airoslogin-motherAm 13. +14. Mai 2016 wurde eine Sicherheitslücke (vmtl. im Webserver) der Ubiquiti Airmax Antennen mit AirOS Software ausgenutzt. Die Gesamtzahl der Standorte ist von etwa 230 aktiven Knoten auf knapp mehr als 150 Nodes zurückgegangen, die  unmittelbar nach der Attacke noch online waren. Mittlerweile geht die Zahl zum Glück wieder nach oben.

Aus jetziger Sicht platziert der Hack einige Dateien unter /etc/persistent. Außerdem werden die Login-Daten überschrieben und SSH-Keys installiert, mit denen ein Hacker von außen weiterhin auf die Antenne zugreifen kann.

Sollten Spuren des Hacks auf einer Antenne auftauchen, ist es jedenfalls empfehlenswert, per TFTP ein Image neu zu laden und die Antenne neu zu konfigurieren. Die Vorschläge weiter unten in diesem Text sind eher als Sofortmaßnahme gedacht, um die Antennen rasch wieder online zu bekommen.

Auswirkungen / Festellen des Hacks

Ich habe zwei Auswirkungen des Problems auf meinen Antennen festgestellt:

  • Großteils sind die Antennen auf Werkseinstellungen zurückgesetzt und daher über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ erreichbar. Eine Veränderung an den Antennen konnte ich nicht feststellen, wodurch das Einspielen eines Backups bzw. eine Neukonfiguration das Problem rasch löst. Idealerweise flasht man die Antenne per TFTP neu. Leider muss man diese Schritte vmtl. vor Ort durchführen, also hinfahren…
  • ubnt-hackManche Antennen sind noch online, aber ich kann mich nicht mehr mit dem bekannten Passwort anmelden. Wenn die Antenne „erfolgreich“ gehackt ist, wurden Username + Passwort auf „mother“ und „fucker“ geändert. Mein „ubnt“-User hat nicht mehr funktioniert, obwohl er in der /etc/passwd noch enthalten ist. Seit dem Entfernen des Hacks funktioniert mein ubnt-User wieder normal. Das Passwort ändert man zur Sicherheit trotzdem.
    Im Verzeichnis /etc/persistent/ findet man außerdem mehrere Files als Hinweis auf den Hack. Diese Antenne ist somit vom Virus befallen und muss gesäubert werden!

Details zum Hack

Details findet ihr im Forum von Ubiquiti Networks. Aktuell beginnen auch erste Händler entsprechende Hinweise zu posten:

Lösungsstrategien

Zuerst muss man feststellen, ob sich die Antenne im Werkszustand befindet oder nicht. Wenn sie über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ per Webbrowser erreichbar ist, kann man wie gewohnt die Konfiguration durchführen bzw. ein Backup einspielen. Besser ist es, zur Sicherheit per TFTP neu zu flashen. Dann kann man wirklich davon ausgehen, dass kein Schadcode erhalten bleibt.

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http und https nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Entfernen des Virus

Falls die Antenne erreichbar ist, gehört unbedingt geprüft, ob der bisherige Login noch funktioniert. Wenn die Antenne gehackt wurde, muss man ab sofort mit den Daten des Hackers, Username „mother“ und Passwort „fucker“, einloggen.

Es gibt ein Removal Tool, das auf Java basiert, von Ubiquiti zum dem Problem: https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/m-p/1563869

Alternativ gibt es auf Github ein Script, das aber auch den Standard-Port des Webserver auf 81 setzt: https://github.com/diegocanton/remove_ubnt_mf/

Update 16.5.2016: angeblich verbleiben ein paar ipks installiert, es ist somit ein Reset auf Werkseinstellungen (noch besser: per TFTP neu flashen) dem Entfernen/desinfect-Script zu bevorzugen, siehe auch: https://lists.funkfeuer.at/pipermail/wien/2016-May/012228.html

Update 17.5.2016: Ubiquiti stellt eine Android App – ein Virus Removal Tool – zur Verfügung: https://play.google.com/store/apps/details?id=virusfixer.ubnt.com.ubntvirusremoval

Ich habe mir erlaubt, das desinfect.sh-Script (Ausgangspunkt ist commit #c841d87) von Github zu übernehmen und einige Funktionen anzupassen, damit es für meine Zwecke passt.

Funktionsübersicht:

  • das Script wird lokal auf der Antenne über SSH ausgeführt.
  • das Script überprüft, ob die Antenne infiziert ist.
  • die infizierten/veränderten Files werden gelöscht
  • die Accounts für „mcad“, „mcuser“ und „mother“ in /etc/inittab und /etc/passwd werden gelöscht
  • die Änderungen werden persistent gespeichert
  • Prozesse des Hacks werden gekillt
  • wichtig: danach muss die Firewall (siehe unten) konfiguriert und rebootet werden!

Das angepasste Script findet ihr unten und zum Download hier:

#!/bin/sh
# This script removes the Ubiquiti AirOS hack
# Script is based on this work:
# https://github.com/diegocanton/remove_ubnt_mf
# Colaboration: Alexandre Jeronimo Correa - Onda Internet, PVi1 (Git user)
# modified 2016/05/16 by Stefan Schultheis
FILE=/etc/persistent/mf.tar

# Check virus
if [ -e "$FILE" ] ; then
    echo "Infected :("
    #Access folder
    cd /etc/persistent
    #Remove the virus
    rm mf.tar
    rm -Rf .mf
    rm -Rf mcuser
    rm rc.poststart
    rm rc.prestart
    #Remove mcuser in passwd - by Alexandre
    sed -ir '/mcad/ c ' /etc/inittab
    sed -ir '/mcuser/ c ' /etc/passwd
    sed -ir '/mother/ c ' /etc/passwd
    #Write new config
    cfgmtd -w -p /etc/
    #Kill process - by Alexandre
    kill -HUP `/bin/pidof init`
    kill -9 `/bin/pidof mcad`
    kill -9 `/bin/pidof init`
    kill -9 `/bin/pidof search`
    kill -9 `/bin/pidof mother`
    kill -9 `/bin/pidof sleep`
    echo "Clear Completed :)"
else
    echo "Clear :) No actions"
    exit
fi

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http, https und ssh nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Achtung bei Upgrade zu AirOS 5.6.5

Ubiquiti scheint ein Upgrade zu AirOS 5.6.5 zu empfehlen. Hier ist zu beachten, dass es

  1. keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
  2. keine Custom Scripts (/etc/persistent/rc.*) mehr gibt! Dadurch kann die bestehende Funktion eingeschränkt sein!

Konfiguration der Firewall

Ich schalte mir nur einzelne IP-Adressen für den Zugriff auf die Webinterfaces frei, das mache ich mit folgenden iptables-Regeln. Hier werden künftig nur mehr Zugriffe aus 78.41.113.x und 78.41.113.y zugelassen (bitte eigene IPs einsetzen).

touch /etc/persistent/rc.poststart
echo "iptables -F" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.x -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.y -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 80 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp -i lo --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/

Ich empfehle darüber nachzudenken, ob man nicht die Erreichbarkeit von SSH ebenfalls auf ein paar weniger IPs beschränken möchte.

Nach einem Reboot ist die Antenne nur mehr von den oben eingetragenen IPs erreichbar.

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.

 

 

 

Unifi AP-AC-Pro: erste Eindrücke

Heute habe ich meinen ersten Unifi AP AC Pro erhalten. Eigentlich hat der Händler die Geräte – nach eigenen Angaben – erst ab Jänner 2016 lieferbar, aber ein einzelnes Gerät konnte er mir reservieren und schicken.


Update Dezember 2016: mittlerweile gibt es modernere Access Points, als ich in diesem Beitrag beschreibe. Ich habe dazu einen anderen Blogbeitrag verfasst und würde empfehlen, eher ein Produkt der moderneren UAP AC-Serie zu wählen, falls dieser Artikel zu einer Kaufentscheidung herangezogen wird.


Nachtrag Jänner 2017: mittlerweile sind auch 802.11ac-fähgie Geräte im leistbaren Segment für Außeninstallationen erschienen, die ich in einem separaten Artikel vorstelle. Diese Geräte eigenen sich auch gut für den Innenbereich.


Optik und Montage

Optisch sieht das Gerät den anderen (runden) Unifi APs sehr ähnlich, als Unterschied fällt mir eigentlich nur das neue Ubiquti-Logo auf. Ich möchte einen Unifi AP LR ersetzen, die Montagehalterung ist die gleiche bzw. passt und so musste ich nur den alten von der Halterung herunterdrehen und den neuen AP reindrehen. Das klingt ein bißerl einfacher, als es tatsächlich ist: die Öffnung für den Schraubenzieher, mit dem der AP gehalten wird, hat mich ganz schön ins Schwitzen gebracht, aber es war zu schaffen.

Inbetriebnahme

Das Gerät hat sich sofort an meinem lokalen Unifi Controller angemeldet und problemlos adoptieren lassen und ich habe das WLAN-Profil für zu Hause ausgewählt.

Ich verwende die aktuelle Version 4.7.5 des Controllers. Der AP wurde mit SW Version 3.4.7.3231, die mit einem Klick auf „Upgrade“ rasch auf 3.4.7.3284 gehoben war.

Und schon haben sich die ersten Geräte über den neuen AP verbunden.

Neu: Konfiguration per Handy App

Ich habe es nicht selbst probiert, aber die neue Generation von Unifi APs können per Smartphone-App (derzeit nur Android App) konfiguriert werden und benötigen somit keinen Unifi-Controller bei der Inbetriebnahme!

erste Tests

windowsacViele Geräte verbinden sich lieber über 2,4 GHz und 802.11n-Standard. Nur einzelne Laptops und Smartphones nutzen den 802.11ac-Standard auf 5 GHz. Sie zeigen aber Übertragungsraten von mehr als 300 MBit/s an (im Bild sind es 780 MBit/s, also 2×2 MIMO mit 802.11ac bei 80 MHz Kanalbreite – das Maximum wäre 867 MBit/s). Meine Tests haben derzeit keine gesteigerte Bandbreite ergeben, aber ich möchte das in den nächsten Tagen noch genauer testen.

Was mir auffällt

Ein paar neue Features sieht man sofort im Unifi Controller:

  • unifi-rf-environmentRF environment

Damit scannt der Access Point die Umgebung (alle Clients verlieren derweil die Verbindung, es wird jedoch mit einer kurzen Warnung darauf hingewiesen) und zeigt die Belegung der Kanäle und deren Rauschen (Interference) an. Das finde ich sehr interessant, weil man so auch aus der Ferne einen möglichst idealen Kanal finden und konfigurieren kann.

  • unifi-5ghz-kanäle-acKanalauswahl

Bei 2,4 GHz bietet der AP die üblichen 13 WLAN Kanäle an.
Bei 5 GHz kann man jedoch nur aus Kanal 36, 40, 44 und 48 wählen. Der Grund liegt wohl darin, dass bei diesen Indoor-Kanälen kein DFS gefordert ist bzw. offenbar die APs derzeit DFS nicht unterstützen. Aufgrund meiner Ländereinstellung „Austria“ werden somit die anderen Kanäle ausgeblendet.

  • unifi-rf-env5ghzKanalbandbreite

Standardmäßig werden 40 MHz Kanalbandbreite genutzt. Man kann diese Einstellung auf 20 MHz reduzieren oder auf 80 MHz erweitern. Die Top-Geschwindigkeiten sind natürlich nur mit 80 MHz zu erzielen. Nachdem nur 4 Kanäle zur Verfügung stehen, kommt es hier leider zu Überschneidungen, sobald man 40 oder 80 MHz Kanalbandbreite einstellt.

Fazit

Das Gerät war superschnell installiert und in Betrieb genommen – vor allem, da ich es ja in meine bestehende Unifi-Umgebung integriert habe. Ich würde mir noch DFS-Unterstützung wünschen, damit auch alle, oder zumindest mehr als 4 Kanäle, zur Verfügung stehen.

Unifi Controller in fhem einbinden

Ich habe bereits über meine Unifi-Installation geschrieben, die sich weiterhin bewährt.

Mit großer Freude habe ich gelesen, dass seit 23. August 2015 auch ein Unifi-Modul für fhem verfügbar ist! (Das Changelog sagt: „added: 74_Unifi.pm for the Ubiquiti Networks (UBNT) – Unifi Controller“)

Das muss ich gleich probieren! Einen Unifi-Controller habe ich laufen, jetzt möchte ich diesen mit fhem verbinden und anhand der Clients im WLAN die Anwesenheitserkennung von fhem nutzen.

Mittlerweile habe ich den Unifi Controller in Version 4.6.6 bei mir laufen. Von Version 3 zu Version 4 hat sich einiges geändert, auch in der Unifi API. Es ist daher verständlich, dass man die Versionnummer angeben muss. Gleichzeitig ist es toll, dass das fhem-Modul sowohl Version 3 als auch Version 4 unterstützt.

Ich habe für den Unifi-Zugriff aus fhem einen eigenen User „fhem“ mit „Read Only“-Berechtigung im Unifi Controller angelegt.

Der Zugriff von fhem war mit einer Zeile erledigt:

define myunifi Unifi 192.168.1.9 443 fhem geheim 30 default 4

Der Syntax lautet gemäß Perl Modul:

define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID> [<version>]]]

In der Commandref stehen auch die Details zur Nutzung des Moduls.

Die Standardwerte dafür sind:

  • interval = 30 Sekunden
  • siteID = default
  • version = 4

Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).

fhemunifi-siteidZuerst habe ich den angezeigten Namen vom Unifi-Controller meiner Site als siteID anzugeben. Damit habe ich  keine Werte bekommen. Nach kurzer Suche habe ich die Fehlermeldung im Log gefunden:

myunifi (Unifi_GetClients_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.

Folgender Hinweis hilft: in der URL des Controller sieht man, mit welcher siteID man verbunden ist, auch wenn diese einen anderen Namen trägt, der im Controller angezeigt wird:

Es hat dann sofort funktioniert: im „Unsorted“-Bereich habe ich nun das Objekt myunifi und alle verbundenen Endgeräte:fhemunifi1Die Daten, die fhem vom Unifi Controller bezieht sind umfangreich und ermöglichen viele Anwendungen, auch außerhalb der Presence-Funktion. Hier die Details zu einem Client:unifi2

====================================== 
_id = 558XXXXXXXXXXXXXb85ae047 
_is_guest_by_uap = false 
_last_seen_by_uap = 1441082804 
_uptime_by_uap = 33149 
ap_mac = 24:a4:XX:XX:XX:c3 
assoc_time = 1441043174 
authorized = true 
bssid = 2e:a4:XX:XX:XX:c3 
bytes-r = 3 
ccq = 991 
channel = 7 
essid = MeineSSID 
first_seen = 1435052270 
hostname = android-bfeXXXXXXXXX9f0f 
idletime = 24 
ip = 192.168.XXX.103 
is_guest = false 
is_wired = false 
last_seen = 1441082804 
latest_assoc_time = 1441049655 
mac = 60:af:XX:XX:XX:e5 
name = Stefan Samsung XXXX
noise = -94 
note = 
noted = false 
oui = SamsungE 
powersave_enabled = true 
qos_policy_applied = true 
radio = ng 
radio_proto = ng 
roam_count = 2 
rssi = 40 
rx_bytes = 1339759 
rx_bytes-r = 3 
rx_packets = 6309 
rx_rate = 6000 
signal = -54 
site_id = 53ecXXXXXXXXXXXXXXX91e2a 
tx_bytes = 1905377 
tx_bytes-r = 0 
tx_packets = 5576 
tx_power = 30 
tx_rate = 72222 
uptime = 39630 
user_id = 55892XXXXXXXXXXXXX5ae047 
usergroup_id = 
======================================

neue & weitere Funktionen

Das Modul für Unifi ist neu im fhem. Es wird laufend weiterentwickelt, so wurde letzte Nacht wieder um Funktionen erweitert, zB:

  • einen Client disconnecten,
  • einen Access Point restarten
  • die „Locate“-Funktion eines APs ein- & ausschalten (blinken)
  • Alarme am Controller archivieren

Am besten behält man das fhem Changelog im Auge. Dort werden Änderungen & Erweiterungen protokolliert.

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

Maritime mobile

Bojenfeld in einer Bucht auf Dugi Otok in Kroatien. Unser Boot ist das dritte von links oder rechts

Im Zuge eines Segeltörns in Kroatien (Reiseberichte gibt es unter anderem hier und hier) haben wir am 16. Juni 2015 bei einem Bojenfeld in einer Bucht auf der Insel Dugi Otok im Naturpark Telašćica das Kurzwellen-Equipment ausgepackt und in Betrieb genommen.

Co-Skipper Florian (links im Bild) hat sich aufgrund des starken Winds einen Poncho ausgebort und zieht ebenso stilsicher wie todesmutig mit OM Bernd OE1IHB den Langdraht auf den Mast.

Als Antenne hat ein etwa 22 Meter langer Funkdraht gedient, den ich beim Amateurfunkflohmarkt in Altlengbach im Vorjahr von einem mit Carmouflage bekleideten Ungarn erworben habe. Auf der Haspel waren etwa 40m Draht, wir haben ihn also bereits gekürzt. Die Langdrahtantenne haben wir endgespeist über einen MTFT Magnetic Balun (eigentlich: Unun) mit dem automatischen Antennentuner MFJ 993B verbunden. Das andere Ende haben wir auf dem 17m hohen Mast raufgezogen und somit den Draht eher vertikal montiert.

Als Transceiver hat sich wieder mein Yaesu FT857 für die portable Nutzung bewährt.

IMG_4058
Stromverteiler und Multimeter („sicher ist sicher“)

Zur Stromversorgung hat unser Skipper OM Florian OE3FDS die 12V Bordspannung von einer der beiden 110Ah-Bordbatterien genutzt und mit KFZ-Starterkabel mit meiner 12V-Vielfachverteilerleiste (bis 20A Belastbarkeit) verbunden. Von dort aus konnten wir die aktiven Geräte praktisch über Bananenstecker bzw. Kabelschuhe anschließen.

Damit die Konstruktion nicht verrutscht und die Sachen durcheinander fliegen, wird alles noch großzügig mit Duct Tape befestigt. Das schaut zwar nicht gut aus, hält aber super.

Konkret haben wir also folgendes Setup verwendet:

  • Antenne: Langdraht, ca. 22m endgespeist
  • Balun/Unun: MTFT Magnetic Balun 1:9
  • Tuner: MFJ 993B
  • Transceiver: Yaesu FT857
  • Stromversorgung: direkt von 12V Bordbatterie per KFZ-Starterkabel und 12V-Vielfachverteilleiste
  • genutzte HF-Leistung: max. 35W, normalerweise ca. 20-25W
  • unser Locator: JN73nv98
Skipper Florian OE3FDS (9A/OE3FDS/mm) macht es sich im Hintergrund gemütlich und lauscht...
Skipper Florian OE3FDS (9A/OE3FDS/mm) macht es sich im Hintergrund gemütlich und lauscht…

Und schon kann’s losgehen: wir hören auf 40m die ersten Stationen. Ich probiere auch andere Bänder und stelle fest, dass um ca. 16:30 Lokalzeit am besten die Stationen auf 15m und 20m zu hören sind. Also beantworte ich die ersten CQ-Rufe mit meinem „Maritime Mobile-Call“ 9A/OE1SCS/mm und komme auch sofort durch. Wir arbeiten ein paar Stationen aus Griechenland, Italien, der Ukraine und zu meiner Freude erreichen wir als Premiere für mich Kuwait, das sind immerhin fast 3.300km Luftlinie!

IMG_4097
9A/OE1SCS/mm

Ich finde es immer wieder interessant, welche Abweichungen manche OMs und YLs zum vorgeschriebenen Funkalphabet finden. Ich bin es ja schon gewohnt, dass man beispielsweise bei Rufzeichen mit „RG“ oft „Radio Germany“ statt „Romeo Golf“ hört. Falls mein Gesprächspartner beim QSO meinen Call nicht versteht und bis zur Heiserkeit „QRZ? Oscar Echo One Questionmark? Questionmark?“ ruft, antworte ich auch oft als „Oscar Echo One Sugar Chicago Sugar„, da mein „Sierra Charlie Sierra“ offenbar mehrfach nicht zu verstehen war. Aber meinen Maritime Mobile-Call 9A/OE1SCS/mm hat ein italienischer OM mit „Mickey Mouse“ (als /mm) bestätigt. Das finde ich mal wieder kreativ. Und ich muss sagen, es ist nicht so unpassend, schließlich versteht es wirklich jeder sofort.

IMG_4057Aber wir sind ja verabredet: um 17:30 Lokalzeit sollten wir auf 7.125kHz +/- unseren Freund OM Simon OE3FSS hören. Ich bin noch mit dem Abschluss eines QSOs nach SV (Griechenland) beschäftigt und drehe um 15:33 UTC auf 7.125 kHz LSB. Und da hört man auch schon Simon rufen! Und das ziemlich gut sogar, nur ein bißerl Rauschen und Knacken im Hintergrund. Gut, das Rauschen war hier im Naturpark vorher sehr gering, es schwankt zwischen S2 und S4. Wir beantworten den Ruf natürlich unmittelbar, geben 58 und bekommen 56. Simon funkt von Prottes bei Gänserndorf aus, gute 500km entfernt, mit einem Dipol (80m lang), seinem Elecraft KX3 und einer HF-Endstufe, über die er für diesen QSO ca. 150 Watt Ausgangsleistung erzielt. In Prottes herrscht zur Zeit ein Gewitter, wir vermuten, dass das Rauschen daher stammt.

OM Bernd OE1IHB, meinereiner Stefan OE1SCS, Skipper OM Florian OE3FDS
OM Bernd OE1IHB, meinereiner Stefan OE1SCS, Skipper OM Florian OE3FDS

Ein paar Minuten später übernimmt OM Florian als 9A/OE3FDS/mm und tauscht mit Simon die wesentlichsten aber weiterhin vorschriftsmäßig belanglosen Daten über die Funkverbindung aus, um dann an OM Bernd 9A/OE1IHB/mm zu übergeben.

Die Anzahl der Stationen auf 40m nimmt um diese Zeit (mittlerweile wird es 16:00 UTC) stark zu, es war ja auch zu erwarten, dass das Band um diese Zeit „aufmacht“. Die Störungen nehmen daher zu und Simon und wir werden von benachbarten Stationen immer mehr verdrängt. Bald sind nur mehr Stationen aus den üblichen Ländern mit den vielen Kilowatt-Stationen zu hören.

Auch die Situation in den anderen Bändern hat sich eher verschlechtert, 20m und 15m verschwinden immer mehr im Rauschen.

Auf 14.313 kHz erreichen wir DJ3CD, der vor allem auf Maritime Mobile-Stationen achtet, und uns die Wetterinformationen für die nächsten 24h übermittelt. Dass wir nicht alleine sind, haben wir erkannt, als uns DH6HW mit einem kurzen Zwischenruf die Windstärken in Beaufort ergänzt hat.

Nach diesen QSOs (und den Anstrengungen vom Segeln) sind wir schon etwas erschöpft und bevor wir QRT senden, rufe ich noch ein paar Mal: „See kuw See kuw See kuw de Nine Alpha Slash Oscar Echo One Sierra Charlie Sierra Maritime Mobile“ (CQ CQ CQ de 9A/OE1SCS/mm).

Hier noch ein paar Eindrücke:

IMG_4041

IMG_4030
https://de.wikipedia.org/wiki/Drei_Affen