Details

Geschrieben von Ralf, DH3WR

Veröffentlicht: 24. September 2014

Zugriffe: 107487

Einleitung

Schon seit einigen Monaten hat sich Ralf DH3WR mit der vom Internet unabhängigen Bereitstellung von Kartenmaterial im Hamnet beschäftigt. Durch die Verfügbarkeit von neuer, leistungsfähiger Server-Hardware in Aachen kann nun dieser Dienst im zuverlässigen Produktionsbetrieb angeboten werden. Basierend auf switch2osm.org und einer Ubuntu 14.04 LTS Installation wurde ein Open Street Map Karten Server aufgesetzt.

Details zur Funktion des Kachelservers

Karten bestehen aus Teil-Bildern, die als Kacheln bezeichnet werden. Diese Kacheln werden aus dem OSM Datenbestand erzeugt. Dieser ist in einer ca. 700 GB (!) großen Datenbank auf Basis von postgresql auf einem SSD-LVM von 1,5 TB Größe gespeichert. Regemäßige Updates dieser Datenbank garantieren aktuelle Karten. Aus dieser Datenbank werden die für die jeweilige Kachel benötigten Daten ausgewählt und damit die Kachel "gemalt". Diese Daten stehen unter http://2com.db0sda.ampr.org/osm zur Verfügung. Es sind bis zur Zoomstufe 14 alle Kacheln der Welt bereits auf Vorrat erzeugt worden. Noch nicht vorhandene Kacheln werden bei Bedarf gemalt (gerendert). Damit dies in einer vertretbaren Zeit abgeschlossen ist, sind sowohl die SSDs als auch schnelle CPUs notwendig.

Struktur des verteilen Caching Clusters

Im Hamnet wird die Ladezeit einer Karte durch zwei Faktoren bestimmt:

1. Geschwindigkeit der Verbindung vom User zum Kachel-Server
2. Geschwindigkeit der Bereitstellung der Daten durch den Kachel-Server

Beide Punkte können durch einen verteilten Caching Cluster verbessert werden. Durch Zwischenspeicher-Server (caching server) wird die Last des zentralen Kachel-Server sigifikant vermindert. Viele Kacheln ändern sich nur selten und müssen daher nicht jedes Mal beim zentralen Server angefragt werden. Wenn sich dieses Konzept weiter im Hamnet verbreitet, kann durch dynamische Anpassung der Anforderungsadresse der Kacheln auch ein zum jeweiligen Nutzer nächster caching server verwendet werden. Dies steigert gleichzeitig die Reaktionszeit und senkt den Datenverkehr auf den Backbone-Linkstrecken. Als caching server wird die Software Apache Traffic Server. Dieser wird u.a. bei der Suchmaschine Yahoo! eingesetzt, wo er täglich 400 TB Daten als Lastverteiler bewegt. Damit ist diese Software als erprobt einzustufen. Das folgende Bild zeigt den aktuellen Stand des Caching Clusters im Hamnet.

Dienste und Webseiten die OSM im Hamnet nutzen

Es gibt mehrere Dienste, die Open Street Map im Hamnet benutzen.

karten.db0sda.ampr.org (Link)

Einer der zentralen Caching Server stellt eine interaktive OSM Karte bereit. Auf dieser kann ebenfalls mit einfach Werkzeugen gemalt werden. Dazu zählt das festlegen von Punkt, Linien und Flächen.

aprs.db0sda.ampr.org (Link)

Eine Kartendarstellung von APRS Postionen von Amateurfunkstationen. Diese Seite wurden von Sven Wittig dem Original aprs.fi nachempfunden. Die Positionsdatenbank auf Basis von MySQL befindet sich ebenfalls im Hamnet und wird auch über dieses mit Daten gefüllt. Den Code dazu haben Claudia Kraft und Ralf Wilke geschrieben. Insgesamt kann damit eine Echtzeitdarstellung von Positionsdaten ohne Internet-Zugang erreicht werden. Dies kann im Katastrophenfall für THW oder BOS interessant sein.

