Raspberry Pi HQ-Kamera mit Kstars/Ekos ...

[linuxer]

Guten Morgen Leute,

vielleicht kann mir jemand helfen der sich mit der Materie auskennt.
Ich habe mir eine Raspberry Pi HQ-Kamera zusammengebaut bestehend aus einem Raspberry Pi Zero W und dem HQ-Kameramodul.
Die Kamera steuere ich über eine Python-SW was zwar zuverlässig funktioniert, mich aber nicht ganz zufriedenstellt zumal ich eh Kstars/Ekos für die Steuerung
der Montierung, das Guiding und den Fokus verwende.

Mein Plan war eigentlich das ich den Indi-Treiber Indi-rpicam auf der Kamera installiere und dann die Kamera ganz normal auch über Ekos ansteuern kann.
Leider bekomme ich das nicht gebacken und im Indlib.org Forum hat sich noch niemand dazu geäussert.

Ich habe auf der Kamera Debian Bullseye 32 Bit am laufen und finde dafür keinen Treiber. Die Standard Indi-Treiber sind wohl dort vorhanden, aber der Treiber für die Raspi-Cam nicht.

Ich finde zwar ein Repository-Eintrag für Debian Buster, aber nicht für Bullseye. Wenn ich versuche die Repo von Buster einzubinden dann bekomme ich eine ganze Menge an Abhängigkeits Fehler, was ja auch klar ist weil Buster eine alte Version ist.

Was muss ich machen damit ich einen indi-rpicam Treiber für Bullseye bekomme, bzw. wo bekomme ich den her ?

Hat irgendjemand diese Kombi am laufen ?

Hoffende Grüße
Thomas

 

[riff-raff]

Hallo Thomas,

die Raspberry Pi HQ Cam ist aktuell das Sorgenkind. Unter 64 bit ist sie momentan mit EKOS/INDI nicht mit verwendbar.

Bei 32 Bit probier mal den libcamera-Treiber (unter Raspberry oder Other gelistet)

CS, Ralf

 

[linuxer]

Hallo Ralf,

die Kamera Funktioniert "Solo" bestens, nur habe ich keinen Indi-Treiber um die Kamera mit Ekos zu steuern.
Ich bräuchte den indi-Treiber auf der Kamera "indi-rpicam".

Momentan steige ich da eh nicht ganz durch. Unter Buster (der älteren Debian OS Version) gibt es einen Treiber der aber nicht das neue libcam von Bullseye unterstützt, - soweit ich verstanden habe.
Dann gibt es wohl einen Ubuntu-Indi-Treiber für die Kamera. Soviel ich mitbekommen habe, -lasse mich gerne von gegenteil überzeugen, gibt es aber kein libcam unter Ubuntu. War zumindest mal so.
Bullseye 64Bit scheint auf dem Pi immer noch Probleme zu machen, was ich eigentlich nicht ganz nachvollziehen kann.

So wie es aussieht kann ich nur abwarten bis Buster stirbt und man den Treiber auf Bullseye Kompiliert.

Gruß
Thomas

 

[Counterfeiter]

Versuch mal Debian Buster unter Bullseye ist libcamera zum Standardtreiber geworden und Indi ist an der Stelle noch nicht so weit. Es gibt einen libcamera branch, aber der steht seit dem Sommer und wurde nicht weiter entwickelt… Der Branch funktioniert bei mir nicht. Hatte den von den Sourcen gebaut und ein Segfault bekommen, danach die Lust verloren. Auch diese gefühlt 1 Million Dummy Codezeilen die der Autor für den Treiber heranziehen musste, haben mich abgeschreckt da irgendwie mitentwickeln zu wollen. ?

Da Hilft erstmal nur altes OS, was aber auch okay ist.

 

[Neuge]

Hallo,

so ganz einfach scheint das aber auch nicht zu sein.
Ich habe im letzten Jahr da intensiv mit experimentiert, aber wie oben schon geschrieben, unter 64bit gibts nix neues.
Die Treiber die da so im Forum beschworen werden, sind wohl alle für 32bit und sehr umständlich zu installieren und zu bedienen.
Hatte auch bei Stellarmate nachgefragt, wie es denn aussieht mit dem HQ Treiber. Als Antwort kam dass es in 10 Tagen so weit sei. Aber das ist auch schon wieder einen Monat her.
Unter Astroberry mit Buster läuft meine HQ Cam aber auch nicht richtig. Hier stolpern nur s/w Bilder heraus.
Habe auch ältere Versionen von Stellarmate getestet. Da funktioniert die Kamera unter Buster, aber mit der neuen App kann man keine Bilder mehr aufnehmen, weil sich das irgendwie beißt.
Es ist wirklich schade dass sich da irgendwie keiner so richtig drum kümmert. Ich würde ja gern, aber mir fehlt einfach das Wissen dazu einen Treiber zu schreiben.
Im INDI Forum gibts ja einen extra Thread zum Thema Libcamera und HQ Cam.

Tino

 

[Counterfeiter]

