Dieses Wochenende in den Herbstferien war Bastelwochenende. Zur Vorbereitung für den Hexbeam Aufbau im kommenden Frühjahr auf dem Dach des Heimat-QTH hat sich der Autor Gedanken gemacht, wie er seinen Rotor ohne Computerinterface über das Logprogramm steuerbar macht.

Ausgangssituation ist das auch an der Schulstation unter Linux genutzte Logprogramm CQRLog. Dort gibt es die im Programm integrierte Möglichkeit über Hamlib einen Rotor zu steuern. Ein bisschen Recherche im Internet brachte den ERC (Easy Rotor Control) USB in der Version 4 von schmidt-alba.de als Bausatz zum Vorschein. Die Referenzen in eham.com waren alle überaus zufrieden mit dem Interface, die Rotorenliste, die das Interface unterstützt beinhaltete auch den vorhandenen Fukner 400 und in der Softwarebeschreibung stand, dass Hamlib mit dem Interface umgehen können soll. Also war der ERC 4 flugs bestellt und lag schon ein paar Tage später im Briefkasten.

Der Aufbau gestaltete sich problemlos, die zu lötenden Bauteile sind durchgängig bedrahtet, alle Aufbauschritte sind im Detail beschrieben, vor der Installation der ICs wird ein elektrischer Test durchgeführt.

Der Moment der Wahrheit ergab sich dann, als das Interface zum ersten Mal an einem Windows Rechner betrieben wurde. Mit der Konfigurationssoftware (die leider nur als .exe Datei vorliegt) ließen sich alle benötigten Parameter wie z.B. unterstütztes Protokoll (GS232A, GS232B oder DCU-1) problemlos konfigurieren. Die Kalibrierung des Interfaces wird auch in der Konfigurationssoftware erledigt, wobei man die Wahl hat zwischen einer einfachen Kalibrierung an den beiden Endanschlägen des Rotors und einer linearen Interpolation der vom Rotor rückgemeldeten Spannungswerte des Rotorpotis und einer feineren Kalibrierung in 30° Schritten. Da die im Rotorcontroller verbaute einfache Anzeigenadel sich bei Drehung des Rotors nicht sehr linear verhält führten wir eine erweiterte Kalibrierung durch.

Danach wurde der Rotor das erste Mal an den Linux-Log-Rechner gehängt. Wie zu erwarten funktionierte zuerst einmal nichts. Schlimmer noch, auch die Frequenzanzeige des Transceivers erschien nicht mehr im Logprogramm. Zum Glück erinnerte sich der Schreiber dieser Zeilen daran, dass der Dienst rigctld zur Steuerung des TRX über die Datei /etc/rc.local gestartet wurde. Dort wurde dann auch die entsprechende Befehlszeile für den Rotorsteuerdienst rotctld eingepflegt.
rotctld -m 601 -r /dev/ttyUSB2 -s 9600 -t 4533 -vvvvv&
Das brachte aber zunächst keine Besserung, so dass in rc.local erst einmal alles auskommentiert wurde und die beiden Dienste nach jedem Neustart per Hand gestartet wurden. Dadurch ging zumindest die Frequenzanzeige in CQRLog wieder!

Ermuntert von diesem Erfolg ging es dann weiter mit der Ausprobiererei. Im Netz wurden verschiedene Erfolgsmeldungen mit dem Interface unter Hamlib beschrieben. schmidt-alba.de schreibt, dass sie es bei der Satellitenverfolgungssoftware gpredict mit dem Protokoll GS232A geschafft hätten, eine tschechische Internetseite schrieb, dass sie in Hamlib als Rotor die Nummer 601 YAESU GS232A erfolgreich eingesetzt hätten, es aber mit der (damals) neuen 404 DF9GR ERC seinerzeit stark vereinfacht worden sei. Nach unzähligen Änderungen in den Einstellungen in CQRLog und Neustarts des Rechners gelang es dann wenigstens die Rotorstellung auszulesen.

Nur das Bewegen des Rotors wollte nicht klappen. Nach weiterer Recherche im Netz wurde dann klar, dass man den Rotor mit dem rotctl Kommando M 8 bzw M 16 direkt über ein Terminal ansprechen kann um ihn in Bewegung zu versetzen. Das wollte aber auch auf diesem direkten Weg nicht klappen, rotctl meldete immer einen Timeout Fehler. Durch Zufall klickte der Schreiber dieser Zeilen dann in CQRLog statt auf die Steuerbuttons „left“ bzw. „right“ nach Eingabe eines Rufzeichens auf den button „Long Path“. Und siehe da, der Rotor setzte sich in Bewegung und stoppte als die Azimuth-Richtung zum vermeintlichen Gesprächspartner erreicht war! Was für ein Glücksgefühl!

