Beiträge von Martin_R im Thema „CCD - Camera Eigenbau“

Martin_R · 17. Oktober 2010

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

Martin_R · 17. Oktober 2010

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

Martin_R · 4. April 2010

Hallo Frank,

da nach so einem teuren Teil, das sich ja noch aktuell in Produktion befindet, wahrscheinlich eine gewisse Nachfrage von Kamera-Herstellern besteht, glaube ich eher nicht dass man da ein Schnäppchen machen kann. Dem müssten seine Chips aus den Händen gerissen werden, wenn er sie wesentlich unter dem Kodak-Preis verkauft.

Die Broker machen ihren Gewinn ja eher bei Restbeständen von ausgelaufenen Teilen, wenn die Anwender aufschrecken weil sie auf normalem Weg über Hersteller/Distris keine Teile mehr bekommen, und ein Redesign oder gar Fertigungsstillstand droht.

Oder bei Versorgungsengpässen noch aktiver Teile, wie aktuell wieder regelmäßig zu beobachten.

In beiden Fällen langt der Broker ordentlich hin.

Aber du kannst ja mal das Pokerspiel eröffnen... [;)]

cs
Martin

Martin_R · 2. April 2010

Hallo Frank,

merkwürdiges Geschäftsgebaren. Sitzt der im Orient?

Außerdem finde ich etwas sonderbar, dass dein Broker Grade 1 anbietet, während das Kodak Datenblatt nur Grade 2 kennt.

Wie lautet denn die genaue Bezeichnung seiner Chips?

cs
Martin

Martin_R · 2. April 2010

Hallo Frank,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
besteht denn noch Interesse an KAF6303? wieviel und welcher Preis für Grade1!
Ein Anbieter hat mich angeschrieben und wüsste gerne Menge und Preisvorstellung.<hr height="1" noshade id="quote"></blockquote id="quote">

Wie ist das jetzt zu verstehen?

Dir will jemand den 6303 verkaufen, und will wissen was du dafür zu zahlen bereit bist?

cs
Martin

Martin_R · 2. April 2010

Hallo Marcus,

die E500 hat doch auch nur den KAF-8300 als Farbversion.

Da ist der ICX453 aus der Nikon D70/50/40 ohne Zweifel besser geeignet.

Interessant wäre es ein kommerzielles Produkt auszumachen, wo ein großer Monochrom-Chip verbaut ist, und das man auf dem Gebrauchtmarkt günstig bekommt. Das düfte aber schwierig werden. Wofür braucht schon große Monochrom-Chips? Da bleiben eigentlich nur Hi-Tech Anwendungen.

cs
Martin

Martin_R · 31. März 2010

Hallo Marcus,

da muss ich leider einen Dämpfer reinhauen... [:0]

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Ist es geplant die Kamera nacher in Serie (Kleinserie) zu fertigen?
<hr height="1" noshade id="quote"></blockquote id="quote">

Von mir nicht. Ich denke es wird eher ein Nachbauprojekt für Leute die absolut fit in Elektronik sind, und gerne mal eine brauchbare Kamera bauen wollen.

Vom ursprünglichen Gedanken, einen Super Chip für kleines Geld in eine Selbstbau-Elektronik reinzubasteln, hat sich die Diskussion ja (richtigerweise) angesichts der Chip-Preise wegbewegt.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Da ich mir für die kommende Wintersaison ne CCD zulegen möchte, wäre ich evtl. interressiert.
<hr height="1" noshade id="quote"></blockquote id="quote">

Das wird zeitlich nicht hinhauen. Meine letzte Kamera hat nach 12 Monaten das erste Bild geliefert, und ist jetzt nach 18 Monaten halbwegs praxistauglich.

Ich möchte auch zur Sicherheit nochmal darauf hinweisen, dass die von mir oben skizzierte Kamera nicht das Ziel haben kann, in die dichte Formation der kommerziellen Anbieter einzudringen. Und auch nicht, ein easy-going Nachbauprojekt zu werden (dafür ist die Technologie zu komplex, wenn das Ergebnis vorzeigbar sein soll).

Es geht mehr um den Spaß an der Sache für einen bestimmten Personenkreis, und vielleicht darum ein spezielles Feature einzubauen (z.B. den Stand-Alone Betrieb).
Für wenig mehr als der zu erwartende Teilepreis gibt es schließlich fertige Kameras mit gleichem Chip zu kaufen (--> QHY8).

cs
Martin

Martin_R · 28. März 2010

Hallo,

an ein paar Stellen hat sich das Design mittlerweile verändert:

- für den Analogen Bereich (Videoverstärker, Correlated-double sampling, Biaspunkt-Einstellung, AD-Wandler) kommt ein fertiger Chip rein, ein sogenanntes "Analog Front End". D.h. die doppelte Signalkette (für schnelle 8 bit und langsame 16 bit) entfällt, das Frontend macht gleich 16 bit mit 8 MPix/s oder mehr.

- Der Microcontroller wird wohl entfallen, und dafür ein Soft-Core in's FPGA implementiert.

