Wetterstation mit WeeWX und APRS.fi Anbindung

Schon seit längerem Betreibe ich zu Hause eine Wetterstation WX-2013 bzw. WH1080 mit diversen Sensoren. Bereits kurz nach dem Erwerb entschloss ich mich die Daten etwas besser nutzen zu können, im LAN per PC, Smartphone und Tablet. Nach etwas Recherche fand ich die Software WeeWX, welche unter http://www.weewx.com zu bekommen ist. Diese ist auch sehr gut dokumentiert und hat eine große Community.

Die ersten Versuche mit einem Jessie Image auf einem RaspberryPi B schlugen fehl. Erfolgreich wurde ich dann aber mit dem HamServerPi Image, welches auf Debian Wheezy basiert. Mit dem ansehlichen Image „Sofaskin“ (Quelle) wurde eine schöne Seite daraus 

Der RaspberryPi ist dann auch ganz schnell in das HAMNET gewandert, damit auch andere von den Daten profitieren können bzw. ich von extern auch mal darauf zugreifen kann.

Die Wetterstation ist im HAMNET unter folgenden Adressen erreichbar:

Schon bald hatte ich Pläne die Wetterstation auch an APRS.fi zu binden. Dort können die Daten dann einem noch größeren Publikum nützlich sein. Leider wusste ich nicht, wie das funktioniert. Also blieb dieser Wunsch lange unerfüllt.

Im Juni 2018 habe ich dann auch mal ein neues Image aufgesetzt. Grund war, dass wohl nach knapp 2 Jahren die SD-Karte schlapp gemacht hat. Das Dateisystem war defekt. Nachdem ich die Datenbank (weewx.sdb) gesichert habe, habe ich ein neues Image auf Basis von Debian Stretch aufgesetzt, und zwar in der Lite Version. Das Image sollte relativ schlank bleiben und es sollten keine unnötigen Dienste im Hintergrund mitlaufen. Beim HamServerPi liefen trotz nicht-Aktivierung von Haus aus etliche unnötige Dienste im Hintergrund. Ein schlankes Stretch Image mit WeeWX und nginx als Webserver war schnell aufgesetzt. Die Datenbank und Konfigurationsdatei von WeeWX aus dem alten Image konnte ich noch retten und direkt ins neue Image einspielen. Das Ganze hat übrigens locker auf einer 2 GB SD-Karte Platz.

Per Zufall las ich dann wenige Tage später einen Beitrag in Facebook in der HAMNET Gruppe, wo OM Peter DL6MB davon sprach das er WeeWX einsetzt und diesen an APRS anbinden wollte – er brauchte dazu nur ein passendes Gateway aus dem Hamnet. Ein Glücksfall für mich, ich habe mich in die Diskussion gleich mit eingeschmuggelt. Peter und OM Egbert DD9QP konnten auch schnell helfen.

Nach etwas Probieren war es dann auch schnell erledigt.

Folgende Zeilen müssen in der /etc/weewx/weewx.conf editiert werden:

