www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik sehr schnell sehr viele LEDs ansteuern


Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian T. (shuzz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: gastlich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und auch nicht zu vergessen... wie hoch ist ein Budget?

Autor: Karlheinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... max. 66kHz ...

Hilf mir bitte auf die Sprünge. Wozu muß man 66 000 Bilder pro Sekunde 
"sehen" können?

Autor: David ... (volatile)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die andere Sache ist, dass man dafuer so krass beleuchten muss, dass man 
da garnicht mehr drauf klar kommt :P

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wozu muß man 66 000 Bilder pro Sekunde
>"sehen" können?

Lesen ist von Vorteil... steht alles da!

Autor: Markus M. (adrock)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: Karlheinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus M. (adrock)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
10eur bitte =)

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/p...

Ist zwar schon etwas angestaubt, aber mit 559 Pins kann man eine ganze 
Menge machen - wenn man day Layout hinbekommt.

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 =)

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wie oft müssen denn die Daten auf dem Display geupdated werden?

sagt mal, kann hier niemand mehr lesen???

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag

also ich denke mal das du mit Spartan 3 FPGAs schon genügend weit kommen 
kannst (modularbauweise vorausgesetzt).

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian T. (shuzz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Matthias Keller (mkeller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karlheinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... die Wetten auf Nichtverwirklichung des Projekts setzen ...

Muß ich mal wieder überlesen haben. Mit der Bitte um Nachsicht - wo 
steht das?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: hae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Overclocker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: hae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Overclocker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hae:

Schon mal die Zeitlupe in einem Crash-Test gesehen?

Autor: hae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja auf einem normalen Fernseher, evtl mit 660-facher zeitlupe :-)

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 
;-)

Autor: hae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch mein Reden...

Autor: eberhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: hae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh Danke, jetzt habe ich verstanden!
Schon eine spezielle Anwendung!
Ich habe das wohl nicht richtig gelesen, sorry!

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: golem23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da ist die LED längst verdampft. ;-)

Wäre jedenfalls auch mal ne schöne Zeitlupenaufnahme XD

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Shuzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: eberhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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.

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pothead,
> 4.) Die Matrix direkt vom FPGA ansteuern.
Was für eine Matrix?

Gruß Stefan

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: jl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Armin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
: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...

Autor: Tim Seidel (maxxie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Torsten W. (wirehead)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Stalter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_...

nicht mehr aktive, sondern reflektive Bilderzeugung.

Grüße ...

Autor: Force (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "AS1119 - The 144ch dot matrix LED driver demoboard by austriamicrosystems"
Youtube-Video "AS1119 Movie board.WMV"

Autor: Udo Schmitt (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.