Beiträge von ckr7

Hmm...nun, es IST einfach, aber am Ziel bin ich noch nicht.

Ich kann z.B, Folgendes tun:

try
{
    string response = serialPort.ReceiveTerminated(terminator);
}
catch (Exception e)
{
    System.Windows.Forms.MessageBox.Show("timeout");
    throw new ASCOM.DriverException("timeout " + e);
}

Das tut auch, wenn der "terminator" nicht binnen timeout (default 5 Sek) kommt, dann triggered die Exception und meine MessageBox erscheint, aber NINA reagiert leider nicht (wie erhofft mit so einem roten popup). Finde ich jetzt merkwürdig, denn der Dome Driver tut an anderer Stelle im code exakt dasaselbe, wenn er nicht auf den für den Dome konfigurierten COM Port zugreifen kann.
Dort geht es aber.

Grüsse
Joerg

Edit:
Ich habe im NINA discord gefragt - geht nicht, exceptions müssen entweder sofort triggern oder gar nicht. Eine "verzögerte" exception, wie ich sie wollte, ist nicht möglich.
Schade, dann muss es bei der MessageBox bleiben. Besser als nix

Hi Alex,

ReceiveTerminated(x) ist das ganze Geheimnis?
Ich wusste, es ist einfach

Ich probiere es aus und lasse Dich wissen, ob es klappt.

Danke!

Hallo Alex

danke für die Antwort.

Ja, das ist eben so eine Sache mit den Methoden. Es findet ja erst mal gar keine Rückmeldung statt seitens Arduino.
Ich nehme dort ohnehin nur zwei mögliche Kommandos entgegen. Einmal ein simples "P", was meine Kuppel auf die Parkposition fahren lässt und sonst ein "T nnn.nn", wobei nnn.nn ein float Wert zwischen 0 und 359.99 ist. Aber das war es auch schon, die Kommunikation mit dem ASCOM Treiber ist also unidirektional, sofern man es dann überhaupt Kommunikation nennen will.

Das Problem ist also ein Grundsätzliches, denn mir ist weiterhin nicht klar, wie das bidirektional implementiert werden muss. Zwar habe ich Beispiele in Visual Basic gefunden, aber die helfen für die C# Implementierung leider nicht weiter. Wenn ich einfach wüsste, wie ich eine mögliche Rückgabe über den seriellen Port im ASCOM Treiber lesen kann, dann wäre der Rest wohl kein Problem. Ich müsste nur ein Signal definieren, was der Arduino sendet und mein ASCOM Treiber dann sehen und eine exception werfen kann.
Ich bin mir sicher, dass es trivial ist. Aber halt erst, wenn man weiss, wie es geht

Mit dem ascomtalk hatte ich überhaupt kein Glück. Ich habe mich dort schon vor etwa vier Monaten registriert, drei Mal eine Frage gestellt, welche drei Mal nicht publiziert wurde.
Das waren völlig normale Fragen, also nichts, was irgendwie gegen Regeln verstossen würde. Am Ende dachte ich mir dann, dass ich das echt nicht brauche und habe den Account wieder gelöscht.

Grüsse
Joerg

Ich bin (endlich) fertig mit meiner Gartensternwarte, der Antrieb der Kuppel läuft gut, gesteuert wird alles via Arduino. Den ASCOM Treiber habe ich in C# erstellt (aus dem ASCOM dome template).
Auch das läuft wunderbar, die Kuppel dreht sauber synchron zum Teleskop, ich bin also am gewünschten Punkt angekommen - ich kann am Schreibtisch sitzen und alles fernsteuern

Eine Sache ist aber noch offen, eventuell kann jemand helfen?

Ich habe eine Überwachung im Arduino eingebaut. Wenn der Motor läuft, muss sich die Kuppel drehen (logisch...). Das wird mit einem Drehgeber kontrolliert (und zwar unabhängig von der Motorachse!).
Wenn sich etwa zwei Sekunden nach Start des Motors die Position des Drehgebers nicht verändert hat, dann stimmt was nicht und der Motor stellt ab. Auch das klappt prima, aber.....ich sehe es nicht.

In NINA gibt es ja diese roten/gelben/grünen Popups. Ich möchte also jetzt, dass im Falle von "Dach bewegt sich nicht" so ein rotes Popup in NINA erscheint. Aber wie macht man das?
Es sind hier zwei Stufen im Spiel - zuerst muss der Arduino diesen Fehlerzustand an den ASCOM Treiber melden (wie?). Dann muss dieser seinerseits etwas tun, eine exception werfen, was NINA als Anlass für ein Popup erkennt.

