Home

Teleskopsteuerung-Projekt (Schaltungsbeschreibung)

 

Das Design des Systems ist nun abgeschlossen. Daher will ich mal eine kurze Schaltungsbeschreibung abgeben, die grob das Konzept veranschaulicht und Hinweise gibt, warum ich es gerade so mache und nicht anders. Mit dem ersten Prototypen konnte ich ja bereits einschlägige, wenn auch nicht immer positive Erfahrungen sammeln.

Hauptcontroller Xmega1328A1 32MHz

Das Herz der ganzen Steuerung ist ein Xmega128A1 Controllerboard. Die neuen Atmel Xmega Controller haben viele Vorteile gegenüber den bisherigen ATMegas. Einerseits sind die IO-Möglichkeiten deutlich erweitert worden und andererseits stellt das Event-System eine prima Möglichkeit dar sich vom Interrupt-System zu lösen. Das EBI-Interface bietet weiterhin die Möglichkeit große externe Speicher anzuschließen. Das verwendete Modul ist mit 39€ deutlich preiswerter als das bisher im letzten Prototypen eingesetzte XMega256-Modul. Auf den Einsatz eines ARM Controllers habe ich bewusst verzichtet. Zwar bieten diese deutlich mehr Rechenleistung (die man hier aber nicht braucht) bringen aber auch durch das OS eine Menge Ballast mit.

Auf dem Controllerboard selbst sind 2 RS232-Schnittstellen über einen MAX232 integriert. Diese werden für die Kommunikation mit der Handsteuerbox und dem Display verwendet. Sie sind direkt auf die entsprechende Buchse erausgeführt. Ebenso befindet sich auf dem Controllerboard ein 64MBit RAM der über das EBI ( PortH, PortJ, PortK) angesteuert wird. Hierin werden dann die Objektkataloge gepuffert, was den Zugriff und sie Suchfunktionen deutlich beschleunigen sollte. Ebenfalls auf dem Board integriert ist ein µSD-Karteninterface. Da das Board, wie auch die komplette Schaltung mit 3,3V arbeitet kann hier der Level-Shifter weg gelassen werden. Alle anderen Ports sind komplett nach außen geführt und können frei verwendet werden. Ein ADC des Ports A wird für die MEssung der Batteriespannung benutzt. Die Aufläsung der XMega-ADCs beträgt 12bit. Ebenso werden am Port A alle Zusatzsignale für die Ansteuerung der RA- und DE-Stufe erzeugt bzw abgerufen. Die Motorstromregelung erfolgt direkt über zwei getrennte DAC mit jeweils 12bit. PWM wäre zwar auch möglich gewesen, bedeutet aber wieder zusätzlichen Schaltungsaufwand um daraus eine wirklich genaue Spannung zu erzeugen. DAC mit 12bit ist da deutlich genauer. Port B wird hauptsächlich zur Auswertung des Autoguider-Anschusses (ST4) der über einen Optokoppler angeschlossen ist, verwendet. die USART-Schnittstellen des PortC dienen der Kommunikation mit dem VDIP2-Modul (USB) und dem Lantronix-XPort (LAN,WLAN). Auch der Temperatur-Luftfeuchtesensor SHT11 ist hier angeschlossen. Von Port E wird momentan nur das I2C- interface benutzt. Dieses dient Steuerungsintern zum Auslesen der eingebauten Sensoren (Luftdruck) und anderer Bauelemente (z.B. DS1338 RTC). Der Port F wird komplett für die SPI-Kommunikation genutzt.

Man könnte prinzipiell allein mit diesem Modul und zwei Schrittmotortreibern eine komplette Steuerung aufbauen, die sich mit den am Markt befindlichen Steuerungen messen kann.

TMC457-Modul