Ich denke, ich werde demnächst einen libcamera Treiber mit Hilfe der PyIndi Bibliothek schreiben. Das sah, von weiten betrachtet, recht simpel aus, wenn man nicht gleich alle Funktionen unterstützen möchte. Zumindest deutlich übersichtlicher als die C++ Variante. Ich benötige für meine IMX290 auch einen solchen Treiber und mein vorgestelltes Projekt „Not So Lucky Imaging“ würde davon auch profitieren.
Mal schauen wann ich dazu komme. Und eine ähnliche Funktion bietet bereits die Allsky Camera. Die haben das für sich schon getan… aber ich konnte es nicht 1zu1 anwenden.

VG
Sebastian

 

[Neuge]

Das mit dem AllSky Treiber habe ich ehrlich gesagt nicht wirklich verstanden.
Der scheint ja schon zu laufen auch unter 64 bit. Was ist denn daran so speziell? Ich meine, der müsste doch 1:1 gehen. Macht ja auch nix anderes als Bilder aufzunehmen. Mal abgesehen vom Videomode der zwar wünschenswert ist, aber nicht zwingend nötig.

 

[Counterfeiter]

Den kann man durchaus jetzt schon zum laufen bringen. Der Treiber called im Grunde immer nur raspberry-still. Muss man nur aus dem Projekt herauslösen und wie du schon sagst, erfüllt er einen speziellen Task. Im Gegensatz zum Indi-Anspruch, nahezu alle Möglichkeiten abzudecken.
Daher wäre es wünschenswert, einen Standalone-Treiber, der irgendwas in der Mitte abdeckt, zu bauen.

 

[linuxer]

Da ich Probleme mit Kstars/Ekos und der HQ-Kamera hatte, habe ich mich etwas mit Python beschäftigt und mir 2 Programme geschrieben.
Die Programme sind nichts besonderes und ich bin jetzt auch nicht der Oberprogrammierer sondern habe einfach angefangen und nach und nach das Programm erweitert.
Ich weis das es einige von euch gibt die das besser können, aber das Programm funktioniert für mich.

Das Programm kann..
Einzelbilder
Videos
Langzeitbelichtung von 0.02 - 230 Sekunden
usw.
aufnehmen..

Wer die Programme benutzen möchte kann das gerne tun. Allerdings müssen die Pfade angepasst und eventuell einige Python Bibliotheken nachinstalliert werden.

Das Erste ist das Server-Programm wird einfach auf der Kamera gestartet.
Ich verbinde mich mit der Kamera per ssh und starte dann einfach das Server-Programm.
Dieses Programm macht nichts besonderes sondern nimmt einfach die Befehle vom Client entgegen und startet dann den zusammengesetzte libcamera Befehl.

Das Zweite wird auf dem Rechner gestartet. Allerdings habe ich das Programm für Linux geschrieben. Wer es auf Windows starten möchte der muss schauen wir wie man es da zum laufen bekommt.

Im Prinzip wird auf dem Client nur der libcamera Befehl zusammen gesetzt und an die Kamera übertragen.
Ich verwende die neuen Libcamera von Bullseye. Wer das alte Buster mit dem alten Libcamera verwendet muss des übergebenen String anpassen.

Wenn die Aufnahme beendet ist dann wird das Bild/Video per scp von der Kamera abgeholt und in den jeweiligen Ordner abgelegt.
Da ich immer wieder an dem Programm arbeite möchte ich es als Baustelle zu bezeichnen.
Die Hauptfunktionen sind aber gegeben und es Funktioniert.
Ich habe versucht mit Bordmitteln und relativ einfach das Programm zu gestalten.
Zum einen weil ich es nicht besser kann und zum anderen möchte ich keine großen Aktionen starten müssen wenn ich mal den Rechner wechsel.

Also wie gesagt wer die HQ-Kamera verwenden möchte kann mit diesen beiden Programmen die Kamera voll nutzen.
Die Programme sind offen und wer möchte kann gerne daran herum basteln. Sie können weiter gegeben werden und vielleicht ist ja der eine oder andere unter euch der voll den Plan hat und ich sehe irgendwann mal eine Version davon wieder, die von einem Profi gemacht wurde.
Da meine Kamera kein TFT hat habe ich auch keinen Wert auf ein Vorschaubild gelegt.
Meine EQ6 steht auf dem Balkon und ich sitze im Wohnzimmer am Laptop und steuer von dort die EQ mit der Kamera.
Das Mondbild im Intro ist mit der HQ-Kamera und diesem Programm als Mosaik aus 6 x 30 Bilder gemacht worden.

Hier zum Download

Ich hoffe dem einen oder anderen damit zu Helfen die Kamera zu verwenden.
Da ich noch einen PC außer dem Laptop benutze der unter Kubuntu läuft, habe ich festgestellt das unter Plasma/KDE die Icons und Knöpfe etwas anders aussehen als auf dem Laptop unter Ubuntu-Mate.
Ich bin gerne Bereit etwas Unterstützung zum Betrieb des Programms zu geben, aber ich werde keine bitten hinsichtlich Erweiterungen entgegen nehmen, da bitte ich um Verständnis.
Die Entwicklung des Programmes ist für mich eigentlich beendet und funktioniert für mich in dieser Form. Falls ich über grobe Fehler stolper werde ich das dann irgendwann mal bearbeiten.
Da die SW opensource ist,- im Sinne des Wortes, wird auch keine Software irgendwo nachgeladen und Viren gibt es auch keine

Gruß
Thomas

 

[AstroM]

Hallo Thomas,

ich hatte mir ja auch eine simple Oberfläche programmiert, deine (muss ich sagen) ist schicker geworden!
Das Mondbild finde ich spitze - hast du dich auch mal mit der HQ an DSOs versucht? Ich bin ja relativ neu dabei und versuche mich gerade mit der HQ am Pferdekopf. Mir ist klar, dass die Sensor und Pixelgröße nicht so geeignet ist, aber 49 Euro sind halt auch ein echter Schnapper

Daher würde mich interessieren, wie DSOs mit der HQ Cam bei anderen aussehen. Hast du da zufällig was zum zeigen?

Beste Grüße,
Matthias

 

[Counterfeiter]

Hallo Thomas,
da hast du nicht nur schnell eben mal was zusammen geklickert, dass sieht ja richtig schick aus!

Irgendwie schon fast ein bisschen Schade, dass jeder für sich seine libcamera Adaptierung baut. Wenn man unsere Programmierbemühung bündeln würde, hätten wir schon einen schönen Indi-Treiber.

Ich hab nochmal ein bisschen herumgeschaut. Also die Implementierung von Allsky können wir nicht nehmen. Das ist leider kein richtiger Inditreiber sondern eine Wrapper classe die dem Indi-Client von Allsky angeboten wird und einfach für das Projekt die libcamera emuliert.

Der richtige Python-Weg wäre dieses Beispiel für libcamera aufzubohren:

pyINDI/blob-device.py at master · MMTObservatory/pyINDI

Pure Python 3.7+ implementation of INDI for client and server - pyINDI/blob-device.py at master · MMTObservatory/pyINDI

github.com

Letztendlich called man dann den indiserver mit dem python file und hat einen richtigen Treiber der in jeder Indi-fähigen Astroapplication (also alle?) benutzt werden kann. Also letztendlich auch für Nina-Benutzer interssant, weil das Raspberry Pi dann nur der Indi-Server sein kann.

Wenns die Zeit und Lust erlaubt, werde ich mal damit starten.

Viele Grüße

Sebastian

 

[linuxer]

Guten Morgen,

Hast du da zufällig was zum zeigen?

Ich habe mich mal an M16 versucht.
Damals hatte ich den IR-Filter vor der Kamera entfernt was aber keine gute Idee war. Ich hatte Probleme die Farben wieder in den Griff zu bekommen deswegen musst ich den IR-Filter wieder drauf frimeln.

Hier ist noch eine Testaufnahme von M42.
38 Lights und 16 Darks.
Belichtungszeit weis ich nicht mehr. War eigentlich nur ein Test.
Wie gesagt damals noch ohne IR-Filter.
M42 müsste man eh mit unterschiedlichen Belichtungszeiten aufnehmen sonst wird das nix.

Dieses Jahr werde ich es etwas mehr mi der Pi-Cam versuchen zumal ich auch ein Peltier eingebaut habe und die Kamera auf 0°C abkühlen kann.
Ob das was bringt weis ich nicht, weil so lange belichte ich ja nicht. Allerdings habe ich festgestellt das die Kamera bei einer längeren Belichtung doch ziemlich warm wird.

da hast du nicht nur schnell eben mal was zusammen geklickert, dass sieht ja richtig schick aus!

Vielen Dank
Das Programm ist über die letzten 3 Jahre gewachsen. Ich habe mit einem Bashscript angefangen und alles per ssh auf der Kamera gemacht.
War mir aber im laufe der Zeit zu unbequem. Das nächste war dann eine Webserver auf der Kamera. War dann irgendwann auch nicht das wahre und da ich schon lange mal in Python einsteigen wollte dachte wieso nicht da ein Projekt daraus machen.
Die Anfänge waren hart und zäh aber nach und nach ist es dann gewachsen. Ich stochere aber immer noch herum weil ich nur ab und zu etwas Programmiere. Aber hey was solls, in der Ruhe liegt die Kraft.

Sebastian wenn du da einen Treiber Basteln könntest den man ganz normal über den Indiserver auf der Kamera starten kann und mit Kstars/Ekos bedienen könnte wäre echt cool.

Die Kamera ist nicht schlecht für Ihren Preis und ich denke was DSO's angeht ist da auch was machbar.


Gruß
Thomas

 

[Neuge]

hallo Thomas.

Es ist schade dass alle immer im Kämmerchen an solchen Sachen basteln.
Auch ich habe angefangen eine gekühlte Variante der Kamera zu bauen. Allerdings ist sie noch nicht fertig.
Mir ist das Problem mit der libcamera dazwischen gekommen und ich habe alles in die Ecke gelegt, da keine Lösung in Aussicht war.
Ich habe Aufnahmen bisher immer mit der PiCamera App gemacht. https://github.com/Billwilliams1952/PiCameraApp
Die ist aber eher für Planeten geeignet. Aus Astroberry bekomme ich nur noch ein s/w Bild heraus und unter Stellarmate geht ja bekanntlich gerade nichts mehr.
Die Kühlung bringt auch bei 60sek eine Menge an Verbesserung im Bild. Voraussetzung ist immer, dass man vorher den "Stareater" ausgestellt hat.
Ich hatte das irgendwann mal auf dieser Seite gelesen: https://www.strollswithmydog.com/pi-hq-cam-sensor-performance/#more-4297
Stellt man das nicht aus, verschwinden auf wundersame Weise die kleinen Sterne im Hintergrund. Aber ich denke, das hast du sicher schon in deiner Software bedacht.
Ein INDI Treiber wäre natürlich der Hammer. Es gibts da ja auch schon Ansätze und wohl auch schon einen Beta Treiber. Aber ich habs nicht zum Laufen bekommen. Eigentlich auch alles viel zu kompliziert. Wer will sich bei der Beobachtung schon mit Konsoleneingaben beschäftigen. Das muss einfach startbar sein.

Tino

 

[linuxer]

Hallo Tino,

das...

Stellt man das nicht aus, verschwinden auf wundersame Weise die kleinen Sterne im Hintergrund. Aber ich denke, das hast du sicher schon in deiner Software bedacht.

... kannte ich bis jetzt nicht. Sterne verschwanden bei mir keine, zumindest ist mir nix aufgefallen

Ich habe lange an den Einstellungen herumgeschraubt bis ich als Ergebnis eigentlich das hatte was ich erwartet habe.
Ich bin sicher das man noch etwas mehr herausholen kann als ich es mit der SW jetzt mache.
Das gute daran ist das jeder den zusammengesetzten "Befehls-String" mit einem Editor ändern kann.
Wenn man da etwas ändern sollte um ein besseres Ergebnis zu bekommen lasst es mich wissen.

Mit Astroberry habe ich auch herum gespielt und Stellarmate kostet glaube ich etwas.
Mit keinem der zusammen gestellten Binaries war ich richtig zufrieden.
Ich dachte mir wieso nicht selber etwas aufsetzen.
Kstars/Ekos, Phd2, Stellarium aus dem Repo installieren, Ubuntu-Mate als OS auf dem RaspberryPi 4, fertig.
Kstars/Ekos für die Steuerung, Stellarium für die Planung falls ich da mal einen Monitor benötige.

Im Prinzip starte ich jetzt auf dem Pi4 nur ein Script das den Indiserver mit diversen Treibern startet.

OnStep für meine EQ6.
QHYCCD für meine alte ALCCD5 für das Guiding.
MyFocuserPro2 für meinen Fokuser.
Canon DSLR für meine alte Canon EOS350Da.

Mehr braucht es nicht.

Wenn ich mit der Pi-Cam aufnahmen mache dann läuft das bei mir folgendermaßen ab.
Ich starte auf meinem alten Laptop eine Konsole.
Stelle eine ssh-Verbindung zur Kamera her und starte dort den Server.
Dann starte ich auf meinem Laptop den Client der sich mit der Kamera verbindet.
Auf dem Laptop starte ich Kstars/Ekos und stelle eine Verbindung zum RaspberryPi4 her.
OnStep (EQ6), ALccd5 (Guiding) und MyFocuserPro2 (Fokuser)

Das war's dann eigentlich auch schon. Die Bilder werden vom Client direkt auf den Laptop gezogen und ich kann sie in aller Ruhe schon einmal
vorsortieren.

Die Kamera und die SW war eigentlich nur als Planeten-Kamera gedacht.
Auf die Idee mit dem Peltier kam ich erst als ich versuchte die Kamera auch an Deepsky zu testen.
Also musste die SW etwas aufgebohrt werden.

Früher saß ich immer draußen vor dem ganzen Gerödel.
Im Sommer war das kein Thema, aber im Herbst und Frühjar war das etwas unschön.
Nun jetzt kann ich es bequem vom Wohnzimmer aus steuern und da sowieso alles auf dem Balkon steht ist das Praktisch.

Ein INDI Treiber wäre natürlich der Hammer. Es gibts da ja auch schon Ansätze und wohl auch schon einen Beta Treiber. Aber ich habs nicht zum Laufen bekommen. Eigentlich auch alles viel zu kompliziert. Wer will sich bei der Beobachtung schon mit Konsoleneingaben beschäftigen. Das muss einfach startbar sein.

Ja das wäre cool. Ich habe es momentan aufgegeben darauf zu warten und arbeite solange mit meiner SW, das funktioniert auch.

Gruß
Thomas

 

[AstroM]

Hallo Thomas,

das M16 Bild finde ich ziemlich cool . Das werde ich als Ziel auch mal versuchen. Von 120 Sekunden bin ich leider noch weit entfernt.

Ich habe die letzten zwei Tage mit der HQ Cam mal den Pferdekopf angefahren und mich versucht. Ziel war das Hardware-Binning 2x2 zu testen (--mode 2028:1520) und ob das Bild dann besser wird. Ich war eigentlich positiv überrascht, man kann ihn erkennen!

76/342 (mit IR Filter)
Raspberry PI HQ Cam
AZ-GTIx im AZ-Modus
500 Lights x 15 Sekunden (circa 2 Stunden)
Darks, Bias, Flats

Dieses Jahr werde ich es etwas mehr mi der Pi-Cam versuchen zumal ich auch ein Peltier eingebaut habe und die Kamera auf 0°C abkühlen kann.
Ob das was bringt weis ich nicht, weil so lange belichte ich ja nicht. Allerdings habe ich festgestellt das die Kamera bei einer längeren Belichtung doch ziemlich warm wird.

Das mit der Kühlung finde ich ja mega, das brauche ich auch noch! Bilder würden mich immer interessieren, da man noch relativ wenig findet.

Es ist schade dass alle immer im Kämmerchen an solchen Sachen basteln.

Bei einem Treiber kann ich leider nicht unterstützen... bei mir reicht es nur für eine simple Oberfläche, die ein paar Shellcommands abschickt

Beste Grüße,
Matthias

 

[linuxer]

Hallo Tino,

das...

Stellt man das nicht aus, verschwinden auf wundersame Weise die kleinen Sterne im Hintergrund. Aber ich denke, das hast du sicher schon in deiner Software bedacht.

... kannte ich bis jetzt nicht. Sterne verschwanden bei mir keine, zumindest ist mir nix aufgefallen

Ich habe lange an den Einstellungen herumgeschraubt bis ich als Ergebnis eigentlich das hatte was ich erwartet habe.
Ich bin sicher das man noch etwas mehr herausholen kann als ich es mit der SW jetzt mache.
Das gute daran ist das jeder den zusammengesetzten "Befehls-String" mit einem Editor ändern kann.
Wenn man da etwas ändern sollte um ein besseres Ergebnis zu bekommen lasst es mich wissen.

Mit Astroberry habe ich auch herum gespielt und Stellarmate kostet glaube ich etwas.
Mit keinem der zusammen gestellten Binaries war ich richtig zufrieden.
Ich dachte mir wieso nicht selber etwas aufsetzen.
Kstars/Ekos, Phd2, Stellarium aus dem Repo installieren, Ubuntu-Mate als OS auf dem RaspberryPi 4, fertig.
Kstars/Ekos für die Steuerung, Stellarium für die Planung falls ich da mal einen Monitor benötige.

Im Prinzip starte ich jetzt auf dem Pi4 nur ein Script das den Indiserver mit diversen Treibern startet.

OnStep für meine EQ6.
QHYCCD für meine alte ALCCD5 für das Guiding.
MyFocuserPro2 für meinen Fokuser.
Canon DSLR für meine alte Canon EOS350Da.

Mehr braucht es nicht.

Wenn ich mit der Pi-Cam aufnahmen mache dann läuft das bei mir folgendermaßen ab.
Ich starte auf meinem alten Laptop eine Konsole.
Stelle eine ssh-Verbindung zur Kamera her und starte dort den Server.
Dann starte ich auf meinem Laptop den Client der sich mit der Kamera verbindet.
Auf dem Laptop starte ich Kstars/Ekos und stelle eine Verbindung zum RaspberryPi4 her.
OnStep (EQ6), ALccd5 (Guiding) und MyFocuserPro2 (Fokuser)

Das war's dann eigentlich auch schon. Die Bilder werden vom Client direkt auf den Laptop gezogen und ich kann sie in aller Ruhe schon einmal
vorsortieren.

Die Kamera und die SW war eigentlich nur als Planeten-Kamera gedacht.
Auf die Idee mit dem Peltier kam ich erst als ich versuchte die Kamera auch an Deepsky zu testen.
Also musste die SW etwas aufgebohrt werden.

Früher saß ich immer draußen vor dem ganzen Gerödel.
Im Sommer war das kein Thema, aber im Herbst und Frühjar war das etwas unschön.
Nun jetzt kann ich es bequem vom Wohnzimmer aus steuern und da sowieso alles auf dem Balkon steht ist das Praktisch.

Ein INDI Treiber wäre natürlich der Hammer. Es gibts da ja auch schon Ansätze und wohl auch schon einen Beta Treiber. Aber ich habs nicht zum Laufen bekommen. Eigentlich auch alles viel zu kompliziert. Wer will sich bei der Beobachtung schon mit Konsoleneingaben beschäftigen. Das muss einfach startbar sein.

Ja das wäre cool. Ich habe es momentan aufgegeben darauf zu warten und arbeite solange mit meiner SW, das funktioniert auch.

Gruß
Thomas

 

[linuxer]

Hallo Matthias,
Der Pferdekopf sieht klasse aus und das mit der HQ-Cam.
Was ja eigentlich KEINE Astrokamera ist.
Respekt
Momentan ist das Wetter hier echt besch... da geht gar nix zumal jetzt auch wieder der Mond zum Tragen kommt.
Bleibt mir also nur abwarten und auf besser Wetter hoffen.

Ich kenne mich mit Binning nicht aus, aber ich war der Ansicht das brauchst Du nur wenn die Kamera nicht empfindlich genug ist.
Wo hast du den Gain stehen bei der Aufnahme ?

Gruß
Thomas

 

[AstroM]

Hallo Thomas,

Der Pferdekopf sieht klasse aus und das mit der HQ-Cam.
Was ja eigentlich KEINE Astrokamera ist.
Respekt

vielen Dank für das Kompliment. Ich bin ja noch neu dabei und mich hauts ja immer noch total aus den Socken, wenn nach dem Stacken was auftaucht und dass man den Pferdekopf auf dem Bild dann noch richtig erkennen kann, fand ich super.

Die Aufnahme war mit folgenden Parametern:

libcamera-still -o /home/pi/Desktop/astro/output/Loop_$k_$RANDOM.jpg --shutter 16000000 --gain 16 --awbgains 1,1 --immediate --raw --denoise off -n --mode 2028:1520

Der Gain war auf 16 und so wie ich die Doku verstanden hatte, ist alles darüber ja nur mit der Software aufgehellt.

Ich kenne mich mit Binning nicht aus, aber ich war der Ansicht das brauchst Du nur wenn die Kamera nicht empfindlich genug ist.

Ich habe mir hier auch nur gefährliches Halbwissen angelesen. Da die Pixel des IMX477 ja nur 1,55 groß sind, kann man sie mit Hardwarebinning zusammenfassen und so angeblich die Sensitivität etwas verbessern (weil dann theoretisch größere Pixel). Verdoppelt hat sich da bei mir aber nichts... ich habe zum Test mal eine Aufnahme einer Fläche gemacht (normal und 2x2) und der im Photoshop gemessene Druchschnittsgrauwert war bei der gebinnten Aufnahme etwas höher (ca. 30%) - daher dachte ich es könnte vielleicht etwas Sensitivität gebracht haben. Aber so ganz sicher bin ich mir nicht, ob diese "Rechnung" überhaupt Sinn macht

Grüße,
Matthias

 

[linuxer]

Super, danke das Du die Parameter hier Postest.
Das sind die Einstellungen die ich mit meinem Programm verwenden würde wenn ich ein 15 Sekunden Bild aufnehmen würde.

/usr/bin/libcamera-still  --width 4056 --height 3040 --shutter 15000000 --gain 1 --awbgains 0.0,0.0 --sharpness 0 --brightness 0 --contrast 1 --saturation 1 --immediate -n --denoise off -r  -o /home/pi/Videos/testbild_20230222_154341.jpg

Ich kenne mich mit den Parametern auch noch nicht so genau aus und bin mir auch noch nicht ganz sicher was eigentlich genau was bewirkt.
Das funktioniert bei mir eigentlich ganz gut.
Wie ich sehe sind die Parameter im Prinzip, - bis auf den Modus, gleich

Gruß
Thomas

 

[AstroM]

Hallo Thomas,

ja, ich finde es super interessant sich hier mal auszutauschen. Daher war ich auch gespannt mal andere Astro-Bilder mit der HQ-Cam zu sehen. Wir sind bei den Parametern fast gleich. Der Modus verändert bei der Größe auch das RAW (wegen dem Binning), was ja bei width und height nicht passiert, wenn ich mich nicht irre.

Interessant - du hast einige Parameter (Sharpness, Brightness, Contrast) gesetzt. Diese haben, wenn ich es richtig gelesen aber habe nur Auswirkungen auf das erzeugte JPG (nicht die RAW), oder? Ich habe daher extra keinen dieser Parameter gesetzt, damit ich beim Sichten (ich zeige mir das letzte Bild immer auf der Oberfläche an) möglichst nahe am RAW bin. Bei mir geht das Speichern eines neuen Bildes viel schneller, wenn ich keine Bildbearbeitung mache.

Grüße,
Matthias

 

[linuxer]

Es ist interessant sich da mal Auszutauschen und die Bilder zu vergleichen die mit der Kamera aufgenommen worden sind.

Ja das Einstellungen (Sharpness, Brightness, Contrast) sollten sich nur beim .jpg auswirken.
Das RAW sollte die Rohdaten enthalten und wird nicht bearbeitet.

Deswegen habe ich im Programm oben eine checkbox "RAW" solange der nicht aktiv ist wird nur das jpg aufgenommen. Das spart Zeit beim kopieren der Daten dann auf den Laptop wenn ich noch am Einstellen des Bildausschnittes und der Schärfe bin.
Passt alles dann setze ich RAW auf aktiv und die Kamera nimmt dann auch das Rohbild auf.

Der Modus verändert bei der Größe auch das RAW (wegen dem Binning), was ja bei width und height nicht passiert, wenn ich mich nicht irre.

Da bin ich überfragt, weil ich Modus eigentlich bis jetzt nicht benutzt habe.

Gruß
Thomas

 

[AstroM]

Da bin ich überfragt, weil ich Modus eigentlich bis jetzt nicht benutzt habe.

Die RAW Datei verkleinert sich mit "mode" auch um ein Viertel und hat dann die kleinere Auflösung, daher denke ich, dass dies wirklich das Hardware-Binning auslöst.

Es ist interessant sich da mal Auszutauschen und die Bilder zu vergleichen die mit der Kamera aufgenommen worden sind.

Hier noch ein zweiter Test der HQ Cam an M42:

76/342 (mit IR Filter) / AZ-GTIx im AZ-Modus
Raspberry PI HQ Cam
227x20 Sec
282x15 Sec
gesamt ca. 2,3 Stunden
Darks, Bias
(Bei mir hängts auch noch ein wenig am Stretching, aber ich übe weiter das richtige Maß zu finden .)

Ich bin gespannt, wie es weitergeht. Es kam ja kürzlich eine neue Kamera raus, aber leider mit einem kleineren Sensor
(Raspberry Pi Camera Module 3 & High Quality: Neue Raspi-Cams)

Beste Grüße,
Matthias

 

[riff-raff]

Hallo Matthias, starke Aufnahme!

Hast Du den IR-Cut der Kamera drin gelassen oder einen separaten UV/IR-Cut verwendet?

CS, Ralf

 

[AstroM]

Hallo Ralf,

danke! Ich habe den IR-Cut (diese kleine blaue Scheibe) der HQ-Kamera mit einem Wattestäbchen rausgedrückt und dann auf die 1.25 Hülse vorne einen günstigen UV/IR Cut von SVBONY geschraubt. Der Grund war, dass ich diesen dann leicht runtermachen kann, wenn ich an meinem Spiegelteleskop (SLT130) bin. Ich hatte mir auch ein paar andere Filter gekauft - bin aber noch nicht zum Testen gekommen, weil ich mich so viel mit der Montierung und dem Ekos-Tracking rumärgere

Grüße,
Matthias

 

[linuxer]

Hallo Matthias,
klasse Aufnahme
Ja ist etwas "überstreckt" aber man sieht viele Details. Das ist klasse. Ich habe bei meiner Kamera der IR-Cut wieder aufgeklebt. Ich hatte keinen anderen und die Farben waren total daneben.
Wie bearbeitest Du Deine Bilder ?
Welche SW verwendest Du ?

Gruß
Thomas

 

[riff-raff]

Ich würde vermuten, dass ein nachgerüsteter UV/IR-Cut zwar eine lustige Farben hinterlässt, jedoch im Halpha deutlich mehr durchlässt als der Balancing-Filter der Kamera. Im Laufe de nächsten Woche werde ich den Balancing-Filter mal vermessen, dann wissen wir mehr.

CS, Ralf

 

[AstroM]

Hallo,

klasse Aufnahme
Ja ist etwas "überstreckt" aber man sieht viele Details. Das ist klasse. Ich habe bei meiner Kamera der IR-Cut wieder aufgeklebt. Ich hatte keinen anderen und die Farben waren total daneben.

danke, die Aufnahme hatte ich mit PS gestreckt und dann noch wild mit den Reglern im Raw-Filter gespielt . Das muss ich noch mal richtig mit Tutorials üben. Aber ich denke mit etwas Fantasie sieht man vielleicht schon, was die HQ-Cam in der Hand eines Profis theoretisch könnte. Ich finde die HQ Cam schon echt lustig (weil so günstig) - das mit der Kühlung muss ich auch noch nachrüsten, sobald ich auf längere Belichtungszeiten komme. Da würde ich mich dann noch mal melden, denn das sieht bei dir schon echt cool aus.

Ich hatte mich ja im März auch schon mal an einer Galaxie (M66) mit der HQ-Cam versucht. Jetzt mit der AT-GTIx (im Gegensatz zur SLT) läuft das AZ-Modus Tracking schon viel besser, aber gibt mir zwischendurch immer wieder Rätsel auf .

Im Laufe de nächsten Woche werde ich den Balancing-Filter mal vermessen, dann wissen wir mehr.

Sehr spannend! Wie kann man das denn bestimmen?

Ich bin wirklich gespannt auf neue Bilder der Kamera, ich glaube da kann man noch viel optimieren wenn nur mal das Wetter passen würde...

Beste Grüße,
Matthias

 

[riff-raff]

Hi Matthias,

Ich hatte mal eine NexStar SLT und das Tracking war erstaunlich gut. Meine jetzt für das EAA-Projekt verwendete Skywatcher SynScan AZ ist ja sehr ähnlich, wenn sie bei Syntha nicht sogar vom selben Band gefallen ist. Ist das Tracking bei Deiner AZ-GTI im vergleich zur NexStar SLT deutlich besser? Könnte es am Aufstellen/Alignment liegen, wenn das Tracking nicht passt?
Da die Montierung mir ja immer noch Probleme macht überlege mich von ihr zu trennen bzw. für den EAA-Einsatz zusätzlich eine AZ-GTi anzuschaffen und die Skywatcher SynScan als visuelles Grab'n'Go System zu verwenden.

Den Filter würde ich mit einem Photospektometer vermessen, Transmissionsspektrum ~380-1000 nm sollte reichen.

@linuxer Hast Du mehr Infos zur Umsetzung der TEC-Kühlung der HQ-Cam? Find ich sehr interessant.

CS, Ralf

 

[AstroM]

Hallo Ralf,

Da die Montierung mir ja immer noch Probleme macht überlege mich von ihr zu trennen bzw. für den EAA-Einsatz zusätzlich eine AZ-GTi anzuschaffen und die Skywatcher SynScan als visuelles Grab'n'Go System zu verwenden.

meine SLT hatte ich ja sehr günstig spontan gebraucht gekauft und die sah auch recht mitgenommen aus. Daher denke ich könnten es hier auch andere Probleme gewesen sein. Das Alignment der GTI ist dank Guidescope und nahezu perfekt funktionierendem Platesolving jetzt echt Spitze. Die Gotos sind meist Volltreffer. Somit funktioniert die GTI(x - beidseitig) für mich wesentlich besser als die SLT. Nur gibts noch ein paar Sachen, die ich noch besser verstehen muss. Ich starte am Abend im Südosten mit einer relativ konstanten 1,6 RMS und dann (ich glaube wenns mehr Richtung Westen geht) wird das Tracking so schlecht, dass die Sterne relativ flott aus dem Bild laufen und das EKOS-Guiding nicht mal mehr kalibrieren kann... aber wie du schon sagst, es kann auch ein Userfehler sein. Ich bin ja platzbedingt und ohne Norden im AZ-Modus und das bringt ja an sich einige Schwierigkeiten mit, die noch besser verstehen muss (Fieldrotation). Mein Südbalkon liegt auch noch am Hauseck, da pfeifen auch immer wieder Böen um die Kurve . Manchmal glaube ich aber auch, dass der INDI Treiber einfach Fehler macht, davon hatten wir es ja schon in dem anderen Thread.

Wenn das mit dem Tracking läuft wollte ich für die HQ-Cam mit einem Arduino und einem kleinen Stepper-Motor etwas basteln, was mir die Kamera dreht aber eines nach dem anderem... derzeit starre ich nur auf Wolken.

Beste Grüße,
Matthias

 

[linuxer]

Hallo Ralf,

hier sind die 3D-Druckdaten zur Kamera wer sie nachbauen möchte.
Ein paar Worte vorweg. Da ich nicht damit gerechnet hatte die Daten zugänglich zu machen müsst Ihr beim Nachbau etwas kreativ sein
Es ist jetzt > 3 Jahre her das ich die Kamera gebaut und ich eigentlich alles verwendet hatte was ich zuhause hatte.

Der Kern der Kamera besteht aus einem Raspberry pi Zero W1, der alte also noch.
Als Display für die Temp-Anzeige verwende ich ein TM1637 7 Segment-Display von Banggood.
Der Temp-Sensor ist ein 30 Jahre alter LM50C der bis zu einem halben Grad genau ist. (Dient ja nur zur Anzeige und regelt nix.)
Da der Raspi ja leider keinen AD-Wandler besitzt habe ich einen Arduino-Nano eingebaut und gut Lichtdicht verpackt.
Der Arduino ist nur zuständig für das einlesen des Temp-Sensors und die Anzeige der Temperatur.
Da die Referenzspannung abhängig ist von der Versorgungsspannung des Arduino ist, muss die im Arduino-File "geeicht" werden das ich beigelegt habe, dann stimmt auch die Temperaturanzeige.
Einfach nur den Wert anpassen. Erklärung meine ich im File hinterlegt zu haben.

Ich habe aus einem alten Laptop M2,5 Gewindebuchsen ausgeschlachtet und mit dem Lötkolben in der Kamera verbaut.
Das Peltier-Element ist ein TEC1-12706 auch von Banggood.
Der Lüfter ist ein 50mm Lüfter den ich noch herumliegen hatte.

Da das Peltier ein paar Ampere zieht musste ich mir etwas ausdenken. Ich hatte noch ein altes PC-Netzteil von meinem ersten Astrokoffer-PC was ich etwas modifiziert habe.

Die 5V des Netzteiles gehen direkt zu einer USB-Buchse die für die Versorgung der Kamera zuständig ist.
Die 12V des Netzteiles regle ich mit einem Mosfet und Poti für die Versorgung des Peltier herunter ( ist glaube ich ein BUZ11 und ja auch ca. 30 Jahre alt
Ein anderer tut es aber auch.
Wo die Werte jetzt genau liegen kann ich gar nicht sagen ist schon ein paar Jahe her das ich das gebaut habe.
Ich wollte den Peltier nur nicht gleich voll mit 12V füttern. So kann ich die Temperatur der Kamera steuern.

Der Kühlkörper der Kamera habe ich von einem alter Kaffebecherwärmer von der Fa.Pearl aus Buggingen.
Obs den noch gibt weis ich nicht. Aber dabei war auch ein Peltier das ich allerdings beim testen über den Jordan geschickt habe.

Da ich die Kamera jetzt ungern zerlegen möchte hier ein knapp der Aufbau.
Ich habe den Rückenteil des Kameramoduls mit Kaptonband abgeklebt und darauf den Temeratursensor.
Da der nur 1mm hoch ist, geht der da gut verloren und ist zur Rückseite des Modules Elektrisch isoliert.


Darauf folgt ein 50x50x2mm dickes Wärmeleitpad. Die Dinger habe ich bei Ebay damals gekauft.
Ich habe mir den Kopf zerbrochen wie ich die unebene Rückseite der Kamera mit dem Peltier verheiraten kann und bin beim Stöbern dann auf das hier gestoßen. Hier werden die Unebenheiten der Bauteile zum Peltier ausgeglichen und alles liegt aneinander an.

Gab es für 3,50€

Dann das Peltier und der Kühlkörper mit der Kamera.
Viel Spaß beim Nachbau.

Den Okularanschluss habe ich mir neu gedruckt und mit einem alten Okular-Gehäuse verstärkt. So kann ich die Kamera besser im OAZ anziehen.

Gruß
Thomas