Grüsse
Joerg

Freunde, ich habe ein unerwartetes und etwas ärgerliches Problem:

Ich habe meine Gartensternwarte soweit fertig und bin am programmieren der Steuerung. Die Kuppel ist drehbar und wird von einem Motor angetrieben.
Leider habe ich einen Designfehler gemacht. Die Öffnung im Dach ist zu schmal. Dreht die RA Achse der Montierung jetzt also weit genug aus der senkrechten, schaut das Teleskop nicht mehr vollständig durch die Öffnung der Kuppel.
Das ist erst mal nicht tragisch, ich muss nur die Kuppel ein wenig drehen, dann ist das wieder OK.

Also sagen wir, die Montierung steht "Ost" und aktueller Azimut ist 160°, dann muss ich die Kuppel z.B. auf 140° drehen, damit ich das Sichtfeld des Teleskops nicht durch das Dach abschatte. Easy.

Nuuur...das muss die Software meiner Steuerung machen. Also in Abhängigkeit des Azimuts des Teleskops. Und natürlich ist auch noch die Höhe das aktuell beobachteten Objekts relevant.
Ich habe mir da jetzt einiges überlegt, aber ich nicht nicht sicher, ob ich die Aufgabe in Gänze verstehe.

Von Ascom bekomme ich ständig den aktuellen Azimut des Teleskops. Mein Treiber nimmt diesen Wert und dreht die Kuppel auf denselben Wert. Wie eben erklärt ist das aber nicht ausreichend.
Kann ich jetzt bei Azimut < 180° einfach z.B. 20° abziehen und die Kuppel entsprechend drehen (weil die Montierung jetzt "Ost" steht) und bei Azimut > 180° nochmal 20° hinzuzählen (weil wir jetzt "West" sind) oder sind andere Fälle zu berücksichtigen? Je näher ich am Zenit bin, umso "egaler" wird es wohl, aber auch dort muss ich eventuell eine Korrektur machen.

Grüsse,
Joerg

Sofern eine gerade Fläche entlang des Daches besteht (Holzbalken etc.), kann man einfach eine Nut fräsen, eine Rollenkette einkleben (mIt Epoxidharz und Glasfasermatten umkeidet hält das perfekt).

Steuerung über einen Arduino, dann einen Schrittmotor, der via Ritzel in diese Kette greift als Antrieb. Gekoppelt mit einem Drehencoder lässt sich auch der Lauf prüfen (dIe Elektronik sagt "Motor läuft", der Drehencoder sagt aber "da bewegt sich nix" zeigt ein Problem an und man kann den Motor sofort stoppen und eine passende Art von Alarm oder Benachrichtigung auslösen).

Ich habe eine NEQ-6 und will mir eine EQ6-R zulegen. Ich nutze aber eine Betonsäule mit passendem Adapter für die NEQ-6.
Passt die EQ6-R da drauf?

Merci!

Hm....ich habe mal die qhyccd.dll im PHD2 folder gegen eine aktuelle Version ausgetauscht und im Moment scheint das tatsächlich geholfen zu haben....

Grüsse,
Joerg

Edit: Schön ist es nicht (Vorsicht, Masstab beachten!). Aber eventuell ist das noch "tunable".

Also das ist vollkommen sinnlos. Inzwischen kriege ich mit PHD2 gar nichts mehr zustande, aber ich fürchte jetzt, das liegt an meiner "alten" Guiding Kamera.
Es ist eine ALccd5L-IIc, welche allerdings als QHY erkannt wird. Das mag ein Problem für sich sein, oder auch die Tatsache, dass ich eben eine QHY 268c als "Hauptkamera" dran habe.
Auf jeden Fall crasht PHD2 meistens mit dieser Meldung:

Faulting application name: phd2.exe, version: 0.0.0.0, time stamp: 0x621482e8

Faulting module name: qhyccd.dll, version: 21.3.13.17, time stamp: 0x604c811c

Was man wohl als einen Hinweis auf eine Treiberproblem deuten kann.
Ich fürchte, ich muss eine Kamera kaufen. Das ärgert mich jetzt gaaaar nicht

