Wolkensensor mit Bordmitteln

Status
Es sind keine weiteren Antworten möglich.
willfrid

willfrid

Mitglied
Hallo Freunde der Nacht,

da ich mir dieses Jahr eine Gartensternwarte mit elektrisch betriebenem Rolldach gebaut habe, lag es nahe, diese remote bzw. autark zu betreiben.
Dabei muss eine Menge an Ausrüstung zusammenwirken bei langen Belichtungszeiten, tlw. über mehrere Stunden mit vielen Aufnahmen.

Eine entscheidende Erleichterung dabei sind sog. Sequenzer-Programme, z.B. N.I.N.A. oder Sequence Generator Pro, die das gesamte Equipment verwalten und mittels Sequenzen die Aufnahmen automatisieren können.

Aufgrund der langen Aufnahmesequenzen besteht die Gefahr, dass Wetteränderungen wie Wolken, Regen, Schnee oder Wind nicht rechtzeitig erkannt werden, die Aufnahmen negativ beeinflussen und das Equipment schädigen.
Einen Regensensor halte ich für überflüssig, denn bei Regen säuft die Technik ab, nicht zu vergleichen mit Tau oder Frost.
Daher finde ich es wichtiger, die Wolken zu überwachen, denn Wolken kommen immer vor dem Regen und dann kann reagiert werden, bevor alles nass ist.
Zielstellung ist also das Erkennen von Risiken durch Wetteränderungen und rechtzeitiges Einleiten eines sicheren Zustandes. Dabei soll keine zusätzliche Hardware erforderlich sein.

Nach meinen Recherchen gibt es verschiedene professionelle oder Eigenbaulösungen (SQM-Meter), denen die Messung der Himmelstemperatur bzw. Differenztemperatur zugrunde liegen oder auch mittels Webcam.
Dies würde zusätzliche Hardware erfordern.

Lösungsansatz
Die o.g. Sequenzer-Programme beinhalten einen Safety-Monitor, der dazu geeignet ist, bei bestimmten unsicheren Bedingungen (z.B. Wetteränderungen) entsprechende Reaktionen auszulösen. Unterstützt wird jedoch nur der ASCOM-Standard für Geräte und Software.
Ich und mein Freund Micha (kein Astro-Verrückter) haben dazu ein Software-Tool zur Lösung der o.g. Probleme entwickelt und möchten dieses hiermit vorstellen.

Eine elegante Möglichkeit mit vorhandenen „Bordmitteln“ ist die Nutzung des Guiding-Systems, unabhängig ob mit Guidescope oder Off-Axis-Guider.
Es ist üblicherweise eine Kamera mit einer beheizten Optik vorhanden, die bei Aufnahmen gen Himmel gerichtet ist.
Die Guiding-Software, z.B. PHD2, erfasst den relevanten Bereich des Himmels und errechnet bei jeder Aufnahme den SNR-Wert (Signal to Noise Ratio).
Dieser Wert ist bei klarem Himmel sehr hoch und sinkt, sobald sich die Sicht verschlechtert.
Ursachen können sein:
  • Wolken
  • Nebel
  • Taubeschlag auf der Linse
Es kommt nicht darauf an, den ganzen Himmel in Echtzeit zu überwachen, sondern den regionalen Bereich.
Auch durchziehende Wolken sollen das System nicht beeinflussen, sondern erst dauerhafte Verschlechterungen über längere Zeit, z.B. bei nahendem Regen, sollen einen sicheren Zustand zur Folge haben, d.h.
- Aufnahmen beenden,
- Guiding beenden
- Montierung in definierte Position fahren
- Dach schließen

Die Beschreibung und Anleitung zu diesem Software-Tool findet Ihr im Anhang:

Falls Interesse besteht oder bei weiteren Fragen , bitte melden.
Das Tool soll kostenfrei zur Verfügung stehen.
 

Anhänge

Hmm, so ganz sicher bin ich mir nicht, wie gut das funktioniert. Wenn du z.B. etwas 20 Grad über dem Horizont aufnimmst, kann das Guiding super funktionieren und trotzdem hast du gerade eine Gewitterwolke über dir. Gerade Regenfronten kommen ja gerne mal (meist von Westen) rein und in die andere Richtung sieht es dann u.U. noch gut aus. Mir wäre das wohl zu riskant.

CS, Daniel
 