In meinem ersten Prototypen hatte ich eine Kombination aus einem TMC428 und drei TMC249 Schrittmotortreibern verbaut. Das ging zwar prinzipiell, aber hat auch jede Menge Nachteile mit sich gebracht. Der TMC428 ist zwar prinzipiell nicht schlecht, bedarf aber einer ungeheuer aufwändigen Zusatzbeschaltung um vernunftig einsetzbar zu sein. EInserseits sollte bei einer Teleskopsteuerung eine möglichst hohe Microstep-Auflösung realisierbar sein, andererseits aber auch effizient eine hohe Motorgeschwindigkeit erreichbar sein. Das geht mit dem TMC428 schlichtweg nicht. Microstep ist nur bis 64-Fach möcglich, eine automatische Umschaltung auf Fullstep bei hohen Geschwindigkeiten ist gar nicht vorgesehen und muss kompliziert durch On-The-Fly-Umschreibung der Lookup-Table erfolgen. Das dauert aber seine Zeit, auch bei schnellem SPI, was zu Ruckeln führen kann. Hohe Motorgeschwindigkeiten sind ohne Resonanzprobleme auch nur mit chopSync(TM) möglich, was beim TMC428 zwar geht, aber halt auch nur mit etlichen zusatzbauelementen. Will man dann noch im Microstepbetrieb den Motorstrom regeln, so braucht man weiter OPV, Transistoren und Widerstände. Ein Weiterer Flaschenhals beim TMC428 ist der SPI-bus. Dieser kann zwar prinzipiell drei treiberstufen ansteuern, aber dadurch hat jeder Treiber nur noch ein Drittel der Geschwindihkeit zur Verfügung. Daher wäre es ratsam für jede Motorstufe einen eigenen TMC428 zu verwenden. Dieses Manko war natürlich auch den Entwicklern bei Trinamic ein Dorn bekannt, weshalb diese den TMC457 entwickelten. Ich habe ich für diesen Motorcontroller entschieden, weil ich mit Ihm einfach alle Problem auf einmal löse.

Der TMC457 wird nur in einem 144-Pin BGA Gehäuse geliefert, was das Löten zunächst als problematisch erschienen ließ. Dennoch war der Controller ideal, weshalb ich eine kleine 6-Lagen-Platine entwickelte auf der der Controller augelötet ist. Nach außen werden nur die Signale geführt, die ich für meine Steuerung benötige. Einzige Zusatzbauelemente die ebenfalls mit auf der Platine sind ist ein 12bit-DAC und ein 74MHC4053 Multiplexer. Durch diese Kombination ist einerseits 12-bit Microstepping, also 4069-fach sowie eine schrittverlustfreie sofortumschaltung zwischen Microstep und Fullstep bei hohen Geschwindigkeiten gewährleistet. Die Stromregelun der Motorstufe kommt direkt com DAC des XMegas. Ebenfalls besitzt der TMC457 ein integriertes Hardware-Encoderinterface mit digitalen Filtern. Ein integrierter PID-Regler kann benutzt werden um die Motorposition ohne Fremdzugriff auszuregeln (z.B. Windlast). Alle Register intern sind in 32bit ausgeführt was entsprechend hohe Positioniergenauigkeiten bzw. Geschwindikeiten ermöglicht. Ebenso verfügt der TMC457 über virtuelle Stop-Switsches. Dadurch kann man zum beispiel ohne Hardwareaufwand ein Anschlagen des Teleskops verhindern. Hierz wird dann später in der Firmware in einer Tabelle hinterlegt wann das Teleskop bei welchen RA-DE-Konstellationen anschlagen würde. chopSync(TM) ist auch schon schon fertig im TMC457 integriert und bedarf keiner Zusatzbeschaltung.

TMC429-Modul

Hier bin ich dem alten Prototypen treu geblieben. Allerdings habe ich auch diesen Teil der Schaltung auf eine kleine 6-Lagen Leiterplatte verfrachtet. Ein Zweilagen-Design ist beim TMC249 recht grenzwertig und es hat sich gezeigt, daß selbst kleinste Fehler sich hier massiv auswirken. Dieses Problem hatte ich wirklich unterschätzt, was dazu führte, daß im ersten prototypen, die maximal erreichbare Geschwindigkeit doch sehr übersichtlich war um es mal vorsichtig auszudrücken. Zudem hatte ich für die Sense Widerstände Drahtwiderstände eingesetzt. Diese wirken aber wie Induktivitäten und haben ständig den StallGuard(TM)-Mechanismus ausgelöst. In der neuen Leiterplatte sind extra eine Ground-Plane und eine Power-Plane vollflächig integriert. Ebenso sind die Außenlagen mit großen Masseflächen versehen. Durch den TMC457 konnte auch der Schaltungsaufwand nochmals deutlich reduziert werden.

Lanronix Xport Pro

