CCD - Camera Eigenbau

  • Hallo


    kameras mit dem Chip sind gerade erst um 1200€ im preis gesunken, wenn das am Chippreis liegt müsste der fast umsonst sein.
    ja wieviel für welchen Preis? mit Grade 12 hast du sicher recht 400$ ? vielleicht ein paar Etwickler für 150$ oder meinst du eher in € ??
    ich habe denen erst mal klar gemacht das es um teurere geht mit über 2000 Auftragsvolumen und sich die Stückzahl auch etwas nach dem Preis und der Qualität richtet, eventuell auch an Kaf 3200 mit Microlinsen und sie mal ein Preisliste machen sollen. Allerdings möchten die gern das ich eine Firma bin, aber wird sich schon jemand finden der eine hat, ist doch bei Export eigentlich auch egal, wegen ohnehin Steuer und Zoll was die doch einen feuchten Dings angeht. na ja die Dinger werden eben auch miltärisch genutzt.


    Gruß Frank

  • Hallo Leute,


    ihr habt doch nicht etwa gedacht, das hier ist wieder so ein Thread wo großspurig Pläne geschmiedet werden, dann aber nix bei rauskommt? [;)]



    Also, was ist inzwischen passiert:
    - das elektronische Design für die Kamera ist fertig
    - die Platinen-Layouts sind so gut wie fertig
    - die Mechanik-Konstruktion ist auch so gut wie fertig.


    Entwicklungsseitig fehlen noch:
    - das Bediengerät
    - das Filterrad
    - die komplette Programmierung/SW-Entwicklung natürlich [xx(]



    Auf der Elektronik-Seite haben sich nochmal konzeptionelle Änderungen ergeben:


    - es wird doch ein Microcontroller verwendet (kein Softcore, die Gründe dafür kann ich bei Interesse darlegen). Und zwar ein ATXMEGA mit 32MHz Taktfrequenz.


    - zur USB-Übertragung wird doch nicht der isochrone Mode verwendet. Dieser ist zwar für Videoübertragung in Echtzeit optimiert (so dass die Kamera keinen Bildspeicher braucht), macht aber keine Korrektur von Übertragungsfehlern. Das ist für unsere Zwecke natürlich nicht akzeptabel. Stattdessen wird der bulk mode verwendet. Der USB device Controller ist ein FT2232H, was die Sache gegenüber dem Cypress vereinfacht.



    Und bei der Mechanik:


    - wie an anderer Stelle bereits ausgeführt habe ich das Alu-Dings vom ICX453 weggefräst, so dass der Chip jetzt direkt auf den Kühlfinger kommt.
    - für die Wärmeableitung zum Kühlkörper wird Kupfer statt Alu verwendet, wegen der deutlich besseren Wärmeleitfähigkeit



    Fahren wir also fort mit ein paar Raytrace-Bildchen:


    Das hier ist die Hauptplatine (Bild erstellt mit dem Eagle3D Konverter von M.Weißer, ge-raytraced mit POVRAY):





    Oberhalb des Wärmebrücken-Durchbruchs das FPGA, ein Altera Cyclone mit 144 pins. Links daneben der USB Controller. Rechts neben dem FPGA sitzt ein 256Mbit dynamisches RAM (ausgeschlachtet aus einem PC133 Speicherriegel). Darunter der Microcontroller im TQFP100 Gehäuse.


    Am unteren Rand der Platine sitzt mittig bis rechts der Schaltregler für das Peltier-Element. Links neben dem größeren roten Stecker befindet sich die Ansteuerung für den DC-Motor im Filterrad.


    Unten links werden über Schalt- und Längsregler die digitalen Versorgungsspannungen erzeugt, darüber ein paar Teile für die Lüfterregelung.


    Am linken Rand sitzen die Steckverbinder zur Außenwelt, der Power-Taster, und 2 LEDs.


    Die andere Seite der Platine beherbergt vor allem das nötige Vogelfutter, also insbesondere die vielen Abblock-Kondensatoren der digitalen Bausteine.




    Der CCD-Chip sitzt auf einer zweiten Platine, die Huckepack auf die erste draufkommt:




    Zwischen Platine und CCD der Kühlfinger.


    Auf der CCD-Platine sitzt alles was direkt mit der CCD-Ansteuerung zu tun hat:


    - Erzeugung der Versorgungsspannungen für die Taktsignale (15V, 6V, 5V, -7V)
    - Treiber für die Vertikal- und Horizontaltakte (für letzteres braucht man einige Ampere Spitzenstrom!)
    - Verstärkung und Digitalisierung der Bilddaten



    Der Kühlfinger ragt durch bis auf die Unterseite, dort sitzt dann das Peltier-Element:




    Die Warmseite des Peltier sitzt direkt auf einem Kupferzylinder, der zum Kühlkörper führt. Hier im Bild auch die hintere Hälfte der Kühlkammer:




    Zusammen mit der vorderen Hälfte sieht das dann so aus:




    Oben befindet sich ein Schlitz, durch den die Platine hindurchgeht. Muss natürlich später abgedichtet werden.





    Das seitliche Gewinde rechts oben an der vorderen Kühlkammer-Hälfte hat auch seinen Sinn: hier wird eine Trockenpatrone eingeschraubt:



    Im Inneren ist Platz für ca. 1cm³ Silica-Gel.



    Wenn wir das bisher gesehene zusammenbauen, erhalten wir dieses hier:





    Das Ganze braucht natürlich noch ein Gehäuse:




    Die Gehäuseabmessung ist 103x103x50mm.



    Hier mit dem Innenleben:





    Und mit den Wänden drin, und die Kühlerei hinten drauf, ergibt dieses:






    (Wobei der Lüfter im Moment noch in der Luft hängt... [;)] )



    Und als "Beweis" dass die Sache nicht nur im Rechner existiert... die CCD-Platine liegt schon hier...




    Jetzt mache ich mich erst mal an das Filterrad, da zu dessen Anbindung frontseitig am Kameragehäuse noch was getan werden muss.


    cs
    Martin

  • Hallo Martin,


    das sieht ja bisher phantastisch aus! Da steckt bereits sehr viel Arbeit drin. [:)]


    Verwendest du für die Erzeugung der CCD-Spannungen noch an die Schaltregler nachgeschaltete LDOs? Bildsensoren mögen ja keine Schaltregler in ihrer Nähe... [:D]


    Was für ein DRAM verwendest du? DDR/DDR2? Hast du bereits einen Speichercontroller fürs FPGA oder muss der neu programmiert werden? Ich frage nur, weil der Speichercontroller nahezu das Schlimmste im FPGA ist... [;)]


    Viele Grüße und weiter so!
    Robert

  • Hallo Robert,


    die +15V für den Vertikal-Sync und den Ausleseverstärker kommen aus einer Ladungspumpe (angetrieben mit 250kHz aus dem 12V/5V Schaltregler für die Digitalversorgung). Dort ist ein Längsregler drin.


    Die +6V für die Horizontaltakte und Reset Gate kommen über einen Längsregler aus der 12V.


    Die -7V für den Horizontal- und Vertikal-Sync kommen direkt aus einem 12V/-7V Schaltregler, d.h. ohne nachgeschalteten LDO. Ich meine dass diese nicht so empfindlich sind bzgl. Ripple.


    Siehst du eher den supply voltage ripple oder den magnetischen Streufluss kritisch bei CCDs?



    Das RAM ist nur SDR. Reicht locker von der Geschwindigkeit, und die ganzen skew-Problematiken bei DDR will ich mir nicht antun.


    Den SDRAM Controller gibt es noch nicht. Ich denke an eine eher einfache Lösung. Größtes Problem werden wohl (wie meistens) die Refresh Cycles sein. Wahrscheinlich betreibe ich das RAM im Burst Mode mit 8 words, und danach immer ein Refresh.

    Die CCD Timing-Erzeugung im FPGA läuft bereits in der Simulation, aber im Moment erstmal für meinen neuen Autoguider mit dem ICX405 (291x500 Pixel). Aber die Pixelanzahl ist im VHDL-Code natürlich einfach skalierbar [:D]


    Ich habe das Timing übrigens in Form von 4 hierarchisch organisierten Master/Slave State Machines realisiert. Gibt es einen Trick wie es einfacher geht?



    cs
    Martin

  • Hallo Martin,


    vielen Dank für die Infos.


    Bezüglich der ganzen Versorgungsgeschichte: Spannungs-Ripples sind sicherlich von Bedeutung, und diese würde ich so gut wie möglich vom Sensor fernhalten. Deshalb der Vorschlag mit den nachgeschalteten Längsreglern.
    Aber probier es einfach mal aus; wenn es einen Einfluss gibt, dann kannst du ihn unter Umständen auf die Quelle zurückführen, d.h. wenn es "Rauschmuster" im Bild gibt, die sich zusammen mit dem Takt des Schaltreglers und dem Zeilentiming ergeben. Aber das sind Feinheiten, die du erst siehst (wenn überhaupt), wenn du einen Prototypen vor dir zu stehen hast. [:)]


    Wegen des Speichercontrollers: Vielleicht gibt es z.B. bei "Open Cores" bereits eine fertige Lösung, die du integrieren kannst. Denn bis die State Machine für den Refresh etc. geschrieben ist, vergeht sicherlich etwas Zeit. Auf jeden Fall wäre ein Speichertester, den du in den Bildpfad multiplexen kannst, sinnvoll.


    Hm, Tricks zum Sensortiming... Ich sag's mal so: wenn es die Aufgabe erfüllt, relativ einfach skalierbar und zudem noch lesbar ist *g*, ist jede Lösung okay. Aber eigentlich müsste eine State Machine reichen, die "extern" (also außerhalb dieser) Zähler startet und stoppt. Mit entsprechenden Vergleichern kannst du dann gezielt dein Zeilentiming zusammenbasteln. So kann man das Ganze noch etwas schneller takten, als wenn alles in einer FSM "verpackt" ist... [:)]


    Grüße
    Robert

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!