Also ich finde das ne super Idee. Man könnte doch sicherlich auch ein extra Teleskop (Sucher) mit einer billigen Kamera einfach in Wetterrichtung installieren und nur das als Überwachung heranziehen( hab ich jetzt zufällig übrig). Bei uns kommt das Wetter eh meist aus West Süd West und abends mal den Wetterbericht checken sollte man ja sowieso. Ich würde mal implementieren und rumspielen.
Ideal wäre natürlich das ganze irgendwie mit der allskycam hier aus dem forum zu koppeln. Da müsste man natürlich wieder programmieren, z.b. Sektoren definieren und die einzelnen snr Werte entsprechend interpretieren machen.
Da bin ich allerdings raus. Wo kann ich das Programm denn downloaden?
Grüße Sebastian
 
Hallo Michael,

sehr spannender Ansatz, die SNR Werte aus PHD2 zur Einschätzung der Bedingungen zu verwenden. Man muss dann nur einmal SNR-Schwellenwert beim durchziehen von Wolken ermitteln.

Im besten Fall hat man, wie Sebastian schon schreibt, einen Sucher+Kamera übrig und kann diesen fest installieren oder eine Allsky-Kamera nutzen. Man müsste mal probieren, ob PHD2 dann auch SNR Werte ausgibt, obwohl kein Guiding im eigentlichen Sinne stattfindet.

Grüße,
Alexander
 
Hallo,
mir ist bewusst, dass das Sichtfeld der Guidingkamera ziemlich eingeschränkt ist und ggf. flach in Richtung Osten gerichtet ist während sich das Regengebiet von Westen heranschleichen könnte. Dafür habe ich natürlich vorgesorgt.

Das System besteht bei mir aus folgenden (Software-) Komponenten:

1. Guidingcam mit PHD2
2. SnrLogChecker-Tool zur Auswertung des SNR (von PHD2)
3. ASCOM SafetyMonitor Hub zur Einbindung des ASCOM Environment Safety Monitor Driver und des Generic ASCOM File Safety Monitor
4. N.I.N.A. Safety Monitor für Einbindung in Advanced Sequenzer

Vor Beginn der Aufnahmen stelle ich im Advanced Sequencer die Sequenz zusammen und binde übergeordnet den Safety Monitor (s. Abb.1) zur Überwachung ein.
Mittels Wetteronline.de schaue ich mir die Wettersituation der kommenden Stunden an und berücksichtige das im meiner Sequenz (Aufnahmedauer).

Damit bei plötzlicher Wetteränderung trotzdem keine unangenehmen Überraschungen eintreten, habe ich den ASCOM Environment Safety Monitor Driver zusammen mit OpenWeatherMap eingebunden (s.a. Abb.2) und kann hier z.B. Niederschlag oder Windgeschwindigkeit in der Region mit überwachen.
Sobald ein eingestellter Grenzwert überschritten ist, geht die Anzeige auf ROT und nach Ablauf einer eingestellten Karenzzeit fährt das System in den sicheren Zustand.
Die Karenzzeit für alle überwachten Parameter ist wichtig, damit nicht bei jeder kleinen Wolke oder Windböe die Sequenz abgebrochen wird.

Abb.1: Safety Monitor
Safety-System_k.jpg


Abb.2: OpenWeatherMap
OpenWeatherMap.jpg


Falls Ihr euch fragt, warum ich selbst einen Wolkensensor mit GuidingCam brauche, wenn doch OpenWeatherMap (Wetter-App) alle Daten liefern könnte, dann habe ich die Erfahrung gemacht, dass die Daten der Wetter-App nicht genau mit den Verhältnissen an meinem Standort übereinstimmen und gerade die Wolkensituation eine ganz andere sein kann, als von der App vorgegeben.
Wenn allerdings Regen in der Nähe ist oder starker Wind, dann stimmen diese Angaben besser und ich gehe dann lieber auf Nummer Sicher, bevor mir die Anlage Schaden nimmt.

Stehe gerne für weitere Hinweise und Fragen zu Verfügung
CS Peter
 