srv.db0ii.ampr.org/aprs (Link)

Diese Installtion stellt einen Klon mit Standort Mönchengladbach von aprs.db0sda.ampr.org dar. Sinn ist es, im Raum Mönchengladabach / Düsseldort einen eigenen Server für die APRS Kartendarstellung zu haben.

Aufruf zur Beteiligung am verteilten Caching Cluster

Damit diese Idee und Funktionalität im Hamnet weiter verbreitet werden, rufen wir zum Mitmachen auf. Jeder Hamnet-Knoten, der einen Linux-Server und min. 1 GB Festplattenspeicher zur Verfügung hat, kann einfach ebenfalls einen Caching Server und auf Wunsch auch eine eigene Kartendarstellung auf seiner Webseite betreiben. Die Installation ist einfach und für unerfahrende Sysops in weniger als 20 Minuten durchzuführen.

Anleitung zum Aufsetzen eines Open Street Map Proxys

1. Paket installieren

Für debian basierte Systeme:

apt-get install trafficserver

Für openSuSE: Anleitung zum selbst kompilieren

2. Konfigurieren /etc/trafficserver/storage.config

/var/cache/trafficserver 2560M

Die Größe und der Speicherort können natürlich angepasst werden.

3. Konfigurieren /etc/trafficserver/remap.config (Beispiel)

Diese Datei verbindet die Proxy-URL mit der Quell-URL. Der OSM Proxy sollte vorteilhafterweise auf Port 80 laufen. Wenn auf dem Rechner, auf dem der Proxy-Server laufen soll, auch ein Webserver auf Port 80 läuft, muss man einen Trick anwenden. Dazu stellt man in der Webserver-Config den Webserver von Port 80 auf Port 81 um. Der Traffic Server leitet dann die Anfragen, die sich nicht auf OSM beziehen, auf diesen Port um. Anfragen an xxx.ampr.org/osm werden an den Quell-Kachelserver bei DB0SDA c2com.db0sda.ampr.org weitergeleitet. Die Reihenfolge der Einträge in dieser Datei ist wichtig. Daher zuerst den "/osm" Fall abfangen und dann den allgemeinen "/" Fall. Der Ausdruck "example.db0aaa.ampr.org" ist durch den eigenen Domainnamen zu ersetzen, auf dem der Server laufen soll.

map http://example.db0aaa.ampr.org/osm/ http://c2com.db0sda.ampr.org/osm/
reverse_map http://c2com.db0sda.ampr.org/osm http://example.db0aaa.ampr.org/osm/

map http://example.db0aaa.ampr.org/ http://example.db0aaa.ampr.org:81/
reverse_map http://example.db0aaa.ampr.org:81/ http://example.db0aaa.ampr.org/

4. Konfiguration /etc/trafficserver/records.config

Hier muss der Port auf Port 80 angepasst werden.

CONFIG proxy.config.http.server_ports STRING 80

Das müssten alle notwendigen Änderungen gewesen sein. Wenn nicht, bitte bei uns kurz melden, dann berichtigen wir diese Seite.

5. (optional) Cache auf Vorat befüllen

Wir haben leider keine Möglichkeit gefunden, den Cache mit einem speziellen Kommando zu befüllen. Daher wurde ein Perl-Skript osmcache.pl geschrieben, welches dieses mittels http-Anfragen tut.

#!/usr/bin/perl
use LWP::Simple;$num_args = $#ARGV + 1;
if ($num_args != 3) {
  print "\nUsage: osmchache.pl minzoom maxzoom FQDN\n";
  exit;
}
$minzoom = $ARGV[0];
$maxzoom = $ARGV[1];


for(my $zoom = $minzoom; $zoom <= $maxzoom; $zoom++) {
  for(my $x = 0; $x <= ((4**($zoom/2))-1); $x++) {
    for(my $y = 0; $y <= ((4**($zoom/2))-1); $y++) {
      $url = "http://$ARGV[2]/osm/$zoom/$x/$y.png\n";
      get($url);
    }
  }
  print ("Zoom: $zoom fertig.\n");
}


