Das leidige LED-PWM-Thema mal wieder. Aber diesmal fürchte ich, wird es nicht ohne Hardwareschlacht und einiges an Know-How lösbar sein. Meine Aufgabe: Ich möhcte ein LED-Display bauen, das bei Zeitlupenaufnahmen zum Einsatz kommt. Dementsprechend ist eine ziemlich hohe Bildwiederholrate nötig. Das Ganze soll skalierbar sein, also ergeben sich folgende Worst-Case-Eckdaten: max. 64 Zeilen * max. 128 Spalten RGB LED-Matrix (max. 24'576 Kanäle) Framerate: max. 66kHz, also min. 15µs Es ergibt sich also zunächst die Notwendigkeit, in einer Zeitspanne, die deutlich kleiner als 15µs ist, ein Bild komplett aufzubauen und das Bild dann für diese 15µs zu halten. Da die Hardware diese Leistungsfähigkeit haben muss, dürfte es im nächsten Schritt nur vergleichweise geringe Schwierigkeiten bereiten, eine PWM zu realisieren, also einzelne LEDs noch vor Ablauf der 15µs zu deaktivieren. Für die weiteren Überlegungen habe ich jetzt pro Farbe einfach eine 4-Bit-Auflösung angesetzt. Also müssten diese 15µs in 2^4 = 16 Schritte zerlegt werden. Die PWM läuft dann also ca. mit 1Mhz. Die Frage ist jetzt, wie man denn - auf ziemlich engem Bauraum - diese große Zahl an LEDs treiben kann. Mit Schieberegistern denke ich mal, ist kein Land in Sicht, weil eine Registerkette ja in 1µs komplett "durchgeschoben" werden können muss. Trotzdem sollten die Ausgänge einen Großteil dieser Zeit noch stabil sein und nicht "flimmern". Die nächste Idee wären (viele) CPLDs gewesen, die die einzelnen Farbwerte von einem/mehreren µC empfangen und dann die PWM selbständig umsetzen. Wirklich viele Ports haben CPLDs aber auch nicht. Dabei ist zu sagen, dass die Kommunikation vermutlich über einen Parallelbus erfolgen muss. Und je weniger Leitungen dieser Bus hat, desto schneller muss er laufen. Bei welcher Frequenz schätzt ihr die Grenze des Machbaren ein? Ich komme mit 24 Datenleitungen nämlich auf gut 400 MHz... seufz Gibt's noch weitere Ideen? Könnte man etwa CPLDs und Schieberegister zusammen verwenden? kleiner Hinweis: Ausreden kann man mir das Projekt nicht. Vielleicht wird es ein paar Jahre verschoben, aber mehr ist nicht drin :P
PWM wird relativ schwierig werden bei diesen Geschwindigkeiten. Wieviele Stufen soll die PWM denn haben? Bei z.B. 16 Stufen (4Bit) PWM hast dann nur noch ~1µs pro komplettem Bildaufbau übrig, bei Takt entspricht das etwa 16 Takten... Die Wiederholrate erscheint mir auch ein wenig sehr hoch, sicher dass es 66kHz sein müssen? Laufen Zeitlupenkameras wirklich mit 66.000 Bildern pro Sekunde? oO
Armin schrieb: > kleiner Hinweis: Ausreden kann man mir das Projekt nicht. Vielleicht > wird es ein paar Jahre verschoben, aber mehr ist nicht drin :P 10eur darauf, dass das so nicht realisiert wird...
Christian T. schrieb: > Die Wiederholrate erscheint mir auch ein wenig sehr hoch, sicher dass es > 66kHz sein müssen? Laufen Zeitlupenkameras wirklich mit 66.000 Bildern > pro Sekunde? oO Dann muesse man das Filmmaterial ja - grob gerechnet - auf doppelte Schallgeschwindigkeit bringen... ;) Volker
Mal von dem Detail der LEDs abgesehen: Ich komme bei 64 Zeilen * 128 Spalten 3 Farben 4 Bit * 66 kHz auf eine Datenrate der Ansteuerung von 6,5 GBit/s. Das ist nicht ganz wenig... Mit Videoschnittstellen könntest du vielleicht weiterkommen. Da braucht es schon HDMI 1.3 oder ähnliches. Du könntest einen hochauflösenden Frame quasi umwidmen, z.B. aus einer Zeile wird ein kleiner Frame. Etwas Puffern um die vertikale Austastlücke auszugleichen. Dann kannst du zumindest für die Quelle was handelsübliches nehmen, einen PC der eine entsprechen präparierte Bildfolge im RAM durchschaltet, oder was auch immer unkomprimiertes Video kann. Tipps für die LED-Ansteuerung überlasse ich anderen Experten.
@Christian Es gibt noch deutlich schnellere Cams. Aber natürlich auch langsamere. Wer schon einmal einen Bildschirm gefilmt hat, weiß, dass es nicht schaden kann, mit der Framerate ein gutes Stück drüber zu gehen. Mir ist auch klar, dass dafür wohl eine zügige CPU nötig ist. Oder mehrere. Dieses Problem ist aber auf jeden Fall leichter zu handhaben als die große Menge an nötigen schnellen Outputs auf sehr kleinem Raum. Soweit ich weiß, arbeiten CPLDs ja parallel. Die dürften also kein Pproblem haben, das Bild in der Zeit aufzubauen. Wenn es denn schnell genug übern Bus kommt! @Michael Deine Aussage war zwar selbstbewusst, aber undeutlich. Meinst du, dass man das heutzutage nicht so realisiert? Klar, kann man die Daten einfach in der Post ins Bild einblenden. Das bedeutet aber je nach Daten einen erheblichen Mehraufwand. Außerdem wird die Aufgabenstellung nicht so weit abgeändert... :P Oder meinst, dass die zwei Umsetzungsvorschläge von mir so nicht realistisch sind? Gut möglich. Mach nen Vorschlag! Das sind ja nur Ideen...
eieiei ... da hast du dir was vorgenommen .... ich sehe da eigentlich "nur" die möglichkeit, dein Bild zu splitten und das ganze auf mehrerern fpgas zu machen. ein mikrocontroller der mereren fpgas (so viele wie es denn benötigt um alle leds treiben zu können) den bildinhalt zuschanzen kann. um den speed zu erreichen währe allenfalls ein grosses dualport ram tauglich, in dem der mikrocontroller alle bilder im vorraus abgelegt hat und den fpgas nur noch mitteilt was sie darstellen müssen. wie schauts denn aus, was willst du darstellen? zeit? wie genau muss das synchronisierbar sein? gruss Claudio
... max. 66kHz ... Hilf mir bitte auf die Sprünge. Wozu muß man 66 000 Bilder pro Sekunde "sehen" können?
Die andere Sache ist, dass man dafuer so krass beleuchten muss, dass man da garnicht mehr drauf klar kommt :P
>Wozu muß man 66 000 Bilder pro Sekunde >"sehen" können? Lesen ist von Vorteil... steht alles da!
...aber allgemein wird das schon ziemlich gross werden: - 8192 RGB LEDs kosten auch so einiges - Nehmen wir mal 20mA pro LED-Farbe(!), dann sind das 490(!) Ampere Viel Spass bei der Dimensionierung des Netzteils und der Anschlussleitungen ;-) Ciao... Markus
... Lesen ist von Vorteil... steht alles da! ... Tja, da steht mir wohl meine Lese- und Verständnisschwäche im Weg. Eine genauere Erklärung wäre schon nett.
ich blick da nicht durch ... wer soll denn 66KHz Bildwiederholrate sehen? ... Wir Menschen sehen ab 25Hz schon flüssiges Bild, ok, es soll nicht flackern, sagen wir mal 100Hz für die Darstellung. Wenn ichs richtig verstanden hab soll mit 66kHz aufgezeichnet werden, ok, das ist schon eine Herausforderung, aber die Darstellung braucht doch diese Geschwindigkeit nicht. Wohl eher Aufzeichnung mit 66kHz und dann in 100Hz Ausgabe also zeitverlangsamt dann, oder? Gleich schnelles aufnehmen und darstellen macht ja irgendwo nicht richtig Sinn, oder?
Armin schrieb: > Soweit ich weiß, arbeiten CPLDs ja parallel. Die dürften also kein > Problem haben, das Bild in der Zeit aufzubauen. Gatterlaufzeiten nicht vergessen und wenn PWM im Spiel ist ist auch wieder ein Takt im Spiel
...wenn eine Aufzeichnung mit 66KHz Framerate stattfindet, müssen in dieser Zeit alle LEDs min. einmal leuchten. Wenn man das ganze multiplexen würde, aber z.B. die Ausgabe der einzelnen Zeilen nicht mit dem Aufnahmegerät synchronisert, benötigt man min. sogar die doppelte Refreshrate, also 128KHz. Dann noch 16 Stufen PWM - haha - ist man schon > 1MHz. Das wird doch dann auch eine riesige Antenne inkl. Störungsabstrahlung, oder? Also ich glaube auch das es so nicht zu realisieren ist. Ciao... Markus
@Armin: Wo beziehst Du denn deine RGB-LEDs her? Bei >8000 LEDs musst Du da ja ziemlich billig ran kommen, oder ist das Projekt kommerziell? Sollen da Animationen laufen? Oder eher statische Bilder? Was ist denn das größte erhältliche Schieberegister mit Latch? TFT display-treiber arbeiten so wie ich das verstehe auch mit Schieberegistrern - aber ich fürchte mal, dass die nicht ohne Probleme erhältlich und verbaubar sind, oder? Denn sonst wäre meine erste Idee den Propeller zu benutzen, um die Daten in die Schieberegister raus zu hauen. Der hat pro Kern einen Video-Generator mit dem sich aber auch schnell Schieberegister befüllen lassen. Bei einem Pixel-Takt von 128MHz (wenn ich das recht in Erinnerung habe) reicht das für eine Zeile bei 15 Abstufungen aus. (128 x 66000 x 15) Ein Propeller könnte also vermutlich 7 Zeilen RGB bewältigen. 7 Kerne für die Zeilen und 1 Kern zum Datenaustausch mit nem 'Bild-Server'. Macht also 11 Propeller (einen als Bild-Server). Ein XMOS könnte auch ne Alternative sein. Hat zwar keinen Video-Generator, ist aber 400MHz schnell pro Kern und hat viele I/O.
Okay, ich hab nochmal durchgerechnet und gesehen, dass ich mich bei der Datenübertragungsrate vom PC --> Elektronik verrechnet habe. Ursprünglich sollten die Bilder von einem normalen PC bereitgestellt werden. Aber das wird natürlich nix. Aber: Wenn man auf die PWM verzichtet und nur 8 Farben darstellen lässt, werden es 24'576 Bit mit 66'000Hz. Also "nur" noch gut 200 MB/sekunde. Das wäre vielleicht zumindest an dieser Stelle realisierbar. Ansonsten muss ich wohl auf bessere PCs und Schnittstellen warten. Die Verbindung PC --> Elektronik wird der letzte Entwicklungsschritt sein. Die ersten paar Entwicklungsjahre genügt es, wenn die µCs selbt irgendwelche Testbilder erzeugen (Punkte, Zeilen, Zähler...) @gastlich ja eine Uhr wär mal eine denkbare Anwendung. Also ich möchte natürlich jeden dieser 15µs-Frames sein eigenes, persönliches Bild darstellen lassen. Ohne irgendwelche Beschränkungen. Außer dass diese Bilder tatsächlich im Voraus schon bekannt sein können. Worst-Case allerdings nur 20ms im Voraus (falls es sich z.B. um Messwerte handelt) :P @ich Das leidige Thema: Die Kohlen. Mir ist klar, dass allein schon die LEDs nicht unter 1000 EUR zu haben sein werden. Für die ganze restlichen Bauteile/Platinen möchte ich eigentlich nicht mehr als 500-600 EUR Materiakosten haben. Mir ist auch klar, dass da beim Entwickeln noch einiges an Kohlen draufgehen wird. Gerade an Platinenmaterial wenn ich mich dann ins HF-Platinendesign einlese... (ja, Markus, nächster offener Punkt, i know, aber irgendwo muss man anfangen) Aber wie oben beschrieben sind das maximale Werte, die das Konzept aushalten muss. Vielleicht baue ich auch erstmal nur kleinere Panels mit 32x32 Pixel und schau, wie das ankommt. Ich möchte allerdings, falls ich am Ende doch ein größeres Display bau, nicht wieder von vorne anfangen müssen. Deswegen die hohen Anforderungen. @Markus ich hoffe, mit 5-7 mA auskommen zu können. Wird aber immer noch ziemlich massiv, richtig. Dafür gehe ich auch davon aus, dass in den wenigsten Fällen wirklich alle LEDs laufen, und wenn dann nur kurzzeitig. @ Fhutdhb Ja klar wird das Video dann nur mit geringerer Framezahl abgespielt. Sonst wird's ja nicht langsamer :P Das LED Panel soll VOR der aufnehmenden Hochgeschwindigkeitskamera stehen, um weitere Daten einzublenden, und nicht deren Aufnahmen anzeigen. @MagIO wie gesagt... 1000 EUR muss man wohl schon einplanen :( Ja, Animationen. Latch? Propeller? XMOS? ich werde mal googlen...
Wenn's eine FPGA-Lösung sein soll, dann wahrscheinlich ein paar von dieser Größenordnung: http://www.edel-schrott.de/product_info.php/info/p247_CX4085XL-Gatearray.html Ist zwar schon etwas angestaubt, aber mit 559 Pins kann man eine ganze Menge machen - wenn man day Layout hinbekommt.
@Markus: ich seh nicht, dass ich bisher von irgendwelchen Ideen abgekommen bin. Da ich da eh lang dransitzen werde, ist auch die PWM noch nicht völlig vom Tisch. Außerdem sind bei den Preisklassen die 10 EUR auch noch locker drin, wenn ich dafür wirklich weiterkomm :P @Sebastian: joa lieber CPLD als FPGA, aber so wie's aussieht darf ich nicht wählerisch sein. Danke für den Tip =)
warum eigendlich ein LED-Display? wie oft müssen denn die Daten auf dem Display geupdated werden? Warum kann man die Daten nicht parallel aufzeichnen und hinterher per overlay ins Bild bekommen.
>wie oft müssen denn die Daten auf dem Display geupdated werden?
sagt mal, kann hier niemand mehr lesen???
@armin Also ich würde auch eher zum FPGA tendieren. Das ganze dann als Modulbauweise (z.b. 16x16 oder 32x32 RGB Led's im Multiplex-PWM Mode). Des weiteren kann der FPGA ja über ein entsprechendes Interface schnell und viele Daten aufnehmen (dafür sind die ja ausgelegt). Und zum schluß noch einen Master FPGA der die anderen mit Daten versorgt. Wird zwar nicht billig das ganze, aber das ist dir ja von vornherein klar gewesen. Und ich denke das wäre der praktikabelste weg, da durch die Modularbauweise das ganze erweiterbar ist.
Nachtrag also ich denke mal das du mit Spartan 3 FPGAs schon genügend weit kommen kannst (modularbauweise vorausgesetzt).
ich schrieb:
> sagt mal, kann hier niemand mehr lesen???
Ich bin jetzt grad noch mal drüber geflogen und hab keine Aussage
gefunden.
Edit:
ok, habs dch gefunden:
In jedem Zyklus ein neues.
Armin schrieb: > Wer schon einmal einen Bildschirm gefilmt hat, weiß, dass es nicht > schaden kann, mit der Framerate ein gutes Stück drüber zu gehen. Vielleicht könnte man das Display mit der Kamera synchronisieren? > wie gesagt... 1000 EUR muss man wohl schon einplanen :( Alleine die Arbeitszeit wird dies um ein Vielfaches übersteigen. David ... schrieb: > Die andere Sache ist, dass man dafuer so krass beleuchten muss, dass > man da garnicht mehr drauf klar kommt :P Das Problem sehe ich auch. Die LEDs müssten wahrscheinlich schon sehr hell leuchten, damit man überhaupt was erkennt. Das paßt dann aber nicht so richtig zusammen mit: Armin schrieb: > ich hoffe, mit 5-7 mA auskommen zu können.
Muss es unbedingt RGB sein? Ich würde erstmal mit nem kleineren Display und LowCurrent-LEDs anfangen. Dann hast du 1. nen handhabbaren Stromverbrauch und 2. etwas freundlichere Wiederholfrequenzen/Datenraten. Bei dem Versuch kannst Du denke ich schon recht gut die Grenzen ausloten...
Armin schrieb: > @ Fhutdhb > Ja klar wird das Video dann nur mit geringerer Framezahl abgespielt. > Sonst wird's ja nicht langsamer :P > Das LED Panel soll VOR der aufnehmenden Hochgeschwindigkeitskamera > stehen, um weitere Daten einzublenden, und nicht deren Aufnahmen > anzeigen. > Wie wäre es wenn du diese Daten einfach in die Videodaten der Highspeed Kamera (66k Bilder ist schon richtig schnell...) einspeist. Also per Overlay oder so. Ich denke das Vorhaben ist ansonsten zum scheitern verurteilt, sorry
Bei allem Respekt, aber Kommentare, die Wetten auf Nichtverwirklichung des Projekts setzen, finde ich eine Frechheit. Auch wenn einige Projekte (wie dieses hier auch) äußerst Ehrgeizig sind, fände ich persönlich es wünschenswert, wenn der Dialog ein wenig Sachlicher geführt würde. Gruß, fiete
Wenn ich mich recht entsinne, dann ist doch bei die High-Speed-Aufnahmen das Set immer besonders gut ausgeleuchtet. Dass da bei 6mA / 66000 Bilder noch viel Licht-Leistung pro Bild übrig bleibt wage ich allerdings auch zu bezweifeln. Aber das kann man ja schon mit einer LED mal testen. Einfach nen Strom von 5-10mA einstellen und sehen wie die LED sich im hellen Set noch behaupten kann.
... die Wetten auf Nichtverwirklichung des Projekts setzen ... Muß ich mal wieder überlesen haben. Mit der Bitte um Nachsicht - wo steht das?
@ Friedrich K. (fiete) >Bei allem Respekt, aber Kommentare, die Wetten auf Nichtverwirklichung >des Projekts setzen, finde ich eine Frechheit. Deine Meinung. >Auch wenn einige Projekte (wie dieses hier auch) äußerst Ehrgeizig sind, >fände ich persönlich es wünschenswert, wenn der Dialog ein wenig >Sachlicher geführt würde. Da sollte der OP mal anfangen und sich über Netiquette informieren. Und gleich daruaf über Grundlagen von Hochgeschindigkeitsphotographie bzw. Kameras. Denn ausser einer fixen Idee hat der OP nichts im Kopf (auf diesem Gebiet). MFG Falk
MagIO schrieb: > Wenn ich mich recht entsinne, dann ist doch bei die High-Speed-Aufnahmen > das Set immer besonders gut ausgeleuchtet. Dass da bei 6mA / 66000 > Bilder noch viel Licht-Leistung pro Bild übrig bleibt wage ich > allerdings auch zu bezweifeln. Das ist allerdings ein guter Punkt! Wikipedia schreibt dass man viele Objekte schon mit 40K Frames/s nicht mehr aufnehmen kann, da sie alleine durch die Hitze des benoetigten Lichts zerstoert wuerden. Friedrich K. schrieb: > Bei allem Respekt, aber Kommentare, die Wetten auf Nichtverwirklichung > des Projekts setzen, finde ich eine Frechheit. Finde ich persoenlich jetzt nicht so schlimm... Ich haette sogar gewettet dass so schnelle Highspeed-Kameras nicht existieren, musste aber gerade herausfinden, dass die Schnellste dieser Gattung glatte 200 Mio. (!) Bilder pro Sekunde macht. http://advance.uri.edu/pacer/september2000/story9.htm Aber Armin ist ja nicht Arun! ;) Volker
@Falk: bitte konkreter werden. was hätte ich tun sollen, außer alle Rückfragen - manchmal auch dreifach - zu beantworten? Ich denke, vielen hier im Board könnte eine gewissen Zurückhaltung nicht schaden. Aber ich muss sagen, in diesem Thread geht es verhältnismäßig gut zu und ich habe eine große Zahl hilfreicher Hinweise bekommen. Das ist nicht immer so. Danke an jeden, der sich angesprochen fühlt... grüße
Was ist das denn für ein unsinn soviele Bilder/s darstellen zu wollen?? Für die geschwindigkeit der Aufnahme zählen doch die 66kHz! Davon ist hier jawohl kaum die rede. Wie irgendwo oben schon einmal erwähnt hatte, reicht doch die normale Frequenz von 100Hz oder weniger aus. Wie die Daten zur "Grafikkarte" oder sonst was kommen ist doch ein anderes Thema oder?
hae schrieb: > Was ist das denn für ein unsinn soviele Bilder/s darstellen zu wollen?? > Für die geschwindigkeit der Aufnahme zählen doch die 66kHz! Davon ist > hier jawohl kaum die rede. Wie irgendwo oben schon einmal erwähnt hatte, > reicht doch die normale Frequenz von 100Hz oder weniger aus. Wie die > Daten zur "Grafikkarte" oder sonst was kommen ist doch ein anderes Thema > oder? Du hast es wohl nicht verstanden... ;) Fuer Zeitlupen muss man logischerweise mehr Bilder pro Sekunde aufnehmen als spaeter pro Sekunde abgespielt werden. Spielt man eine 66kHz-Aufnahme mit 100Hz ab, hat man eine 660-fache Zeitlupe. Macht Sinn? Volker
Meine Grafikkarte macht 66kFPS :D Meiner Meinung nach nur verbranntes Geld. Das Bild kann man mit viel weniger Aufwand nachträglich einfügen. Aber darauf geht der OP nicht ein.
Overclocker schrieb: > Meiner Meinung nach nur verbranntes Geld. Das Bild kann man mit viel > weniger Aufwand nachträglich einfügen. Aber darauf geht der OP nicht > ein. Aber er sagte ja eingangs auch schon: > kleiner Hinweis: Ausreden kann man mir das Projekt nicht. Ist also voellig legitim! ;) Volker
Ehrlich gesagt, nein, ich habe es noch nicht verstanden. Aber ich lasse mich gerne belehren :-) Macht es denn Sinn Bilder so schnell abzuspielen? Könnte man nicht nur jedes 2. oder 4. Bild abspielen, wenn man die Zeitlupe nicht so arg langsam haben möchte? (wäre natürlich verschwendung bei der tollen Kamera). Ich sehe den Sinn noch nicht ganz, da das Auge die Bilder doch sowieso nicht wahrnehmen kann, wenn die so einen Affenzahn drauf haben. Mit jedem Stinknormalen Fernseher kann ich mir doch auch ne Aufnahme von einem Wassertropfen der auftritt oder sowas anschauen. Ich hoffe ihr könnt mich aufklären.
Nochmal zum mitlesen: Es geht darum Highspeed-Aufnahmen zu machen. Das ist momentan total in ... siehe Galileo, Splash-Lab und diverse Discovery Dokus ........ so wie ich das verstehe geht es darum Informationen z.B. live Messwerte in die Filmaufnahme einzublenden, oder? Daher nochmal nachgehakt: Müssen wirklich 66k Bilder übertragen werden? Oder geht es um Text-Information? Dann müsste man zu den einzelnen Zeilentreibern oder Matrix-Treibern oder wie auch immer es nachher realisiert wird nicht die ganzen Pixel-Daten verschickt werden, sondern nur der Text der in das entsprechende Segment passt. @Armin: Kannst Du das mit der einzelnen LED vorab schon mal ausprobieren? Möglicherweise sind ja heutige RGB LEDs noch nicht weit genug was die Lichtausbeute betrifft. Ist es jetzt ne kommerzielle Idee? Oder geht es um die Idee an sich? Kommerziell wird es sicherlich einfacher die Information in der Nachbearbeitung ins Bild einzufügen. Solche Kameras werden häufig extern gestartet - z.B. getriggert durch eine Elektronik, die den beginn des High-Speed-Events erfassen kann. Also könnte das auslösende System auch die Aufzeichnung der Messwerte triggern. In der Nachbearbeitung hat man dann alle Zeit der Welt um die Messwerte via Bluescreen einzubauen. Das wird sicherlich um größenordnungen billiger ... es sei denn es wird ständig gebraucht ....
Ja auf einem normalen Fernseher, evtl mit 660-facher zeitlupe :-)
Wie ihr schon erkannt habt, ist das so kommerziell nicht konkurrenzfähig. Deswegen eher als Privatprojekt zu verstehen. Es geht hier aber eindeutig um Bilddaten. Eine Komprimierung des Datenstroms - wie beispielsweise bei Text oder Zahlen - kann nicht so leicht erfolgen. Die Sache mit der Lichtleistung könnte tatsächlich zu einem Problem werden. Aber wie ihr ja schon festgestellt wurde, sind im Extremfall 500 Ampere am Start... Offensichtlich kann ich doch nicht mit dem LED-Strom runtergehen. Wenn man von einer ca. tausendfachen Verlangsamung ausgeht, sollten doch noch genügend mW für jeden Frame drin sein, meint ihr nicht?
@Armin (Gast) >bitte konkreter werden. Kann ich nur voll zurück geben! Sag mal KONKRET, was der Sinn der Sache sein soll? Wozu braucht man ein LED-Display, welche 66k Frames/s anzeigen kann? Zeitlupe braucht eine KAMERA, welche diese hohe Bildfolge aufnehmen kann, aber kein DISPLAY! Und wozu soviele Bilder so schnell anzeigen und dann wieder aufnehmen? >was hätte ich tun sollen, außer alle Rückfragen - manchmal auch dreifach >- zu beantworten? Dein Vorhaben umfassender beschreiben. MFG Falk P S Es ist dennoch eine Schnappsidee, vor allem bei deinem Kenntnisstand ;-)
Also entweder rückt der Tread-Erstelle nicht mit der Wahrheit raus, oder er ist total auf dem falschen Gaul. Zeitlupe heißt schnell aufnehmen und langsam abspielen. Die Aufnahme mit 66k Framerate hat überhaupt nichts mit der Rate beim Display zu tun. Im Gegenteil, würde dort die gleich FR laufen, wär's ja keine Zeitlupe..... Also ist ein legitimes (und ausreichend schwieriges) Projekt ist das Abspeichern der unglaublichen Datenmenge von 66k Frames/s. Display ? Na klar, jeder blöde TFT, Beamer, Fernseher oder was auch immer. Übrigens kann man in jeder besseren Autosendung wunderbare Zeitlupen von Crashtests sehen. Oder hat da jemand schon extra dafür ein 66kFR-450A-Hyper-Wahnsinns-Display kaufen müssen ??? Das ist doch alles Humbug. Nicht mal wert für eine Wette.
Daten anzuzeigen, um sie dann wieder zu filmen, halte ich auch für blöd. Dann lieber per Echtzeit direkt ins Bild oder falls das nicht geht, synchronisiert aufzeichnen und beim Abspielen einblenden, oder einmal direkt in das Video eincodieren. ich finde Variante 2 am sinnvollsten: automatisch auswertbare Messdaten + das Bild kann voll für die Aufnahme genutzt werden
eberhard schrieb:
> Das ist doch alles Humbug. Nicht mal wert für eine Wette.
du verstehst nicht, was der TO will:
er will ein Display mitfilmen um Daten anzuzeigen!
Ahh Danke, jetzt habe ich verstanden! Schon eine spezielle Anwendung! Ich habe das wohl nicht richtig gelesen, sorry!
Wie waere es mit einem einfachen Zaehler aus 7-Segment anzeigen, den kann man sicher mit 66KHz hochzaehlen lassen kann. Dann noch gleichzeitig den angezeigten Wert synchron mit den Daten speichern und hinterher separat auswerten, fertig... oder sehe ich da was ganz falsch? Jan
also ich habs so verstanden ... es soll irgendwas mit 66kFrames/s aufgenommen werden, im Aufnahmebereich soll das Display mit den LED stehen um gleichzeitig, quasi in jeden Frame eine neue Info einspielen zu können ... was weiß ich, n Framecounter oder Messwerte gleichzeitig, irgendsowas. Das Display müsste natürlich mit der Kamera nochmal synchronisiert werden, aber egal. Nun, ich halte den Ansatz die Bilddaten direkt zu manipulieren gewinnbringender, aber des Menschen Wille ist ja sein Himmelreich. Ob RGB-LED mit 66KHz noch was sinnvolles darstellen können halte ich für wenig wahrscheinlich, die Beschaltung dahinter was kapazitive und induktive Kopplungsmechanismen angeht ne echte Herausforderung. Nun, in 5-10 Jahren kann der Entwickler ja dann sein Werk hier präsentieren und allen sagen das sie unrecht hatten.
Nochmal um es zu verstehen: Es soll eine Hochgeschwindigkeitsaufnahme gemacht werden, und schon bei der Aufnahme sollen über die LED-Matrix Informationen eingeblendet werden. Soweit klar. Bei einem Crashtest wird beispielsweise oft ein entsprechender Zähler für die Zeit eingeblendet. Soweit auch klar. Aber wozu braucht man eine Animation? Ich will jetzt mal nur verstehen, wozu man sowas braucht. Ein paar Daten kann man ja per Ziffern- oder Alpha-LED-Anzeige recht einfach (mit vergleichsweise wenigen Segmenten) einblenden, aber wozu zum Geier braucht man Animationen und so eine große Matrix? @MagIO: Der Parallax Propeller läuft mit 80 MHz, evtl. wird der Propeller II mit 160 MHz und mehr (16?) Cores eine Variante.
@ golem23 (Gast) >wenigen Segmenten) einblenden, aber wozu zum Geier braucht man >Animationen und so eine große Matrix? Weil RBG LEDs coooool sind. ;-) >@MagIO: Der Parallax Propeller läuft mit 80 MHz, evtl. wird der >Propeller II mit 160 MHz und mehr (16?) Cores eine Variante. Nie und nimmer. Wenn wir den "Sinn" eine solchen Displays mal aussen vor lassen, dan geht sowas nur mit FETTER paralleler Hardware. Also ein FPGA oder mehrer mit vielen Pins, an denen die LEDs direkt dranhängen. Mit Multiplexing und PWM kann man hier keinen Blumentopf gewinnen. MFG Falk
Was mich ebenfalls interessieren würde ... Was willst du mit 66kFrames aufzeichnen ? Nen Wassertropfen in Zeitlupe sicherlich nicht. Explosionsvorgänge wären da schon interessanter, aber 660fach verlangsamt, da kannst du dir bis zur vollständigen Ausdehnung des Objektes sicherlich ne Tasse Kaffee trinken (ok ist vllt übertrieben), aber was nimmt man so schnell auf ?! Mal ganz abgesehen davon das ich bei weitem nicht wüsste was man mit 200MFrames (wie die schnellste Kamera) aufzeichnen sollte. Ne Atomexplosion ? Wenn die Kamera das überlebt wärs ne interessante Zeitlupe. Aber mal im Ernst. Was ist so schnell das man 66kFrames braucht ?! Im übrigen schließe ich mich schon den Vor-Beleuchtungs-Postern an :-) Die Lichtquelle muß wirklich enorm sein. Prüfe es wirklich erstmal mit ner LED gegen. Vllt das du um ultrahelle nicht drumrum kommst (wenn die überhaupt reichen).
@Falk Na ja. Wenn der FPGA das Multiplexing und PWMming mit 200MHz in Hardware übernimmt vllt schon :-). Jeder Ansatz per uC dürfte scheitern. Bei dem Vorhaben kommt man nicht um eine entsprechend schnelle Hardware drumrum. Also würd ich sagen : da geht nur ein FPGA.
@ Rene Böllhoff (themason) Benutzerseite >Die Lichtquelle muß wirklich enorm sein. Prüfe es wirklich erstmal mit >ner LED gegen. Generation LED. ;-) Wenn man WIRKLICH viel Licht für Hochgeschwindigkeitsaufnahmen braucht, nimmt man auch heute noch Blitzlampen. Die machen Lichtpulse im oberen KW Bereich. Da ist die LED längst verdampft. ;-) MFG Falk
Hi, ich würde, wie auch Jörg vorgeschlagen hat, eine Anbindung per DVI/HDMI an den PC versuchen, die geforderten Datenraten lassen sich so realisieren. Die Ausgabe kannst du über Schieberegisterketten realisieren, bei 10MHz Clockfrequenz und 1 Bit pro Kanal, kannst du pro Kette etwa 150 Kanäle steuern, du brauchst also etwa 160 Schieberegisterketten. 74595 fällt mir als Schieberegister dazu ein, gibts aber nicht in AC was dir zusätzliche Treiber ersparen würde, die treiben ja 20mA, bei HC mußt du dich eben mit 8mA begnügen. Ein FPGA zwischen DVI/HDMI und Schieberegisterketten, fertig ist das ganz. Ich weiß nicht ob ein FPGA direkt mit DVI/HDMI kann. Zur Helligkeit: Hab mal meinen Monitor fotografiert: 300cd/m² bei F3.3 1/30s Belichtung. für 1/60000s brauchst du dann immerhin das 2000 fache also 600000cd/m². Bestimmt hat deine Kamera ein besseres Objektiv also z.B F1.0, dann brauchst du "nur noch" etwa 50000cd/m², bitte um Korrektur falls ich hier falsch liege! Ok - die Sensorempfindlichkeit fehlt noch, kann ich jetzt nix zu sagen. Gute RGB-LEDs ohne Fokusierung bringen bei 20mA etwa 5cd, deine 8000 LEDs bringen dann 40000cd, bei dieser Schätzung käme ich auf 0.8m² auf die du die 8000 LEDs maximal verteilen kannst um die erforderliche Leuchtdichte hinzubekommen. Je LED musst du mit Vorwiderstand etwa 250mW rechnen macht schlappe 2kW für das ganze, da mußt du gut kühlen! Bei 8mA je LED kommst du dann auf "angenehmere" 800W, die Maximalfläche verringert sich dann entsprechend. Also ich denke ist alles machbar aber der Aufwand ist erheblich, vor allem mit den geschätzten Materialkosten wirst du nicht hinkommen. Gruß Stefan
@golem23: Ich weiß, dass der Propeller 80MHz hat ... ich habe genügend davon hier. Ich habe vom Pixel-Takt des Video-Generators geredet. Der Propeller hat 8 Kerne und jeder der 8 Kerne hat einen Video-Generator. Mit jedem einzelnen davon kann man VGA Signale erzeugen. @Falk: Yep ... parallel ... 8 Video Generatoren + ne ganze Horde an Schieberegister gehen schon in die Richtung fett. Dabei ist die Programmierung des Propellers sicher ein gutes Stück einfacher, als die eines FPGAs. Ich habe mal einen Versuch gemacht, indem ich einen Video-Generator dazu verwendet habe, ein Schieberegister voll zu schreiben. Also nochmal die Idee von oben: Ein Propeller-Kern kümmert sich um eine Zeile. Allerdings war da noch nicht so richtig klar abzusehen, dass wirklich für jeden Frame ein EinzelBILD dargestellt werden soll. Ein reines Text-Display wäre damit Problemlos. Gibt es irgendwo Zeilen-Treiber für Laptop-Displays als Bauteil zu kaufen? 60Hz x 768 = 46080 ... wenn die also nicht 768 Zeilen, sondern nur eine zu bedienen hätten, könnte der 46000 mal die Zeile aufbauen. Gibts 100Hz Treiber? Farbe können die auch schon.
Jetzt nochmal genau nachgerechnet: 128 x 64 Pixel x 3 Farben x 4 Bit je Farbe / 8 Bit pro Byte x 66000 Bilder pro Sekunde = ~800MB/Sekunde Mit welchem Bild-Material soll das Display gefüttert werden? Muss es dann noch Verarbeitet werden? (Z.B. einblenden von Zahlen)
Stefan V. schrieb: > Hi, > > ich würde, wie auch Jörg vorgeschlagen hat, eine Anbindung per DVI/HDMI > an den PC versuchen, die geforderten Datenraten lassen sich so > realisieren. Wie hast Du denn das errechnet?!? Selbst wenn Du die Grafikkarte zu 66000 Frames/s ueberreden koenntest, muessten bei genannter Aufloesung und Farbtiefe ca. 6.5 GBit/s uebertragen werden (siehe auch Rechnung von MagIO). HDMI ist, wenn ich nicht irre, bis max. 2.25 GBit/s spezifiziert. Da fehlt noch Einiges! Bei Fuetterung durch einen PC (und auch generell) stellt sich dann noch die Frage, woher die Daten fuer die Animation kommen. 800 MB/s kann man ja (mit Glueck) hoechstens aus dem RAM lesen... > Zur Helligkeit: > Hab mal meinen Monitor fotografiert: 300cd/m² bei F3.3 1/30s Belichtung. > für 1/60000s brauchst du dann immerhin das 2000 fache also 600000cd/m². > Bestimmt hat deine Kamera ein besseres Objektiv also z.B F1.0, dann > brauchst du "nur noch" etwa 50000cd/m², bitte um Korrektur falls ich > hier falsch liege! Das habe ich jetzt nicht nachgerechnet, man kann aber bei 66000 kHz Wiederholfrequenz nicht automatisch von einer Verschlusszeit von 1/66000 s ausgehen. Wenn Du mit Deiner Kamera 8 Bilder/s machst, bleibt Dir pro Bild auch nur eine Verschlusszeit von deutlich unter 1/8 s. Die Helligkeit ist und bleibt, meiner Meinung nach, das Hauptproblem. Volker
Sry, dass ich auch nochmal fragen muss: Warum blendest du die Informationen nicht einfach nachträglich ins Video ein? Wozu braucht man dazu extra ein LED-Display? Kann dir zwecks Hardware nicht helfen, aber mich würde es schon interessieren warum du's nicht einfach per Software machst.
Mal ein anderer Aspekt: Wir haben hier im Thread ja schon den Stromverbraucht mit ca. 490A geschätzt. Ein Freund von mir (E-Techniker) betet mir immer vor: Kämpfe nicht gegen den Strom, der gewinnt sowieso! Ich will auf Folgendes raus: Wie will man denn so hohe Ströme mit so hohen Frequenzen schalten? oO Ich glaube, das macht keine Stromquelle mit, denn im Extremfall könnte man ja versuchen, abwechselnd immer volle Helligkeit und komplett aus anzuzeigen (Schwarz/Weiss im Wechsel).
Shuzz schrieb: > Ich will auf Folgendes raus: Wie will man denn so hohe Ströme mit so > hohen Frequenzen schalten? oO > Ich glaube, das macht keine Stromquelle mit, denn im Extremfall könnte > man ja versuchen, abwechselnd immer volle Helligkeit und komplett aus > anzuzeigen (Schwarz/Weiss im Wechsel). Das muss ja nicht alles aus einer Spannungsquelle kommen... Und man kann ja immernoch ausreichend Kapazitaeten fuer schnelle hohe Anforderungen einplanen. Geschaltet wird sowieso pro LED, wo die Stroeme ja relativ gering sind... Volker
Ich glaube, der Thomas hat da die erste richtige Idee geäussert: "Warum blendest du die Informationen nicht einfach nachträglich ins Video ein?" Ein einziger Trigger reicht ja um zu wissen wo man starten muß. Danach hat man alle Zeit der Welt, in das Video x-beliebige Informationen einzublenden. Meinetwegen in jeden Frame separat (auch wenn man das dann hinterher beim Ansehen wieder nicht erkennen kann) Wie auch immer, ich bin mal gespannt.... Gruß Eberhard
eberhard schrieb: > Ich glaube, der Thomas hat da die erste richtige Idee geäussert: > "Warum blendest du die Informationen nicht einfach nachträglich ins > Video > ein?" Diese "erste richtige" Idee wurde schon vor einer gefuehlten Ewigkeit von jemand anderem in den Thread geworfen... :-/ Volker
Einige Gedanken: 1.) Wenn es wirklich nur Informationen sein sollen, dann reicht doch eine monochrome Darstellung. Schon schwer genug in der Geschwindigkeit und in dieser Menge. 2.) Gesetzt den Fall, dass 1. ein gangbarer Weg ist dann sollte man LED's suchen die im Nennbetrieb sehr hell sind. Wenn man diese bei weniger Strom bereibt sind die immernoch enorm hell und sind besser als spezielle Low Current Typen. 3.) Keine Ahnung ob solche Hochgeschwindigkeitsbildsensoren bei bestimmten Wellenlängen eine besonders hohe Empfindlichkeit haben. Aber wieder gilt, wenn Punkt 1. geht dann sollte man sich LED's mit eben dieser (empfindlichen) Wellenlänge suchen. 4.) Die Matrix direkt vom FPGA ansteuern. Keine Schieberegister verwenden, denn damit treibt man benötigte Takte nur unnötig in die Höhe. Voll parallelisiert bedeutet das bei 66kHz Framerate etwa 14ns PWM-Auflösung (1/66kHz = 15µs für das ganze Bild, also 15µs/64Zeilen = 236ns/Zeile, bei 4Bit-PWM also 236ns/Zeile / 16Zustände/Zeile = 14ns/Zustand ~ 67.6MHz). Sportlich aber machbar würde ich sagen. 5.) Der Stromverbrauch wird keine 500A betragen - dein Glück, denn die Leistung fürdest du nicht ohne weiteres wegbekommen. Es sind ja nicht alle Zeilen immer an. Worst case ist eine komplette Zeile auf voller Helligkeit, was dann über die Zeit betrachtet für alle Zeilen gilt. Also 128 * 20mA = 2.56A. Selbst wenn man RGB ansetzen würde hätte man maximal 2.56A * 3 = 7.68A - und das auch nur dann wenn man R, G und B gleichzeitig ansteuert. Das wären dann meinetwegen 10W Verlustleistung (für den monochromen Fall), respektive 30W. Das sind Werte die machbar sind. Wenn man dann noch sehr effiziente LED's nimmt relativieren sich die 20mA ganz schnell und du landest bei 5..10mA.
Pothead schrieb: > 1.) Wenn es wirklich nur Informationen sein sollen, dann reicht doch > eine monochrome Darstellung. Schon schwer genug in der Geschwindigkeit > und in dieser Menge. Hab ich auch schon gedacht. Wenn man nur Informationen darstellen will, braucht man auch keine PWM mit mehr als 1bit ;) Aber der Thread-Ersteller äußert sich ja überhaupt nicht zu den Alternativ-Vorschlägen.
...dann könntest du aber immerhin noch s/w-Animationen laufen lassen. Was bei einer Auflösung von 128 auf 64 nicht unbedingt der Bringer ist. Aber die Sache soll ja skalierbar sein.
Hi, Volker Schulz schrieb: > Wie hast Du denn das errechnet?!? Selbst wenn Du die Grafikkarte zu > 66000 Frames/s ueberreden koenntest, muessten bei genannter Aufloesung > und Farbtiefe ca. 6.5 GBit/s uebertragen werden (siehe auch Rechnung von > MagIO). HDMI ist, wenn ich nicht irre, bis max. 2.25 GBit/s > spezifiziert. Da fehlt noch Einiges! Bei Fuetterung durch einen PC (und > auch generell) stellt sich dann noch die Frage, woher die Daten fuer die > Animation kommen. 800 MB/s kann man ja (mit Glueck) hoechstens aus dem > RAM lesen... > Ein Bit pro Kanal war die letzte Ansage, sonst halt mehrere HDMI Kanäle parallel. > Das habe ich jetzt nicht nachgerechnet, man kann aber bei 66000 kHz > Wiederholfrequenz nicht automatisch von einer Verschlusszeit von 1/66000 > s ausgehen. Wenn Du mit Deiner Kamera 8 Bilder/s machst, bleibt Dir pro > Bild auch nur eine Verschlusszeit von deutlich unter 1/8 s. > > Die Helligkeit ist und bleibt, meiner Meinung nach, das Hauptproblem. Ich wollte eine Abschätzung ob das ganze im Bereich des Möglichen ist und keine Erbsenzählerei betreiben. Ich hab da noch eine Menge anderer Annahmen drin, die nur so etwa zutreffen. Für mich ist entscheidend zu wissen geht es oder nicht? Die genauen Parameter kann sowieso nur Armin wissen, wo steckt der eigentlich? Gruß Stefan
Stefan V. schrieb: > Hi, > > Volker Schulz schrieb: >> Wie hast Du denn das errechnet?!? Selbst wenn Du die Grafikkarte zu >> 66000 Frames/s ueberreden koenntest, muessten bei genannter Aufloesung >> [...] >> > Ein Bit pro Kanal war die letzte Ansage, sonst halt mehrere HDMI Kanäle > parallel. ...und ich hielt 4-Bit schon fuer einen Kompromiss... ;) Ne, aber mal ehrlich: Der von mir gepostete Wert war ja der spezifizierte Maximalwert von HDMI-Uebertragungen allgemein, ich bezweifle dass eine PC-Grafikkarte da auch nur annaehernd herankommt. Und die Frage nach der Wiederholrate bleibt natuerlich auch noch... >> [...] >> Die Helligkeit ist und bleibt, meiner Meinung nach, das Hauptproblem. > Ich wollte eine Abschätzung ob das ganze im Bereich des Möglichen ist > und keine Erbsenzählerei betreiben. War mir klar, aber sowas muss auch in die grobe Abschaetzung schon mit rein. Ist ja keine Kleinigkeit, das kann schonmal eine Abweichung von 200% bei der benoetigten Lichtmenge ausmachen... > Für mich ist entscheidend zu > wissen geht es oder nicht? Wie ich schon schrieb, halte ich die Anzeige mit der Wiederholfrequenz theoretisch fuer machbar, das Aufzeichnen mit so vielen Frames/s wegen der zu geringen Lichtmenge jedoch eher nicht. Bin aber sehr gespannt... > Die genauen Parameter kann sowieso nur Armin > wissen, wo steckt der eigentlich? Gute Frage! LEDs in die Werkstatt schleppen? ;) Volker
mal was ganz anderes. Kann eine LED denn wirklich so kurze Emmisionszeiten? Da gibt es doch bestimmt auch Anstiegszeiten bis die ersten Photonen wirklich emitiert werden.
Hi, Volker Schulz schrieb: > ...und ich hielt 4-Bit schon fuer einen Kompromiss... ;) Ne, aber mal > ehrlich: Der von mir gepostete Wert war ja der spezifizierte Maximalwert > von HDMI-Uebertragungen allgemein, ich bezweifle dass eine > PC-Grafikkarte da auch nur annaehernd herankommt. Und die Frage nach der > Wiederholrate bleibt natuerlich auch noch... also ich weiss ja nicht was das für Werte sind die hier für HDMI rumgeistern, die allwissende Müllhalde sagt da was anderes, nämlich 8,16 GBit/s für HDMI 1.3. Schon normales HD1080p/60 Hz braucht 60Hz*8bit*3*1920*1080 = 2.985.984.000bit/s und das ohne Sync-Lücken. Die Karten müssen das können, da sie ja entsprechende Monitore ansteuern. Gruß Stefan
@ jl (Gast) >Kann eine LED denn wirklich so kurze Emmisionszeiten? 15µs? Eine Ewigkeit. 0815 LEDs schaffen locker 100ns Schaltzeit, etwas bessere auch noch Faktor 10 darunter. MFG Falk
:D nein, LEDs sind noch keine da, ist ja erstmal eine Ideensammlung. Bei mir dauert das alles immer etwas länger - deswegen auch die Prognose mit der Entwicklungszeit... Danke für die vielen Tipps noch. Wenn ich an die Cam komme, werde ich das als erstes mit der Helligkeit testen. Das wäre echt schade, wenn es daran scheitert. Allerdings hab ich ja im ersten Thread schon von "begrenztem Bauraum" gesprochen. Konkret heißt das, dass ich SMD LEDs verwenden werde und hoffentlich unter 1000cm² = 0,1m² komme. FPGA + Vorwiderstände müssten dann wohl irgendwie auf der Unterseite Platz haben - was auch schon knapp ist. Und dann das angesprochene Problem mit der Kühlung. Das scheint ein Kompromiss zu werden zwischen "Baukleine" und "Kühlung" @Pothead: mit Skalierbarkeit wollte ich sagen, dass 128 x 64 das Maximum ist. @jl soweit ich informiert bin, ist eine Schaltzeit von 1µs noch ohne Weiteres drin. Und selbst, wenn das unsauber ist, geht es für die PWM ja nur um einen Mittelwert über 15µs Das mit der Empfindlichkeit für bestimmte Wellenlängen ist auch ein interessanter Aspekt. Da ich aber das RGB jetzt noch nicht abschreiben möchte, werd ich das erstmal "nur im Hinterkopf" behalten als Plan B Speicher und Grafikkarten drüften in meinen Augen keine größeren Probleme mit der "Erzeugung dieser Datenmengen" haben. Eine Engstelle ist das Protokoll - mal sehen, ob ich am Ende bei HDMI lande. Die andere ist, wenn eine größere Datenmenge von der Festplatte in den Speicher muss. Aber mehr als 1-2sek braucht man ja nicht filmen bei dieser Framerate. Und 12GB-16GB Speicher sind heutzutage schon drin, wenn man das möchte...
Ich würde ein hybrides System bevorzugen. Der Sinn einer "echten" Darstellung besteht darin dass sie in einer harten Referenz zur Realzeit steht. Ein rein auf das Bildmaterial aufgeprägtes Overlay kann die zeitliche Linearität mit dem Orginalmaterial (die Szene) nicht gewährleisten. Die geht allerdings durch die digitale Ansteuerung der Leds auch wieder verloren ... Ich würde also ich nicht dazu übergehen das ganze Display auf diese Art einzubinden, sondern nur eine Referenz und anhand derer dann die Informationen, die urspünglich auf das Display sollten. Am günstigsten eine analoge Referenz, wie ein drehendes Schwungrad mit entsprechenden Markierungen, ergänzt evtl um ein weiteres dann durchaus digitales Display mit der Zahl der vollständigen Umdrehungen des Rades. Das kann dann auch vernünftig überblendet werden und leidet nun nicht mehr unter akummulierenden Abweichungen der Framerate vom Soll.
>>Christian T. schrieb: >> Die Wiederholrate erscheint mir auch ein wenig sehr hoch, sicher dass es >> 66kHz sein müssen? Laufen Zeitlupenkameras wirklich mit 66.000 Bildern >> pro Sekunde? oO >Dann muesse man das Filmmaterial ja - grob gerechnet - auf doppelte >Schallgeschwindigkeit bringen... ;) >Volker 44K Bilder/Sekunde werden mit 4fachprisma gemacht, So landen dann 4 mal so viele Bilder auf dem Film. Die Kamera die ich "kenne" macht 11K Bilder, mit dem Prisma werden es 44K. Allerdings hat die Kamera mehrere KW Leistung. Es reicht eine 10min Rolle (122m) [16mm-Film] fuer ein paar sekunden.
Stefan V. schrieb: > also ich weiss ja nicht was das für Werte sind die hier für HDMI > rumgeistern, die allwissende Müllhalde sagt da was anderes, nämlich 8,16 > GBit/s für HDMI 1.3. > Schon normales HD1080p/60 Hz braucht 60Hz*8bit*3*1920*1080 = > 2.985.984.000bit/s und das ohne Sync-Lücken. Leuchtet ein. Wird aber dennoch knapp. Hab gerade mal nachgegooglet: Grafikkarten mit Dual-Link kommen auf WQXGA bei 60Hz. Also knapp 5.9 GBit/s netto. Bei hoheren Frequenzen sinkt aber die Nettodatenrate ab, da ja pro Frame nicht nur reine Nuztdaten uebertragen werden. Abgesehen davon habe ich immernoch keine PC-Grafikkarte gefunden, die eine Wiederholrate von 60kHz anbietet... Auch bei solchen kleinen Aufloesungen nicht. Weiterhin ist fraglich ob man die Farbtiefe ueberhaupt zugunsten eines hoeheren Durchsatzes verringern kann... Egal wie es es drehe und wende, der PC-Idee als "einfache Loesung" kann ich nicht so viel abgewinnen... ;) Volker
Wenn das display in der schärfe liegt könnte es durchaus sein das das die LEDs auf dem kamerabild schwarz/weis werden... Ein kollege beobachtete einen solchen effekt bereits. Ich glaube es hatte etwas mit der hohen ortsfrequenz der abildung zutun und einem optischen tiefpassfilter der als aufgedampfte schicht auf dem chip vorliegt.
Also , Ich würd es mit einem anderen Ansatz Probieren, der "Kasus Knacksus" ist ja die imens hohe Aufzeichnungsgeschwindigkeit bei der Zeitlupe, ich glaube hier kommt man mit Techniken zur "aktiven Bilderzeugung" sprich LED,LCD etc. nicht weiter. Die Alternative ist eine reflektive Display-Technik zu benutzen , die das Bild nicht aktiv selbst erzeugt sondern: 1. das Umbebungslicht (die Beleuchtung)zur Wiedergabe des Inhaltes benutzt 2. nur noch Zustandänderungen müßen im Bild übertragen werden 3. geringer Stromverbrauch Stichwort ist: Qualcomm MEMS Technologie http://www.qualcomm.de/products_services/consumer_electronics/displays/mirasol/index.html nicht mehr aktive, sondern reflektive Bilderzeugung. Grüße ...
Hallo, bitte denk dran das die LEDs auch noch ein kurzes Nachleuchten haben. (Je nachdem ob Phosphor drinnen ist oder nicht.) Aber bei diesen Geschwindigkeiten gibt es eh nicht mehr viel Auswahl. Gemultiplexte Systeme sind hier zu langsam. Einer der schnellsten Treiber die ich kenne ist der AS1112: http://www.austriamicrosystems.com/AS1112 Wenn du doch eine Matrix bauen willst schau dir mal den AS1130 an: http://www.austriamicrosystems.com/AS1130 Videos: http://www.youtube.com/watch?v=saonKr4YzI0 http://www.youtube.com/watch?v=m2UdiD5M21o
Force schrieb: > Hallo, bitte denk dran das die LEDs auch noch ein kurzes Nachleuchten > haben. (Je nachdem ob Phosphor drinnen ist oder nicht.) Denk du bitte daran, daß diese Diskussion vor einem Jahr und 9 Monaten beendet wurde. Ich glaube nicht daß der TO das jetzt noch braucht :-) Trotzdem danke für die Links, vieleicht braucht ja jemand so was.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.