Auf dem ersten Prototypen hatte ich ein Ethernet Interface mit einem ENC28J60 verbaut als Netzwerk-Schnittstelle verbaut. Das geht zwar prinzipiell, aber hatte auch deutliche Nachteile. Zunächst einmal die Schaltung. Diese kommt nicht ohne einige Zusatzbauteile aus. Ebenso muss man eine extra Netzwerkbuchse vernauen. Das Netzwerkprotokoll muss der Hauptcontroller bereit stellen, was sowohl Speicher- als auch Rechen-Resourcen frisst (TCP/IP-Stack usw). Aus diesem grunde habe ich nun den Lantronix Xport Pro im einstz dieser kostet zwar 59€, aber kann dafür fast alles allein. Er stell einen kompletten Webserver zur Verfügung. Der interne ARM-Controller kann auf 8MB Ram und 16MB Flash zurück greifen. Er unterstützt unterchiedlichste protokolle (TCP/IP, UDP/IP, ARP, ICMP, HTTP, SNMPv2, TFTP, FTP, usw.). Ebenso bietet er von Haus aus die modernsten Verschlüsselungstechniken. Ganz wichtig ist der Serial-Tunnel, der es ermöglicht über einen Virtuellen Com-Port auf irgendeinem Rechner dieser Welt über das INternet direkt auf den USART des XMega zuzugreifen. Dadurch kann man auch im Remotebetrieb auf die Steuerung über gewöhnliche Serielle Protokolle (z.B. LX200) zugreifen, als würde sie sich direkt am Rechner befinden. JAVA hab cih auch schon auf dem Teil am laufen gehabt, was die Bedienung der Steuerung über ein Java-Applet ermöglicht. Die Anbindung des Xport Pro erfolgt direkt über eine USART Schnittstelle des XMega (Port C).

VDIP-2-Modul

Eine Moderne Steuerung sollte in jedem Falle eine USB-Schnittstelle haben. RS232 ist einfach out und auch zu unflexibel. Zunächst wollte ich alles über einen FT232 realisieren. Leider bietet dieser aber keinen Host-Modus, was aber zur Kommunikation mit USB-Speichersticks oder USB-WLAN-Sticks zwingend nötig ist. Daher entscheid ich mich für den Einstz des FTDI Vinculum VDIP-2 Modules, welches zwei USB-A Buchsen zur verfügung stellt und in eine Herkömmliche 40-polige DIL Fassung passt. Das Modul wird seriell vomo zweiten USART am XMega Port C angesteuert. Übe rein einfaches Protokoll kann auf das Filesystem eines angesteckten USB-Speichersticks zugegriffen werden. Auch der Einsatz einer Maus, eines GPS-Empfängers (hab aber shcon einen im Handcontroller) oder eines USB-Keyboards sind denkbar.

Hauptplatine

Alle oben genannten Module befinden sich auf einer zweilagigen Platine um Europaformat 160mmx100mm. Durch den Einsatz von Modulen ist nahezu jede Komponente der Steuerung austauschbar. Ebenso konnte das Problem mit den Mehrlagenlayouts gelöst werden, die für den TMC249 und den TMC457 nötig sind. So kann die Hauptplatine zweilagig bleiben. Sie dient primär also als Modulträger und enthält nur wenige Baugruppen. Eine davon ist die Spannungsversorgung. IM alten prototypen wurden noch LM317 Spannungsregler eingesetzt um die Betriebsspannungen zu erzeugen. Nachteil dieser Lösung ist, daß der LM317 die Differenz aus Eingangs- und Ausgangsspannung förmlich verbrät. Hier war eine direkte Kühlung über das Gehäuse nötig. Jetzt kommen zwei Schaltregler zum Einsatz die aus der Eingangspannung (7-34V) die internen Versorgungsspannungen 5V und 3,3V (je 1,5A) erzeugen. Aus den 3,3V werden dann mit einem SMD-LM317 dann nur noch die 1,5V (100mA) für den TMC457 erzeugt). Eine Kühlung der Schaltregler ist nun nicht mehr erforderlich. Die Eingangsspannung wird auch als Motorspannung für die Schrittmotoren genutzt. Hierzu wird diese zusammen mit der Masse über eine 2x6 Pin Jumperleiste geführt. Steht eine eingangsspannung bis 30V direkt zur Verfügung, so werden hier Jumper aufgesteckt. Falls nur 12V zur Verfügung stehen, aber z.B. 30V gewünscht sind können die Jumper entfernt wedren und ein Step-Up Converter, der auf einer extra Platine sitzt aufgesteckt werden. Alle internen Spannungen sind über SMD-Elkos gepuffert. Ebenso gibt es Anschlüsse für SuperCaps. Diese dienen der kurzfristigen Pufferung der Versorgungsspannung im Falle eines Stromausfalls. So kann die Steuerung noch alle relevanten Daten sichern und in den Standby gehen. Die Lösung im vorherigen Prototypen über Goldcaps hatte versagt, da diese intern zu hochohmig sind und dadurch der interne Spanungsabfall so stark war daß die Spannung fast augenblicklich zusammenbrach. Goldcaps eignen sich nur zum Puffern von RTC oder Speichern. Ein Spannungswächterchip überprüft die Eingangsspannung und löst sofort beim deren Fehlen oder Unterschreitung eines Grenzwertes einen Interrupt am XMega aus. Ebenso erzeugt er die RESET Signale und der Reset-TAster ist hier angeschlossen.