Wahrscheinlich werde ich als "Technologiemission" ein Redesign meines Stand-Alone Guiders noch vor der Kamera durchziehen. Dieses um die grundlegenden Themen rund um die FPGA/Softcore-Funktionalität und die Frontend-Funktion abzusichern, bei wesentlich reduzierten Leistungsanforderungen.

cs
Martin

Martin_R · 25. Februar 2010

Hallo allerseits,

inzwischen habe ich es geschafft meine Ideen zur 453er Kamera weiter zu konkretisieren.

Hier mal ein Schnappschuss zum aktuellen Stand der Dinge.

Die eigentliche Kamera wäre in einem Gehäuse von ca. 103x103mm Querschnitt unterzubringen. Dazu passend wäre rückseitig ein 100x100mm Kühlkörper, darauf ein 80mm Lüfter. Für diesen KK mit Lüfter habe ich einen Wärmewiderstand von ca. 0,45 K/W gemessen.

Im Gehäuse befinden sich 2 Platinen: eine für den CCD-Chip, die Takttreiber, und den analogen Schaltungsteil bis zum AD-Wandler, und eine Hauptplatine mit dem digitalen Teil, und den Schaltreglern für die Versorgungsspannungen und Peltier-Versorgung.

Der CCD-Chip wird zusammen mit dem Nikon-Träger eingebaut. Der Träger hat 3 Befestigungspunkte, die anscheinend auf der Vorderseite individuell überfräst worden sind, damit der CCD genau senkrecht in der DSLR saß. Bei meinem Chip unterscheiden sich die Materialstärken der 3 Punkte um 0,12mm.

Die Kühlkammer besteht nach bisherigem Stand aus 2 Halbschalen, zwischen denen die Platine sitzt. An einer Seite geht die Platine dabei durch die Kühlkammer-Wand, an den anderen 3 Seiten liegen die beiden Halbschalen direkt aufeinander.
Frontseitig ist eine runde Vertiefung zur Aufnahme eines Glasfensters, z.B. ein Baader "Clear"-Filter in 2" Ausführung (ohne die originale Filterfassung. Das Fenster wird zwischen 2 O-Ringen geklemmt.

Die Kühlkammer leiter die rückseitige Wärme auch nach vorne zum Fenster, um Taubefall zu verhindern.

Der CCD-Träger wird mit 3 Kunststoffschrauben und Kunststoff-Distanzhülsen von innen an die vordere Halbschale geschraubt. Auf der Rückseite sitzen Kühlfinger und Peltier-Element.

Die Wärmeableitung nach hinten zum Kühlkörper erfolgt über ein Stück 28mm Rund-Alu. Dieses geht durch ein Loch in der Hauptplatine hindurch.

Das Gehäuse besteht aus rechteckförmigen 1,5mm Alublechen, und in den Ecken je 1 Stück sogenanntes "Gehäuseprofil". Dadurch kann man die Abmessungen genau den Anforderungen anpassen, und für die Herstellung braucht man nur eine Metallsäge und Feile.

Die elektrischen Schnittstellen sehen zur Zeit wie folgt aus:
- NV-Buchse zur Einspeisung der 12V
- Mini-USB Buchse zum Windows-Rechner, wenn PC-Betrieb gemacht wird
- eine RJ45-Buchse, falls die Kommunikation mit der Stand-Alone Kontrollbox nicht ebenfalls über USB erfolgt. Darüber bin ich mir noch nicht im klaren. Vielleicht ist es einfacher, eine synchrone LVDS-Übertragung (ähnlich SPI) aufzuziehen. Würde wahrscheinlich eine Menge Software-Aufwand in der Kontrollbox sparen (und zwar die komplette Host-USB Funktionalität).
- eine Klinkenbuchse, um ein Handshake-Signal mit dem (=meinem) Autoguider aufzubauen, für automatisches Dithern zwischen den Aufnahmen
- dazu noch 1 Schalter und 2 LEDs

Für das elektronische Innenleben ist folgendes geplant:

- 1 FPGA für die Erzeugung der Auslesesignale, und Datenübergabe zum USB Controller bzw. zur Kontrollbox. TQFP100 Gehäuse.
- 1 Microcontroller (Atmega 2561) für die Grundabläufe, die Peltier-Regelung, Konfiguration des USB-Controllers etc. TQFP64 Gehäuse
- 1 USB 2.0 Peripheral Controller (mit Isochronem Modus), wahrscheinlich ein Cypress CY7C68001.
- 1 8bit AD-Wandler (LTC1406?) für 10MPix/s, entsprechend einer Bildauslesezeit von ca. 0,7s
- 1 16bit AD-Wandler (AD7653?) für 1MPix/s, entsprechend einer Bildauslesezeit von ca. 7s
- für das schnelle 8bit-Auslesen plane ich einen CXA1439 als CDS-Chip, für das langsame Auslesen wahrscheinlich die Schaltung von meiner '285er Kamera. Dem 1439 traue ich noch nicht über den Weg bezüglich DC-Drift und Rauschen (keine Angaben im Datenblatt).
- ... sowie jede Menge Kleinzeug, wo die Detaillierung noch aussteht.

