Größere CCD Sensoren

Da die Ströhme sehr gering auf den Leitungen sind, bekommen die ein furchtbares Ripple, aus die zusätzlichen Linearregler lässt sich dann wahrscheinlich eh nicht mehr verzichten. Und in diesem Fall scheint die Ladungspumpe einfacher aufzubauen zu sein. Zumindest ist es nicht sehr angebracht, wenn die Versorungspannung des Vorverstärkers nicht sauber ist. Dann macht auch ein 30$ 16bit ADC keinen Sinn mehr...

Jetzt fehlt eigendlich nur noch die Lösung für den Fokusmotor und die Peltierregelung.

Irgend wie ist das Proekt fast richtiger Wahnsin. Zumindest wenn ich mir meinen Desktop anschaue... rund 20 PDF Files liegen da schon rum. MIndestens 10 davon betreffen das Projekt direkt.

Und ich hab die ersten fehlenden Daten in den Datenblättern gefunden: Die Timingdiagramme für das Horizontale lesen fehlen anscheinend im Datenblatt des CCDs. Genauso wenig steht da drin, wo für es H1a + H1b und H2a + H2b gibt. In dem einzigem Timingdiagram werden beide gleich getaktet.
Wichtig wäre die Daten aber auch nur wen der Timingchip durch programierte timings des EZ USB ersetzt werden soll. (Theoretisch müste es möglich sein eigene Auslesemodis zu konstruieren, z.B. 1/4 aller Zeilen fürs GUiding und 3/4 für das Bild)

Zu den relativ kleinen 4,4µm Pixeln ist mir noch etwas eingefallen: Da die sinvolle Brennweite bei etwa 750mm-1500mm liegt, könnte man den Sensor quasi als Fangspiegelersatz verwenden. Noch besser wäre aber ein Spiegel mit ein wenig Astigmatismus, so das die Cam neben dem Strahlengang liegen kann. (Eigendlich nur noch ein Herschelspiegel) Die minimal schiefligende Bildeben kann man dann durch kippen des Sensors/Cam wieder ausgleichen.... zumindest für Deep Sky würde so eine relativ kompaktes Teleskop möglich sein...

Mir ist noch zum Filterad folgende Filteranordnung eingefallen:

Rot,H-Alpha,Schwarz,O3, Grün ,Transparent,Blau, Schwarz, Sonstiger

Läst sich bestimmt noch verbessern.... aber irgend wie macht es sinn die Schmalbandfilter neben einem Shutter zu plazieren und den Breitbandigen Filter zwischen Schmalband und transparent...

Ich hab jetzt zum großem Teil die Bauteile als Eaglebiblioteken, un kann wahrscheinlich morgen damit anfangen den ersten Schaltplan zu zeichnen.

So wie ich die Hardware beis etzt einschätzen kann, ist sie weniger komplex als beim Audineproekt, jedoch sind nur SMD bauteile eingeplant. Zumindest den Vorverstärker und den AD Wandler kann man nur noch mit Heißluft/IR löten. In Sachen Leiterbanen wird es dagenen kaum komplex werden. Eine 2 Layer Platine sollte ausreichen.

Naja was kostet der? mit 16 MPix wird der sicher nicht ganz billig sein. Von den Timings ist der etwas einfacher zu benutzten, aber so wie ich die Preise kenne ist der fast nicht zu bezahlen... (Ich werde wohl bei der Planung erst mal beim ICX274AL bleiben)

So nun gibt es ein erstes Bild vom Schaltplan:
http://cpux.de/base/cam.png
Es fehlen zwar einen menge Beschriftungen, aber was solls. nachbauen kann man es eh noch nicht. (Außerdem fehlt noch die Stromversorgung und einige wichtige Steuerleitungen)

Ich glaube, dass ich nun entgültig auf die Timingchips verzichten kann. Die Vertikale Ansteuerung kann der µC problemlos selbst erledigen, wärend die Horizontale von dem GPIF erledigt werden kann. Dem GPIF muss nur die Richtige Wellenform der Signale einprogramiert werden und wie oft sie wiederhohlt werden muss. Dann wird zwar auch der Datenmüll (7 Pixel Latenz vom ADC + inaktive Pixel + Darkpixel insgesamt ca 5-10%) mit übertragen, aber dafür wird das ganze sehr Portabel und es könnten fast beliebige CCDs verwendet werden. Lediglich die Spannungen und Timings müssen dann angepasst werden...