Beispielaufruf:

sudo -u xxx nice -n 19 /usr/local/bin/osmcache.pl 1 9 proxy1.db0sda.ampr.org > /dev/null &

6. Mitteilung an RWTH AFU, dass neuer Proxy besteht

Nach erfolgreicher Installation würden wir uns über eine kurze Nachricht freuen, damit wir den neuen Proxy in den Load-Balance-Verbund aufnehmen können.

Details

Geschrieben von Ralf, DH3WR

Veröffentlicht: 18. September 2014

Zugriffe: 92452

Als zentrale Ablage und zum Verteilen von Dateien wurde an der Amateurfunkstation der RWTH Aachen ein Cloud-Server installiert. Basierend auf dem System OwnCloud wurde einer der Server mit diesem System ausgestattet. Der Zugriff geschieht in erster Linie über das Web-Interface; es gibt aber auch Hilfsprogramm für Desktop-PCs und mobile Endgeräte auf Android und iOS Basis. Zur Zeit stehen ca 3 TB Speicherplatz zur Verfügung. Wer einen Benutzer-Zugang haben möchte, schreibe uns einfach eine Email. Der Zugriff ist zunächst nur aus dem Hamnet möglich, evtl. werden wir auch das Internet erlauben. Der Speicherplatz pro Benutzer ist nominell 10 GB, kann aber auf Anfrage und Begründung erhöht werden.

Zugriff auf die AfuCloud über http://db0sda.ampr.org/owncloud.

Bildschirmfoto als Appetitanreger

Details

Geschrieben von Ralf, DH3WR

Veröffentlicht: 15. September 2014

Zugriffe: 97923

RasPager und RasPager Digi

Für Bezugsquellen hier klicken

Einleitung

Die Abdeckung durch Funkrufsender in Deutschland ist nach einem Aufschwung im letzten Jahrzehnt immer noch stark lückenhaft. Grund dafür ist unter anderem die mangelhafte Verfügbarkeit an Sendern, welche das POCSAG Signal ausstrahlen können. Auf der UKW-Tagung 2012 wurde ein Funkrufsender basierend auf Software Defined Radio vorgestellt [1]. Dieser ermöglichte mittels eines Java-Programms, eines Computers mit Soundkarte und eines Funkgerätes einen Funkrufsender aufzubauen. Von dieser Art der Sender wurden mittlerweile einige an verschiedenen Standorten in der Republik in Betrieb genommen. Dennoch ist weiterhin ein 9k6-fähiges Funkgerät sowie Interface-Kabel von Nöten. Der in diesem Paper beschrieben Funkrufsender beinhaltet bereits den Sender sowie einen Raspberry Pi, mit dessen Hilfe die Einbindung des Senders über Hamnet oder Internet in das Verwaltungsnetz möglich ist. Es wird eine Variante für In-House-Betrieb mit kleiner Leistung sowie eine Funkturm-taugliche Lösung im professionellen 19 Zoll Gehäuse vorgestellt. Diese Entwicklung entstand im Rahmen einer Diplomarbeit von Christian Jansen unter Betreuung von Ralf Wilke am Institut für Hochfrequenztechnik der RWTH Aachen Universtiy.

Übersicht des Aufbaus

Der Funkrufsender besteht aus drei Teilen. Ein Raspberry Pi Computer sorgt für die Kommunikation über TCP/IP mit dem Funkrufmaster. Dieser ist ein zentraler Server, welcher die Benutzereingaben zum Versenden von Funkrufen entgegennimmt, ein Warteschlagensystem betreibt und die Funkrufe an alle weiteren Master des Funkruf-Netzes verteilt. Ebenso versorgt der Funkrufmaster die Sender mit Informationen zu den gewünschten Aussendungen. Die hier vorgestellte Lösung verhält sich auf der Netzwerk-Seite wie die etablierten Funkruf-Sender auf Basis des RPC von Adacom. Damit ist diese Software kompatibel und in der bestehenden Server-Infrastruktur lauffähig. Als Sender wird ein ADF7012 verwendet. Dieser stellt einen frequenzvariablen Sender da, der nur geringe externe Beschaltung zur Funktion benötigt. Abbildung 1 zeigt den schematischen Aufbau.