Wolken haben erstmal nicht unbedingt viel mit Regen zu tun, sie können aber die Aufnahme-Session ruinieren.
PHD2 meldet sich bei schlechter Sicht (geringer SNR-Wert) akustisch und bei besserer Sicht entfällt die Signalisierung wieder.
Ist ja alles kein Problem, wenn ich die ganze Zeit daneben sitze und entscheiden kann, ob ich warten soll oder die Session beende.
Diesen Fall hatte ich öfter, obwohl laut OpenWatherMap keine Wolken angezeigt waren, es waren aber Wolken da und es wurden mehr, so dass ich entschied, abzubrechen.
Aber sobald die Sache autark laufen soll, muss die Technik selbst entscheiden.
Wenn längere Zeit Wolken sind (nicht bei einer Wolke), breche ich halt ab, egal ob 2h später vielleicht wieder eine Wolkenlücke auftaucht.
Das kann auch keine AllskyCam besser detektieren, denn die sieht auch nur den momentanen Zustand.

CS Peter
 
Zitat von willfrid:
Diesen Fall hatte ich öfter, obwohl laut OpenWatherMap keine Wolken angezeigt waren, es waren aber Wolken da und es wurden mehr, so dass ich entschied, abzubrechen.
Aber sobald die Sache autark laufen soll, muss die Technik selbst entscheiden.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Also wenn es sicher nicht regnet, läuft mein Setup einfach die ganze Nacht durch. Im Herbst steigt das ganze dann üblicherweise irgendwann in der Nacht aus, weil Nebel aufzieht (danke lieber Bodensee), die Aufnahmen werden das einfach am Morgen gelöscht. NINA kann ab einem definierten Guiding-Fehler die Aufnahme auch selbst abbrechen. Finde nur gerade nicht, wo man das konfigurieren konnte.

CS, Daniel
 
Nebel oder Tau auf der Linse (wegen vergessener Heizung) sind auch Thema und werden erkannt.
Der Guidingfehler tritt nur auf, wenn Guiding stattfindet, bei schlechter Sicht eben nicht.
 
Dann hab ich wohl dein Anliegen nicht richtig verstanden. Ich war der Meinung dir ging es um den Schutz des Equipments. Dem ist eine Wolke ja völlig egal, Regen eher nicht.
 
Hallo Daniel,
mir ging es darum zu erkennen, wenn sich die Sicht dauerhaft verschlechtert, dass die Session abgebrochen wird.
Oft hatte ich auch Schleierwolken oder Nebel, so dass das Guiding zwar nicht abbrach, aber die Aufnahmen trotzdem schlecht wurden.
Dafür gibt es einen SNR-Schwellwert, bei dessen Unterschreitung auch abgebrochen wird.

Und Wolken können ja auch Regen mitbringen, daher hab ich die OpenWeatherMap zusätzlich mit eingebunden, zur Sicherheit.
 
Hallo,

ich habe zwar eine Sternwarte, aber nicht mit Motordach, denn das Dach ist zu gross dafür. Ich muss also bei Bedarf raus zur Sternwarte und das Dach mittels Winden manuell schliessen. Ich benutze NINA als Sequenzer und programmiere in der Regel eine ganze Nacht ein. Ich habe keine Scheu davor, hinterher Daten ganzer Nächte in den Mülleimer zu werfen, wenn ständig Wolken durchrauschen. Ausser Wetter können auch Instrumentenfehler zu Verlusten führen. Vor kurzem ist mir ein Kabel abgerissen, weil es sich verhakt hat.

Vor einer Astronacht schaue mir die Wetterlage bei yr.no an, und wenn ich sehe, dass es stabil ist, lasse ich die Anlage die Nacht durchlaufen und schaue fern oder lege mich hin. Ich habe die Geräte über Windows remote desktop laufen und kann die Sternwarte sowie die Bildschirme der Aufnahmerechner von innen aus überwachen. Da die Sternwarte nur wenige Meter vom Haus steht, ist das kein Problem. Wenn eines der PHD2 anfängt zu läuten, so kann ich das ¨ber remote desktop auch hören.

Ich nehme nebenher auch ein Video des Sternwartenraums und des Himmels auf. Dazu verwende ich eine asi120mm von ZWO, welche mit Extremweitwinkelobjektiven geliefert werden (wurden?). Um später nachzusehen, was ich wegkippen kann, schaue ich das Video an. Anhand der Zeit sehe ich genau, welche Bilder weg können. Aber gerade diese Videosequenz hakt leider oft nach einigen Stunden so dass ich oft keine ganzen Nächte aufgenommen habe. Allerdings nehme ich neuerdings auch eine zweite Aufnahme vor indem ich mit VLC-Player den Desktop des Wohnraumrechners abfilme. So habe ich also zwei Überwachungsvideos. Auf dem zweiten Video sieht man auch eventuelle Probleme bei der Aufnahme, so dass man aus Fehlern lernen kann. Die Geräte benehmen sich leider nicht immer so zuverlässig oder irgendein Teil steigt seltsamerweise aus.