[[CWOP]]
enable = true
station = RUFZEICHEN [Hier kommt das Rufzeichen rein, mit dem die Station in APRS.fi erscheinen soll]
passcode = 12345 [Für AFu Stationen notwendig: Passcode kann z.B. hier generiert werden https://apps.magicbug.co.uk/passcode/ ]
server_list = aprsc.db0gw.ampr.org:14580, db0res.ampr.org:14580, rotate.aprs.net:14580, rotate.aprs2.net:14580, cwop.aprs.net:14580, cwop.aprs.net:23
log_success = true
log_failure = true

Achtung, Zeilenumbrüche beachten! Der Text wird umgebrochen in der Webseitendarstellung.

Die Serverangabe hat übrigens Probleme bereitet. Ich hatte zuerst nur aprsc.db0gw.qmpr.org angegeben, das hatte WeeWX sowohl mit als auch ohne Gänsefüßchen nicht korrekt interpretiert und mit der folgenden „lustigen“ Meldung quittiert:

Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'a'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'p'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'r'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 's'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'c'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: '.'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'd'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'b'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: '0'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'g'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'w'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: '.'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'a'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'm'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'p'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'r'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: '.'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'o'; ignored
Jun 19 21:06:03 weewx weewx[759]: restx: CWOP: Bad server address: 'r'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: 'g'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: ':'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: '1'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: '4'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: '5'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: '8'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Bad server address: '0'; ignored
Jun 19 21:06:04 weewx weewx[759]: restx: CWOP: Failed to publish record 2018-06-19 21:06:00 CEST (1529435160): Tried 26 servers 3 times each

Warum auch immer, aber ich habe dann einfach noch ein paar Server hinzugefügt. Seitdem nimmt er es korrekt an.

In der obigen Serverliste sind erst zwei HAMNET APRSC Server gelistet, dahinter nochmal vier Server aus dem Internet als Fallback-Lösung, falls das HAMNET oder die beiden HAMNET Server nicht erreichbar sein sollten.

Die „log_“ Abschnitte dienen dazu, einen Logeintrag in die /var/log/syslog zu schreiben, wenn das Übermitteln der Daten erfolgreich war oder nicht. Diese sind für den eigentlichen Betrieb nicht notwendig, ich habe sie Informationshalber aber mit eingebaut.

Eine gute Dokumentation dieses Abschnitts findet man auch im WeeWX User Guide im Abschnitt [[CWOP]].

Der WeeWX Server kann übrigens mit folgendem Befehl sofort neu gestartet werden, ein Reboot des ganzen PI ist nicht notwendig.

sudo /etc/init.d/weewx restart

Das Endergebnis sieht auf APRS.fi dann so aus:

Motorola GM1200 als Funkrufsender

Eine kleine (Leidens-)Geschichte. Vielleicht hielft sie mal einem anderen weiter 🙂

Von einem befreundeten OM im OV, Alfred DL8NCE, erwarb ich im April 2018 zwei Motorola GM1200 Mobilfunkgeräte. Dazu musste ich lustigerweise erst zum FunkTag nach Kassel fahren und herauszufinden das er diese Geräte hat. Daraus dachte ich, wollte ich mir eventuell mal einen Repeater bauen – rein interessehalber. Aber es kam anders. Das Thema Funkruf (DAPNET) kam auf im OV (Interesse von DB3NF und DL3MRK). In der DAPNET Wiki ist auch ein schöner Beitrag darüber, wie man das schön mit einem RaspberryPi und z.B. einem GM1200 hinbekommt. Also entschloss ich mich das zu realisieren.

Software:

Für DAPNET wird die Software „Unipager“ zur Verfügung gestellt, sie läuft auf (fast) jedem Linux-System, Pakete sind für Debian Distributionen verfügbar. Also auch für den RaspberryPi. Für andere Distributionen gibt es eine Anleitung zum selbst kompilieren. Für die Anbindung eures Funkrufsenders an das DAPNET Backbone müsst ihr diesen noch vorher über die Hampager Webseite registrieren. Hier öffnet man einfach ein Ticket für einen „neuen DAPNET Sender“. Nach wenigen Tagen erhält man dann die Zugangsdaten per E-Mail. Das Rufzeichen und den Authentifizierungs-Key gibt man dann in der Weboberfläche der Unipager Software ein.

Tipp: Für den Anschluss an die Zubehörbuchse des GM1200 benötigt man keinen teuren Motorola Zubehörstecker. Man kann einen handelsüblichen 25-poligen weiblichen SUB-D Stecker benutzen. Man muss allerdings das Metallgehäuse entfernen, so das nur der Kunststoffstecker übrigbleibt. Mindestens aber die Laschen an den Seiten müssen weg, sonst passt er nicht in das „Loch“ im GM1200.

Problem 1:

Meine anfängliche Idee, dies auf einem HAMServerPi mitlaufen zu lassen, musste ich begraben. Denn der basiert auf einem Wheezy Image. Das ist aber leider zu alt, eine Library (libc6) muss mindestens in Version 2.18 oder höher verfügbar sein. Für das Wheezy Image gibt es die aber nur in einer älteren Version. Auch das selbst kompilieren bringt nichts, auch da wird die neue libc6 Version benötigt. Ein Versuch das Wheezy Image mit „dist-upgrade“ zu aktualisieren, funktionierte scheinbar. Unipager liess sich danach auch endlich installieren. Aber einige vorinstallierte Programme auf dem HamServerPi haben beim Upgrade gemeckert. Vermutlich läuft danach nicht alles rund. Unipager liess sich aber dennoch anschließend starten.

Problem 2:

Unipager lief jetzt, allerdings wurde die PTT nicht ausgelöst am GM1200. Es passierte nichts. In der Unipager Oberfläche Stand der Sender angeblich dauerhaft „on Air“. Das ist nicht gut. Irgendwas stimmt vermutlich mit den GPIO Einstellungen nicht. Der Verdacht lag bei den vorinstallieren Programmen auf dem HamServerPi. Dort habe ich zwar in den Configfiles einige GPIO Einstellungen (z.B. für SVXLink, die RepeaterBox etc.) deaktiviert, aber geholfen hat es nichts. Irgendwo in den Untiefen des Systems ist noch ein Fehler. Für mich unauffindbar. Also habe ich mal ein sauberes frisches und aktuelles „Debian Stretch“ System aufgesetzt, und siehe da, die PTT funktioniert auf anhieb. Das HamServerPi Image ist daher nicht ohne Weiteres für den Unipager zu gebrauchen. Schade eigentlich.

Problem 3:

Mit dem frischen System ging der Sender auch auf Sendung! Jippie! Aber zu früh gefreut. Es kommt keine Modulation. Die Verschaltung auf der Platine habe ich anschließend mehrfach geprüft. Sogar meinen Oszi ausgepackt (den ich schon viele Jahre habe aber erst einmal vorher benutzt habe). Als ich testweise einen Yaesu FT-7800 angeschlossen habe, funktionierte es allerdings auf Anhieb einwandfrei. An meiner Platine kann es daher definitiv nicht liegen. Als alles nichts half, suchte ich mir Rat beim Verkäufer der Geräte. Wir schauten uns die Programmierung nochmal an, konnten aber nichts finden. Er gab mir dann seinen Programmier-PC und das Programmierkabel freundlicherweise mit, damit ich weiter probieren kann. Außerdem noch ein weiteres ungeflashtes GM1200, falls ich mal ein anderes Gerät testen möchte. Aber weiter kam ich deswegen auch nicht. Eine Doku im Internet führte mich dann zu OM Dieter DC1NF. Nach einigem Austausch verwies er mich an einen Experten in Berlin (interessanterweise kein Funkamateur). Dieser erklärte sich freundlicherweise bereit mir zu helfen. Schnell stellte sich heraus, dass das umflashen meiner Geräte auf die Gerätesoftware „MC2100“ das Problem war. Der Pin24 für die Sende-NF (AUX TX IN2) ist nämlich nur bei aktiviertem „Datenkanal-Modus“ nutzbar. Und den Modus gibt es nur mit der Original Bündelfunksoftware, nicht aber im MC2100 Modus. Das umflashen wurde ja gemacht, damit man es besser für Amateurfunk einsetzen kann. Leider ist ein zurückflashen in den Ursprungszustand nicht mehr möglich. Weder ist ein Geräteimage verfügbar (vermutlich ein Staatsgeheimnis), noch sind die Gerätedaten vorher gesichert worden. Dies hätte man vor dem flashen machen müssen. Meine zwei schönen Geräte sind daher eine Sackgasse, leider. Doch da war ja dann noch das ungeflashte Gerät was mir Alfred geliehen hat. Wenn ich das passend einstellen könnte, wäre das meine Rettung!

Problem 4:

Doch so einfach ging es auch wieder nicht, warum auch!?! Das ungeflashte Gerät hatte eine zu alte Geräte-Firmware drauf. Um den Datenkanal zu aktivieren, ist mindestens Firmware-Version 0010 erforderlich. Ich hatte nur die 0004.

Also ging ich wieder auf die Suche im Internet und fand in einem Forum einen Beitrag dazu. Ein OM schrieb, dass ihm OM Ralph DK5RAS weiterhelfen konnte. Wie, stand da aber nicht. Also habe ich OM Ralph kontaktiert. Ja er kann mir helfen, aber dazu bräuchte ich zum einen einen echten (alten) MS-DOS PC, und ein paasendes Programmierkabel (RIB) zu flashen. Das Kabel von Alfred konnte ja auch programmieren, super! Der MS-DOS PC – na klar! Ich kann mich doch schwer trennen von altem Zeug. Ich habe daher die alte Kiste rausgekramt. Ein Pentium2 mit 266 MHz. Darin war noch eine alte Festplatte (120 MB!) mit MS-DOS 6.20 und Windows 3.1. Gehörte zwar früher zu einem anderen PC, aber damals war das nicht so schlimm. Da lief die Platte auch problemlos in einem anderen PC. Na dann kann es ja losgehen!

Problem 5:

Wie kriege ich nun das Flash-Programm, das mir DK5RAS über Telegram gesendet hat, auf den alten PC? Der hat nur 3,5″ und 5,25″ Diskettenlaufwerke. Ein alter CD-Brenner war zwar auch noch drin, aber kaputt. Das CD-Fach geht nicht mehr auf. Außerdem war das CD-Laufwerk nicht konfiguriert in der autoexec.bat. Wie war das nochmal…? Und einen Treiber bräuchte ich ja auch. Also umdenken. So kramte ich einen weiteren älteren PC raus, der noch eine IDE-Schnittstelle hat. Ich habe in diesen dritten PC die alte MS-DOS Festplatte eingebaut und so die Flashsoftware draufkopiert. Die Platte anschließend wieder zurück in den DOS-PC. Flash-Software war jetzt drauf! Perfekt. Also RIB und Funkgerät anschließen, los kanns gehen. OM Ralph erklärte mir noch wie man genau vorgeht.

Power-Taste am Funkgerät gedrückt halten und das Flash-Programm starten. Wenn was nicht stimmt, bricht es eh gleich ab, ansonsten läuft es ca. 3 Minuten. Während dieser Zeit muss man den Power-Knopf gedrückt halten. Wenn man ihn loslässt, ist es aus und vorbei. Nein, Spaß beiseite. Den Vorgang kann man beliebig oft wiederholen. Aber ich schaffe das ja gleich beim ersten Mal, gell!? Der erste Durchgang ging natürlich schief (wie solls auch anders sein), mein Daumen würde müde und ich wollte die Hand wechseln. Vorbei war es, ich ließ beim Wechsel versehentlich los. Also noch ein Durchgang, diesmal drückte ich das Gerät mit dem Knopf gegen den Tisch. Diesmal hielt ich durch. Im Display stand allerdings „Fail 01/90“. Fehlerbeschreibung: Hardwarefehler. Mist!

Und es ging nicht mehr an, dachte ich! Also nochmal flashen…. aber das Programm sagt jetzt, es ist bereits die aktuellste Version auf dem Gerät. Ja was denn nun?

Aber ich täuschte mich. Das Gerät war an, die Diplay-Beleuchtung war nur aus. Ich konnte mit der Programiersoftware das Gerät noch auslesen. Die neue Firmware war drauf! Supi! Der Datenkanalmodus liess sich auch aktivieren! Perfekt.

Problem 6:

Der TT-Timer stand allerdings auf 60 Sekunden.

Der muss nämlich auf 0 stehen, da es die Sendezeitbegrenzung ist. Die muss natürlich erstmal raus. Diese Daten sind eigentlich schreibgeschützt und können nur mit einem speziellen Programm geändert werden. Aber eine andere Methode war erfolgversprechender. Man muss in der Programmiersoftware einfach eine neue „Kennung“ anlegen und die alte löschen. Damit sind viele Einstellungen auf Standard. Auch der TT Timer war damit wieder auf 0.

Ein weiteres herumdoktern mit einer weiteren Software (Warum zum Teufel gibt es eigentlich für jeden Mist ein eigenes Programm?) wollte ich vermeiden.

Folgende Einstellungen in der Software sind nun wichtig:

Unter „Konventionelle Kennung“ auf einem Kanal die Frequenz eingeben, 439,9875 MHz. Ich habe es für TX und RX eingegeben.

Diesen Kanal noch „bearbeiten“ und dort den „Datenkanal“ aktivieren.

Damit wird der NF-Eingang für diesen Kanal auf Pin24 freigeschaltet. Super, dann kanns ja jetzt losgehen!

Problem 7 („gefühlt“ Problem Nr. 281.654)

Denkste. Wäre ja zu schön gewesen! Das Gerät geht nicht auf Sendung! Nachfrage bei OM Ralph. „Du musst es noch in den „konventionellen Modus“ schalten. P-Taste länger gedrückt halten, dann rebootet es und ist im „konventionellen Modus“. Aha, ok, war mir neu, aber was solls, man lernt ja nie aus. Also ich drücke und drücke, und es passiert – nichts! Egal was ich mache. Nada! Es bleibt bei der Bündelfunkeinstellung.

Also mal Tante Google bemüht und glücklicherweise gleich fündig geworden! Zitat: „Du mußt die Funktion „Repeater umgehen“ in der Programmiersoftware aktivieren, dann klappt auch die Umschaltung. Die Funktion findest du unter Bearbeiten/Allgemein/Unabhängige Kennungsparameter“. Und das war es dann auch. Sobald diese Option aktiviert war, konnte man tatsächlich wie beschrieben in den „konventionellen Modus“ umschalten. Wichtig hierbei ist noch, dass das Gerät auch mehrmals ein und ausgeschaltet wird nach dem Programmieren und dem Umstellen auf den konventionellen Modus, damit es auch sicher abgespeichert wird. Erst wenn das Gerät auch wieder im konventionellen Modus startet, passt es. Na dann kann es ja losgehen!

RaspberryPi an den GM1200 angeschlossen, Gerät an, abwarten. Jawoll, es kommen Funkrufsignale raus. HEILIXBLECHLE! Das war ja mal ein Marathon….

Problem 8:

Aber mein Funkrufempfänger will noch nichts empfangen. Menno! Was ist das jetzt? Ich habe dann doch erst zwei Tage Pause gemacht bevor ich mich wieder daran gemacht habe. Nochmal getestet, Der Skyper hat immernoch keinen Empfang. OK, also testweise wieder den FT-7800 anschließen. Und siehe da, Skyper hat Empfang. Hmm, also was ist jetzt mit dem GM1200? Überlegt, überlegt. Nicht richtig abgeglichen vielleicht? Das Audio hört sich übrigens einwandfrei an. Mein im Kopf eingebauter Spektrumanalyzer merkt keinen Unterschied. OK, die letzte Eichung ist aber schon eine Weile her. Vertrauensvoll wendete ich mich daher an die DAPNET Community im Telegram Support Chat. Dort habe ich das Problem geschildert. Ein paar Vorschläge kamen, aber da war nichts dabei. Und dann tauchte ein User namens „fl0“ auf. Er meinte was zu wissen, und zwar dass man im Unipager den Haken bei „Inverted“ setzen muss für den GM1200. Ich habe zwar keine Ahnung, was die Optiom bewirkt, aber einen Versuch ist es Wert. Also Haken gesetzt (und es heißt wirklich „Haken“, und nicht „Hacken“ wie viele andere das im „tollen Internet“ so schreiben).

Unipager dann auf Knopfdruck neu gestartet und abgewartet. Das „habe keinen Empfang“ Symbol im Skyper ist dann auch gleich verschwunden. Ja super! Ich setzte eine Testnachricht über den Unipager ab, und es bimmelt! Noch zwei, drei abgesetzt, und es bimmelt immer wieder! Über Hampager.de eine Nachricht abgesetzt an mich selbst, und es piepst! Thomas DB3NF gebeten mir eine Nachricht zu senden, und es piepst!

Ja >Herrschaftszeiten< … kann ein Mann glücklicher sein? Endlich mal ein Projekt das erfolgreich war. Hat zwar nur ein paar Wochen gedauert, aber macht ja nix. Der User „fl0“ hat meinen Tag gerettet! Vielen Dank nochmal dafür! Ich habe ihm ein Bier als Dankeschön angeboten – hat er nicht angenommen. Na gut, vielleicht mag er das nicht (ich ja auch nicht – Bier ist bäh). Und warum schreibe ich seinen echten Namen bzw. sein Rufzeichen hier nicht? Nunja, er hat ein gewisses „Problem“ mit seiner „Prominenz“. Und damit er nicht noch prominenter wird und vor lauter Anfragen wie „bist du nicht der, der….“ nicht mehr zum funken kommt, belasse ich es mal dabei.

Nachstes Ziel: Aufbau des Senders bei DB0NU in Altenstein JO50IE. Und dann mal von dort aus die Reichweite testen.

Vielen Dank fürs lesen. Und wer Fragen hat, bitte einfach Mail an CALL@DARC.DE.

vy73 de DL1NUX

Und hier noch ein paar weitere Bilder:

Der Raspi mit der aufgesteckten Platine von oben.

Der Raspi mit der umgedrehten Platine daneben. Der 2er Block geht zur Soundkarte, der 3er Block geht zum Funkgerät (PTT, GND, Audio Out).

Dies ist mein Testsetup in der Totalen. Ganz rechts ist der Uralt-PC (P2 266 MHz) mit seinen Diskettenlaufwerken.

Noch eine Ansicht mit dem GM1200 am Netzteil, daneben der Raspi mit noch abgesteckter Platine. Hinten am Regal klebt horizontal eine kleine 2m/70cm Magnetfußantenne, die an den Sender angeschlossen ist. Links neben dem Monitor sieht man auch das Programmierkabel von Alfred.

PS: Sorry für die Mischung der Bilder aus Screenshots und Fotografien 😉

4 Element Yagi für 50 MHz

Antennebau 4 Element Yagi für 50 MHz nach DK7ZB in 28 Ohm Technik

Dies ist ein weiterer Erfahrungsbericht vom Bau einer Antenne nach DK7ZB. Da ich Anfang 2006 eine Sondergenehmigung für den Betrieb auf 50 MHz erhalten habe, wurde ich recht schnell QRV auf diesem Band. Mein erstes Bauprojekt war eine 3 Element Yagi mit 2,5m Boom nach DK7ZB, zu sehen unter http://dk7zb.darc.de/6m/3-28-250.htm.

Einige Zeit später veröffentlichte Martin, DK7ZB, im „Funkamateur“ ein neues 50 MHz Yagi Design, mit vier Elementen, aber nur 2,2m Boom. Eine Besonderheit war auch, das sie mit normalem 20mm Vierkant Boomrohr und den bekannten Polyamid Elementhaltern aufgebaut wird. Diese Beschreibung ist auch im Internet unter http://dk7zb.darc.de/6m/428-breit.htm zu lesen. Weiterlesen

3 Element Yagi für 50 MHz

Bau einer 3 Element Yagi für das 6m Band im 28 Ohm Design nach DK7ZB

Original Baubeschreibung: http://dk7zb.darc.de/6m/3-28-250.htm

Element Elementposition Elementlänge
Reflektor 0mm 2940mm
Strahler 1320m 2810mm
Direktor 2500mm 2660mm

Als Anfang 2006 in Deutschland für das 6m Band wieder eine Lotterie für Sondergenehmigungen veranstaltet wurde, habe ich einen Antrag abgeschickt und glücklicherweise „gewonnen“. Also musste schnell eine Antenne her. Durchweg positive Erfahrungen hatte ich mit Yagis für 2m und 70cm nach DK7ZB. Auch für 6m hatte er einige „im Angebot“. Es sollte auf jeden Fall eine Yagi in 28 Ohm Technik sein, da sie mit anderen Antennen am Mast problemlos befestigt werden kann. Da es (noch) keine 4 Element Yagi gab und die 5 Element Yagi für meine Zwecke schon zu lang war, entschloss ich mich zum Bau der 3 Element Yagi mit 2,5m Boom. Weiterlesen

3 Element Yagi für 28 MHz

Nachbau einer 3 Element Yagi für 28 MHz im 28 Ohm Design nach DK7ZB

URL: http://dk7zb.darc.de/3-Ele-Kurzwelle/10m-28Ohm.htm

Vorwort:

in diesem Erfahrungsbericht schreibe ich nur meine persönlichen Bauerfahrungen nieder und zeige wie man bestimmte mechanische Probleme beispielsweise handhaben kann. Meine Lösungen sind kein Muss und bestimmt noch verbesserungsfähig. Es dient lediglich als Hilfe für Diejenigen, welche sich durch die Bauanleitungen von DK7ZB über die mechanischen Einzelheiten kein Bild machen konnten und daher nach Ideen suchen. Über positives Feedback würde ich mich aber trotzdem freuen.

Weiterlesen

2 Element Yagi für 21 MHz

Bau einer 2 Element Yagi für 21 MHz nach DK7ZB

Vorgeschichte:

Im Herbst 2006 habe ich bereits mit DO3NDW eine 4 Element Yagi für 21 MHz gebaut. Leider ist diese groß und schwer und kann nicht alleine aufgebaut werden. Daher habe ich mich entschlossen für den eigenen Gebrauch eine 2 Element Yagi für 21 MHz zu bauen, welche ich auch notfalls alleine aufbauen kann. DK7ZB Bietet auch dafür eine Bauanleitung:

http://dk7zb.darc.de/2-Ele-Kurzwelle/2-Ele-15m-Ref.htm

Weiterlesen

4 Element Yagi für 21 MHz

Bau einer 4 Element Yagi für das 15m Band im DK7ZB Design

Im Herbst 2006 hatte Stefan, DO3NDW, die Idee eine gute Antenne für das 15m Band zu bauen, welche bei Portabeleinsätzen genutzt werden sollte. Nachdem auch er schon viele gute Erfahrungen mit dem Bau von DK7ZB Antennen für 2m und 70cm gemacht hat, fiel die Wahl wieder auf die Designs von Martin, DK7ZB. Er entschloss sich, die 4 Element Variante zu bauen, welche unter http://dk7zb.darc.de/3-Ele-Kurzwelle/4-15m-28ohm.htm veröffentlicht wurde.Nachdem ich schon Erfahrung hatte im Bau von Kurzwellenyagis nach DK7ZB hatte, bot ich ihm meine Hilfe an, die er auch annahm. Weiterlesen

Einfache Draht-Groundplane für 7 MHz

Einfache Groundplane Antenne für das 40m Band für temporären Aufbau

Schon lange plante ich eine einfache GP Antenne für 40m zu bauen, welche man bei bestimmten Events wie z.B. Fieldday oder Contest schnell und einfach aufbauen kann. Als ich preiswert an einen 12m GFK Mast der Firma ZK-Antennen kam, konnte ich diesen Plan verwirklichen. Weiterlesen

Projekt Wires-X C4FM/FM Relais mit Yaesu DR1-XE

Im Sommer erwarb ich preiswert einen Yaesu Repeater DR1-XE. Was sollte ich nun damit machen? Ein eigenes Relais betreiben? Hmm, vielleicht, aber hier in Coburg gibt es ja schon eins. Also entschloss ich mich, mich etwas mehr mit der Materie zu beschäftigen. Besonders C4FM und Wires-X interessierten mich. Aber ich brauchte noch ein wenig was dazu. Also besorgte ich mir noch ein HRI-200 Wires-X Modem und einen FTM100DE Mobiltransceiver von Yaesu. Auch ein seperates Netzteil war vonnöten. Weiterlesen