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.
Am 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…
Manche 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:
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.
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!
#!/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
keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
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.
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:
Der 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.
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 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 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:
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.
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 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
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:
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)
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
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 SmartBeaconin
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.
Die 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)
In den nächsten Tagen habe ich das Gerät überall mitgenommen. Zum Testen natürlich.
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.
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
Viele 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:
RF 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.
Kanalauswahl
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.
Kanalbandbreite
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.
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:
Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).
Zuerst 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:Die 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:
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.
Das Gerät besteht aus mehreren Teilen:
einer 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.
Ich 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.
Nachdem 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.
Der 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:
Update Februar 2021: mich hat Thomas OE1TRI angeschrieben – er hat ein anderes (vmtl. neueres?) Gerät probiert, mit dem er sehr zufrieden ist. Die Position ist sehr exakt und im Innenbereich hat er auch bei einer Distanz von 15m zum Sender keine Probleme. Das ist doch erheblich besser als meine Erfahrungen mit dem hier beschriebenen Gerät. Daher möchte ich euch den Link zum von ihm getesteten Gerät nicht vorenthalten: https://www.ebay.at/itm/GPS-Signal-Repeater-Amplifier-Transfer-25M-Antennen-Kit-fur-den-Innenbereich-L1/254094640578?hash=item3b293885c2:g:3v4AAOSwH-RcSps5 (GPS Signal Repeater Amplifier Transfer 25M Antennen-Kit für den Innenbereich L1)
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.
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
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!
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.
Aber 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
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).
Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.
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.
