Projektseite 'Steuerung für einfachen Antennenrotor'

Rotor billig

Meine Antennenanlage besteht schon seit einigen Jahren aus einer 6-Element-Yagi für UKW sowie einem Rundstrahler. Dieses Gebilde wird von einem einfachen Antennenrotor gedreht, wie er z.B. von Conrad für kleinere UKW-Rundfunkantennen vertrieben wird [1]. Zwei solche Rotoren habe ich in recht gutem Zustand (Unterdacheinbau) bei eBay ersteigert (Abb. zeigt ein schlecht erhaltenes Exemplar).
Der Rotor vollführt eine Drehbewegung um 360 Grad in ca. 70 Sekunden und hat einen Anschlag, welcher üblicherweise nach Norden ausgerichtet wird, bei mir jedoch nach Westen... Die Synchronisation mit dem Steuergerät bzw. dessen Skala geschieht dadurch, dass sich in jenem ein ähnlicher Motor befindet, der einen Zeiger mit der aktuellen Antennenrichtung dreht. Wählt man eine neue Richtung vor, wird über mehrere Schaltkontakte alles eingeschaltet und die Drehrichtung vorgegeben. Von Zeit zu Zeit ist es erforderlich, Steuergerät und Anzeigeeinrichtung neu zu synchronisieren, eine Rückmeldung gibt es nämlich nicht.

a similar rotor and its control unit

Anforderungen

Übliche, höherpreisige Rotorsteuergeräte haben

  • zur Rotorseite hin mehrere Relais, die die Spannung entsprechend der Drehrichtung auf die Motorwicklungen schalten bzw. diese umpolen
  • eventuell ein Relais, das auf eine Bremse wirkt
  • benutzen zur Rückmeldung die winkelproportionale Spannung eines Potis, welches im Rotor verbaut ist
Wünscht man Steuerung durch eine Computer, so bilden die angebotenen Interfaces i.A. die rotorseitige Schnittstelle nach, zum Computer hin scheinen meist eher proprietäre Protokolle zum Einsatz zu kommen, die dann auch von den AFU-Programmen mit Rotor-Unterstützung 'gesprochen' werden müssen.

Für das zu bauende Gerät gibt es folgende Anforderungen, hier nach meinen Prioritäten geordnet:

  1. Ansteuerung für oben geschilderten 'Einfachstrotor'
  2. Bediengerät mit Anzeige der aktuellen Richtung, Preset-Möglichkeit, etc.
  3. Ansteuerungsmöglichkeit sollte auch für 'Standard'-AFU-Rotoren gegeben sein
  4. Der maximale Drehbereich sowie die Lage des Anschlages, sollte konfigurierbar sein
  5. Ansteuerung durch Computer, zur Einbindung in gängige AFU-Programme, sollte auch mindestens eines der hier verwendeten Protokolle 'gesprochen' werden. Gegenwätig denke ich da an das Yaesu GS-232 Protokoll [2].
  6. Ansteuerung über das Internet (Stichwort: remote controlled station) sollte möglich sein
  7. CAT-fähig, falls es so etwas gibt (wenn ich auch noch nicht weiß, wie das gehen könnte...)

Grundaufbau...

Die Steuerung läßt sich grob in folgende Funktionsbaugruppen bzw. funktionelle Teile untergliedern:

  • Zentrale Steuerung mit Mikrokontroller
  • Anzeige der aktuellen Antennenrichtung und Preset-Werten
  • Taster zur Benutzereingabe
  • Aufbereitung bzw. Bereitstellung der Richtungsinformation
  • Relais-Steuerung
  • Stromversorgung des Rotors
  • Stromversorgung der Steuerung

scheme of the control unit

Es frägt sich, ob es notwendig ist, die Aufgabenstellung mit mehreren Mikro-Controllern (u-Controller) zu lösen. Angesichts der (späteren) Code-Größe, lässt sich alles sicherlich in einem einzigen u-Controller unterbringen, nur die Hardware wird dann etwas ausgefeilter sein müssen. Auch von der Programmentwicklung her ist das Entwickeln an 2 'Enden' etwas anspruchsvoller, dafür sind die Einzelprogramme an sich weniger komplex und einfacher zu überschauen.

'Positionsanzeige' und Bedienung