Doch weiter zum Thema: Es gibt hier Stadtlicht, doch die Luft ist meistens sehr klar so dass das kaum ein Problem ist. Wenn nun Wolken aufkommen, werden diese vom Stadtlicht von unten beleuchtet und werden entsprechend hell. Das wollte ich mir in einem Experiment zunutze machen:

Mein Experiment war, die Himmelgegend über der Stadt mit einem Lichtsensor plus Arduino zu untersuchen. Dazu ist so ein einfacher "Lichtsensor" (z B Photodiode) aber zu schwach, also habe ich eine asi120mm mit einem Flohmarktobjektiv verbunden und das Bild auf einen Bildschirm ausgegeben (als Dauerausgabe mit ASIStudio). Ich habe also eine Kamera-Laptop-Kombination als Lichtverstärker verwendet. Dann den besagten Sensor vor den Bildschirm positioniert und fertig. Über eine einfache Funkstrecke wurden dann die Werte an einen zweiten Arduino ins Wohnzimmer geschickt, welcher eine Lampe zum Leuchten brachte. Man könnte mit einem Mikrofon auch Geräusche oder andere Werte ins Wohnzimmer übertragen. Auch die Arduinos bräucht man nicht unbedingt, wenn man den Aufnahmerechner dazu mitverwendet, aber für mich war dieser Weg das einfachste Vorgehen und ich hatte alles im Hause. Ausserdem war fast kein Lötvorgang nötig. Statt der Lampe kann ich auch eine Klingel nehmen und sich wecken lassen oder was auch immer. Man sollte aber so programmieren, dass es "träge" ausgewertet wird um nicht ständig gewarnt zu werden.

Vielleicht lässt sich aus diesem Versuch was weiterverwenden...

mfG, Tom.
 
Hallo Tom,
so ein Lichtsensor erfasst ja auch die Himmelsqualität und es gibt ein schlechtes Signal-Rausch-Verhältnis, wenn die Lichtverschmutzung zu hoch ist.
Wie willst du denn das Signal verwerten? Soll es nur ein Warnsignal geben, damit du eingreifen kannst oder munter wirst?

Dasselbe mache ich mit meinem Software-Tool SnrLogChecker über PHD2, indem ich den SNR auswerte und bei längerer Verschlechterung (z.B. Wolken, Nebel, Tau auf der Optik) kann ich mittels Safety Monitor in NINA die Aufnahmesession beenden oder unterbrechen und ggf. das Dach schließen.
Ich brauche dazu keine zusätzliche Hardware und das System läuft autark, so dass ich mich nicht darum kümmern muss.

Wer mag, kann sich das Tool über o.g. Link herunterladen und testen.
CS
Peter
 
Hallo, ja das ist richtig. Aussserdem misst man das Licht über der Stadt, also deutlich seitlich vom Beobachtungsort verschoben.

Man müsste für NINA sowas wie eine "versuch noch einmal nach x Minuten" haben, "solange bis die Zeit für dieses Objekt vorbei ist". Vielleicht gibt es diese "Funktionen" sogar, aber ich habe sie nur noch nciht gefunden. In der ersten "Funktion" müsste man dann auch einen Aussensensor ansprechen können, der ohne PHD auskommt, denn man will das Dach vielleicht nicht bei Regen/Schnee öffnen lassen um nachzusehen, ob es "jetzt geht".

\Tom
 
Ich mache mir auch seit einigen Jahren Gedanken, wie man feststellen kann, ob der Himmel klar ist, habe das aber nie intensiv weiterverfolgt. Spannende Ideen, die hier diskutiert werden ?

Vielleicht eine ganz andere Idee: haltet mal ein Infrarot-Thermometer gen klaren Himmel, das Zeigt -30°C oder weniger an, sobald man auf die kleinste Wolke zielt steigt die Temperatur rapide an. Es geht jetzt nicht um die absoluten Messwerte... man könnte aber den Verlauf auswerten und daraus Rückschlüsse auf Wolken ziehen
 