Hat jemand eine Empfehlung, eventuell grade für die Kombination PHD2 und QHY 268c? Auf jeden Fall soll es keine QHY sein, falls es wirklich ein Problem mit zwei von den Teilen gleichzeitig geben sollte.

Grüsse,
Joerg

Ich bin auf der Suche nach etwas Starthilfe zum Thema.

Meine fast fertig gebaute Gartensternwarte hat eine rotierbare Kuppel, ich bin grade dabei, den Motor dafür mit einem Getriebe zu versehen.

Die Steuerung geht über einen Arduino, ich kann die Kuppel dann auf eine bestimmte Position drehen (also die Öffnung der Kuppel natürlich) und ich habe eine definierte Parkposition.

Was ich nun brauche, ist eine Anbindung an ASCOM (also einen Dome-Controller). Mein Protokoll für die Kommunikation wäre simpel, ich brauche nur die aktuelle Blickrichtung des Teleskops aus ASCOM um diese an den Arduino zu senden.
Ausserdem möchte ich auf "geh Parken" seitens ASCOM reagieren können.

Ich habe auf YT einen recht guten Video gefunden, aber der ist noch aus VB Zeiten und ASCOM scheint nur noch .NET zu unterstützen. Ich habe zwar keine Lust, NOCH eine Programmiersprache zu lernen, aber der Scope hier ist ja überschaubar.

Kann da jemand helfen? Hat wer schon mal einen Treiber, idealerweise eine Dome-Treiber, erstellt?
Jede Starthilfe zum Thema ist willkommen, dann muss ich nicht erst die ganze ASCOM Doku lesen (von welcher ich am Ende 2% brauche).

Grüsse,
Joerg

Ich habe die EQMOD Settings grade heute Abend nochmal geprüft.
Sie standen wieder auf 0.1, was sehr merkwürdig ist, denn ich hatte das vorgestern geändert. Weiss nicht, warum es das zurückgesetzt hat.
Aber 0.9 hatte ich vorher nicht, ich werde das testen, wir haben ja ein paar weitere klare Nächte in Aussicht.

Ja Klaus, das Teil habe ich auch schon bewundert. Aber im Moment ist einfach kein Budget mehr vorhanden.
Aber aufgeben ja sowieso nicht, ich bin ja mit meiner Gartensternwarte fast fertig. Die Motorsteuerung der Kuppel ist in Arbeit, einen Treiber für ASCOM muss ich dann noch schreiben.
Ich will Azimut der Montierung und Öffnung des Daches synchronisiert haben...

Grüsse,
Joerg

....und ich habe gerade völlig genervt aufgegeben. Es ist hoffnungslos, irgendwas mit meinem kompletten Setup ist daneben und ich habe keine Ahnung, was es sein könnte.

Erst Mal ist PHD2 völlig unberechenbar. Grade läuft noch alles gut, Guiding im Rahmen von +/- 1, dann dreht er völlig durch und korrigiert wie irre durch die Gegend. Idealerweise crasht dann die Teleskop-Verbindung von NINA zu EQMOD. Das wiederum hat aber mit PHD2 zu tun, denn ohne PHD2 guiding scheint das nicht zu passieren.
Das Wiederherstellen der Verbindung zum Teleskop hilft auch nichts, denn irgendwas ist dann zerschossen seitens EQMOD, die Montierung bleibt irgendwie stehen, soll heissen, mindestens eine Achse läuft nicht weiter. Es ist aber auch nichts mechanisches, denn ich kann ohne Probleme "Park" sagen und das wird sofort ausgeführt.

Im PHD2 log steht gar nichts dazu (das endet einfach), im Windows Eventlog gibt es was, aber das hilft auch nichts. Entweder er hat was mit dem QHY Treiber zu maulen oder noch sinnloser mit MSVCR90.dll als "faulting module", was zur Fehlersuche genau gar nichts nützt.

So macht das echt keinen Spass

Grüsse,
Joerg

Gestern Nacht lief das nun soweit problemlos. Allerdings mit dem wesentlichen Unterschied, dass ich das neu gelieferte EQMOD Kabel einsetzen konnte und damit also einen anderen Montierungs "Typ" in N.I.N.A. und PHD2 hatte.

Trotzdem ist PHD2 2x mal ohne erkennbaren Grund gestorben. Es hat sich einfach beendet, keine log-Einträge, die auf Fehler hindeuten würden.
Aber das guiding war soweit sehr ordentlich und alle Bilder sind scharf.