Auf einer Lochrasterplatine sind einige Digi-Taster (Reichelt DTL 2 bzw. DIT 1) sowie Leuchtdioden untergebracht. Mit den Tastern lässt sich Rechts- und Linkslauf wählen, sowie die Preset-Funktion ansprechen. 2 jeweils 3-stellige 7-Segmentanzeigen mit jeweils unterschiedlichen Farben dienen zur Anzeige der aktuellen Antennenrichtung bzw. des Preset-Wertes.
Während die Taster nebst zugehörigen LEDs direkt mit entsprechenden Pins des u-Controllers verbunden sind (auf der zentralen Steuerungsplatine) werden die 7-Segment-Anzeigen von einem eigenen ATmega8 angesteuert, der die darzustellenden Daten via TWI-Bus erthält. Hier kommt ein Hardware-Design von Ulrich Radig in etwas abgewandelter Form zum Einsatz, diese Einheit war als U/I-Anzeige in einem Labornetzgerät konzipiert [3].

Auswertung der Rotor-Position

Üblicherweise wird das mit einem Poti gemacht, das mit der Drehachse des Rotors verbunden ist. Es ist als Spannungsteiler geschaltet, die jeweilige Spannung wird dann als Rükmeldung des gegenwärtigen Drehwinkels interpretiert wird. In dieser Weise könnte man auch den vorliegenden Rotor erweitern, siehe [4] ...
Leider hat dieses Verfahren auch den Nachteil, dass es zur Alterung kommt und man die Rüchmeldung gelegentlich neu kalibrieren muß
Andere, etwas 'abgefahrenere' Möglichkeiten wären (ohne Anspruch auf Vollständigkeit):

  • Drehwinkelgeber, absolut oder imkrementell
  • elektr. auslesbarer Kompass
  • Web-Cam, mit oder ohne Digitale Bildverarbeitung
Ich bevorzuge momentan die zweite Variante, hier sollte sich der mechanische Aufwand in Grenzen halten, natürlich ist der finanzielle und software-technische Aufwand weitaus höher, letzteres macht für mich auch den Reiz der Sache aus.

image of Pololu 1250 breakout board with LSM303 chip

In meinem Fall habe ich mich für die Kombination 3D-Magnetfeldsensor und 3D-Accelerometer LSM303DLH entschieden, die von [5] vertrieben wird, Datenblätter etc. siehe [6],[7]. Dieses, auf einem sog. Breakout-Board montierte Modul, läßt sich via SPI oder I2C (TWI) ansprechen, da ja der Sensor sich bei der Antenne und damit vom Steuergerät abgesetzt befinden soll, müssen die Steuersignale irgendwie umgesetzt werden. Angeregt von einem Artikel in der cq/dl [8], nehme ich hier RS-485 Signale. Ein mit dem Modul verbundener u-Controller liest es periodisch aus, rechnet die Werte um (u.a. Lagekompensation mit Hilfe des 3D-Accelerometers) und schickt sie dann im NMEA-Protokoll (ähnlich einem GPS-Modul) periodisch über die serielle Schnittstelle mit RS-485 Signalpegeln zum Steuergerät.

Die Ansteuerung bzw. Auslese des LSM303DLH, welcher geschützt am Boom der Antenne montiert ist, erfolgt durch einen eigenen u-Controller. Dieser initialisiert den DSM303DLH und frägt dann periodisch seine Sensoren ab. Die erhaltenen Werte werden über die serielle Schnittstelle wieder ausgegeben, die gesendete Zeichenkette hat Ähnlichkeit mit den bei GPS-Geräten verwendeten NMEA-Datenformat. Ein geeigneter Pegelkonverter (z.B. MAX 485) setzt das TTL-Ausgangssignal des u-Controller-UARTs in RS-485 kompatible Signale um.

Das Programm für diese Aufgabe, ist weniger als 2 kByte groß, es liesse sich bereits in einen ATtiny2313 unterbringen. Jenem fehlt allerdings die TWI-Schnittstelle, so daß es doch ein ATmega48 oder ATmega8/88 sein muß.

Die Applikationsschrift AN 3192 [7] beschreibt, wie man mittels der beiden Sensoren des LSM303DLH einen neigungs-kompensierten Kompass (wichtig für Handheld-Geräte) aufbaut. Unter der Annahme, daß die Antenne sich in einer horizontalen Ebene dreht, ist das eigentlich unnötig, es wird also erst mal darauf verzichtet. Ein weiterer Aspekt ist, daß die dazu erforderlichen Fliesskommarechnungen mehr als 8 kByte Programmspeicher benötigen, ein ATmega48 oder ATmega8/88 damit also überfordert wäre.