Abbildung 1: Übersicht des Aufbaus

In dieser Variante liefert der Sender ca. 10 mW Ausgangsleistung auf der Funkruf-Frequenz 439,9875 MHz. In Verbindung mit einer kleinen Ansteck-Antenne reicht damit die Ausleuchtung für den Funkamateur zu Hause im beaufsichtigen Betrieb. Es kann also ein Funkruf-Hotspot mit dieser Konfiguration aufgebaut werden. In der Variante für den Einsatz auf Funktürmen folgt dem Sende-Chip eine Endstufe, welche mit aktiver Kühlung die Ausgangsleistung auf nominell 10 Watt erhöht. Bei Bedarf kann diese noch weiter angehoben werden, etwa um Verluste in den Speiseleitungen der Antenne auszugleichen. Hier ist die behördlich genehmigte EIRP nicht zu überschreiten.

Beschreibung des Senders

Ursprünglich war angedacht, den ADF7012 direkt mit der GPIO-Leiste des Raspberry Pi zu verbinden. Über diese Schnittstelle würde sowohl die Konfiguration des Sende-Chips, als auch die zu sendenden Daten übertragen werden. Bei der Entwicklung hat sich allerdings herausgestellt, dass der Raspberry Pi nicht dazu in der Lage ist, die Sendedaten in einem konstanten Takt über einen GPIO-Anschluss auszugeben. Das Betriebssystem belegt in unvorhersehbaren Abständen die CPU und erzeugt dadurch Aussetzer im Takt der zu sendenden Daten. Zur Lösung wurde ein ATMega-8 Mikrocontroller zwischen Raspberry Pi und ADF7012 implementiert, welcher als Buffer nach dem FIFO Prinzip arbeitet. Er nimmt die Sendedaten vom Raspberry Pi asynchron entgegen und schreibt sie in einen Ringbuffer. Mittels seines eigenen Taktgenerators werden die Daten dann mit einer konstanten Rate an den ADF7012 geschickt und ausgesendet. Abbildung 2 zeigt den Aufbau grafisch.

Abbildung 2: Blockschaltbild des RasPagers

Schaltung des Senders RasPager

Die äußere Beschaltung des ADF7012 ist recht einfach. Im Wesentlichen muss das PLL-Filter und das Ausgangsfilter des Senders dimensioniert und bestückt werden. Das Datenblatt des Chips gibt bereits Bauteilwerte für 433 MHz vor, welche an die Sendefrequenz von 439,9875 MHz angepasst wurden. Mittels einer Software des Chip-Herstellers kann das PLL-Filter entsprechen den Anforderungen des POCSAG Protokolls ausgelegt werden. Das Ausgangsfilter dient zur Unterdrückung von Oberwellen und zur Anpassung des Ausgangswiderstandes des Senders an die 50 Ohm Koplanar-Leitung. Diese endet auf einem SMA Stecker, an den eine Aufsteckantenne oder die optionale Endstufe angeschlossen werden kann.

Die Platine wurde als Aufsteck-Variante für den Raspberry Pi entworfen. Alle Datenleitungen und die Stromversorgung werden über die GPIO-Leiste des Computers im Scheckkartenformat realisiert. Bei Verwendung eines Gehäuses ist eine Öffnung für die SMA Buchse zu schaffen. Abbildung 3 zeigt ein Foto der bestückten Platinen und Abbildung 4 das Fertiggerät RasPager.

Abbildung 3: Foto der bestückten Platine	Abbildung 4: Fertiggerät RasPager

 

Beschreibung der Software

Die alte Java-Software ist bereits überholt. Wir empfehlen die Verwendung von Unipager für die Anbindung an das DAPNET.

Für den ATMega gibt es auch eine neue Software. Es war in der Original-Version in Bug enthalten, der dafür sorgt, dass der Sender 1202 Baud statt 1200 Baud lieferte. Dieses ist nun behoben. Wer updaten möchte, kann sich https://github.com/dh3wr/RasPagerDigi/tree/master/software/AVR%20FIFO anschauen.