Theoretisch wäre dann auch eine preiswerte (ohne CCD!!!!) Kamera auf KAF-16803 basis möglich. (Ich weiß nicht was in der Yahoogruppe vor sich geht). Das Filter/Shutterungetümrad macht dann aber bestimmt eindruck...

Mit dem EZ USB hab ich noch keine Erfahrung. ICh mein aber, dass ich das GPIF mehr oder weniger verstanden zu haben. Die 4 Wellenforman beziehen sich auf 4 mögliche Betriebsmodis: Einzelenes Lesen, Einzelnes Schreiben, Fifo Lesen, Fifo schreiben. Bei den letzten beiden gibt es irgend wo einen Counter der anscheinen 2³² Zyklen zählen kann, die dann automatisch ablaufen, sobald die Ausführung getriggert wurde.

Damit mir die entwicklungskosten nicht über den Kopf wachsen, werde ich erst mal den CCD Sensor ICX098BL verwenden. Die anderen Sony CCDs müssten alle abgesehen vom Gehäuse dazu kompatibel sein. Es gibt lediglich beim ICX274AL die einschränkung, das nicht alle modis funktionieren würden, da ich einige unötige Signale zusamenlege...

Eine Überlegung wäre noch ob es sinvoll wäre, die 16 Bit des AD Wandlers zu einem logaritmischen 8 Bitsignal zu Packen. Dazu wäre ein zusätzliches Eprom o.Ä. nötig...
Auch denkbar wäre ein wenig zusätzliche Hardware um zwei nachfolgende Pixel zu addieren. ICh finde aber, das beides zwar zur verigerung der USB Bandbreite führt aber sonst eigendlich eher schadet.

Die Arbeit kannte ich noch nicht. Sieht interressant aus auch wenn es ein IC Grab geworden ist.

Die Timings in ein externes SRam? ICh denke das bringt überhaupt nichts, weil dann würde ich ja das GPIF einfach noch mal nachbauen.
Und ob ich einen 12, 14 oder 16 bit ADC verwende spielt eigendlich auch keine Rolle, es ist nur so, das der LTC2203 keine Spamle & Hold Schaltung benötig und die Spannung automatisch bei fallender Flanke sampled. Die 16 bit garantieren lediglich, das kein zusätzliches Quantisierungsrauschen hinzukommt... (Preislich unterscheiden sich heute die 14 und 16 bit ADC kaum noch und alles was an Freatures nicht wesendlich kosted wird eingebaut...)

Ein externer Ram ist zwar schön aber hat halt die Nachteile, dass dann zwangsweise alles Komplizierter werden würde. Aber es reicht ja wenn eine Zeile durch die Triple oder Quadbuffer Fifo zwischengespeichert wird. Immerhin werden die Daten schneller abtransportiert als sie anfallen...

Noch etwas zu programierung des GPIF:
Der Hoizontale Transfer hat 4 Phasen:
1: CLK=1 ADCLK=0 RG=1 H1=0 H2=1 //Löschen
2: CLK=0 ADCLK=1 RG=0 H1=0 H2=1
3: CLK=1 ADCLK=1 RG=0 H1=1 H2=0
ADC sampled
4: CLK=0 ADCLK=0 RG=0 H1=1 H2=0

CLK ist die IFCLK des EZ USBs. Bei 48 MHz wird noch mit 12MHz gesampled (24MB/s). Die geschwindigkeit könnte verdoppelt werden wenn die ADCLK mit einem Xorgatter aus CLK + H2 und RG mit einem &gatter aus CLK+H2 generiert werden.
Das übernemen der Daten vom ADC geschied sinvoller weise bei Phase 2 oder 3, da die daten dann dort am längsten anliegen.
Für die Programierung üsste nur noch der Idlezustand festgelegt werden:
7: CLK=0 ADCLK=0 RG=0 H1=1 H2=0