Anmerkung: Die Entwicklung der Sensorik, auch angetrieben von der Entwicklung der Smartphones, verläuft so rasant, so daß leider davon auszugehen ist, daß jeder andere hier als Alternative aufgeführte Sensor schon bald nicht mehr erhältlich sein wird.

RS-485 und Bootloader

Da die RS-485-Schnittstelle in ihrer Standardversion eine halb-duplex arbeitende Schnittstelle ist, muss man auf Protokollebene in geeigneter Weise erkennen, ob eine Umschaltung der Übertragungsrichtung notwendig ist, dazu bedarf es eines weiteren Steuerausgangs am jeweiligen u-Controller. Alternativ wäre eine Ansteuerung mit der Vollduplex-Version von RS-485 oder mit RS-422 bzw. RS-232 (aber max. Leitungslänge ist hier eingeschränkt) denkbar...

Bei der abgesetzten Montage des Sensor-u-Controllers ist auch ein nachträgliches Update der Firmware nur recht schwierig möglich, d.h. in diesem Fall muss man einen Firmware-Update über einen Bootloader durchfühen, der natürlich installiert sein muss und auch die Besonderheiten der RS-485-Ansteuerung beachten muss.

Um in den Sensor-u-Controller eine neue Firmware einzuspielen, benötigt man (nur in der endgültigen Montageposition) noch einen geeigneten RS-232-zu-RS-485-Umsetzer, der ist eigentlich trivial, das RTS-Signal nimmt dann die Umschaltung der Senderichtung in der 'Bodenstation' vor. Von FTDI gibt es USB-Serial-to-RS-485-Convertor [], alternativ reicht auch eine Schaltung z.B. nach DL1DMW [].

Rotoransteuerung

Zur Ansteuerung des Rotors (Motors) gibt es zwei 2-polige Relais mit Umschaltkontakten (Wechsler). Eines wird für die Rechtsdrehung geschaltet (CW), das andere für die Linksdrehung (CCW). Damit ist es möglich, die Umpolung für Gleichstrommotoren zu bewerkstelligen als auch die beiden Wicklungen eines Wechselstrommotores (des vorliegenden Rotors) geeignet anzusteuern, um eine Umkehrung der Drehrichtung zu erreichen. Ein weiteres Relais auf der gleichen Lochrasterplatine mit einem Umschaltkontakt ist für eine evtl. vorhandene Bremse vorgesehen.

relaymounting plate

Auf einer kleinen Zusatzplatine befindet sich ein weiteres Relais, das die Stromversorgung des Rotors während der Drehung einschaltet. Die Schaltlogik des alten Rotorsteuergerätes hat so etwas im Prinzip auch implementiert.

Nachfolgende Skizze zeigt, wie man den AC-Rotor geeignet mit den beiden Relais zu verbinden hat:

relay wiring scheme

Zentrale Steuerungsplatine

Der zur zentralen Steuerung eingesetzte u-Controller muss zum einen die Signale von den Tastern, der Richtungsanzeige und (optional) von einem Steuercomputer (CAT) auswerten und zum anderen, die Signale für die Anzeige (TWI) und zur Ansteuerung der Relais bilden. Falls das Gerät in Zukunft auch noch via Netzwerk ansprechbar sein soll, muss der Netzwerkchip auch noch via SPI angesprochen werden. Es werden also eine grössere Anzahl von I/O-Pins benöigt, ein u-Controller in der Größe mindestens eines ATmega32 ist also vorteilhaft. Da außrdem 2 serielle Schnittstellen (UART) benöigt werden, muss es mindestens ein ATmega644P (oder 1284P) sein, der davon 2 besitzt (alternativ könnte man den 2. UART in Software implementieren oder z.B. einen I2C-UART einsetzen).

image of the CPU board on an lab pcb

Gehäuse