Für die Kontrollbox habe ich noch keine Konkretisierung gemacht.

Hier noch die "Designstudie" und ein Blick in meine Bauraumbetrachtung
zum Innenleben:

Ebenso in Planung ist ein passendes Filterrad für 4 Filter / 2" für Schmalbandaufnahmen. Für den Antrieb könnte ein kleiner DC-Getriebemotor von Conrad geeignet sein, hinzu müssen noch 2 Positionssensoren. Die Ansteuerung erfolgt von der Hauptplatine aus.

cs
Martin

Martin_R · 7. Februar 2010

Hallo Wolfi,

gute Idee, mach das doch mal!

Hast du die Preise bei Kodak eigentlich einfach als NoName per Mail angefragt, oder über einen speziellen Kontakt?

Mich würde mal interessieren was der KAF-8300 eigentlich kostet, und der KAI-4022 scheint mir auch interessant.

Der 6303 hat dummerweise kein ABG. Wobei SBIG eine ABG-Option anbietet, bei Kodak ist dazu aber nichts zu finden...

Interessant finde ich auch, dass bei einigen Chips QE-Kurven angegeben sind, aus denen ersichtlich ist dass bei H-Alpha die absolute QE eines Bayer-Chips genauso groß sein kann wie beim Monochrom-Pendant (beim KAI-4022 zu Beispiel mit je 30%, beim 8300 jedoch nicht mit 27% zu 48%).

Der weiter oben aufgeführte 10500 zu 730$ hat übrigens nur 10% QE bei 656nm.

Schade dass Sony die QE nicht absolut angibt. Wenn die von den Kameraherstellern spezifizierte maximale QE für den '453 mit 60% bei grün zutrifft, bleiben bei 656nm noch ca. 45%.

cs
Martin

Martin_R · 5. Februar 2010

Hi Wolfi,

der '453 wäre ziemlich ideal, wenn es ihn als Monochrom gäbe. Die Frage ist halt, ob die Bayer-spezifischen Nachteile so schwer wiegen, dass man sich einem der größeren und teureren Kodak zuwenden müsste.

Als Hauptnachteile des '453 fallen mit ein:
- geringere Empfindlichkeit wegen der Bayer-Matrix
- problematische Sternabbildung bei kurzen Brennweiten (wenn nur 1 Pixel beleuchtet, d.h. falsche Farb- und Helligkeitsinformation wegen der Bayermatrix)

Die Vorteile sind:
- relativ große Fläche (15,7 * 23,6mm, 28,1mm diagonal)
- Preis maximal 200€, eher weniger, zukünftig wahrscheinlich fallend, kein Beschaffungsproblem, langfristig verfügbar
- kein Shutter erforderlich
- keine Kosten für RGB-Filter, kein Filterrad für Farbaufnahmen erforderlich
- moderate Kühlung ist ausreichend (Stromverbrauch!)
- möglicherweise geringere Anforderungen an die Signalqualität der Taksignale als bei Kodak

je nach Brennweite pos/negativ:
- Pixelraster 7,8um

Schade dass die Versuche des Dr. QHY erfolglos waren, die Bayer-Filter mittels UV-Licht zu bleichen...

Welche Monochrom-Kodak kämen denn alternativ in Frage?

KAF-8300: ist recht klein, kleine Pixel, mäßige FWC
KAF-6303: 33mm groß, aber keine Microlinsen
KAI-4022: braucht keinen Shutter, aber mit 15x15mm auch recht klein
weitere?

cs
Martin

Martin_R · 5. Februar 2010

Hi Wolfi,

welchen großen?

Martin_R · 5. Februar 2010

Hi zusammen,

ihr seid so still...

Welchen CCD-Chip würdet ihr denn für ein SB-Projekt favorisieren?

Sehe ich das eigentlich richtig, dass der KAF-8300 "nur" deshalb gerade so boomt, weil es der einzige bezahlbare Monochrom-Chip mittlerer Größe ist (ansonsten aber nicht sonderlich attraktiv ist)?

cs
Martin

Martin_R · 25. Januar 2010

Hi Robert,

sei gegrüßt in unserer Bastelstube!

Deine Ausführungen und Bedenken sind -natürlich- im Prinzip zutreffend, trotzdem würde ich das Ganze nicht a priori so pessimistisch sehen. [;)]

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote"> Mit einfacher Mikrocontrolleransteuerung zum Sensortiming ist da nicht viel.
<hr height="1" noshade id="quote"></blockquote id="quote">

Zumindest bis 1,4MPix geht das erfahrungsgemäß, sofern man entsprechend optimiert, ohne unüberwindliche Probleme. Darüber hinaus wohl nur mit Qualitäts- oder erheblichen Leistungseinbußen.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Die einzelnen Ansteuersignale müssen penibel aufeinander abgestimmt werden, ein FPGA (VHDL-Programmierung) dürfte da unumgänglich sein.
<hr height="1" noshade id="quote"></blockquote id="quote">

