BlueDV und der DVMEGA unter Windows

Inzwischen ist die BlueDV-App von David – PA7LIM schon richtig gut weitergekommen, so dass ich an dieser Stelle einmal kurz auf die App eingehen will:

Nicht nur, dass die Bedienoberfläche aufgeräumt und ohne unnötig verwirrende Inhalte daher kommt, die Software funktioniert mit dem DVMEGA tadellos! Hier hat David ganze Arbeit geleistet und merkt dem Projekt die Erfahrung in der Programmierung schon an.

Die Software unterstützt den parallelen Betrieb in allen drei unterstützten Betriebsarten DMR, C4FM (YSF oder FCS-Reflectoren) und DSTAR. Natürlich ist auf der HF-Seite immer nur eine Betriebsart möglich, aber man hat in der Benutzeroberfläche immer den Überblick, was gerade auf allen verbundenen Reflektoren so geschieht – ein ganz klarer Trupf gegenüber vergleichbarer Software für andere Hotspots.

Zusammen mit dem DVMEGA hat man mit dieser Software, die auch unter Android eine Schwestern-Entwicklung laufen hat, an der parallel zu dieser App auch immer wieder gearbeitet wird, einen Hotspot für den heimischen Schreibtisch, die unter Windows ihren Vergleich sucht!

 

Erweiterungen/Modifikationen an pymultimonaprs

Wer mein Blog verfolgt, der weiß, dass ich immer mal wieder ein APRS-IGate betreibe, sofern mir nicht die Hardware einen Strich durch die Rechnung macht. Kern des ganzen bildet ein Python-Script bzw. Programm, welches unter https://github.com/asdil12/pymultimonaprs herunterzuladen und entsprechend zu installieren ist. Zusammen mit dem Programm „multimon-ng“ realisiert sich ein IGate, welches die APRS-Daten, die auf der Frequenz 144.800 MHz ausgesendet werden in das APRS-IS überträgt.

Im Original werden hier sämtliche Datenpakete, die empfangen und sauber decodiert werden, ins Internet übertragen, was bedeutet, dass natürlich diverse doppelte Datenpakete auf den Servern des APRS-IS auflaufen, die dort mittels komplizierter Algorithmen schlussendlich dann doch verworfen werden. Ebenso werden als RFONLY oder NOGATE gekennzeichnete Datenpakete an das APRS-IS übermittelt, die dort ebenfalls verworfen werden.

Da ich an meinem Standort zum einen sämtlichen Datenverkehr des naheliegenden WIDE-Repeaters empfange, der seinerseits ebenfalls als IGate läuft, auf der anderen Seite aber auch Datenpakete auffische, die dieser offensichtlich nicht hört, saß ich ein wenig in er Zwickmühle. Wer sich z.B. die Status-Seite des TIER2-Servers in Karlsruhe anschaut, der stellt fest, dass ich mit der Problematik jedoch nicht alleine bin: Sehr häufig sieht man hier, dass von den empfangenen Paketen der Gates nur ca. 10 bis 25% Uniques sind, alles andere war bereits irgendwie schon einmal als Datenpaket ins Netz gekommen. Diesen Zustand dachte ich mir, muss ich nicht für mein Gate provozieren. Also ging ich hin und erweiterte das Script (was aktuell bei mir im Testbetrieb läuft) um einige Programmzeilen, die nun anhand einer Liste von Rufzeichen, die im Pfad der Datenpakete zu finden sind, festlegt, ob diese ins APRS-IS übertragen werden oder nicht. Also konkret ist das jetzt als Blacklist implementiert und enthält neben den Begriffen „NOGATE“, „RFONLY“, „TCPIP*“ die APRS-Server „DB0VKL-10*“, „DB0MYK*“, „DB0XIT*“ (aktueller Stand von heute morgen), da diese mir als IGates bekannt sind und Datenpakete, die per Funk zu mir gelangen und von diesen Systemen bereits relayed wurden, nicht mehr übertragen werden brauchen.

Durch diese Erweiterung des Scripts, konnte ich die Effizienz meines IGates (und die damit verbundene Datenmenge, die nicht mehr an das APRS-IS übertragen wird) steigern, da nun zu 2/3 nur noch Pakete übertragen werden, die unique sind. das übrige Drittel besteht (leider) noch aus Duplikaten, die ich noch detektieren muss. Hier lässt sich sicherlich noch durch die Aufnahme des ein oder anderen Digipeaters in die Blacklist, der ebenfalls schon als IGate fungiert, die Effizienz weiter steigern.

ADS-B mit einem DVB-T-Stick