Als Gehäuse wurden die Überreste des Gehäuses einer Turbo- Pumpensteuerung aus dem Schrott verwendet. Die Seitenteile bestehen aus Aluminium-Profilen, an deren Ende die Front- bzw. Rückwand angeschraubt werden. In die Nuten des Alu-Profils lassen sich M4-Muttern verdrehsicher einschieben an welchen man dann die inneren Aufbauten befestigen kann. Front- und Rückwand sind natürlich noch zu erstellen und dürfen auch andere Maße haben, als die Originale. Ober- und Unterseite waren nicht mehr vorhanden, hier sollen Lochraster-Alu-Bleche aus dem Baumarkt zu Einsatz kommen, die lassen sich ebenso in Nuten der Seitenteile einschieben.

Software

Dadurch, daß die Aufgaben der Sensor-Auswertung und die Anzeige der aktuellen und der Preset-Position auf eigene u-Controller ausgelagert wurde, gestaltet sich die Software für die Steuerung um einiges einfacher (Sicher wären die Aufgaben auch von einem einzelnen u-Controller zu erledigen gewesen sein). Grob lässt sich dessen Software in folgende Bestandteile unterteilen:

  • TWI-Schreibfunktionen für Anzeige [11]
  • UART-Lese- und Schreibroutinen [11]
  • Interpretation und Aufbereitung der Daten des MAG-Sensors
  • Abfrage der Tasten mit Entprellen [12]
  • Motor- bzw- Relais-Ansteuerung
  • Zentrale State-Machine

Im Display zur Winkelanzeige kommt, wie bereits erwähnt, eine modifizierte Software von U.Radig zur Verwendung. Die neue Software gliedert sich grob in folgende Teile:

  • periodisches Auslesen eines Display-Puffers (enthält die darzustellenden Segmente) und Schreiben zur Anzeige
  • TWI-Slave nach [9], es wird ein EEPROM emuliert
  • Interpretation der via TWI erhaltenen Befehle, Konvertieren der Daten (in 7-Segment-Darstellung) und Schreiben in den Display-Puffer

Projektstatus bzw. -Fortschritt

  • 02/2016: HF-Tests mit HB9CV und 50W (2m) beeinflussen Sensor nicht
  • 11/2015: Gehäse und Montage für Antennensensor fertig
  • 03/2014: Alles ins Gehäse eingebaut, Gehäse f¨r Sensor vorbereitet, Platine f¨r Sensor (Lochraster) gefertigt und getestet
  • 12/2013: Nach langer Pause geht es weiter, geätzte Netzteil-Platine hinzugefügt
  • 06/2012: Messung der Antennenrichtung via RS-485, Berechnung und Anzeige funktionieren, Preset noch fehlerbehaftet, das ist Version 1.0
  • 05/2012: CPU-Platine aufgebaut, Verdrahtungsarbeiten weitestgehend ausgeführt, Abfrage der Taster und korrekte Ansteuerung (software-seitig) der Relais
  • 04/2012: Großteil der Arbeiten am Gehäuse (Laubsägearbeiten, Durchbrüche, etc.) abgeschlossen - noch nicht lackiert; Relais-Platinen 1 und 2 und Tasterplatine (Lochraster) aufgebaut
  • 12/2011: Software füer die Winkel-Anzeige, TWI-Slave, Anzeige-Platine funktionsfähig
  • 11/2011: Software füer den MAG-ACC-Sensor, noch keine Lagekompensation implementiert
  • 08/2011: Projektstart, 1. Planungen, Kauf des Sensors, Sammeln von geeigneten Software-Fragmenten u.ä.

Nachlese

  • Irgendwann in 2013 erreichte mich eine Anfrage zu dem Projekt von Bogdan-Ioan (YO2MKE) mit dem Hinweis auf ein generisches Software-Projekt von K3NG, das es erlaubt, mehrere Arten von Rotoren zu steuern und auch unterschiedliche Sensoren zur Rüeckmeldung zu verwenden.
    Dieses Projekt ist bei github gehostet, stellt aber sicher, was die Auswahl der zu verwendenden Module und die Konfiguration der Software betrifft, eine Herausforderung dar.
  • Eine weitere Anfrage, u.a. von Manuel, DD6ZJ, betrifft die Möglichkeit, dass die Abstrahlung der Antenne den Magnetfeldsensor beeinflussen könnte. Nun, bisher habe ich noch keine solchen Beeinflussungen gesehen, getestet wurde mit 50W auf dem 2m Band und einer HB9CV-Antenne (indoor).

Referenzen