Das sehe ich auch so bei Multi-Megapixel-Chips.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Ebenso kommt es auf eine sehr saubere Takterzeugung und -weiterführung an.
<hr height="1" noshade id="quote"></blockquote id="quote">

Ich weiß nicht wie sich die Kodak-Chips verhalten. Bei den Sonys hatte ich hier bisher noch keine Probleme. Will sagen: das was man als "gestandener Elektroniker" automatisch macht wenn man mit solchen Signalen zu tun hat, war bisher offenbar ausreichend [;)]

Allerdings dürfte das bei den größeren Chips kritischer werden, da diese z.B. das "gleiche" Taktsignal an verschiedenen Pins brauchen, mit unterschiedlichen Flanken-Anforderungen. (Ich meine z.B. die H-Takte der letzten Stufe vor dem Ladungsverstärker)

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Das Platinenlayout ist sehr kritisch und benötigt viel Erfahrung mit Störsignalen, insbesondere digitale Störungen vom Interface usw.
<hr height="1" noshade id="quote"></blockquote id="quote">

Da hatte ich bei meinem letzten Projekt durchaus Sorge, dass der Schaltregler für das Peltier-Element oder die Leitungsführung zum Peltier in den Analogteil reinhaut. Meine "Vorsichtsmaßnahmen" waren aber ausreichend, so dass es hier kein Problem gab. Nur wenn ich das Kabel zum Peltier dicht über den Analogteil halte, sieht man Streifen im kontrastverstärkten Bias-Bild. Ansonsten ist es völlig gleichmäßig verrauscht mit irgendwo 8-15 e- RMS.

Natürlich gebe ich dir Recht dass Plazierung und Entflechtung bei so einer Kiste durchaus eine Herausforderung sind.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Ganz wichtig ist die Spannungsversorgung und -stabilität, gerade unter Lastschwankungen.
<hr height="1" noshade id="quote"></blockquote id="quote">

Wieder Sony: ich hatte nur mal Ärger mit einer einbrechenden negativen Versorgung, wenn viele schnelle Horizontalsyncs kommen. Ansonsten gilt auch hier: die üblichen Vorsichtsmaßnahmen haben offenbar ausgereicht.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Spezielle Blockkondensatoren (Stichwort ESR) an den einzelnen Bausteinen sind obligatorisch, ebenso SMD-Bauweise zur Minimierung parasitärer Bauteileigenschaften.
<hr height="1" noshade id="quote"></blockquote id="quote">

Logo, damit rennst du eine offene Tür bei mir ein. THT-Antennen kommen mir nicht mehr in's Haus, siehe weiter oben [;)]

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Einen Mikrocontroller wird man sicherlich brauchen, um die ganzen Parameter einzustellen und die Hardware zu konfigurieren.
<hr height="1" noshade id="quote"></blockquote id="quote">

Mein aktuelles Konzept sieht ein FPGA vor um das Auslese-Timing und den Rest der digitalen Geschichte bis zum USB-Controller zu machen, und einen kleinen 8-Bitter für die Konfiguration, Grundabläufe, Temperaturregler und die Filterraddreherei.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Bei so einem gemeinsamen Projekt wäre es auch wichtig, saubere Updatemöglichkeiten zu realisieren, so dass die Hardware (wenn sie einmal bei den Leuten ist) aktualisiert werden kann.
<hr height="1" noshade id="quote"></blockquote id="quote">

Da die Leute die HW ja selbst aufbauen, muss die erstmalige Programmiererei bzw. Updates natürlich irgendwie gelöst werden. Aber wer sowas löten kann, der kann sich auch Programmieradapter löten und die zugehörige SW bedienen.
Für Microcontroller und FPGAs ist das ja auf einfache Weise und kostenfrei z.B. über den Druckerport möglich. Mache ich seit Jahren so für Atmel-Controller und Lattice-FPGAs.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Alles in allem ist es ein erheblicher Aufwand, der sehr viel Erfahrung in den einzelnen Bereichen voraussetzt. Es ist eigentlich ein Job für Profis, darüber hinaus ist es ein Full-Time-Job.
<hr height="1" noshade id="quote"></blockquote id="quote">

Ja.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Falls man computerseitig etwas programmiert, würde ich etwas Plattformübergreifendes empfehlen (z.B. Qt), das für die Anwendung kostenlos wäre und sich auf Windows und Linux compilieren ließe.
<hr height="1" noshade id="quote"></blockquote id="quote">

Zum Glück habe ich von diesem Gedöns zu wenig Ahnung, und überlasse es deshalb Freiwilligen sich sowas anzutun!

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Ich wollte Euch jetzt nicht gänzlich demotivieren, sondern nur etwas zum Überdenken bringen,
<hr height="1" noshade id="quote"></blockquote id="quote">

