Hallo Wolfi,
ich selbst mache beim Autoguiding keine Darks.
DEC: bißchen backlash ist nicht schlimm. Gemessen hab ic es nie. Ich balanciere aber das Teleskop so aus, daß es ein wenig auf der Schneckenflanke schwimmt.
DAs ist beim Guiding einfacher. Wenns zu stramm ist, isses auch nix.
Tolles Projekt! 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
...
nur der okularauszug vom 100/1000 Skywatcher Frauenhofer-leitrohr muss dringend weg, aber das ist ein mechanisches problem. zwei fragen hab ich:
- braucht man darks für den autoguider? sie einzubinden ist kein drama, aber irgendwie nach meinen erfahrungen würde ich das eher hintansetzen ...
...
lg
wolfi
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Hallo Wolfi,
ich bin auch der Meinung, dass man Darks nicht unbedingt braucht. Aktuelle Kameras sind empfindlich genug um Bilder bei noch moderaten Belichtungszeiten zu liefern ohne Hotpixel zu zeigen. Hängt natürlich auch vom Guidungrohr ab, ob man noch genügend helle Sterne findet. Wäre dann doof, wenn man auf ein Hotpixel nachführt, auch wenn die Guidingkurve dann super aussieht [B)] Das Problem könnte man aber auch anders abfangen. Ein Hotpixel ist ja ziemlich statisch im Bild, wenn nach z.b. 5 Bildern keine Änderung am "Stern" meßbar ist, einen Fehler generieren. So als spontane Idee.
Gruß Dirk
hi!
hotpixel - also das, was man als salt and pepper noise bezeichnet - killt eh der medianfilter! ich werde die darks einmal hintanstellen und stattdessen schauen, ob das guiding überhaupteinmal funktioniert.
eine frage ist mir noch gekommen: ich hab als letztes noch ein ST4-interface reinprogrammiert - ist ja mit dem gpio vom pi kein echtes problem. aber je mehr ich drüber nachdenke, desto misstrauischer werde ich ob der sinnhaftigkeit einer digitalen st4. meine korrekturpulse, die ich mir so ausrechne (hoffentlich stimmen sie ) sind so in der grössenordnung 50 - 350 ms bei siderealer geschwindigkeit. nachdem st4 ja knallhart ein/aus ist, renne ich da in ein samplingproblem ... und zwar egal, was ich verwende. die latenzen vom arduino sind laut interwebs bis zu 100 mikrosekunden, ich gehe jetzt einmal davon aus, dass daher die eventqueue vom z. B. ATMEL auch keine sehr viel höhere frequenz als 20 Hz hat (so habe ich meine queue jetzt eingestellt, und weil der pi doch 1.2 GHz hat, kostet ihn das auch nix). das heisst aber, dass ich bei der abfrage schlimmstenfalls einen fehler von 50 ms mache. und das ist kein raspberry problem, das hat jeder, der st4 - egal mit was - über GPIO ausliest. beim original waren das ja relais, da hat das ein/aus sinn gemacht. aber digital halte ich das für einen designfehler ...
oder hab ich was falsch verstanden? ich werde auf jeden fall einmal probieren, ob der interne autoguider (der geht ja nicht über st4, sondern rechnet steps aus) einen unterscheid zu externem guiding mit st4 macht ...
lg
wolfi
Hallo!
Bevor ich einen neuen Thread eröffne - hier nun einmal ein Link zur vollständigen Beschreibung auf GitHub . https://github.com/selste/TwoStepperControl/wiki/TSC ... Kommentare und Anmerkungen willkommen
lg
wolfi
Hallo Wolfi,
klasse gemacht! Wirklich.
dankeschön gibt aber noch viel zu tun
lg
wolfi
hallo!
kleines update:
-ASCOM geht mit dem Advanced LX200 treiber, skytechx und cartes du ciel syncen und slewen einmal brav. da soll noch wer sagen, ich hätt kein herz für windows (den scchmarrn, den elendichen) ...
-ich hab mir einen internen rs232 konverter fürs lx200 eingebaut. kein externer konverter mehr, kein nullmodemkabel, sehr angenehm 
lg
wolfi
... und eine Liste der genauen Details ist auf dem Wiki: https://github.com/selste/TwoStepperControl/wiki/TSC
ganz kurz: mit dem Advanced LX200 treiber, der auch slews mit meridianflip unterstützt, gehen CdC 4.0, SkyTechX 1.05 und C2A. Hallo Northern Sky zickt mit dem ASCOM treiber herum und läuft nicht stabil. die handbox-funktionalität des ASCOM treibers (also das bedienfeld von der software) geht noch nicht, ich muss erst einmal kapieren, wie das genau funktionieren soll
stellarium ist ein sonderthema: die direkte kommunikation über die serielle schnittstelle ist nur zum tracking, also zu visualisierung der teleskopposition brauchbar. syncen kann stellarium so nicht, und das, was es als slew bezeichnet, folgt nicht dem LX200 protokoll. das programm sendet nur koordinaten, nicht aber den befehl, den slew auch auszuführen - vermutlich kann es deshalb auch nicht syncen, da der befehlsablauf übermitteln von kooridnaten und dann sync oder slew ist. wenn man nur koordinaten übermittelt und dann erwartet, dass der controller dann sofort den slew macht, widerspricht das dem LX200 protokoll. und ASCOm ist scheinbar nur über eine andere software, nämlich stellariumscope eingebunden - und die fliegt mir um die ohren, wenn ich den Advanced LX200 treiber lade. der standard LX200 treiber ist leider unbrauchbar ...
unter linux geht cdc und stellarium halt nur mit tracking. kstars muss ich noch einbidnen, da rumpelts irgendwo
lg
wolfi
Hi,
Das ganze mit stelarium stimmt nich so gsnz.
Sync macht er nicht, das ist klar.
Aber slew, den macht er nach lx200 soweit ich mich erinnere.
Gruß
Igor
Hallo wolfi,
Der stelarium führt den :MS# Befehl aus.
Ich benutze es seit jahren schon.
Ich weiß es 100% auch weil ich genau diese Befehl benutze um es zu synchronisieren.
Dabei entscheide ich selber auf arduino (taste) ob das ein sync ist was grade gekommen ist oder wirklich ein slew.
Einfach oder 
Gruß
Igor
Stellarium macht den goto mit Steuerung 1.
Also objekt anklicken und dann steuerung taste und taste 1.
Dann macht er den sr und sd und ms Befehl hintereinander.
Ganz normal bei mir alles.
Poste mal dein log.
Gruß
Igor
hi!
und wenns stellarium nicht tut - wursxht, dafür aber zwei dinge, die kleinigkeiten sind, mich aber trotzdem mit gewisser genugtuung erfüllen:
1.) kein nullmodemkabel und kein externer rs232 adapter mehr
2.) VNC anbindung ohne wlan über einen vom pi initiierten hotspot und auch ohne monitor am pi - wenn man will 
lg
wolfi
Hi Wolfi,
sehr schön, ich benutze auch INDI mit eine raspbery pi.
Der Fehler ist mir nicht aufgefallen.
Kann aber an der lx200 skript liegen.
Freut mich dass es klappt!
Grüße
Igor
hi!
... und - nun auch mit meridian flip. ich denke, wenn einmal eine alternative schnittstelle zu anderen schrittmotortreibern geschaffen ist (RAPS, oder DRV8825, und am ende auch dspin), dann kann man es ein alpha nennen
eine frage habe ich: ich habe jetzt einmal die DRV 8825 mit einem arduino ein wenig herumgesteuert und habe sie mit einem encoder überprüft. ohne last sind die teile schon ganz genau. was meints ihr - wenn man encoder unterstützt, welche sollten das sein?
- argo navis oder ähnliches - 2 bogenminuten auflösung, kosten 100 € pro achse. was würde das bringen??
- HEDSS IHC 3808 o. ä. - auch nicht ganz billig (~ 50 €), kann man wg. der auflösung nur sinnvoll an der motorachse anbringen - braucht man das ??
- irgendwas superteueres mit hoher auflösung ...
lg
wolfi
Hallo Wolfi,
die Encoderauflösung auf der Montierungsachse sollte schon Sinn machen. Während für den visuellen Einsatzzweck vielleicht Auflösungen im Bogenmintuenbereich ausreichend sind und
die Steuerung manuelle Schwenks dann erlaubt (EQ8 z.B.), dann ist das ok.
Photographisch machen aber nur hochauflösende Encoder Sinn. Und da kannst Du mit den Dingern in Deiner Liste nicht landen.
Solltest Du die Encoder via Übersetzung an die Achse anschließen. Freu Dich nicht zu früh. Dann hast Du i.d.R. den Getriebefehler des Vorgeleges zum Encoder im System.
Damit kann man Guiding nicht umsetzen oder verbessern.
Hier sollte man also auf hochauflösende Encoder setzen. Z.B. einen Gurley R158, Heidenhain ERN180 oder ERN480 und Renishaw.
PRoblem bei den Dingern ist aber, daß man mit einem Iterpolation Error zu tun hat, den es zu kompensieren gilt.
Herausforderung ist auch: Die Dinger sind intern Sin-Cos-Encoder und werden via Interpolation ausgelesen (vereinfacht: Aus dem Sin-Cos Signal wird eine Position ermittelt).
Für diesen Zweck gibt es dann Interpolatoren, die wiederum ein RS422 A/B signal ausspucken. Der Gurley hat sowas "On Board".
Was heißt das für die Steuerung? Man berechnet die Anzahlt der Ticks pro Gesamtumdrehung genau einmal und liest die aktuelel Position über die A/B Kanäle über anschließende
Quadratur aus.
Ich wrüde mal sagen: Bis dahin hast Du noch einige Hausaufgaben zu machen, denn das ist schon eine Herausforderung.
Und das gibt es fertig: Sidereal Technologies Sitech Steuerung. Die unterstützt: Encoder an den Motoren (Servos) und Achsencoder.
hi!
ich bin eh ganz bei dir - wenn es auf der achse ist, dann muss es sinn machen und sollte nicht über grossartige untersetzungen implementiert sein. und wie du richtig sagst, mit den 08/15 dingern schau ma da schlecht aus. das auslesen etc. von einem heidenhain etc. stresst mich hingegen nicht im geringsten, mehr schon der preis, ein ERN 180 liegt so bei 700 €, was ich mich erinnere.
die sidereal technologies lösung schaut auch interessant aus. auch klar, dass sie encoder braucht, wenn sie mit servos lauft. nur - hast du dir einmal angeschaut, was das gebastel (und was anderes ist es nicht) kostet? 895 USD fürn controller, wireless handpad 350 USD und - mein liebling, der Bluetooth to Serial adapter - ein FTDI adapter mit einem HC05 draufgelötet für lächerliche 129 USD im liebevollen Schrumpfschlauchgehäuse ... ich könnte mir das sogar leisten, aber ich werds sicher NICHT tun
aber danke für Deinen input!
lg
wolfi
Hallo Wolfi,
ist ja nett, daß Du die Arbeit anderer als gebastel ansiehst. Bis lang war die Sache ja noch Sympathisch.
Aber an der Stelle muß ma eigentlch das Diskustieren aufhören.
Ich denke Du bist im Moment noch weit davon weg abschätzen können, worin der Mehrwert in der Blackbox Namens "Sitech" besteht.
Im übrigen sogar unterhalb von 1000 Euro die fortschrittlichste Steuerung auf dem Markt.
Schau Dir mal die Doku an.
Hier mal ein paar nette Referenzen, was mit der Sitech geht:
http://www.poguntkeweb.de/sternwarte/umbaudermontierung/
Ein weiteres Beispiel:
Mit Gurley R158, 320K Encoder auf RA. Treibt schon über 150 kg an Last der Faulhaber Servo:
Unguided dann PE = +/-0,5 arcsec.
Und das Forum zur Steuerung zeigt einige erfolgreiche Anwendungen.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