Seit zwei Tagen experimentiere ich mit meinem USB-DVB-T-Stick herum und lausche den ADS-B-Baken der Flugzeuge, die sich hier so im saarländischen Luftraum befinden. Dass hierbei nicht nur Signale aus dem Saarland, sondern teilweise unerwartet weit über die Landesgrenzen hinaus den Weg zu meiner nun doch absolut nicht unbedingt auf den Empfang von solchen Signalen ausgelegte Antenne auf der Fensterbank (eine ca. 30 cm lange  Gummiwendel-Antenne für 2m/70cm) fanden, finde ich sehr interessant zu beobachten. Hier mal noch ein Screenshot von der von mir verwendeten Software adsbSCOPE, welche ich zusammen mit adsb# betreibe, um die Funksignale zu visualisieren.

Screenshot adsbSCOPE
Screenshot adsbSCOPE

Das eingezeichnete Gebiet zeigt das Areal, aus dem die empfangenen Signale stammen. Mein Empfangsstandort befindet sich übrigens in der Kartenmitte, dort wo die grünen Linien in einem roten Fadenkreuz münden. Bemerkenswert aber erklärbar ist eine sehr starke Nord-Verschiebung der Signale: Die Antenne steht am Bürofenster, welches eben in nördlicher Richtung liegt. Es wäre, wenn man ernsthaft das ganze betreiben möchte, zu überlegen, eine entsprechend auf 1090 MHz resonante Rundstrahlantenne oder Discone-Antenne im genannten Bereich an die frische Luft zu bringen, um eben auch sicher zu stellen, dass rundherum die Signale auch empfangen werden.

Owncloud auf dem Raspberry Pi

Diejenigen, die mein Blog mehr oder weniger regelmäßig besuchen oder auch den persönlichen Kontakt zu mir pflegen wissen, dass ich im Besitz mehrerer Raspberry Pi-Rechner bin. von diesen vielen (drei an der Zahl bisher) betreibe ich einen als Home-Server im Keller, direkt am Router angeschlossen.

Auf diesem Home-Server habe ich jetzt seit wenigen Wochen die Software Owncloud installiert, um darüber z.B. Dateien, Kontakte und Termine mit verschiedenen Endgeräten wie Laptop, PC, Handy, Tablet, … zu synchronisieren. Im Grunde kann ich mich trotz der doch leistungsschwachen Hardware, die so ein Raspberry Pi darstellt, nicht beschweren, was die Verarbeitungsgeschwindigkeit der Anfragen angeht.

Als Basis nutze ich den lighttpd als Webserver, der mit einigen Tuning-Einstellungen und einem PHP-Accelerator die Sache zu stemmen weiß.

Die Zugriffszeiten liegen beim Browsing innerhalb des Webinterface (z.B. beim Verzeichniswechsel in der Datei-Cloud) bei ca. 1-3 Sekunden, was denke ich durchaus tragbar ist. Die Schauergeschichten, die man im Web so lesen kann, dass man mit Owncloud auf einem Raspberry Pi nicht arbeiten kann, kann ich also absolut nicht bestätigen. Vielleicht hat sich hier im Laufe der Zeit bei der Software selbst ja auch einiges getan. Die aktuelle Version 7.0.2.1 jedenfalls läuft wie die Katz‘!

Ich sollte noch erwähnen, dass ich zusätzlich den Lighttpd mit SSL-Zertifikat betreibe, also jede Anfrage automatisch auf eine SSL-Verbindung umgebogen wird und damit eine verschlüsselte Dateiübertragung stattfindet. Auch eine Sache, die laut Berichten im Web mit dem Raspberry Pi angeblich grausig langsam laufen würde, was ich wiederum auch widerlegen muss!

Hier noch die lighttpd.conf, falls sich jemand für die Detailkonfiguration des Webservers interessiert:

server.modules = (
„mod_access“,
„mod_accesslog“,
„mod_alias“,
„mod_compress“,
„mod_fastcgi“,
„mod_redirect“,
„mod_rewrite“,
)

server.document-root = „/var/www“
server.upload-dirs = ( „/var/cache/lighttpd/uploads“ )
server.errorlog = „/var/log/lighttpd/error.log“
server.pid-file = „/var/run/lighttpd.pid“
server.username = „www-data“
server.groupname = „www-data“
server.port = 80

accesslog.filename = „/var/log/lighttpd/access.log“
index-file.names = ( „index.php“, „index.html“, „index.lighttpd.html“ )
url.access-deny = ( „~“, „.inc“ )
static-file.exclude-extensions = ( „.php“, „.pl“, „.fcgi“ )

# compression settings for gzip

compress.cache-dir = „/var/cache/lighttpd/compress/“
compress.filetype = („text/xml“,“application/x-javascript“, , „application/javascript“, „text/javascript“, „text/x-js“, „text/css“, „text/html“, „text/plain“, „image/png“, „image/gif“, „image/jpg“, „image/svg+xml“, „application/xml“)