Keine Sorge! In der Sache sehen wir das alles glaube ich recht ähnlich, die Frage ist halt ob sich die Herausforderungen mit vertretbarem Aufwand stemmen lassen.

Jedenfalls bin ich keineswegs demotiviert.... Wie war das bei Deep Thought? Meine Schaltkreise sind jetzt unwiederruflich mit der Lösung dieser Aufgabe beschäftigt... [8D]

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
denn Ihr habt nebenher sicherlich auch noch andere Sachen zu tun... [:p]
<hr height="1" noshade id="quote"></blockquote id="quote">

DAS ist das eigentliche Problem!! [xx(]

cs
Martin

Martin_R · 24. Januar 2010

Hallo Frank,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: FrankH
 der preis und 16 bit ist schon nicht schlecht, aber Bayermaske mag ich nicht haben.
Der Chip wird in Europa auch nicht gehandelt, habe auch kein PDF dazu gefunden
<hr height="1" noshade id="quote"></blockquote id="quote">

Es gibt dazu auch kein PDF im Netz. Tippe auf NDA mit Nikon. Nur vom 413er, der Vorgängerversion mit Interlace.

Natürlich ist Bayer nich ideal, kostet Faktor 3 an Empfindlichkeit.

Aber ich kenne keinen leicht verfügbaren, erschwinglichen, monochromen Chip in dieser Größe. Der elektronische Shutter ist auch praktisch. Hinzu kommt dass die Sonys offenbar mit weniger Kühlung auskommen als die Kodak.

Welchen Chip würdest du nehmen?

cs
Martin

Martin_R · 24. Januar 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Gamma Ray
 Hallo Wolfgang!
Darf ich Dir vorher eine geeignete Lötzinnempfehlung geben? [:D]
Gruß
Gerhard
<hr height="1" noshade id="quote"></blockquote id="quote">

Blei muss drin sein, viel Blei... [:D]

cs
Martin

Martin_R · 24. Januar 2010

Hi Wolfi,

du meinst ich sollte das Design mal weiter konkretisieren?

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Birki
 was ich hingegen kann, ist bildverarbeitungssoftware schreiben, das ist mein job...
<hr height="1" noshade id="quote"></blockquote id="quote">

Dann könntest du doch eigentlich den Windows-Part übernehmen... oder würdest du eher die Stand-Alone Lösung für deine Zwecke verwenden wollen?

Hallo Gerhard, meinst du die Kostenschätzung wird nicht einzuhalten sein, oder für den Preis lohnt sich kein Selbstbau?

cs
Martin

Martin_R · 24. Januar 2010

Liebe Photonensammler,

gebt mir doch mal ein Feedback ob folgendes Projekt für euch interessant wäre:

CCD-Kamerasystem, bestehend aus
A. Kamerakopf
B. Bedienbox

Betriebsmodi:

a. Stand-Alone: A + B über USB 2.0 verbunden. Die Bedienbox zeigt die Bilder auf einem kleinen Display an, und speichert auf CF-Karte. Die Bedienbox sähe ungefähr so aus wie die Displayeinheit bei meiner 285er Kamera, etwas größer wahrscheinlich.

b. PC/Laptop-Betrieb: der Kamerakopf wird über USB 2.0 angeschlossen. Eine spezielle Windows-Software zieht die Bilder von der Kamera ein, zeigt sie an und speichert auf Festplatte.

Details:

A. Im Kamerakopf werkelt ein ICX453 (28mm Diagonale, 6 MPix, 7,8µm Pixelraster, Bayer-Array). Der ist ja inzwischen astronomisch bewährt, aber vor allem günstig (<200€) und langfristig(!) über gebrauchte Nikon-DSLRs in der Bucht beschaffbar.
Wird natürlich geregelt Peltier-gekühlt.

Ansonsten hat der Kamerakopf die nötige HW um Bildaufnahme und CCD-Auslesen durchzuführen, und die Daten auf den USB 2.0 Bus zu bringen.

Das Auslesen erfolgt über 2 Modi:
- schnell mit 8 oder 10 Bit, und ca. 10 Megapixel/s, d.h. ca. 1,4 Vollbilder werden pro Sekunde ausgelesen und an den Host übertragen
- langsam mit 16 bit und ca. 1-2 Megapixel/s. Übertragungszeit also ca. 4-7s für das Vollbild

Der Kamerakopf kann keine Bilder zwischenspeichern, es gibt nur einen kleinen Datenpuffer für den USB Verkehr. Die USB Übertragung erfolgt im Isochronen Modus mit garantierter Übertragungsrate/Latenzzeit.

Zusätzlich kann ein Filterrad für 4 2" Schmalbandfilter integriert werden (kleiner Gleichstrommotor + 2 Sensoren).

B. Die Kontrollbox beinhaltet alles um die Kamerafunktion zu steuern (Belichtungszeit, Reihenaufnahmen etc), die Bilder anzuzeigen (OLED Display), und zu speichern (Compact-Flash Karte). Sie enthält einen USB Host Controller, so dass mit der Kamera (die ein USB "Device" darstellt), kommuniziert werden kann. Versorgt wird die Kontrollbox per USB von der Kamera (da diese wegen dem großen Strom für den TEC der Einspeisepunkt für die Versorgung sein muss)

Wer nur mit PC/Laptop arbeiten will, braucht keine Kontrollbox.

Alternativ könnte sicher jemand, der sich damit auskennt, auch andere Gerätchen als Controller einsetzbar machen (PDAs?)

Technologie:

Beide Geräte werden Platinen enthalten, die kommerziell hergestellt werden müssen. Es kommen fast nur SMD Bauteile zum Einsatz, maximal TQFP 100 mit 0.5mm Pinabstand bzw. in der Kontrollbox TQFP144.

Die Kosten für die Elektronikbauteile wären grob geschätzt:

für A: ca. 240€ inkl. Platine, mit Peltier, ohne CCD, ohne Mechanik, ohne Kühlkörper, ohne Lüfter
für B: ca. 220€ inkl. Platine, ohne Gehäuse

Wäre sowas interessant als Bau/Nachbauprojekt, oder liegt es zu dicht an existierenden kommerziellen Kameras?

cs
Martin

Martin_R · 9. Januar 2010

Hallo Frank,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">[i]Das mit dem Ausleserausch steht beim Hersteller durchaus für die Geschwindigkeit genau andersrum,
das hängt aber auch davon ab welches Rauschen man betrachtet, bei einer Verstärkerstufe gibt es da ja einige Quellen, Streuung bei der Der Abtastimpulsfolge erscheinen widerrum auch als Rauschen. man wird sich wohl in der Mitte treffen müssen?
<hr height="1" noshade id="quote"></blockquote id="quote">

Bei welchem Hersteller? Kodak?

Das Verhalten der Sony-Chips ( zumindest 098, 405 und 285) ist eindeutig, und zwar so wie ich es beschrieben habe. Dann macht übrigens auch die Angabe der fps beim Rauschen im Datenblatt Sinn.

Die Ursache dieses Rauschens kommt vom Leckstrom der Schiebepixel, und betrifft somit vermutlich alle Interline-Chips.

Dafür braucht man bei den FullFrame einen mechanischen Shutter, auch nicht gerade erfreulich.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Ob es nun vom AD zum Ram parallel oder seriell geht ist doch egal der AD wird die Schnittstelle die für seine angegebene Geschwindigkeit nötig ist mitliefern.
<hr height="1" noshade id="quote"></blockquote id="quote">

Der ADC hat damit natürlich kein Problem. Die Daten müssen für's RAM halt wieder parallelisiert werden.

cs
Martin

Martin_R · 8. Januar 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: FrankH
 Prinzipell verlassen die Daten den CCD ja seriell, würde nicht bringen das an anderer Stelle zu ändern?
<hr height="1" noshade id="quote"></blockquote id="quote">

Ich meine die Schnittstelle vom ADC zum Bus (RAM). Bei hohen Datendurchsätzen (die erforderlich werden wenn wir von Multi-Megapixel reden) ist parallel sinnvoller (8 oder 16 bit). Bei 1 Megapixel oder so geht auch seriell ohne Probleme (wobei dieses dann nicht direkt ins RAM kann, aber z.B. über ein Kabel zu einem Bediengerät übertragen werden).

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
was vielleicht wichtiger wäre ist zu prüfen ob es in der CCD Familie? nicht Signalkompatible unterschiedlich große typen gibt, das würde in der Entwicklungsphase der Hardware kosten senken, ob man ein Layout schafft das verschieden große CCD zulässt weis ich nicht wäre aber einem Selbstbauprojekt förderlich wenn es bloß eines Softwareupdates bedarf.
<hr height="1" noshade id="quote"></blockquote id="quote">

Bei den mittleren + größeren von Sony ist das zumindest schwierig, da sind sogar die Versorgungsspannungen und die Taktpegel verschieden. Die Kodak kenne ich nicht.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
ob das Auslesen 1s oder 10s dauert ist bei Langzeitbelichtung eher nebensächlich, Vielleicht ist es Möglich für Focus auch hochzutakten und Subframes zu verwenden, muß nicht sein, wäre aber lecker
<hr height="1" noshade id="quote"></blockquote id="quote">

wieder bei Sony: es ist keineswegs nebensächlich, wie oben ausgeführt! 10x so langsam auslesen heißt 10x so starkes Ausleserauschen!
Kodak: keine Ahnung.

Das mit den Focus-Subframes mache ich bei meiner 285er Kamera. Aber da man CCD Chips immer zu 100% auslesen MUSS, auch wenn man nur einen einzigen Pixel will, bringt es nicht so wahnsinnig viel. Meine Kamera braucht zum Auslesen eines vollen Bildes (1392*1040) ca. 1,6s, für ein 640*480 Subframe ca. 1s.

cs
Martin

Martin_R · 8. Januar 2010

Hallo Frank,

ich würde erst dann einen ADC auswählen, wenn klar ist mit welcher Geschwindigkeit die Pixel ausgelesen werden sollen, und wie die digitale Schnittstelle aussehen sollte (seriell / parallel).

Ich denke man sollte sich erst mal über die Größenordnung der Pixel-Anzahl klar werden, da hiervon Einiges abhängt (spez. Geschwindigkeiten und Speicherbedarf). Eher 1 MPix oder eher 10 MPix?

Abhängig davon kann man sich dann überlegen ob ein uC für das Timing hinkommt, oder ob es in Richtung FPGA geht, oder auch ob ein fertiger Timing Chip passt.

cs
Martin

Martin_R · 8. Januar 2010

Hallo Daniel,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: daniel
 Ich mag SMDs fürs Prototyping und die Schaltungsentwicklung überhaupt nicht. Später wenn das Design klar ist, kann man dann auf SMD umsteigen.
<hr height="1" noshade id="quote"></blockquote id="quote">

Das macht eigentlich keinen Sinn, da man halt die guten Bauteile in THT überhaupt nicht bekommt. Und da auch der konkrete Aufbau (Leiterplatten-Design, Abstände etc.) bei so einem Mixed-Signal Thema immer mitspielt, könnte man den THT Aufbau noch nichtmal 1:1 in SMD umsetzen.

Warum die Abneigung gegen SMD? Man braucht nur einen stinknormalen Lötkolben. Damit kann man ohne weiteres bis TQFP144 mit 0.5mm Pinabstand löten. Hab ich schon etliche Male gemacht. Die LP muss man natürlich fertigen lassen, aber dafür hat man eine Menge Vorteile (beliebige Anzahl Vias und viel höhere Packungsdichte).

Ich bin auch für's Hobby vor ca. 10 Jahren weitgehend auf SMD umgestiegen, und habe es nicht bereut.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Das man die Takterzeugung nicht über einen MC realisieren kann, bzw. das schwierig wird, würde ich so nicht unterstreichen. Da wir hier kein HD Videokamera entwickeln wollen, sondern man das ganze auch etwas "ruhiger" angehen kann, sollte hier ein Mikrocontroller ausreichen. ggf. könnte man ein Mehrprozessor System realisieren. Und wenns wirklich zeitkritisch wird, kann man da auch auf Assembler zurückgreifen und das Maximum an Geschwindigkeit rauskitzel.
<hr height="1" noshade id="quote"></blockquote id="quote">

Das kommt jetzt darauf an über welche Pixel-Größenordnung wir reden. Den 1,4 MPix '285 lese ich ja auch per SW aus, aber das geht nur nach knallharter manueller Optimierung, und natürlich in Assembler. Alle 66ns haue ich dabei einen neuen Portzustand raus. Ich würde es gerne noch schneller machen.

Zumindest die Sony Chips sind sehr(!) zeitkritisch beim Auslesen. Das muss wirklich Ratzfatz und vor allem gleichmäßig gehen, da die Schiebepixel so stark rauschen. Ein kleine Verzögerung bei einem Pixel lässt diesen im Bias-Bild erkennbar heller werden, da sich mehr Ladungen durch Leckstrom aufbauen. Und der gesamte Bias-Level und somit das Rauschen steigt, je langsamer das Auslesen erfolgt. Das Bild wird nach unten hin immer heller. Kühlung verbessert das natürlich (und ist auch deshalb unverzichtbar).

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Wenn man sofort auf SD Karte schreibt kann man sich auch ein großes RAM sparen. Alternativ könnte man auch ein DMA über das Hardware-Design realisieren, also die Daten vom A/D Wandler direkt in den RAM schreiben ohne den Umweg über einen Prozessor und erst dann langsam auf SD Karte auslagern.
<hr height="1" noshade id="quote"></blockquote id="quote">

Direkt auf die SD kann man vergessen, da nicht kontinuierlich möglich, sondern nur Sektorweise und wegen dem FAT-System clusterorientiert. Das machen noch nicht mal die DSLRs so, die haben auch ein SD-RAM an Bord.

Den direkten Schreibvorgang vom ADC ins RAM und dann später vom RAM auf die KArte mache ich bei meiner Kamera auch über sowas ähnliches wie DMA, das funktioniert durchaus.

Bei Multi-Megapixel CCDs ergibt sich dann nur das Problem, dass das RAM nur in SD-Technik praktikabel ist. D.h. der verwendete uC muss SD-RAM unterstützen, und DMA Zugriffe von/nach externer Peripherie machen können.

cs
Martin

Martin_R · 8. Januar 2010

Hallo Frank,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: FrankH
 so unbedingt af SMD zu setzen ist meist gar nicht gut, bei konventionellen Bautelen braucht man beuí geschickter Anordmung für Doppellayer nicht mal durchkontaktieren und hat was die Leiterbahnführung angeht sehr viel mehr Freiheitsgrade, bei SMD besteht meist alles nur aus vielen elend langen Leiterzügen, ein stehender Wiederstand nimmt kaum mehr Platz ein als SMD aber liegend kann man locker 20 Leiterzüge durchquetschen, das hat gar keinen Sinn solange mann die Schastlung nicht auf Papier hat, wenn man da mit Tastköpfen ran will sollte man Stifte einlöten um fest anstecken zu können<hr height="1" noshade id="quote"></blockquote id="quote">

An THT-Bauteilen gibt es aber nur noch alten Schrott. Zeig mir mal einen CCD-Vertikaltreiber, ein brauchbares RAM, einen schnellen uC, einen USB Controller, einen modernen OP, ein FPGA etc. in Drahtausführung.

THT ist tot.

Wenn SMD Baugruppen aus "elend langen Leiterzügen" bestehen hat der Entflechter rumgemurkst, oder blind den Autorouter benutzt. Bei SMD-Baugruppen sind die Leiterbahnlängen eindeutig kürzer als bei THT. Das fängt schon beim Weg zwischen Silizium und Lötstelle an.

Messpins kann man vorsehen wenn man
- vorher weiss welche Signale man später für die Fehlersuche sehen will
- man genug Platz für Messpins hat
- die Messpins die Signalintegrität nicht stören.

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">der LTC 2203 PBF mit 25Mhz wäre wenn man ihn mit 5Mhz betreibt mehr wie ausreichend<hr height="1" noshade id="quote"></blockquote id="quote">

QFN48 package, Power-Pad unter dem Gehäuse...

" The LTC2203/LTC2202 require a printed circuit board with a
clean unbroken ground plane; a multilayer board with an
internal ground plane is recommended. "

[;)]