Die Fifos und die USBengine des EZ USB sind so intelligent, das sie quasi den kompletten Transfer von Streamingdaten nach erfolgter Programierungs selbständig durchführen könnten.
Der Fifo besteht aus 1KByte Blöcken, die als Tripel oder Quadbuffer verwendet werden können (Tripel wenn man noch einen zusätzlichen Endpoint braucht) Die Statemaschine sucht sich selbst eine Freinen Block aus und transferiert mit den im GPIF abgelegtem Timings die Daten in die Fifoblöcke solange der Counter noch sagt das noch Daten übertragen werden müssen.
Es gibt nur eine Bremse: Wenn der USB die Datenmenge nicht schafft, wird der Transfer so lange unterbrochen bis ein 1K Block wieder frei ist.
Das ist aber nicht so sclimm, da bei 16bit Datentiefe bis zu 2048 Pixel einer Zeile in die 4 KByte passen. (Zudem werden die Daten ja auch abtrantportiert)
Grundsätzlich gilt bei diesem Design, das die Daten nicht durch den µC verarbeitet werden, sondern eher DMA ähnlich.

Zur Zeit bin ich mit dem Design des Analogteils beschäftigt. Vorallem benötige ich mindestens eine Spannung aus einem DAC zum einstellen des Schwarzlevels und eventuell eine Zweite um die Verstärkung des Vorverstärkers zu regeln (Mir ist jetzt nur noch keine gute Lösung dazu eingefallen) Warscheinlich werde ich einen LTC2600 mit einplanen. es ist zwar kein I2C aber eine serielle Schnittstelle muss ja eh schon für den IMT902 zweckentfremdet werden. (Dann kann auch der DAC damit rann)
Was mich etwas stöhrt ist, das der LTC2600 wie auch die anderen Linearchips nicht beim Elektronikhändler um die Ecke zu bekommen sind...

Die Versorgungspannung will ich möglichst vollständig aus der USB Spannung generieren. Lediglich Peltier und Schrittmotoren sollen extern versorgt werden. Da für das CCD nur sehr geringe Ströme auf den 15V und -8V Leitungen benötig werden ist die Ladunspumpe mit anschließenden Linearregler wahrscheinlich die beste Lösung.

Zu Clamp&Hold macht es eventuel sinn nur das Blacklevelsignal zu speichen und es auf den zweiten Eingang des des differentiellen Zwischenverstärkers zu legen. Eigendlich müssten dort aber noch 1,25V draufaddiert werden, damit der AD Wandler auch den vollen Bereich ausnutzt und der Bereich nicht erst bei 50% anfängt...
Alternativ wäre noch die rein digitale Methode auf die 16 bit vertrauen und beide Werte Samplen und mit einem CPLD die Subtraktion in Hardware durchführen. Teoretisch wäre dann auch noch das aufaddieren zweier nachfolgender Pixel möglich.

ICh hab noch ein paar interresante Schaltungen gefunden:
http://www.web-ee.com/primers/files/DesignSem7.pdf
Das Hauptproblem ist nicht etwa irgend was zu konstruieren, sonern Teile Zu finden, die man auch kaufen kann.

Also die Analogtechnik ist ein wahrer Alptraum. Das was man beim großem C bekommt ist Schrott aus den 80gern und alles was schnell ist, ist bereits in die AD Wandler intigriert (ist auch in meinem geplantem drin) Leider ist mit den intigrierten Sample&Hold kein DCS möglich.
Jetzt gibt es 3 Möglichkeiten:
1. Digitales Diffentielles Sampling (um mal was neues zu erfinden):
Ein XC9572XL von Xilinx wird zwischen den AD Wandler und den EZ USB geschaltet. Er übernimmt die Subtraktion von dem Schwarzlevel vom eigendlichen Sample. Das analoge Frontend besteht nur noch aus dem Vorverstärker einem Kondesator zu DC abtrennung und dem LT1994 und eine entgültige Anpassung an den AD Wandler.
Vorteil:
Preiswert (4,70 für den XC9572XL)
Der Analogteil bleibt sehr einfach und es ist kein Gebastel aus minderwertigen Bauteilen notig.
Die Schaltung bleibt relativ Flexibel. So wäre auch ein Schifting der Signale auf einen sinvollen 8bit Modus möglich. (Quasi Helligkeitsverdoppung)
Nachteil:
Ein Chip muss mehr programiert werden und die intigrierte Entwiklungsumgebung dafür ist grauenhaft.

2. Selbstgebaute Sample&Hold für den Scharzlevel:
Ich will gar nicht wissen was die bei 12MHz rumrauscht..

3. Irgend eine intigrierte schnelle Sample&Hold Schaltung finden

Treiber:
--------
Eine USB Klasse lässt sich leider nicht nutzen (universelle vorhandene Treiber fallen also weg)
Da ich nur noch unter Linux arbeite wäre die entwiklung für Windowstreiber für mich fast unmöglich. Den Linuxteil müsste ich aber hinbekommen.

