BitBangCCD Eigenbauprojekt vorgestellt

  • Wird etwas dauern bis ich hier wieder was berichten kann. Bin dabei die Schnittstelle zwischen PC und Kamera komplett neu zu programmieren. Das Kommandointerface, welches ich für die erste Inbetriebnahme gebaut hatte eignet sich nicht so gut für die Zusammenarbeit mit Programmen wie AstroArt. Auf der PC-Seite muß auch der Treiber entstehen. Das wird auch etwas dauern da ich seit Ende der 90er keine Software mehr für Windows geschrieben habe. Dort hat sich doch einiges getan.


    ;)

  • Hallo zusammen,


    ein kurzes Update vor Weihnachten. Diverse Arbeiten an meiner gebraucht erworbenen Montage haben mich auch etwas abgehalten. Dennoch ist schon mal eine Protokollbeschreibung für die USB-Schnittstelle entstanden, in der Camerafirmware sind der Kommandosatz implementiert und die ersten Kommandos sollten auch Daten zurückliefern. Leider kann ich erst beginnen das zu testen wenn auch der AstroArt-Treiber soweit ist. Dort ärgere ich mich momentan noch mit der Instanziierung der SerialPort Klasse von der Treiber DLL aus herum.


    Für die Software habe ich bei BitBucket ein geschlossenes Repository angelegt. Leider kann ich das nicht so ohne weiteres unter eine OpenSource Lizenz stellen und öffenen da die Firmware große Teile der ASF-Bibliothek von ATMEL nutzt welche nicht OpenSource ist. Man kann aber bis zu 5 Leute dahin einladen.


    Ich hoffe der Treiber beginnt über die Feiertage zu leben.
    Allen Sternfreunden wünsche ich über die Feiertage viel Zeit für die Bauprojekte und gutes Wetter zum Beobachten.
    In diesem Sinne ein frohes Fest und guten Rutsch in ein gesundes 2015.

  • Da es im Netz unter dem Stichwort myCCDcam schon eine Software für USB-Kameras gibt habe ich das Projekt in BitBangCCD umbenannt.


    Bei Mikrokontrollern ist der Begriff des Bit Banging für eine Art der Steuerung gebräuchlich, bei der die nötigen Signale von der Software aus über IO-Befehle bedient werden. Genau das passiert hier beim Auslesen des CCD Sensors.

  • Hi Thomas !


    Ich verfolge ebenfalls Dein Projekt schon einige Zeit.
    Auf dem HTT habe ich ja Dein Werk schon in Aktion gesehen.
    Für die ersten Testreihen war es sehr interessant.


    Meine Frage bzgl. des Kodak-Chip-Typ´s...:
    Gibt es bei exakt desselben Chip-Typ´s nicht dennoch eine Timing-Streubreite der Ansteuersignale ?
    Ich denke mal "Ja" sodass man um eine kleine Umprogrammierung softwareseitig nicht herumkommt oder ?
    Zumindest was das Signalverhalten und evtl. auch des Ausleseverhaltens angeht.


    Aber genug der Fragen.
    Finde es immer wieder klasse, das sich einige an dieser Materie herantrauen.
    Du nutzt vorhandene Komponenten um diese auf optimale Bedürfnisse zu modifizieren.
    Und da bist Du schon wirklich weit in der Materie vorangekommen. Hut ab !
    Was Du da alleine auf die Beine stellst.
    An diversen CCD-Projekten wirken da schon einige mit.


    Mir juckte es damals auch in den Fingern.
    Ein Projekt CCD-komplett-Selbstbau zu realisieren.
    Zudem käme noch das nötige Budget hinzu.
    Da habe ich dann aufgegeben und mich dann doch lieber der Antriebstechnik gewidmet. ;)
    Ist auch etwas einfacher.


    Soweit von meier Seite.


    Also bis zum nächsten HTT und...


    Frohe Weihnachtstage und nen guten Rutsch in´s neue Jahr 2015.


    M.f.G.
    Thomas der Zeltnachbar

  • Hallo Thomas,


    dir auch ein gesundes 2015 mit klaren Beobachtungsnächten. Danke für den Zuspruch. Meine Motivation generiert sich überwiegend aus dem was ich innerhalb des Projekts so lernen konnte.


    Zu der Frage des Timings ist es eigendlich eher so, daß es für einen bestimmten Typ eine maximale Geschwindigkeit gibt, mit der man den Sensor takten kann um die Ladungen auch sauber von Zelle zu Zelle zu transportieren. Diese maximale Taktrate gibt der Hersteller auch im Datenblatt an. Bis zu diesem Tempolimit garantiert der Hersteller die Eigenschaften im Datenblatt. Wenn man schneller sein will spielen dann Exemplarstreuungen, Temperatur und Spannung sicher eine nicht zu vernachlässigende Rolle.
    Ich bin mit dem ARM controller deutlich langsamer. Da der AD-Wandler im Controller maximal 1M-Sample kann brauche ich insgesamt 2..3 Sekunden um das volle Bild vom Chip zu lesen. Zum Focus einstellen will ich dann Teilbereiche lesen. Das geht dann deutlich schneller da nur die Pixel durch den AD-Wandler müssen die man auch sehen will. AstroArt unterstützt auch solche Subframes.


    Über die Feiertage konnte ich das Problem mit dem Öffnen des COM ports von der DLL aus lösen. Nun bin ich da im Lösungsmode und es entsteht wieder Programmcode. AstroArt verbindet sich nun mit der Kamera und schickt schon mal ein Kommando zum Starten einer Belichtung raus. Nächster Schritt ist nun die Kamera darauf entsprechend reagieren zu lassen.


    Wer sich mit der Programmierung nicht beschäftigen mag kann jetzt aufhören mit Lesen.
    Ich hatte Kontakt mit Fabio vom ArtroArt Team. Mir ging es darum ob man in der treiber DLL lieber die 'managed class' Bibliothek aus .net verwenden sollte oder das alte win API. Er meinte, daß man bei AA bisher in den DLL's keinen managed code verwendet hat. Es sollte aber gehen da die dllmain nicht benötigt wird. Let me know if it works, war seine Antwort. Das Interface zwischen managed und unmanaged code sieht sehr kryptisch aus und mir ist auch nicht wirklich klar, wie ich in einer DLL den ersten Wurzelzeiger für managed code erzeugen und verwalten muß. Daher habe ich mich dann doch für das alte winAPI entschieden. Ich hoffe das funktioniert noch eine Weile.


    Je nach dem wie viel Zeit ich habe könnte in 2..3 Wochen vielleicht das erste Bild in AstroArt zu sehen sein.


    Viele Grüße, Thomas.

  • Das Wochenende war recht produktiv, was die Firmware für die Kamera anging. Für das erste Bild hatte ich noch alles der Reihe nach programmiert und auch die Belichtungszeit war eine einfache delay-loop. Um flüssig mit dem AstroArt Treiber zusammen zu arbeiten geht das so nicht mehr. Keine Aufgabe darf den Controller mehr als 50..100ms am Stück blockieren. Der Controller muß ständig an den einzelnen Schauplätzen vorbei kommen und sehen ob irgendwo was zu tun ist. Dadurch läuft die Kommunikation und die Bedienung des Sensors und des Shutters quasi parallel.
    Um dabei einen klaren Zeitbezug zu behalten mußte auch ein entsprechender Timer und eine Uhr entstehen. Ein 32kHz Uhrenquarz ist auf der Platine mit drauf. Die Uhr läuft nun mit JulianDate und muß vom PC anfangs mit der richtigen Zeit versorgt werden.
    Da ich den Shutter nicht sehr schnell steuern kann lasse ich den Timer 8 mal pro Sekunde einen interrupt auslösen. Damit lassen sich dann Belichtungszeiten von n*1/8 sec. erzeugen. Mal sehen ob das reicht. Für kürzere Belichtungen müßte ich an der Hardware was ändern.
    Mit dem Timer als Basis kann nun als nächstes eine StateMachine für die Belichtungssteuerung entstehen. Die Funktionen zum auslesen des Sensors muß ich noch dahingehend ändern, daß immer mal wieder Pausen für die Kommunikation eingelegt werden. Das bedeutet das Bild in ~20 Blöcken zu lesen. Ich hoffe das ist nachher im Bild nicht zu sehen. Bisher wurde das Auslesen auch immer mal vom USB Interrupt unterbrochen ohne das ich im Bild sofort etwas gesehen hatte.
    Danach noch die Funktionen zur Übertragung des Bildes und dann wird's spannend [:D]

  • Momentan muß ich leider wegen einiger Bauarbeiten im Haus das Hobby hinten an stellen. Letzter Stand im März vor den Bauarbeiten war, daß ich von AstroArt aus eine Belichtung auslösen konnte und die Kamera das Bild in ihren internen Speicher liest. Was nun noch fehlt ist die Übertragung an den AstoArt Treiber und die Übergabe des Bildes in den Buffer von AstroArt.
    Ich hoffe, daß ich ab Mai dann damit weitermachen kann.


    Viele Grüße, Thomas.

  • Geschafft. Nach einigen Monaten Pause hatte ich im Juli und August wieder Zeit für die Software und es hat schon mal für ein erstes Bild in AstroArt gereicht.
    Vor dem Sensor sitzt zu Entwicklungszwecken erstmal ein altes 50mm Foto-Objektiv. Den letzten Urlaubsabend lag eine dünne Bewölkung am Himmel. Also habe ich zum Test mal über die Ostsee geschaut und zum Test die Windräder des neuen Baltic2 Windparks anvisiert. Der soll etwa 30km vor der Küste stehen.



    Die helleren Flecken sind Schiffe. Ich habe 5s belichtet. Die Lichter der Windräder sind synchronisiert und in der Zeit etwa 2s eingeschaltet. Man sieht auch deutlich, daß der Camera noch die Kühlung und die Subtraktion des Schwarzbildes fehlt. Der Hintergrung ist auch noch deutlich verrauscht. Das könnte von der Stromversorgung kommen. Der Behelfsaufbau hat da seine Grenzen.


    Die letzte Woche hatte ich noch die Funktionen zum Auslesen eines Teilbildes zum Fokussieren implementiert. Das funktioniert auch schon recht brauchbar.


    Jetzt werde ich erstmal Zeit in die Stabilität investieren müssen. Momentan bleibt die Verbindung nach einiger Zeit hängen und es ist noch nicht richtig klar ob das am Treiber für AA oder an der Firmware in der Camera liegt.

  • Wer Interesse hat kann sich hier noch etwas zum lesen herunter laden.


    Mit den Links poste ich mal einen Snapshot der momentanen alpha Software mit der das Bild entstanden ist.


    Snapshot des AstroArt-drivers:
    https://app.box.com/s/au3m5zjllef0qqnb0mned9yzcwqs3n85


    Snapshot der Firmware:
    https://app.box.com/s/o3et29155iar1dthckt65vutxpqg9xdn


    Und noch den Arbeitsstand des Manuals. Um selbst den Überblick zu behalten habe ich das Protokoll und anderes aufgeschrieben:
    https://app.box.com/s/yhdm13e86d8gjcshrkmbr6omh6xlsg3f


    Viele Spaß, Thomas.

  • Bei der weiteren Arbeit am Projekt haben sich im gegenwärtigen Aufbau folgende Schwächen gezeigt, für die ich nach einer Lösung gesucht habe:
    <ul><li> Messungen an der geöffneten Kamera sind extrem schwierig da der Sensor selbst bei geringem Umgebungslicht sehr schnell sättigt und man den typischen Betrieb nicht beobachten kann.
    </li>
    <li> Die Spannungswandler müssen besser von der Sensorplatine und dem Analogteil isoliert werden
    </li>
    <li> Der relativ langsame FS USB nervt, das wird vermutlich der primäre Grund sein an der Controller Platine was zu ändern, besonders wenn der Sensor dann mal größer wird.
    </li>
    <li> Die Kodak Megaplus ist nicht gekühlt und die Integration aller Elektronik in einem Gehäuse erschwert die Konstruktion eines Kühlers
    </li></ul>


    Daher habe ich mich entschlossen zwischen Sensor und Steuerprozessor eine "genormte" Schnittstelle einzuführen. Damit sollten sich noch folgende Vorteile ergeben:
    <ul><li> Hermetische, optische und elektromagnetische Kapselung des Sensors während der Rest der Elektronik zugänglich bleibt </li>
    <li> Kühlung so wie für den Sensor nötig mit Entwärmung durch eine nahe Gehäusewand </li>
    <li> Stark verringertes Luftvolumen im Sensorgehäuse </li>
    <li> Verschiedene Sensorköpfe und unabhängige Weiterentwicklung von Sensorkopf und Prozessorelektronik Idealerweise würde ein anderer Sensor "nur" geänderte oder erweiterte Software erfordern Momentan ist der Programmspeicher nur zu etwa 15% benutzt </li>
    <li> Geschaltete Spannungswandler werden auf der Prozessorseite untergebracht um wie gewohnt aus 9..18V leben zu können </li>
    <li> Im Sensorbereich nur Längsregler um ggf. weitere Spannungen zu erzeugen </li>
    <li> Man kann auf der Prozessorplatine ein paar LED's haben ohne das diese später Licht in der Kamera erzeugen</li>
    <li> Verlustleistung die bei der Spannungswandlung und in den Stromquellen für den Kühler entsteht kann man über einen kleinen Kühlkörper an der Prozessoreinheit bei höheren Temperaturen los werden </li></ul>



    Als Steckverbinder hatte ich einen Mixed SUB-D im Sinn bei dem man auch einen Koax-Verbinder für das Analogsignal integriert hat. Bin noch beim Durchzählen der nötigen Signale. Folgendes ist soweit eigendlich klar:
    <ul><li> Sensor H, V, R zum herausschieben der Pixel (5V TTL)</li>
    <li> Sensor Analogsignal als niederohmig angepasstes 50Ohm koax </li>
    <li> Shutter (4 Leitungen für 2 Magnete aus H-Brücke) </li>
    <li> Spannungen +/-15V, 5V (weiteres muß in der Sensoreinheit erzeugt werden) </li>
    <li> I2C Bus für irgendwelche langsame Steuerungen </li>
    <li> Weitere Digitalleitungen als Reserve für später (5V TTL) </li>
    <li> 2..3 Analogeingänge des Prozessors für Temperaturmessungen o.ä. </li></ul>



    Damit sollte man eigendlich fast alle CCD-Sensoren betreiben können solange diese nicht parallel über mehrere Analogkanäle ausgelesen werden.

  • Für die gute alte Handskizzenmethode wurde die Konstruktion dann doch zu kompliziert. Da habe ich mal angefangen mit FreeCAD. Die Einarbeitung ging dank YouTube recht gut und das Grundkonzept für einen Sensorkopf mit dem KAF1401 steht schon mal.



    Diverse Bauteile werden den Spenden der zerlegten MegaPlus Kameras entnommen. Das Sensorboard kommt von der MegaPlus 1.4 da ich dieses in der Funktion recht gut verstanden habe. Von dem Bündelkauf von 3Stk. 1.4i habe ich genügend Schutter, also kommt davon einer rein.


    Die TEC Elemente waren per Brief aus China sehr günstig zu haben. Alle drei Peltiers sind für max. 8.5A ausgelegt, die großen haben mehr Spannung. Damit kann ich alle 3 in Reihe schalten und lande in der Summe bei 13,8V die nicht überschritten werden dürfen. So ist auch nur einen Strang zu regeln.


    Fehlt als nächstes noch der hintere Deckel mit der bereits beschriebenen Schnittstelle und die Kühler an der Seite. Da werde ich wohl ein paar alte PC Kühler zersägen und passend fräsen. Der vordere Deckel kommt wieder von der 1.4i, wird aber etwas kleiner gefräst und innen ausgehöhlt was 3mm Bauhöhe bringt und Gewicht spart.

  • Inzwischen habe ich ein brauchbares FreeCAD-Modell der CCD-Unit. Die Konstruktionsunterlagen aus FreeCAD kann ich unter einer Creative Commons Lizenz bereitstellen falls jemand Interesse hat.




    Die vordere Deckplatte und damit das primäre Anschlussgewinde stammt von der MegaPlus Camera, wird allerdings bearbeitet. Die Entwärmung des Kühlers erfolgt durch das gefräste Alugehäuse. Die Kühlkörper werden aus ausgedienten PC-Prozessorkühlern gefräst.



    Am hinteren Deckel wird ein flacher 120mm Lüfter befestigt. Das Cameragehäuse ist oben zugänglich. Dort befindet sich die bereits erwähnte Schnittstelle zur Prozessorbaugruppe.
    Leider kann ich mit FreeCAD das Volumen und damit das Gewicht nicht richtig abschätzen. Die momentane Schätzung liegt bei knapp 1kg.
    Mir fehlen einfach noch Erfahrungen wie schwer es sein wird den Sensor plan in der Bildebene zu justieren. Daher gibt es am Kühler eigendlich zu viele Schrauben die gewisse thermische Kurzschlüsse erzeugen und ich habe den Kühler eher überdimensioniert.

  • Langsam hat das Aluminium die Löcher an der richtigen Stelle.
    Objektivseite mit Shutter:


    Aussparung für Kühler und Sensor:


    Wenn alles passt geht's dann zum eloxieren.

  • Nach dem Eloxieren konnte ich die Kühlkörper und den Shutter zusammensetzen.

    Für den Einbau der Sensoreinheit fehlen noch die Platinchen für die I2C Temperatursensoren. Davon soll je einer die Temperatur am Sensor, der Kupferplatte, dem Gehäuse und der Außenluft messen. Damit sollte man neben der Steuerung dieses Aufbaus auch genügend Erfahrungen sammeln können um in späteren Designs die Kühler effizienter auslegen zu können.

  • In den leztzen Wochen habe ich die Temperatursensoren aufgebaut und die entsprechende Software für den I2C-Bus zum Laufen gebracht. Dazu habe ich nun endlich mal eine Controller-Elektronik auf ein Brett geschraubt um leichten Zugang zu haben.



    An dem Bandkabel sitzen behelfsmäßig die vier Sensoren von Maxim. Diese sind bereits kalibriert und man bekommt ohne viel Rechnerei eine korrekte Temperatur. Nach dem Ansprühen mit Kältespray kann man den Auftauvorgang beobachten. In dem Moment wo sich das Eis auflöst meldet der jeweilige Sensor sehr exakt eine Temperatur um 0°C. Das reicht mir im Moment zur Verifizierung.


    Neben den Temperatursensoren soll dann noch ein IC zur Lüftersteuerung mit an den I2C Bus. Das werde ich aber vermutlich erst aufbauen wenn die Camera in diesem mechanischen Aufbau wieder läuft und klar ist, dass die Störeinstreuungen weg sind und der Chip sich in der Bildebene korrekt justieren lässt.

  • Hier mal ein Bild des Sensors mit der 2. Kühlerstufe und dem Temperatursensor auf der Kupferplatte.



    Den Sensor habe ich einstweilen mit einer GoPro-Linsenschutzfolie abgedeckt. Mal sehen ob sich das als Staubschutz bewährt solange das Gehäuse offen ist.

  • Inzwischen ist nun auch der Sensor im Kühlergehäuse eingebaut. Dazu die beiden Peltiers der 1. Kühlerstufe mit Wärmeleitpaste ins Gehäuse gesetzt

    und die Kupferplatte mit 2. Stufe und Sensor drauf montiert.

    Die ebene Ausrichtung der Platte gegen das Gehäuse konnte ich erstmal nur mit einem Messschieber einstellen. Die Justage wird erst möglich sein wenn die Kamera funktioniert und man ein Bild auf den Sensor werfen kann.

  • Da der erste ungekühlte Aufbau im Kodak-Gehäuse immer noch zur Softwareentwicklung taugt wollte ich dieser erste Kamera nicht auseinanderreißen. Daher ist ein weiterer Controller mit Stromversorgung entstanden der dann am anderen Ende der oben genannten Schnittstelle sitzt.

  • Zur Ansteuerung der Peltierkette musste auch noch eine Leistungsstufe her. Nach etwas Suche in alten PC-Netzteilen ist dann folgende Lösung entstanden.

    Als Schaltung sieht das etwa so aus (LT-Spice Simulation):

    Da das Peltierelement (simuliert als R1) gegen seine Umwelt isoliert daher kommt kann man sehr schön mit einem N-FET (M1) gegen Masse arbeiten. Als Ladespule dient L1 und D1 sorgt dafür das der Strom in den Schaltpausen noch etwas weiter fließt. C2 soll den Strom durch den Kühler etwas glätten. L2 und L3 sind parasitäre Induktivitäten von Anschlussdrähten. Diese sind relativ wichtig um den recovery Strom zu begrenzen wenn der Transistor öffnet und die Diode von Fluss- in Sperrrichtung übergeht.


    Bei 100kHz und 80% Tastverhältnis stellt sich ein Strom von etwa 6A ein.

    Die aufgebaute Schaltung oben verhält sich auch sehr gut wie das Modell. Grün der Strom durch das Peltier und rot der Strom durch den Transistor mit den recovery-Spitzen der Diode.
    Im praktischen Aufbau sitzt noch ein MAX626 als Treiber vor dem FET um das Ganze von einem PWM-Timer des Controllers aus der 3.3V Logik ansteuerbar zu machen.
    Damit habe ich die Möglichkeit beim Auslesen des Sensors den Schaltregler für den Kühler zu stoppen.


    Das ganze arbeitet mit den gewählten Bauelementen sehr effizient. Bis etwa 5A kann man von Hand kaum eine Erwärmung des Alu-Blechs feststellen. Erst bei fast vollem Strom wird es handwarm.

  • Mitten in der Inbetriebnahme der ersten richtigen Camera hat mich im Mai die Schliessung unseres ATMEL-Standortes üeberrascht. Das hat momentan einige Prioritäten verschoben und die Kamera musste liegen bleiben. Ich hoffe, dass es im Juli dann endlich weiter geht und ich zum HTT damit Fotos machen kann.

  • Hallo Thomas !


    Jobmäßig hat das natürlich obere Priorität, alles wieder in trockene Tücher zu bekommen.
    Ich hoffe, dass ein Standortwechsel stattgefunden hat, der noch in zumutbarer Nähe erreichbar ist.
    Alles Gute dafür.


    Ansonsten hoffe ich, Dich unter dem CS-Himmel, wie jedes Jahr, auf dem HTT anzutreffen.
    Falls Deine Cam bis dato fertig sein sollte, werde ich mal diese beäugeln wollen. ;)
    Dein Projekt ist schon recht interessant.
    Falls Interesse, habe hier noch zwei Sensoren rumliegen und werde sie mit zum HTT bringen.


    CS & CU


    M.f.G.
    Thomas

  • Hallo Tom,


    danke für die Anteilnahme. Was auch immer Microchip nun mit den ATMEL Funk-Chips machen wird die wir entwickelt haben wird ohne uns Dresdner statt finden. Ich bin also nach 11 Jahren mal wieder auf dem Markt. Eigendlich ist das auch eine Chance mal wieder was anderes zu machen. Vielleicht geht wieder etwas mehr Optik und weniger Antennen. Bin gespannt wie akut der Fachkräftemangel ist.


    Viele grüße, Thomas.

  • Nachdem der ganze Kabelsalat zwischen Controller und Sensoreinheit nun endlich geht habe ich in den letzten Tagen den Analogteil für das Videosignal abgeglichen. Einiges an interessanten Details zu diesem Thema ist hier zu finden:
    http://www.asiaa.sinica.edu.tw/~sfhsu/upload/McLean_2008.pdf


    Um frei messen zu können habe ich einen Sensor mit GoPro-Folie und angestochenem Aluklebeband als Lochkamera verwendet. Bei gemütlicher Abendbeleuchtung schafft man es dann auch den Lichtfleck unter den Sättigungspegel zu bringen.




    Das eigendliche Problem beginnt am Sensorausgang wo dem etwa 1V Signal noch etwa 10V Gleichspannung aufgeprägt sind. Damit ist man satt außerhalb dessen was gängige schnelle Signalverstärker verarbeiten.
    Kodak hatte hier eine AC-Kopplung gebaut um die Gleichspannung los zu werden. Allerdings haben die Jungs auch sehr viel schneller gelesen als ich das kann und auch nur mit etwa 7..8bit aufgelöst.
    Also hatte ich mich bei den ersten Versuchen letztes Jahr schon entschlossen für jedes Pixel den Schwarz und den Belichtungswert zu wandeln.
    Gleichzeitig liegt vor dem Schwarzwert immer noch ein recht hoher Impuls der beim Rücksetzen der Ausgabezelle entsteht.
    Kodak hatte die Verstärkerstufe mit einem Verstärker gebaut der in der Lage ist Signale außerhalb eines einstellbaren Pegels abzuschneiden.
    Auf dem folgenden Bild ist der Reset Impuls bereits weitestgehend abgeschnitten.



    Der Bildinhalt steckt also in der Höhe der fallenden Flanke nach dem Dunkelwert. Nun geht es also darum das Signal möglichst breit in die +/- 1.5V Treiberbereich zu bringen und dabei so viel Luft zu haben, dass es einen je nach Bildinhalt wandernden Offset noch verkraftet.
    Über eine komplette Bildzeile zusammengeschoben ergibt sich folgende Hüllkurve.



    Die obere Kante bilden die Reset-Pulse die vom Verstärker begrenzt wurden. Darunter erkennt man die Linie des Dunkelwertes und wie dieser sich je nach Bildinhalt leicht verschiebt. Die Unterkante der Kurve wird durch die Pixelwerte bestimmt.
    An der Kodak-Sensorplatine waren etwa 10 Bauelemente im Wert zu ändern um an diesen Punkt zu kommen. U.a. wurde den Koppelkondensator von 100n auf 2.2uF erhöht und zwei Potis nachgerüstet um Verstärkung und Offset einstellen zu können da das Bildsignal einen Gleichanteil hat.


    Interessante Beobachtung dabei, der Sensor den ich gerade verwendet habe liefert innerhalb der herstellerseitig abgedeckten Pixel am Zeilenanfang für zwei Pixel ein lichtabhängiges Signal.
    (2 kleine Nadeln sichtbar)
    Bei hinreichend stabilem Offset kann man den Dunkelwert eigentlich am Zeilenanfang aus diesen Pixeln bestimmen.


    Jetzt wo dieser Bereich bekannt ist kann ich den ADC-Eingang passend tunen.

  • In den letzten Wochen ist an der Software viel passiert:
    - Die Instabilitaet bei der Bilduebertragung an den PC ist beseitigt.
    - Firmware und AstroArt-Treiber unterstuetzen Dark Frames
    - I2C Bus Treiber und Temperatursensoren sind in die Firmware eingebaut
    - Diverser Informationsaustausch zwischen Kamera und AstroArt wurde in Ordnung gebracht
    - Der Treiber stellt beim Verbinden die Julian Date Uhr in der Kamera
    - PWM-Signal fuer den Kuehler und PID Regler dazu. Hier muss als naechstes der Leistungsregler und der Luefter angebaut werden.
    - Ueber eine serielle Schnittstelle mit grossem DMA-Buffer ist die Kamera nun sehr gesp#8206;raechig was gerade ablaeuft.
    #8206;
    Alles in allem ist es nun an der Zeit das Geraet langsam mal ans Teleskop zu montieren. Dann gibt#8206; es auch wieder ein paar Bilder. Momentan sieht es so aus als ob das HTT eine gute Gelegenheit werden koennte den Dynamikbereich zu testen.

  • Hi Thomas !


    Na da bin ich auch mal drauf gepannt, wie es beim HTT so klappt.
    Ist Deine G11 nun mechanisch wieder fit?


    Ansonsten bis zum HTT.


    CS & CU


    M.f.G.
    Thomas

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!