Variante für den Einsatz am Funkturm

Für den Einsatz als automatisch arbeitende Amateurfunkstelle werden meist Ausgangsleistungen im Bereich von 10 Watt benötigt. Daher wurde ebenfalls die Variante RasPager Digi entwickelt. Hierbei handelt es sich um einen professionellen 19 Zoll Einschub mit 1 Höheneinheit. Hier ist neben dem RasPager ein Leistungsverstärker-Modul eingebaut, welches die Ausgangsleistung des RasPagers anhebt. Die Kühlung des Moduls erfolgt aktiv über zwei Lüfter. Diese blasen einen Luftstrom von vorne nach hinten durch das Gehäuse an den Kühlrippen vorbei. Dadurch wird auch bei Dauerbetrieb und hohen Temperaturen in einem Geräteschrank die Betriebssicherheit nicht gefährdet. Abbildung 6 zeigt ein Foto des geöffneten Gehäuses. Die nominelle Betriebsspannung ist 12 Volt.

Abbildung 6: Fotos des RasPager Digi in 19 Zoll Technik

Evaluierung

Beim Betrieb von Sendern müssen die gesetzlichen Bestimmungen und Grenzwerte eingehalten werden. Daher wurde das Ausgangsspektrum sowohl des Tischsenders RasPager als auch der Variante für den Einsatz als Basisstation vermessen. Abbildung 7 und 8 zeigen die gemessenen Ausgangsspektren, welche die Anforderungen erfüllen.

Abbildung 7: Ausgangsspektrum RasPager	Abbildung 8: Ausgangsspektrum RasPager Digi

Die thermische Untersuchung zeigt, dass das Gerät für den unbeaufsichtigten Betrieb geeignet ist. Nach 60 Minuten Dauersendung mit Nennleistung 10 Watt hat sich der Kühlkörper bei 25 °C Raumtemperatur auf nur ca. 38 °C erwärmt, wie die Wärmebildkamera in zeigt.

 

Abbildung 9: Temperaturverteilung auf dem Endstufenmodul nach 60 Minuten Dauersendung

Zusammenfassung

Als verfügbarer Ersatz für die umgebauten kommerziellen Funkrufsender wurde ein Komplettgerät neu entworfen. Auf Basis eines Sender-ICs und eines Kleincomputers vom Typ Raspberry Pi wurde ein Tischsender mit 10 mW Ausgangsleistung vorgestellt. Die Stromversorgung des Senders erfolgt über den Raspberry Pi, ebenso die Konfiguration und die Datenübermittlung.

Für den Betrieb als automatisch arbeitende Station mit großer Reichweite wurde eine Variante mit nominell 10  Watt Ausgangsleistung vorgestellt, die in einem 19 Zoll Gehäuse mit 1 HE ihren Platz findet. Eine Zwangskühlung sorgt für Betriebssicherheit.

 

Bezugsquellen

Der RasPager wird als Bausatz von CJ-Elektronik vertrieben. Ein Teil des Erlöses dieses Bausatzes geht als Spende an den Verein zur Förderung der Hochfrequenztechnik in Aachen e.V. und wird für Projekte der Amateurfunkgruppe der RWTH Aachen verwendet werden. Damit wird der Amateurfunk in und um Aachen unmittelbar gefördert.

 

Literatur und Quellen

[1]       Ralf Wilke und Michael Delissen, „Funkruf-Sender basierend auf Software Defined Radio“, 57. Weinheimer UKW Tagung, Weinheim, 14.-16.9.2012

[2]       Christian Jansen, „Modularer Funkruf-Sender basierend auf Raspberry Pi“, Diplomarbeit am Institut für Hochfrequenztechnik der RWTH Aachen, 4.8.2014

[3]       Amateurfunkgruppe der RWTH Aachen, Homepage https://www.afu.rwth-aachen.de,
im Hamnet http://db0sda.ampr.org