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
...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...
@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.
@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.
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.
@ 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 ....
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!
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 ...
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.