Grüsse,
Joerg

Settings siehe unten, die Aggressiveness habe ich mal auf 50 geändert.
Sind die guiding-Algorithmen so OK?

Grüsse,
Joerg

Ich weiss nicht, ob es eine "dumme Frage" ist. Vermutlich nicht.

Das war erst meine vierte Foto-Session überhaupt mit NINA und PHD2, ich habe also keine Erfahrungen damit.

Das macht es sehr schwer, verstehen zu wollen, was da nicht stimmen könnte. So richtig rund lief das bisher noch nie, aber zumindest vorgestern war das Guiding über 2 Stunden OK.
Ich habe seither eigentlich nichts geändert und gestern war alles völlig daneben, trotz etlicher Versuche, der Ursache auf den Grund zu kommen.

Grüsse,
Joerg

Kollegen, was mache ich nur falsch?
Nachdem ich die letzten Tage (bin Frischling bei dem Thema) ein halbwegs funktionierendes PHD2 Guiding hatte, spinnt heute Abend alles nur noch rum.
Abgesehen davon, dass PHD2 immer wieder einfach "stirbt", ist das guiding völlig planlos. Kalibrierung ist OK, den Assistant habe ich auch laufen lassen, Einnordung ist 1A.
Es ist eine NEQ-6, sie trägt nur einen kleinen Refraktor, Balance ist OK. NINA ist im Einsatz. Belichtungszeit in PHD2 scheint keine grosse Rolle zu spielen, ich habe alles von Auto bis zu 5sek fix probiert. Ich bin über einen off-axis Guider dran mit einer ALccd5L-IIc. Seeing war gut, ich habe Tests gemacht mit hoch und tief stehenden Sternen, alles egal.

Was ist also der Grund für das Chaos?

Grüsse,
Joerg

Ich habe seit Kurzem ein Askar FRA 400. Angeschafft wurde es für Astrofotografie (mein Newton ist einfach zu sperrig).

Da kam mir in den Sinn, dass der kleine Racker doch ein prima Spektiv auf einem Fotostativ abgeben würde und in der Tat, so ist es.
Allerdings brauche ich eine 35mm und eine 50mm Distanzhülse, damit ich in den Fokus komme. Dann habe ich noch etwa 15mm am Auszug, die ich "noch weiter raus" drehen könnte.

Natürlich wäre für den Einsatz als Spektiv eine seitenrichtige Darstellung fein. Also ein Amici-Prisma.

Ich hatte so etwas noch nie. Wie wirkt sich das jetzt aus? Muss ich dann noch weiter "raus", also längerer Lichtweg? Das könnte knapp werden.

Danke!

Hallo zusammen,

die Gartensternwarte steht endlich, mit 5 Jahren Verspätung. Geplant und gebaut habe ich sie eigentlich für visuelle Beobachtung mit meinem 10" UNC.
Inzwischen hat sich die Ausgangssituation aber geändert. Es geht mir nur noch um Fotografie und dafür ist der UNC nicht ideal. Kamera ist eine QHY268c.

Wie auch immer, ich möchte einen Refraktor anschaffen für diesen Zweck. Aber ich hatte noch nie einen, in den letzten gut 30 Jahren waren es nur Newtons oder Maks.
Ich habe versucht, mir einen Überblick zu verschaffen und bin gelandet bei:

(TS) 76 EDPH
William Optics GT 81
William Optics RedCat 71

Preislich ist das halbwegs vergleichbar, mehr als 1500€ soll es nicht sein. Das RedCat fällt eigentlich aus, weil ich einen ZWO Motor-AF habe und das mit dem Riemenantrieb behagt mir nicht.

Was meint Ihr? Ich bin um jeden Hinweis froh und weitere Alternativen wären sehr interessant.

Grüsse,
Joerg

Aufgebaut....tatsächlich und nur 5 Jahre später als geplant.
Ist aber noch viel zu tun. Mein rotierendes Dach tut noch nicht. Es geht grundsätzlich zwar sogar sehr gut, aber es verliert die Zentrierung und "hakt" dann.
Meine Rollen von oben sind also eine Fehlkonstruktion. Das ist etwas verwunderlich, weil alle Versuche zuvor einwandfrei waren. Mir ist nicht klar, was jetzt anders ist.

Wie auch immer, ich mache andere Rollen und sehe dann weiter. Zur Nor muss ich noch einen Mechano bauen, der das Dach bei Drehung in Position hält.