fastcgi.server = ( „.php“ => ((
„bin-path“ => „/usr/bin/php5-cgi“,
„socket“ => „/tmp/php.socket“
)))

# default listening port for IPv6 falls back to the IPv4 port
include_shell „/usr/share/lighttpd/use-ipv6.pl “ + server.port
include_shell „/usr/share/lighttpd/create-mime.assign.pl“
include_shell „/usr/share/lighttpd/include-conf-enabled.pl“
$HTTP[„scheme“] == „http“ {
# capture vhost name with regex conditiona -> %0 in redirect pattern
# must be the most inner block to the redirect rule
$HTTP[„host“] =~ „.*“ {
url.redirect = („.*“ => „https://%0$0“)
}
}

$HTTP[„url“] =~ „^/owncloud/data/“ {
url.access-deny = („“)
}

$HTTP[„url“] =~ „^/owncloud($|/)“ {
dir-listing.activate = „disable“
}

Zusätzlich aktiviert sind die Konfigurationsdateien für SSL und fastcgi-php mit entsprechenden Detailanpassungen:

Hier die SSL-Konfiguration:

# /usr/share/doc/lighttpd/ssl.txt

$SERVER[„socket“] == „0.0.0.0:443“ {
ssl.engine = „enable“

# Contains certificate + key
ssl.pemfile = „/etc/lighttpd/ssl.pem“

# Contains ca-certificate and intermediate
ssl.ca-file = „/etc/lighttpd/chain.pem“

ssl.cipher-list = „ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM“
ssl.honor-cipher-order = „enable“
}

Und hier die Konfiguration für Fast-CGI:

# -*- depends: fastcgi -*-
# /usr/share/doc/lighttpd/fastcgi.txt.gz
# http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#mod_fastcgi-fastcgi

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server += ( „.php“ =>
((
„bin-path“ => „/usr/bin/php-cgi“,
„socket“ => „/var/run/lighttpd/php.socket“,
„max-procs“ => 1,
„allow-x-sendfile“ => „enable“,
„bin-environment“ => (
„PHP_FCGI_CHILDREN“ => „4“,
„PHP_FCGI_MAX_REQUESTS“ => „10000“,
„MOD_X_SENDFILE2_ENABLED“ => „1“
),
„bin-copy-environment“ => (
„PATH“, „SHELL“, „USER“
),
„broken-scriptfilename“ => „enable“
))
)

Bei Fragen einfach Fragen 🙂

DAB-Player für Windows 7 (und später)

Unter Funkamateuren sind die DVB-T-Sticks mit Realtek-Chipsatz mittlerweile ja recht gut verbreitet. Jetzt ist es auf Dauer sicherlich auch mal ganz interessant, diese Sticks nicht nur als SDR zu nutzen (z.B. mit SDR# oder HDSDR) sondern vielleicht auch mal „ernsthaft“ als DAB(+)-Empfänger! Das geht mit diesen Sticks nämlich auch einwandfrei.

Das Einzige, was man dazu benötigt, ist ein Stück Software, welches derzeit aktuell kostenlos im Internet zu finden gibt. Am einfachsten und zuverlässigsten unter folgender URL: http://ukwtv.de/cms/downloads-aside/281-dab-player-von-andreas-gsinn.html.

Ich selbst nutze dieses Programm seit mehreren Monaten, um im Büro am PC DAB-Sender zu lauschen. Bisher kann ich mich über die Funktionsweise und Empfangsqualität nicht beschweren.

Schön sind solche „Nebensachen“ wie die Journaline-Darstellung, Slideshow-Anzeige und die Ausgabe verschiedener technischer Informationen zum aktuellen Stream – was sicherlich den technisch interessierten Zuhörern ganz gut gefallen dürfte, mal etwas mehr über die Sender zu erfahren, als man so aus dem schnöden Display lesen kann.

Schaut es euch einfach mal an!

 

Am 23.03.2014 geht es auf die SAFA

In knapp zwei Wochen ist es wieder so weit: Die SAFA in Dillingen/Saar öffnet wieder ihre Pforten. Diesmal bin auch ich mit einem kleinen Stand dabei.

Was ich zeigen werde? Nun – ich werde ein kleines Demo-System vorstellen, welches die Software SvxLink auf einem Raspberry Pi zeigt und hier ein vollduplex-fähiges Relais mit Echolinkanbindung, Voice-Mailbox und METAR (Flugwetter)-Information anbietet!

SvxLink ist nichts neues, wenn auch im Saarland und Umgebung bei den Relaisfunkstellen noch nicht in Verwendung. Vielleicht kann ich mit meinem Demo-Aufbau die Relaisbetreiber, die ihre in die Jahre gekommenen Relaisfunkstellen evtl. ein wenig erneuern möchten, auf den Geschmack bringen, sich diesem Projekt vielleicht zuzuwenden?