Auch der RTC ist auf der Hauptplatine untergebracht. Er dient dem Speichern der aktuellen Uhrzeit. Zwar ist diese auch aus dem GPS Signal auslesbar, aber in einer gut geschirmten Aluminiumkuppel ist GPS empfang so eine Sache. Es wurde hier der DS11307 eingesetzt. Dieser und auch der integrierte Luftdruchsensor HCA811 bringt aber das problem de runterschiedlichen Busspannungen mit. Der I2C-Bus des XMega arbeitet wie der gesamte Prozessor mit 3,3V. Die beiden I2C-ICs arbeiten aber mit 5V was den einsatz eines bidirektionalen Level-Shifters nötig machte. Es gibt zwar Steuerungshersteller, die für sowas einfach Spannungteiler einsetzen oder sich drauf verlassen, daß der 5V IC auch sauber 3,3V erkennt, aber spätestens, wenn die Datenrate steigt kommt es zu Signalverschleifungen und Timingproblemen. Daher bin ich da lieber für eine saubere Lösung, zumal die nur 12ct kostet.

Als Schnittstelle für externe Sensoren wurde ein I2C Treiber-IC integriert. Dieser ermöglicht eine Erweiterung des I2C Busses bis auf 40m. Ohne ihn wären maximal 1-2m möglich, da dieser Bustyp eher für geräteinterne Kommunikation entwickelt wurde. Es stehen extern sowohl 3,3V als auch 5V Buspegel zur Verfügung. Zudem gibt es für I2C unzählige ICs, die auf andere Bussysteme umsetzen.

Neben der I2C Schnittstelle ist auch die Anschlussbuchse für die Encoder auf der Hauptplatine integriert. Die Encodersignale werden über eine Zusatzschaltung in Ihrer Flankensteilheit angehoben bevor sie dem TMC457 zugeführt werden. Dieser filtert dann intern nochmals digital. Hierdurch lassen sich sehr hohe Impulsfrequenzen verarbeiten.

Die Anschlussbuchse für den Handcontroller ist als 9 Polige SUB-D-uchse ausgeführt. Es werden hier zwei RS232-Kanäle sowie die Versorgungsspannungen übertragen.

Von den geplanten Sensoren sind zwei, nämlich der Luftdrucksensor und der Luftfeuchte-Temperatur-Sensor direkt im Steuerungsgehäuse verbaut. Der Luftfeuchtesensor sitzt direkt an der Frontplatte, und misst über ein kleines Loch in selbiger.

Auch wenn wegen der Encoder prinzipiell nicht mehr benötigt habe ich der Steuerung dennoch ein ST4-Kompatibles Autoguider-interface gegönnt. Hierfür wurde neben der standardisierten Buchse auch ein Optokopler auf der Hauptplatine integriert um die Signale zu entkoppeln.

Über einen Expansionsstecker sind sämtliche Busse (SPI, I2C) und mehrere Freie Port Pins sowie alle Versorgungsspannungen geführt. Hier können Erweiterungsplatinen aufgesteckt werden (auch gestapelt). Somit lassen sich andere Funktionen wie zum Beispiel die früheren Relais-Schaltausgänge, zusätzliche Sensoren, weitere A/D-Wandler usw. angeschlossen werden.

Erweiterungsplatine

Auf der Erweiterungsplatine sind alle zukünftig geplanten Komponenten untergebracht. Über den Expansionstecker auf der Hauptplatine sind alle Versorgungsspannungen, der I2C-Bus, der SPI-Bus, ein USART sowie einige freie Port Pins herausgeführt. Am USART wird über einen MAX232 die Autoguiderkamera angeschlossen. Weiterhin wird ein I2C Portexpander (Philips PCA9696) der zusätzlich 40 freie Port Pins zur Verfügung stellt. Einige davon werden mit Relais ausestattet und dienen so zur Schaltung externer Verbraucher (Taukappenheizung, Kaffeemaschine ;-), etc. ). Sollten weitere UARTs nötig sein, o kommt hierfür ein MAX3107 zum einsatz der über den I2C-Bis angesprochen wird. Ein MCP2515 Can-Bus Controller, der am SPI Interface hängt rundet die ganze Sache dann ab. Ebenfalls auf der Zusatzplatine befindet sich der Focusertreiber, sowie die Kuppel (Dome)-Steuerung.

 