Hallo,

ich denke, aus meiner Erfahrung mit Experimenten, dass man eine brauchbare "Trägheit" verbauen muss. Man will ja sicher nicht, dass das Dach ständig auf und zufährt, wenn da mal eben eine Wolke drüberhuscht. Man könnte ja auch verschiedene Sensoren verwenden, wenn man diese mit einem ASCOM Treiber zu versehen weiss. Genau das kann ich trotz Programmiererfahrung bis heute nicht, weil ich noch nicht die Zeit hatte, mich damit zu befassen.

Ich werde dieses PHD Software Toll weiter oben versuchen, wenn ich Zeit finde.
\Tom
 
Hallo Freunde der Nacht,

hier nochmal der Link zum runterladen, wer mag kann das Tool testen, feedback wäre nett:

SnrLogChecker-Tool

Der Signalfluss sieht dann insgesamt wie folgt aus:

1701285311900.png


CS
Peter
 
Hallo Peter,

Sehr schönes Projekt, lade ich mir runter. Du nutzt das PHD2 Event Monitoring und zapfst das via TCP Verbindung an und die Openweathermap API. Sehr witzig, ich habe gerade das gleiche gebaut, aber als ASCOM Observing Conditions Treiber. Zusätzlich ist da noch ein Lichtsensor, Temperatur/Druck/Feuchtigkeit und IR Thermometer mit enthalten, die via MCU und Serial eingebunden sind. Aktuell nutzte ich den gelieferten HFD Wert, was aber nicht ganz den ASCOM Specs entspricht. Bin daher gerade dabei PHD2 den FWHM Wert, der leider im Monitoring (nur HFD) nicht mitgeliefert wird, zu entlocken. Aktuell via get_star_image, was den Guidingstern liefert und dann den FWHM Wert selbst zu berechnen.

Viele Grüße,
Alex
 
Hallo Alex,
HFD war bisher bei mir nur ein Wert zum fokussieren und zur Guidingkontrolle,
und FWHM ein Maßstab fürs Seeing.
Offensichtlich leitest du aber mehr daraus ab und willst den letzteren aus dem ersten ableiten bzw. berechnen.
Ergeben sich daraus irgendwelche Maßnahmen oder nur das Seeing "messen"?
Ich erkenne schlechtes Seeing nach dem Autofocus bereits am schlechten HFD Wert, liege aber meistens zwischen 2,5 und 2,8, besser wirds ganz selten und ich muss immer Kompromisse machen bei den seltenen klaren Nächten.
Da das Seeing über Nacht meistens besser wird, kann am Beginn der Session entscheiden, ob die Aufnahmen sinnvoll sind.
Willst du mit Ermittlung des FWHM ein Kriterium festlegen, Aufnahmen zu beenden?
VG Peter
 
Hallo Peter,

mir gehts erstmal lediglich um die Erfassung und Gestaltung eines vollständigen Monitorings, das alle in der Observing Conditions Klasse spezifizierten Werte ermittelt und damit eine mögliche zusätzliche Basis zur Auswertung/Einschätzung der Qualität schafft, als der Vergleich der Aufnahmen untereinander wie bspw. mittels PI SubFrameSelector.

Zwischenzeitlich ist es mir auch gelungen die FWHM Werte zu erfassen. Der ASCOM Treiber weißt PHD2 via Event Monitoring Interface an, das aktuelle Guidingbild zu speichern (get_star_image). Das Bild lese ich via der C# Fits Libary JPfits ein und ermittele den durchschnittlichen FWHM Wert der 20 hellsten Sterne.

Über die Sinnhaftigkeit so zusätzlich erfasster FWHM Werte aus dem Guiding-Setup lässt natürlich diskutieren. Die beste Basis dürften ja immer noch die FWHM Werte im aufgenommen Bild selbst sein, worauf es am Ende ja ankommt.

In dem Zusammenhang muss ich mich auch mal schlau machen / testen, welche Werte bspw. NINA im Fitsheader aus dem Observing Conditions Treiber ablegt.
Werden die ausgelesenen Werte wie bspw. Temperatur, SQM, etc. über die Einzelbelichtungszeit von NINA intern gemittelt und im Fitsheader gespeichert oder wird der Wert zum Ende der Aufnahme abgelegt?

Grüße,
Alex
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben