BitBangCCD Eigenbauprojekt vorgestellt

Ja, die G11 ist inzwischen ganz gut beisammen, hat aber viel Arbeit gemacht. Da ich Escap-Motoren mit Planetengetriebe habe war der Anbau etwas umständlicher:
http://www.astrotreff.de/topic.asp?TOPIC_ID=173569
Das alte Fett hatte die Festigkeit eines soliden Haribo Goldbären entwickelt. Das war aus den Nadellagern schwer heraus zu bekommen, ich wollte sie aber auch drin lassen.

Ansonsten hängt die Kamera seit gestern schon mal am Teleskop.

Der Controller ist noch ein loser Drahthaufen.

Mehr als ein paar helle Sterne die durch die Wolken scheinen waren gestern aber noch nicht zu holen. Ohne Kühlung wird das ohnehin nicht so dolle werden. Mit dem ordentlich gesättigten Punkt des Sterns haben sich auch ein paar merkwürdige Linien im Bild gezeigt. Dem muss ich noch mal nachgehen. An der Stelle zeigt sich AstroArt nun sehr hilfreich um solche Fehler brauchbar zu analysieren.

Zwischen den Wolken gab es kurze Momente in denen man Testbilder mit Wega machen konnte. Die erste Auswertung eines echten Sternfotos brachte folgendes zutage.

Innerhalb der Auflösung des AD-Wandlers (0...4095) liegt der Dynamikbereich des Sensors etwa zwischen 210 und 3380. Das ist dem AstroArt Histogram recht brauchbar zu entnehmen. Im Prinzip ist die Hardware also in der Lage den Sensorbereich mit mehr als 11 bit aufzulösen.
Gleichzeitig zeigt das Bild die Schwäche des alten Sensors ohne Anti Blooming. Gesättigte Pixel laufen gnadenlos über.
Vor dem schwarzen Hintergrund zeigen sich nun auch horizontale Fehler die offenbar beim Auslesen durch Unterbrechungen entstehen. Alle 50 Zeilen haben die anderen Funktionen mal kurz Zeit etwas abzuarbeiten. Jetzt kommen also langsam die spannenden Bugs.

Die horizontalen Linien waren überwiegend Restladungen die beim Löschen des Sensors offenbar in der Matrix geblieben sind. Vor der Belichtung muss ich den kompletten Sensor "leerschieben". Bei einem Modell ohne Antiblooming ist er einzige Verlässliche Ort wo man die Elektronen sicher los wird die Ausgabezelle mit aktiviertem Reset Transistor. Ich habe nirgends etwas finden können ob man den Hauptteil der Ladung unbeschadet einfach durch Zeilenschieben in die Ausgabezeile transportieren darf und diese läuft dann eben über. Das würde etwas Zeit sparen.
Besonders wenn der Sensor nach längerem Stillstand mal wieder belichtet werden soll reicht ein Löschzyklus nicht um alles sauber zu bekommen. Die Software flitzt jetzt 2x drüber und vor dem zeilenweisen Verschieben in die Ausgabezeile räume ich diese auch noch mal leer. Nun ist das Rauschen im Hintergrund gleichmäßig.

Den Kühler und den PID-Regler mit der oben beschriebenen PWM-Leistungsstufe habe ich inzwischen auch getestet. Funktioniert gut. Den D-Anteil werde ich voraussichtlich Null lassen, ein PI-Regler reicht also. Wie es aussieht werde ich 35°C unter der Kühlkörpertemperatur problemlos erreichen. Muss jetzt erst mal den Lüfter anbauen, sonst ist der Spaß nur von kurzer Dauer. Dazu gehört dann noch ein Sensor für die Außenlufttemperatur. Damit sollte sich in der Software das thermische Weglaufen erkennen lassen, welches ich bei der SBIG STV immer wieder mal hatte.

Pünktlich zum HTT ist die neue hintere Gehäusehälfte fertig geworden. In der alten hatte nur ein kleines Trockenpäckchen Platz und ich hatte ständig Eis auf dem Sensor. Zur Trocknung hat das Teil bei 55°C im Bachofen übernachtet.

Nach der Montage Trockenperlen einfüllen.

Lüfter drauf und fertig ist der Fotoziegel.

Das Trockenlegen der Sensoreinheit hatte gut funktioniert und zum HTT ist mir der Sensor nicht mehr zugefroren. Nun bin ich bisher mehr Bastler als Fotograf und Bildbearbeiter aber erste Bilder sind in den Wolkenlücken zum HTT schon entstanden. Momentan kann ich mit der Kamera keine Filter verwenden.

M15 stand günstig und so habe ich es mal da versucht.

Das Bild entstand mit 120s Belichtung, ohne Kühlung aber mit Subtraktion eines dark frames. Hier sieht man die Schwäche des alten Sensors der noch kein Antiblooming hat.

Um die Stabilität des Treibers und der Software zu testen habe ich AstroArt mal eine Serie aus 10min-Bildern des Galaxienhaufens um NGC1275 machen lassen.

So entstanden in der Wolkenlücke am Donnerstag Abend 8 Bilder zu je 10 Minuten bei Kühlung auf -5°C. Kamerafirmware und PC-Treiber zeigten stabiles Verhalten.
Optimierung in Richtung besserer Schärfe würde ich noch hinten anstellen und das momentan sehr schwere Kameramodell eher zu Entwicklungszwecken verwenden. Die momentane Mechanik und Kühlung ordnet sich noch den Erfordernissen unter die die Verwendung der Kodak Bauteile mit sich bringt.

Folgende Funktionen will ich mit diesem Modell noch hinzufügen:
- Firmware für die interne SD-Karte, damit sich die Kamera die Darks für die Temperatur/Belichtungszeit - Kombinationen merken kann

- HighSpeed USB-Interface um die Ladezeiten zu verkürzen

- Regelung für den Lüfter

- Treiber für andere Software als AstroArt. Die Software ist für relativ intelligenzfreie Kameras gedacht und ich vermisse zunehmend Funktionen wie z.B.
- Übergabe von Bildattributen für die Speicherung in FITS
- Temperatursteuerung geht nur per skript
- ...

Wenn das geschafft ist müsste ich dann eigentlich alles zusammen haben um über eine nächste Generation mit einem guten Sensor und leichter Bauweise nachzudenken. [:D]

Ach ja, Tipps welche Fotosoftware gut ist oder welchen Bildsensor man für die Zukunft anvisieren könnte sind stets willkommen.

Um zügiger mit der Kamera arbeiten zu können will ich die Mikrokontrollerinterne Schnittstelle (12Mbit USB) durch einen HS-USB am Erweiterungssteckverbinder ablösen. Dazu muß der Treiber auf der PC-Seite überarbeitet werden. Da ich mit dem AstroArt-Treiber auch immer mehr an die Grenze der Funktionalität gestoßen bin habe ich entschieden gleich mit ASCOM weiter zu machen. Ist in Summe also ein größerer Umbau mit folgendem Inhalt:
- FT2232 Modul (8bit - Async '245) an Erweiterungsstecker anschließen (done)
- Kommunikationsfunktionen der Kamerafirmware umbauen (im Gange)
- ASCOM Kamera-Template zum Laufen bringen (done)
- Treibersoftware von C++ nach C# portieren (im Gange)
- Alles wieder stabil zum Laufen bekommen (oh weh)
- ASCOM-Treiber um Dialoge zur Kamerasteuerung erweitern (hoffentlich nächstes Jahr)

Wenn das geschafft ist sollte das Projekt dann hinsichtlich der Software langsam "state of the art" sein. Falls jemand Interesse an der Software hat, ich verwalte alles in einem Cloud-Repository für das ich Einladungen verschicken kann.

Ich sag' schon mal frohes Fest! Viele Grüße, Thomas.

Inzwischen hat der Controller einen handverdrahteten Aufsatz mit einem FTDI3232-Modul bekommen. Das kann HiSpeed USB und die Daten werden Byte-Weise parallel übergeben. Die Firmware ist auch schon so umgebaut, dass sie über die neue Schnittstelle redet.

Seit Dezember arbeite ich für eine neue Firma wo es auch viel spannendes zu lernen gibt. Das begrenzt meine freien Gehirnwindungen im Moment sehr stark. Trotzdem habe ich es immer wieder geschafft mich weiter in das Thema ASCOM-Treiber einzuarbeiten. Das herunterladbare Beispiel war recht schnell am Laufen und erste Module der Software sind auch schon nach C# portiert. Der Treiber nimmt zumindest schon mal Verbindung mit der Kamera auf und versteht die alle Sekunden von der Kamera kommenden Statusinformationen mit Uhrzeit und Kühlerstatus.
Bis zum ersten Bild wird es wohl noch einige Zeit dauern. Als nächstes ist erst mal das Auslösen einer Belichtung dran. Die Tatsache, dass ich nicht kontinuierlich daran arbeiten kann zwingt mich dazu die Softwarestruktur besser zu dokumentieren. Das ist aber eigentlich gut.
Eine größere Baustelle tut sich bei der Unterstützung von Subframes auf. Für AstroArt hatte ich eine feste Größe von 100x100 pixeln implementiert. Das hat viel Zeit gespart um erst mal was zu haben womit man fokussieren kann. Für ASCOM will ich das gleich richtig machen und beliebige Subrames zulassen, so wie der Treiber das vorsieht.