Jetzt blieb noch die Frage warum die links/rechts Buttons nicht funktionierten. Über das Terminal konnte mit dem Befehl p die aktuelle Position des Rotors ausgelesen werden und mit z.B. P 210.000 100.000 auch der Winkel 210° angefahren werden (der Wert 100.00 stellt im Protokoll einen notwendigen Elevationswinkel dar, den unser Rotor nicht benötigt). Offenbar klappte die Kommunikation über das Interface einwandfrei, nur der Befehl M konnte nicht interpretiert werden. Als weitere Möglichkeit stellte sich noch Hamlib dar. Die verwendete Versionsnummer war 3.3 und damit schon veraltet. Bislang scheute der OM aber ein Upgrade (never change a running system) da doch eine Menge anderer HAM-Programm auf Hamlib zurückgreifen. Aber es half nichts, Hamlib wurde von git geclont, kompilliert und in der aktuellen Version 4.6 installiert. Nach einem Neustart dann die frohe Kunde: der Transceiver spricht mit CQRLog und der Rotor auch. Und es funktionieren jetzt zudem die beiden buttons left bzw. right um den Rotor für maximal 15s zu drehen oder ihn vorher mit dem Stop button anzuhalten. Um die Dienste rigctld und rotctld nicht jedes Mal wieder händisch starten zu müssen, wurde die rc.local Datei wieder aktiviert. Insbesondere rigctld ist vor CQRLog zu starten, damit mehrere Programme über Hamlib gleichzeitig auf die Frequenzanzeige des TRX zugreifen können. Ein Neustart zur Überprüfung der Einstellungen verlief positiv. Damit war der Tag spätnachts erfolgreich beendet.

Die Ernüchterung erfolgte dann am nächsten Morgen. Nach dem Hochfahren des Rechners schaltete der TRX auf Senden und reagierte nicht mehr. Zugriff auf die Frequenzanzeige des TRX oder auf den Rotor waren nicht mehr möglich. Nun war guter Rat wieder teuer. Mehrere Neustarts zeigten, dass das System immer dann richtig arbeitete, wenn rotctld nach dem Hochfahren händisch gestartet wurde. Ein Zusammenhang mit der rc.local drängte sich also auf. Zudem zeigte sich, dass bei vollständiger Aktivierung der Dienste über rc.local manchmal alles korrekt arbeitete, meistens jedoch nicht bzw. in der oben beschriebenen fehlerhaften Art.

Eine Suche mit dmesg|grep ttyUSB brachte dann Licht ins Dunkel: die USB Ports wurden bei manchen Bootvorgängen neu festgelegt, so dass die Angabe -r /dev/ttyUSB0 bzw. -r /dev/ttyUSB2 in der rc.local nicht mehr stimmten, schlimmer noch, rotctld versuchte auf den TRX zuzugreifen und schaltete ihn so in den Sendebetrieb! Als Lösung schien es zunächst machbar eine udev Regel zu formulieren, die das System die USB Ports immer gleich zuweisen lässt. Bei der Recherche zu Hamlib ist auf einer Seite des CQRLog Forums aber auch der Hinweis aufgetaucht, dass Hamlib ab der Version 4 nun auch reference-by-id beherrscht und zwar ohne die vorherige 90 Zeichen Beschränkung, die eine sinnvolle Verwendung unmöglich machte. Flugs wurden die beiden Einträge in rc.local geändert in
rigctld -m 1037 -r /dev/serial/by-id/hierkommtderlangeReferenznamedesTRX -s 9600 -t 4532 -vvvvv&
und
rotctld -m 601 -r /dev/serial/by-id/hierkommtderlangeReferenznamedesRotors -s 9600 -t 4533 -vvvvv&

und siehe da: ab jetzt liefen die beiden Geräte einwandfrei!

Zum Schluss musste noch die Frage entschieden werden ob die Leiterplatte des Interfaces in einem eigenen Gehäuse neben dem Rotorcontroller stehen soll oder in das Gehäuse integriert werden soll. Für beide Arten hat schmidt-alba.de Befestigungsmöglichkeiten in Form von Abstandshaltern und Befestigungswinkeln mitgegeben. Fürden ersteren Fall wäre ein 3D gedrucktes Gehäuse machbar gewesen und das Gehäuse des Rotorcontrollers hätte nicht angebohrt werden müssen. Dagegen sprach der zusätzliche Kabelverhau der nach außen geführten 6 Steuerleitungen. Also fiel die Entscheidung zu einer internen Anbringung des Interfaces. Hierfür hat schmidt-alba.de eigens eine Bohrschablone in Form eines Aufklebers mitgeliefert. Nach dem Ausmessen des geplanten Anbringungsorts im Gehäuse gestaltete sich das Bohren der Befestigungslöcher und Buchsen dann einfach.

Zusammen sieht das Ganze nun so aus:

Was jetzt noch fehlt ist das Anbringen eines vernünftigen Rotorsteuerkabels. Das Lapp Ölflex classic 110 black 7G1 wird aber erst konfektioniert, wenn der Rotor am Mast ist.

• Über
• Letzte Artikel

Wolfgang Lormes

DJ4QV, Diplomphysiker und Lehrer für Physik und Mathematik am Markgraf-Georg-Friedrich Gymnasium in Kulmbach.
Dort bin ich auch der MINT-Beauftragte, betreue die Robotik AG und das MGF-Lab, bin Fachschaftsleiter Physik und Sammlungsleiter sowie der Strahlenschutzbeauftragte, betreibe die Amateurfunk-Schulstation DK0MGF und führe eine Junior-Ingenieur-Akademie der Deutsche Telekom Stiftung.

Letzte Artikel von Wolfgang Lormes (Alle anzeigen)

• DK0MGF bietet Meshtastic Knoten an - 17. Juli 2024
• Europatag 2024 mit vielen kleinen Unwägbarkeiten - 6. Mai 2024
• Endlich etwas Übersicht - 22. April 2024