cs
Martin

Martin_R · 8. Januar 2010

Hallo zusammen,

bin eben auf eure angeregte Diskussion gestoßen...

Ein wenig Senf will ich gerne dazugeben:

Ich denke die Preise für die kommerziellen Kameras sind in der Regel gerechtfertigt. Entgegen der allgemein verbreiteten Ansicht, dass Elektronikbauteile quasi "nichts" kosten, gilt das für bessere CCD-Chips in keiner Weise. Es wurden ja schon Zahlen genannt.

Ein Selbstbauprojekt macht m.E. nur "Sinn", wenn einer der folgenden Punkte erfüllt ist:
- was Neues zu lernen steht im Vordergrund, d.h. das Endergebnis muss nicht "konkurrenzfähig" sein
- Es soll ein besonderes Feature realisiert werden, das kommerziell nicht erhältlich ist

Ansonsten fährt man mit einer gekauften Kamera bestimmt besser. Man sollte auch die Gefahr nicht unterschätzen, einen teuren Chip versehentlich zu zerstören. Bei den Sonys reicht dafür ein zu langer Bildauslesepuls, bei manchen(?) Kodak Chips ein Kurzschluss am Ausgang. Ich halte jedenfalls immer den Atem an, wenn ich mit den Tastköpfen in Sensornähe hantiere...

