Ich setze seit kurzem die ESP32 basierenden Gateways (PoE-fähig!) für LoRa APRS auf 70cm von OE5BPA ein. Nachdem ich diese iGates nicht nur zu Hause betreibe, sondern auch bei Relaisstationen an exponierten Standorten installiere, ist mir wichtig, dass auch neue Entwicklungen dort genutzt werden können – das setzt voraus, dass ich die Konfiguration von der Ferne anpassen kann (das funktioniert wunderbar über FTP und ist von Peter OE5BPA bereits gut beschrieben worden) und auch Firmware Updates mit neuen Features von der Ferne installiert werden können. Dieses Feature nennt sich Firmware Update over The Air (kurz: FOTA- oder OTA-Update).
iGate bei 73% des Over The Air Firmware Updates
Eine Beschreibung der Hardware findet ihr hier auf meinem Blog. Da ich die Geräte über PoE nutze, gibt es hier für Interessierte eine Übersicht über PoE, die früher mal geschrieben habe.
iGate im (Test-)Betrieb
Nachdem ich kein Programmierer bin und auch mit der Entwicklungsumgebung Platformio (siehe auch https://platformio.org) noch nicht viel Erfahrung habe, war mir am Anfang nicht ganz klar, wie das FOTA/OTA funktioniert. Daher möchte ich es hier kurz beschreiben.
Welche Schritte sind für uns Benutzer nun also nötig, um ein Update durchzuführen? Die Voraussetzung ist, dass die Umgebung so aufgesetzt ist, dass der Code fehlerfrei kompiliert, also alle Bibliotheken vorhanden sind uä. Damit wäre ja das Update über USB machbar. Wenn das klappt, prüft man die Einstellungen bzw. Konfiguration, die befinden sich in der Datei is-cfg.json.
Auch wenn man bisher noch kein Update Over the Air durchgeführt hat, ist es dennoch auf den iGates auf der Firmware aktiv. Es ist also möglich, einen Gateway, den man vor ein paar Wochen installiert hat, künftig OTA zu aktualisieren.
Wie geht das nun? Ein Blick in die Datei platformio.ini, im Anfangsverzeichnis des Projekts, zeigt uns die Konfiguration:
# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = OE1SCS-12.local
Im Beispiel oben möchte ich den iGate „OE1SCS-12“ updaten, der sich bei mir im LAN befindet. Falls sich dein iGate auch im LAN befindet, brauchst du also nur ggf. die Kommentare rausnehmen und den Call deines iGates – gefolgt durch .local – ersetzen.
Peter hat die Konfiguration so gewählt, dass sich die Gateways mit dem mDNS-Namen (multicast DNS) unter dem Namen des iGate + .local registrieren. mDNS ist ein DNS-Dienst, der keine Server benötigt, sondern über Multicast (dafür nur im gleichen LAN) DNS-Namen ermöglicht. Ich kann also meinen Gateway auch über diese Adresse pingen:
mDNS im LAN funktioniert, ich kann mein iGate erreichen
Dazu muss natürlich die Konfiguration erstmal (vmtl. über USB) auf dem iGate aufgebracht sein, danach ist ein Update wie beschrieben möglich.
Wenn das klappt, kann ich in Platformio das „Alien“-Symobl auswählen und „Upload Filesystem Image“. Schon wird Platformio die aktuelle Version builden (quasi kompilieren) und über das Netzwerk upgraden:
OTA läuft
Im „Task“ Fenster bei Platformio (auch Konsole) genannt kann man den Status verfolgen:
Wenn die Meldung „SUCCESS“ auftaucht, war der Vorgang erfolgreich. Der iGate startet nun die neue Firmware und sollte in Kürze erreichbar sein.
Und wie funktioniert das über die Ferne? Ganz einfach: man ersetzt in der platformio.ini den mDNS-Eintrag (in meinem Fall „OE1SCS-12.local“ durch die IP-Adresse des in der Ferne installierten iGates, speichert die Änderung und kann nun genauso von der Ferne das Update einspielen! In meinem Fall sieht das dann so aus:
# activate for OTA Update, use the CALLSIGN from is-cfg.h as upload_port:
upload_protocol = espota
upload_port = 192.168.132.146
Ich nutze viele PoE Converter, um die nominal 48V von PoE bzw. PoE+ gemäß 802.3af / 802.3at auf 5V zu übersetzen und über Micro-USB dem Raspberry bereitzustellen. (Bei Raspi 4B ab jetzt natürlich häufiger mit USB-C).
Die neueren Raspberry-Modelle (3B+ und 4B) unterstützen ein offizielles Raspberry PoE HAT Modul. Dazu wurden 4 weitere PINs auf dem PCB des Raspberry Pi gesetzt und vom PoE HAT genutzt:
mitte/rechts: die 4 PINs für PoE
günstiges PoE HAT
Ich betrachte in diesem Blog nicht das offizielle PoE HAT, sondern eine günstige Alternative ohne Lüfter:
die günstige Alternative zum offiziellen PoE HAT
Im Gegensatz zum offiziellen PoE HAT gibt es hier zwar keine vorgesehene Position für einen Lüfter, allerdings sind die GPIO PINs verlängert bzw. werden durch das günstige PoE HAT durchgereicht. Ich kann also weitere HAT Aufsteckmodule nutzen.
Gekauft habe ich das Modul bei Aliexpress, es ist auch zB. über Amazon erhältlich:
Ich habe es auf einen Raspberry 3B+ gesteckt und an ein Kabel, das von einem Ubiquiti EdgeSwitch 8 150W mit PoE+ versorgt wird.
Mein Ziel ist, einen LoRaWAN Gateway zu testen, der über PoE versorgt wird und LoRaWAN über ein IMST ic880a Board abwickelt. Um das ic880a Board am Raspberry GPIO zu betreiben ist ein Adapterboard nötig, das ich vom Verein OpenIoT erhalten habe.
Raspberry mit bereits aufgestecktem PoE HAT, OpenIoT Adapterboard und IMST ic880a (oben)
In Kombination sieht das „Sandwich“ dann so aus:
Die Module sind halbwegs stabil, ein gutes Gehäuse sollte dennoch her. Es sind leider keine Bohrungen für Distanzhalter vorgesehen.
Ich habe das Board mit einem Ubiquiti EdgeSwitch getestet, der EdgeSwitch unterstützt den PoE+-Standard und gibt mir auch die aktuelle Leistung je Port an: im Leerlauf zieht ein Raspberry 3 B+ mit Raspbian Lite (Buster) nach einer frischen Installation etwa angezeigt 3,6 Watt.
Wenn ich das LoRaWAN Concentrator Board aufsetze und neu starte, wechselt die Anzeige zwischen 6,1 und 6,5 Watt:
PoE Verbrauch mit IMST ic880a LoRaWAN concentrator board in Betrieb
Auch auf einem Raspberry 4B hat sich das günstige PoE HAT problemlos betreiben lassen.
Temperatur
Bemerkenswert ist, dass das Gerät sehr heiß wird, wenn das IMST Board, das ja die Leistungsaufnahme ggü. dem Raspberry verdoppelt, angeschlossen wird. Die Angabe auf dem PoE HAT sind 2,5A – also 12 Watt. Wir nutzen hier zirka die Hälfte und es geht schon heiß her. Die Core Temperatur zeigt etwa 60 Grad bei Nutzung mit dem IMST Board. Dabei ist natürlich auch der Prozessor unter mehreren Aufsteckmodulen versteckt und hat wenig Luftzirkulation. Ohne LoRaWAN-HATs hat es etwa 53 Grad im Bereich der CPU.
Einen Langzeittest habe ich noch nicht gemacht, ich werde den Artikel hier dann aber mit den Erkenntnissen erweitern.
Das Modul funktioniert sehr gut, erspart mir in Zukunft hoffentlich einen weiteren externen Adapter, um PoE über MikroUSB oder USB-C dem Raspi zu geben.
Beobachten möchte ich die Temperatur, weil als Nebenwirkung des Boards der Raspi auffällig heiß wird.
Links zu den Modulen
Hier eine Übersicht der im Beitrag vorgestellten Artikel/Produkte:
An den vielen anderen Beiträgen zum Thema Ubiquiti Unifi könnt ihr erkennen, dass ich diesem System bereits an mehreren Standorten vertraue. Bisher hat sich die Wahl für Unifi für mich bewährt: das System ist einfach zu bedienen, stabil im Betrieb und bietet alle Features, die ich benötige. Vor kurzem (Dezember 2016) sind neue Produkte von Ubiquiti erschienen, die auch im Freien die aktuellen WLAN-Standards kostengünstig bieten.
Das bisherige Dilemma im Outdoor-Bereich
UAP AC Mesh passt dank mitgeliefertem Adapter problemlos in die vorhandene Wandhalterung
Für den Innenbereich habe ich bereits in anderen Beiträgen entsprechende Produkt vorgestellt. Allerdings gab es bisher keine sinnvoll erschwinglichen Outdoor Access Points, die auch 5 GHz mit 802.11ac abdecken. Das war bislang ein großes Manko. Entweder man nimmt den
oder man leistet sich den Unifi AP AC um mehr als € 300,-. Diese bietet zwar 802.11ac, unterstützt allerdings kein DFS, wodurch die Auswahl an Kanälen in Europa auf 4 reduziert ist.
Unifi Mesh
Zum Glück gibt es nun zwei neue Produkte, die diese Lücke schließen:
Beide sind für den Außeneinsatz gerüstet, unterstützen 2,4 GHz und 5 GHz inklusive 802.11ac und DFS. Und das zum erschwinglichen Preis (Stand Jänner 2017: knapp über € 120,- für den Unifi UAP AC Mesh und etwa € 200, für den Unifi UAP AC Mesh Pro).
UAP AC Mesh
Der Unifi UAP AC Mesh hat das Potenzial, mein neues Standardgerät zu werden. Es ist auch für den Innenbereich fesch, bietet alle gängig benötigten Technologien und unterstützt die PoE Varianten „24V Passive PoE“ und „802.3af Alternative A“, wodurch es im Privatbereich günstig eingesetzt, aber auch an bestehende Switches im Firmenbereich angeschlossen werden kann:
ein Gerät für indoor & outdoor
lässt sich mit vielen bestehenden PoE-Switches nutzen, da es zwei Standards für die PoE-Versorgung unterstützt:
802.3af (Alternative A; vmtl. auch an 802.3at nutzbar)
unterstützt beide WLAN Frequenzen: 2,4 GHz und 5 GHz
erfüllt mit 802.11ac und 2×2 MIMO die modernsten WLAN-Standards mit Geschwindigkeiten bis 867 MBit/s. Und ist kompatibel zu 802.11a/b/g/n/ac.
bindet sich in bestehende Unifi-Management-Umgebungen ein und bietet somit zentrale Konfiguration & Monitoring. Optional kann der AP selbstständig mit unabhängiger lokaler Konfiguration betrieben werden.
abnehmbare Antennen. Der APs enthält Montagevorrichtungen, um mit externen Antennen zB. für bestehende Sektor- oder Panelantennen betrieben zu werden.
VLANs und 802.1q. Für mich immer wichtig, mehrere Netze über VLANs zuführen zu können und als separate SSIDs auszusenden (4 SSIDs sind gleichzeitig je Frequenz je AP möglich, die beiden Frequenzen können für unterschiedliche SSID-Konfigurationen genutzt werden)
Außerdem kann der UAP AC Mesh an vorhandene Wandhalterungen oder Antenna mounts (zB. AirMax Antennen oder Unifi Sektor-Antennen) montiert werden (zB. für die Rocket-Serie).
UAP AC Mesh Pro
Was mir zum Unifi UAP AC Mesh Pro als erstes auffällt: er ist erheblich größer! 34,32×18,12 cm ergeben eine ziemlich eindrucksvolle Fläche, für eine Außenmontage auf einem Mast werde ich hier die Windlast speziell berücksichtigen.
Obwohl das Gerät wie eine Panelantenne aussieht, handelt es ich um einen Rundstrahler. Drei Antennen mit 8 dbi Gewinn sind verbaut, wodurch 3×3 MIMO möglich ist und nominal 5 GHz 802.11ac 1.300 MBit/s (1,3 GBit/s!), sowie für 2,4 GHz 450 Mbit/s möglich werden. Natürlich werden die Bandbreiten nur erreicht, wenn auch das Endgerät das Senden und Empfangen über 3 Antennen ermöglicht.
Hinsichtlich PoE wird beim Pro nur 802.3af unterstützt.
Erwähnenswert ist noch, dass der Pro über zwei Gigabit-Ethernet-Ports verfügt, wodurch es möglich ist, weitere Access Points „hinter“ dem Unifi UAP Mesh Pro zu betreiben (Daisy Chain).
Mesh?
Ich finde den Namen „Mesh“ etwas verfänglich: bei Mesh Network denke ich immer an Netztopologien ähnlich zu Funkfeuer. Also zu weit verteilten Netzen, wo WLAN-Systeme oder -Knoten mit mehreren anderen Systemen oder Knoten verbunden sind.
Für die hier beschriebenen Produkte finde ich das nicht ganz passend: Unifi Systeme können zwar über „Wireless Uplink“ einen Access Point über einen anderen AP anbinden. Allerdings kann ein AP, der nur ohne Kabel verbunden ist, das Signal nicht an noch einen weiteren AP weiterreichen. (Update Februar 2017: siehe Kommentar von Harry unten, es ist bei den Mesh-Produkten möglich, auch mehrere Access Points untereinander über Wireless Uplink zu verbinden: https://help.ubnt.com/hc/en-us/articles/115002262328-UniFi-Feature-Guide-Wireless-Uplink).
Unpacking
Ich habe mich bemüht, recht zeitig nach Erscheinen der Produkte zwei Unifi UAP AC Mesh zu bestellen, da ich schon dringend ein paar Außenbereiche mit WLAN versorgen müsste, das aber bisher nur halbherzig gemacht habe, da ja die bisher verfügbaren Produkte nicht zufriedenstellend waren.
Ubiquiti hat scheinbar das Design des Zubehörs angepasst. Neu ist nämlich, dass das Netzteil und das Kabel weiß – wie der AP selbst – sind. Das Netzteil entspricht den Spezifikationen der bisherigen Produkte für 24V Gigabit passive PoE (0,5 A), ich finde abgesehen von Farbe (und der abgerundeten Form) keine technischen Unterschiede. Jedenfalls möchte ich darauf hinweisen, dass – obwohl ältere Netzteile funktionieren – darauf geachtet werden soll, dass Gigabit unterstützt wird. Schließlich ermöglicht der Access Point ja Bandbreiten, bei denen man nicht möchte, dass dann das Netzteil zum Flaschenhals wird.
Ansonst wirkt der Access Point robust, die beiden Antennen sind abschraubbar (RP-SMA-Anschlüsse). Es können also jederzeit externe Antennen angeschlossen werden. UAP AC Mesh können gemeinsam mit AirMax-Antennen oder -Sektor-Antennen genutzt werden, die bisher zB. für die Rocket-Produkte oder Outdoor+/Outdoor5 gedacht waren.
Eine Signal-LED auf der Seite des Access Points zeigt – wie auch bei anderen Unifi-Produkten üblich – den Status des Access Points:
Das Einbinden in den Unifi Controller funktioniert problemlos. Das Gerät wird sofort erkannt, ein Software-Upgrade wird angeboten und man kann es problemlos adoptieren. ich habe das richtige Profil zugewiesen und kurz darauf haben sich schon die ersten Clients verbunden. Fertig.
Das ging wirklich so schnell, dass ich dann noch versucht habe, den Unifi UAP AC Mesh über einen Wireless Uplink einzubinden. Auch hier hat alles klaglos funktioniert.
Die Signalstärken sind einwandfrei: auch mit zwei Wänden und einem Abstand von 25 Metern zum Access Point bekomme ich -65 dB angezeigt.
Fazit
Ich werde wohl vermehrt auf den Unifi UAP AC Mesh setzen, nachdem er universell in Gebäuden wie im Freien eingesetzt werden kann. Der Unifi UAP AC Mesh Pro bietet in Umgebungen mit vielen Clients aufgrund der zusätzlichen Antenne Vorteile, ich habe jedoch kaum Umgebungen, bei denen ich > 30 Geräte je AP versorgen muss.
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.
In einem früheren Beitrag habe ich bereits beschrieben, warum ich baulich für eine ordentliche WLAN-Versorgung in meiner Wohnung ein ordentliches WLAN-System möchte.
Ich habe mich ja damals für ein Unifi System von Ubiquiti entschieden und das nie bereut. Auch die Migration zur „neuen Generation“ (Wave 2?) von Unifi AC Geräten (AC = sie unterstützen den aktuellen WLAN-Standard 802.11ac) hat problemlos funktioniert.
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.
Hier möchte ich einen die Vor- & Nachteile der einzelnen Produkte diskutieren und meine Erfahrung im Einsatz beitragen.
Der AC Lite unterstützt beide Frequenzbänder (2,4 GHz und 5 GHz), natürlich den neuen 802.11ac-Standard (ist aber auch kompatibel zu älteren WLAN-Standards 802.11a/b/g/n/ac), liefert mit 2×2 MIMO im 5 GHz-Band bis zu 867 MBit/s zu den Clients und ist dank 24 V passive PoE mit meinem bestehenden System kompatibel. Im 2,4 GHz Band schafft er 300 MBit/s (802.11n).
Das Gerät ist preisgünstig und kann einerseits als eigenständiges Gerät betrieben werden (Konfiguration über Android App) oder wird in das Unifi-System integriert: damit wird der AP von einem Unifi Controller (zB. Ubiquiti Cloud Key, läuft aber auch zB. auf einem Raspberry oder über eine App im Synology NAS) zentral konfiguriert und gemonitored. Das Anlegen oder Ändern einer SSID in einer Umgebung mit vielen Access Points ist somit sehr bequem zu bewerkstelligen. Je AP und Frequenz werden übrigens 4 SSIDs unterstützt.
Dieser Access Point hat für mich das beste Preis-/Leistungsverhältnis. Er erfüllt alle meine Anforderungen. Ich habe damit auch bereits mehr als 30 WLAN-Geräte gleichzeitig erfolgreich bedient und bisher keine Kapazitätsgrenzen kennengelernt.
Auch beim Roaming mit anderen Unifi AC APs gibt es keine Probleme. Ich verwende dazu kein ZH (Zero Handoff, dabei unterstützen die Access Points den Roaming-Vorgang) und es geht trotzdem wunderbar. Ohne ZH kann jeder AP eine anderen Funkkanal nutzen und stört bzw. überlappt nicht mit den anderen APs.
Unifi UAP AC Pro
Der AC Pro Access Point ist dem LITE sehr ähnlich, unterstützt jedoch 3×3 MIMO, wodurch er 1.300 MBit/s (1,3 GBit/s!) zu den Endgeräten verspricht und wird durch PoE (802.3af oder 802.3at) versorgt. Eine Versorgung durch 24 V PoE ist nicht möglich.
Hinsichtlich Management unterstützt der AP Pro alle oben genannten Methoden.
Unifi UAP AC LR
Die Long Range-Version beinhaltet eine Antenne mit höherem Gewinn. Das ist ermöglicht in vielen Ländern eine höhere Reichweite beim Senden. Da in Österreich (und wie ich glaube in der ganzen EU) die Sendeleistung nach EIRP beschränkt ist, darf der AC LR bei korrekter Ländereinstellung bei uns nicht mit voller Leistung senden.
Die „bessere“ Antenne wirkt aber auch empfangsseitig. Und das ist aus meiner Sicht die große Stärke dieses Modells. In schwierigen Umgebungen (zB. Gebäuden mit dicken Mauern) habe ich damit erheblich bessere Ergebnisse erzielt (Bandbreite und Stabilität). Ich bin teilweise ganz erstaunt gewesen, wie zuverlässig der AP LR über große Entfernungen in Gebäuden noch problemlos funktioniert hat.
Meine Erfahrungen mit diesen Geräten sind jeweils top. Sie funktionieren zuverlässig, haben höchste Kompatibilität (es hat nie Probleme gegeben, dass sich jemand nicht verbinden konnte) und das Management über den Unifi Controller, den ich unter Ubuntu Linux laufen habe, funktioniert super!
Näheres zu meiner Konfiguration mit dem Unifi Controller habe ich in einem älteren Beitrag beschrieben. Die Produkte dort sind mittlerweile veraltert, aber die Funktionen des Controllers sind weiterhin gültig.
Ich betreibe mit den Access Points einen Funkfeuer-Hotspot und sehe eigentlich jeden Tag einzelne User, die den Dienst nutzen. Für den Hotspot wird auch eine Landing Page vorgeschaltet und dann ein Redirect auf www.funkfeuer.at erzwungen. Alles funktioniert seit Monaten einwandfrei. (Das System schon über einem Jahr, aber die UAP ACs habe ich erst ein halbes Jahr damit im Einsatz).
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:
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.