Auf jeden Fall wird die Kammera Treibermäßig 2 Serielle schnittstellen simulieren, von denen eine echt ist und die Zweite wahrscheinlich eine andere Teleskopsteuerung emuliert (es macht kaum Sinn ein völlig neues Protokoll zu entwerfen). Prinzipell dürfte das ansteuern dann einfach mit KStars durch anklicken des entsprechnden Objektes möglich sein...
Beim CCD Teil wird es schon komplizierter: Die V4L architektur arbeitet wie der restliche Video nur mit 8 Bit. dort müsste also ein eigenes Device her, dass aber auch keine unmöglichkeit ist. Als letztes Stück fehlt dann noch ein grafisches Frontend welches die Bilder dann annimmt und speichert (Es macht dann auch noch Sinn die Metadaten des Teleskops in dem Rawbild zu Speichern, da die Steuerung davon unabhängig ist).

Zum Nachbau: Ohne SMD Ausrüstung geht gar nichts. Prototypen kann ich wohl noch bauen, aber nachbauen traue ich fast niemandem zu. Da wird es billiger sein die Platinen zu bestücken lassen.

Würde ich gerne machen aber es würde viel teuerer werden und ich kenne keinen passenden Mikrocontroller. Dazu kommt noch das beim Ethernet die Datenrate 5x geringer ist, so das ein Frame vollständig zwischengespeichert werden müsste. Zumindest würden die Mehrkosten, die Kosten für 5 aktive USB2.0 Repeaterkabel locker auffressen.
Ich bin allerdings noch auf der Suche nach USB Repeaterchips, da beim Wegfall der Stecker eventuel auch ein paar Meter mehr Kabel zwischen den chips funktionieren würde. Notfalls wären auch normale Hubchips möglich, blos die werden fast immer in 10000der Packs verkauft...

Fals sich hier noch jemand mit Analogtechnik auskennt, wäre hier drauf ein Blick sinvoll: http://www.linear.com/pc/downl…,C1009,C1022,P12074,D8737
Ich will nur sicher sein, dass der auch in der Lage wäre das vollständige CCD Signal bei 12MHz an den ADC anzupassen. (Der könnte fast auf den Flanken (bzw kurz davor)von H1 und H2 Samplen. In diesem Augemblick müssen sich die Signale eingependelt haben. Bei 2x12MHz wird alle 41,6ns gesampled. Wenn ich im Datenblatt das "Large Signal Step Response" Diagram anschaue müsste sich das Signal gerade eben eingependelt haben. Wenn ich die Slewrate umrechne komm ich auf 2,7V/41,6ns, was eigendlich ausreichen muss. Aber irgendwie hätte ich da doch lieber größere Reserven...

Der CXA1439 wäre so ein IC wie ich es bis etzt noch nicht finden konnte. Damit wäre es auf jeden Fall möglich einen konventionellen Analogteil aufzubauen. Bei diese Variante gibt es auch kein Problem mit dem LT1994 mehr, da dieser jetzt nicht mehr das Rohsignal verstärken muss (CXA1439 Datenblatt Seite4 erste Wellenform) sondern nur noch das Ausgangssignal der einzelnen Pixel. (4. Wellenform auf der Seite)
Das in der Analogtechnik nicht Fit bin meine ich nicht ganz, aber ich weiß genau, das gerade dort die meisten Fallen gibt...

Warum die 12MHz? Teilen kann man die Frequenz immer noch, aber wenn sie möglich sind, kann die Kammera halt auch für Planeten und Mond eingesetzt werden. Außerdem müsste es mit den heute erhältlichen Bauteilen einfach möglich sein... und wenn ich irgend wann mal auf die Idee kommen solte ein viel größeres CCD einzusezten, wäre die Übertragunstechnik für die größere Datenmenge schon da...

Prinzipell bin ich jetzt immer noch am Überlegen ob ich das CPLD zwischen ADC und EZ USB lasse. Er könnte ein paar Aufgaben übernehmen: Preteiler für den CCD Takt (12;6;3;1,5...MHz) Er könnte die schnelleren Timingsignale liefern und mit Unterstützung des EZUSB auch Dummyauslesesignale generieren, um unötige Pixel+Pipelinelatenz auszugleichen. Notfalls lassen sich damit auch noch Pixel in Hardware addieren oder die Daten auf 8bit logaritmisieren