Handcontroller

Die Platine des Handcontrollers ist als 2-lagen-Leiterplatte ausgeführt. Hauptkomponente ist hier ein ATMega128, der eine 6x4 Tastaturmatrix sowie diverse Sensoren auswertet. Die Kommunikation mit dem Hauptprozessor erfolgt über RS232. Die Tasten sind beleuchtet und die helligkeit kann durch den ATMega128 per PWM über eine Transistorstufe (BCX52) gesteuert werden. Analog wird die integrierte Astrotaschenlampe (2x rote LED) angesteuert. Per I2C sind an den ATMega ein MMA7660 Lage und Beschleunigungssensor sowie ein TSL2561T-Ambient Light Sensor angeschlossen. Über ersteren soll eine Bewegungsdetektion realisiert werden. Damit kann das Display nach einer Zeit der Ruhe ausgeschaltet werden. Sobald der Controller in die Hand genommen wird, schaltet sich das Display wieder ein. Der Anbient Light Sensor steuert die Displayhelligkeit entsprechend der Umebungslichtverhältnisse. So hat das Display bei Sonnenbeobachtung volle Helligkeit und bei Beobachtung in der Nacht wird dann gedimmt bzw. auf Nightview umgeschaltet.

Im ersten Prototypen hatte ich eine GPS-Maus mit PS2 Stecker im Einsatz. Eigentlich wollte ich dann auf USB-GPS-Mäuse umsteigen, was jedoch vom damals verwendeten FT232 vereitelt wurde. Der nun auf der Hauptplatine befindliche VDIP2 kann zwar USB-GPS-Mäuse auslesen, aber ich wollte die Schnittstelle nicht damit verbauen. Daher habe ich dem Handcontroller auch noch einen integrierten GPS-Empfänger gegönnt. Dieser ist mir 35€ auch nicht viel teurer als eine vernünftige GPS-Maus. Zudem hat er den aktuellsten derzeit ma makrt befindlichen Chipsatz mit recht hoher genauigkeit. Der GPS-Empfänger wird zusätzlich von einer 3V Knopfzelle gepuffert. So muss er nicht jedes mal einen Kaltstart hinlegen und hat recht schnell die Position.
Alle Sensordaten (Umgebungslicht, GPS und Lage bzw. Beschleunigung) werden über das Tastatur Protokoll an den Hauptcontroller im Basisgerät gesendet. Wie bereits erwähnt passiert das alles per RS232 wobei ein MAX232 zum Einsatz kommt. Damit kann das Anschlusskabel für den Handcontroller auch mal ein paar Meter länger sein.

Teuerste Komponente der Steuerung ist das Display (140€) .Dafür ist es aber auch erstklassig, aber darüer habe ich mich schon mal an anderer Stelle ausgelassen. Das Display ist auch direkt per RS232 mit dem XMega auf der Hauptplatine verbunden.

Fazit

Durch den Einsatz neuer Komponenten insbesondere in der Motorstufe konnte das Design schaltungstecnisch deutlich vereinfacht werden. Auch preislich bewegt sich Alles nun sehr nach unten. Der Aufbau in Modulbauweise ermöglicht eine bessere Reparatur falls doch mal eine Komponente das Zeitliche segnet. Der Einsatz des Xport Pro macht viele Resourcen in der Firmware frei, die nun für die Unterstützung von USB-Speichersticks genutzt werden können. Auf dem USB-Stick sollen später zum Beispiel die Sensordaten protokolliert oder neue Updates eingespielt werden.

 

Firmware

Die Firmware wird komplett in Pascal geschrieben. Hierzu kommt ein Multitasking system für AVR Microcontroller zum Einsatz. Prinzipiell könnte man die Firmware auch in C programmieren, aber da ich eine abgrundtiefe Abneigung gegen diese Gebilde, was sich Programmiersprechen zu nennen wagt, hege, habe ich mich für PAscal entschieden. Da hat wenigstens die Programmiersprache schon eine interne Fehlerprüfung und der Compiler prüft schon beim Compilieren auf Bereichsverletzungen. Zudem bietet das System umfassende Treiberunterstützung für alles was ich in der Steuerung brauch. Ebenso integriert ist ultraschnelle Fix64-Festkommaarithmetik, die um ein vielfaches schneller und genauer rechnet als Gleitkomma-Arithmetik. So können die astronomischen Positionsberechnungen nahezu in Echtzeit erfolgen. Anderenfalls bräuchte man hierzu mindestens einen ARM-Controller wie man gerade beim opendrive-Projekt sieht.