Es geht voran und die Sternwarte würde stehen, wenn mich das Wetter derzeit nicht bremsen würde.
Trotzdem, lang geht es nicht mehr.

Ich habe mich entschieden, meine eigenen Rollen zu entwerfen. Allerdings habe ich 16 Stück davon im Einsatz, mal sehen, wie gut das am Ende funktioniert.

Das Dach ist an sich fertig und liegt schon seit zwei Wochen draussen. Der Unterbau ist aber eben nicht fertig.

Ich hoffe, dass bis Mitte November alles aufgebaut ist...

Freunde, bitte helft mir mal:

Die Gartensternwarte ist im Bau, in den nächsten Wochen wird sie fertig sein. Fünf Jahre später als geplant

In 2016 habe ich mir extra dafür ein neues Teleskop angeschafft, ein UNC25412 von TS. Aber damals war eigentliche die visuelle Beobachtung im Fokus.
Inzwischen, im Zeitalter von Automatisierung und Fernsteuerung mit NINA und Co., ist es die Fotografie. Schlussendlich geht das auch mit dem UNC25412, aber für Deep Sky wird da die Brennweite von 1250mm eher hinderlich sein.

Kaufen muss ich so oder so eine Kamera. Ich schwanke derzeit zwischen der ZWO 294MC Pro und der ZWO 533MC Pro. Ich habe das mit Stellarium durchgespielt, "Grossfeld-Aufnahmen" liegen mit beiden nicht drin, aber die 294 bietet wenigstens etwas mehr Bild. Aber die 533 hat, soweit ich verstehe, den besseren Sensor.

Eigentlich "muss" ich wohl einen fototauglichen Refraktor mit 400-600mm kaufen, aber das Budget ist durch den Bau der Sternwarte ausgereizt. Für mehr als die Kamera und einen Motor-Fokus langts jetzt und vorerst nicht.

Meine Frage wäre also - in Anbetracht dessen, dass ich gerne jetzt eine Kamera kaufen würde, was soll ich tun? Hat mir jemand einen Rat, was jetzt zum UNC25412 passt mit 1250mm und später gut mit einem APO o.ä. harmoniert?
Oder fahre ich in eine Sackgasse und habe am Ende weder Fisch noch Fleisch?

Danke
Joerg

Danke René!
Nebenbei ist die Idee mit der Kette noch clever, das merke ich mir für meinen Antrieb!

Zitat von Instrumentarium

… vor diesem Hintergrund würde ich nochmal den Gedanken der Spurkranzräder hervorholen. Schließlich ist die Kuppel kein Teleskop-Azimutallager mit höchstem Präzisionsbedarf. So in Spurkranzrad der Art. Auf der Innenseite der Kuppel befestigt. Dürften direkt auf dem Rund des Unterbaus rollen. Damit geht erstmal nichts kaputt … und hinterlassen im Holz ausser den Achsbohrungen im Unzufriedenheitsfall keinen „Schmutz“. Die „unzufriedene“ Achsbohrung bekäme in dem Fall ein Rundholz als Lochstopfer eingeleimt und alles ist auf „Null“ zurückgesetzt und dürfte neuer Lösungen entgegenschauen …

oha.....das mit den Spurkranzrädern habe ich gar nicht geschnallt

Das ist eine super Sache, die Dinger drehe ich doch mal kurzerhand selbst und probiere das aus!
Paar Kugellager noch einkaufen und es kann los gehen. Das mache ich!

Danke!

ah, die. Okay.
Könnte ich mit Distanzhülsen für die Schrauben verwenden, ja. Ich will keine Vertiefungen für die Räder machen.
Wenn ich wüsste, ob das am Ende damit sauber tut, würde ich schon. Aber wenn nicht, dann habe ich Löcher in meinen Holzringen die ich da vermutlich dann nicht haben will

Ich weiss, ich bin möglicherweise etwas zu übervorsichtig. Aber gut studiert ist meistens am Ende auch gewonnen....

Womit Du natürlich recht hast.

Auch mit balliger Lauffläche heissen sie Bockrollen, dann eben "Bockrollen mit balliger Lauffläche"
Ich habe aber noch keine Fertigen gefunden, also Rolle mit Halterung dabei. Eigene Halterungen baue ich dafür nicht, da nehme ich dann eher Bockrollen mit gerader Lauffläche.