Meiner Meinung nach ist es auch der falsche Weg, gekaufte Teilbaugruppen zusammenzustrícken. Damit erreicht man in den seltensten Fällen eine gute Leistung. Es kann aber Zeit sparen (oder mehr Zeit kosten, weil der Krempel doch nicht so wirklich gut dokumentiert war).

Optimale Leistung gibt es nur bei einem von Grund auf durchoptimierten Design. Das gilt speziell auch für das Zusammenspiel HW/SW, gerade wenn man nur spärliche Rechenleistung hat. Ist natürlich eine Frage des Anspruchs.

Die CCD-Takte in SW zu realisieren ist übrigens ein hartes Brot... ich weiß wovon ich rede! Das kann bestimmt kein Display-Controller "nebenbei" erledigen.

Bedenkt die Datenmenge die hier in kurzer Zeit zu handeln ist. Allein der RAM-Speicher für einen zig Megapixelchip ist eine Sache für sich.

Kann man natürlich machen, aber sinnvollerweise nur mit modernen Bauteilen, d.h. SMD pur, viele enge Pins und Multilayer-Platinen. Und das Vorsehen von Alternativbauteilen würde wieder Freiheitsgrade kosten. Damit ist das Projekt nicht mehr zum Nachbau für weniger erfahrene Elektroniker geeignet, und somit als "open source" eigentlich gestorben.

Das Konzept für meine 6,5MPix Stand-Alone Kamera mit dem 453 ist leider noch nicht rund, aber es steht bereits fest dass ganz andere HW-Kaliber aufgefahren werden müssen als für den kleinen 285er. Ohne FPGA und SD-RAM geht da nix, schon gar keine Signalerzeugung per SW.

Ich will jetzt nicht Schwarzmalen, aber die ekelhaftesten Fallstricke sieht man in der Regel vorher nicht ... [;)]

Ich denke das sind die Gründe warum es nach Cookbook und Audine keine Selbst-Nachbau-Kameras mehr gab.

Trotzdem würde ich gerne ein entsprechendes Bauvorhaben sehen...

cs
Martin