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.
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.
