LED Stroboskop - animierte Bilder wirken unscharf

[PhoeBee (Gast)]

Liebes Forum,

Zum Betrachten einer animierten Bildschallplatte (Zoetrope-Picture-LP) 
habe ich mir verschiedene batteriebetriebene LED "Stroboskope" gebaut, 
die mit einer Rate von 25 "Blitzen" pro Sekunde (später auch 30 und 18 
Blitze pro Sekunde) ansteuerbar sein sollten, damit ich die Animation 
flüssig betrachten kann.

Zuerst habe ich einen Bausatz für ein Batteriebetriebenes (9V) LED 
Stroboskop, dessen Blinkrate stufenlos regelbar ist, zusammengelötet.
(siehe Bild im Anhang)

Parallel dazu habe ich mit einem Microcontroller (ATmega328V in meinem 
LilyPad) verschiedene "Blink" Programme (Arduino) geladen und zunächst 
mit einer, dann mit mehreren LED getestet.

Bei allen Versuchen war das Ergebnis immer gleich: Zwar kriege ich die 
"Blitzrate" des Stroboskops so genau eingestellt, dass ich die Animation 
"stehend", also mit der korrekten Blinkrate anschaun kann, aber das Bild 
ist IMMER verschwommen. Und das unabhängig davon, ob ich eine oder 
mehrere LED im Versuch verwendet habe.

Auf die Idee, mir selbst ein Stroboskop zu bauen, kam ich über folgenden 
Link:
http://tapebox.co.uk/2011/11/14/toucylabled/

Deswegen denke ich, dass es grundsätzlich möglich sein muss, sowas 
hinzukriegen. Nun frage ich mich, was ich falsch mache. Brauche ich 
besondere LED dafür oder sind die Arduino "Blink" Programme ungeeignet? 
Bin schon seit Tagen auf der Suche nach Threads, die dieses Thema 
behandeln, aber irgendwie komme ich nicht weiter.

Über Tipps, wo ich nach einer Lösung suchen kann, würde ich mich freuen.

[Mike (Gast)]

PhoeBee schrieb:
> aber das Bild ist IMMER verschwommen
In der Photographie nennt man das Bewegungsunschärfe.
Deine einzelnen Lichtblitze sind zu lang, um die Bewegung ausreichend 
einzufrieren. Reduziere versuchsweise mal die Blitzdauer.

[Sean G. (atmega318)]

Gut möglich, dass es an dem Arduino liegt. (Arduino != kurze Pulse) D.h. 
wenn du die Pulse nicht kürzer machen kannst, ersetze digital write 
durch Pin-set Makro.

[12V DC (Gast)]

Eventuell ist das Arduino auch einfach zu langsam, was ich mir aber 
nicht wirklich vorstellen kann.

PhoeBee schrieb:
> aber das Bild
> ist IMMER verschwommen.

Das doch schon mal etwas.

[Sean G. (atmega318)]

Naja, entweder Arduino zu langsam, oder zu langes Delay, oder z.B. 
Kapazitäten im Treiber. Also:
-1 Led an pin (mit R logischerweise)
-Delay tiefer (falls vorhanden)
Wenn das nicht hilft, dann Makro...

[Sven (Gast)]

Oder Du baust das ohne µC mit variabler Beleuchtungsdauer:
http://www.drehkino.de/drehkino_v2_de.php

[PhoeBee (Gast)]

vielen Dank für die schnellen Antworten!

Klingt logisch - genau wie beim Fotografieren: zu lange Belichtungszeit 
gibt verwackelte Bilder.

Ich kann die Parameter im "Blink" Programm für ATmega328 so verändern, 
dass die "Blitze" kürzer sind, aber dann muss ich auch die Delay-Zeiten 
zwischen den Blitzen kürzer machen. Also die Delay-Werte für "an" (high) 
müssen (laut Anweisung) immer dieselben sein wie für "aus" (low). 
Folglich wird bei kürzeren Blitzen automatisch die Blitzrate höher und 
dann passt es nicht mehr zur Bildrate der Animation.

Ich hatte gehofft, ich würde ein Arduino Programm finden, das ich 
einfach modifizieren kann, aber da muss ich wohl doch mehr programmieren 
üben ;-)

Jedenfalls weiss ich jetzt, wo der Knackpunkt ist. Daumen drücken und 
los. Ich berichte dann.

drehkino ist natürlich auch super ...

[stefanus (Gast)]

Mit delays bekommst Du sowieso kein Exaktes Timing hin. Früher oder 
später werden Verzögerungen auftreten, die Du nicht bewusst programmiert 
hast, und dann wird's unscharf oder unsynchron.

Ich würde dazu einen PWM Timer benutzen.

[Peter II (Gast)]

stefanus schrieb:
> Mit delays bekommst Du sowieso kein Exaktes Timing hin. Früher oder
> später werden Verzögerungen auftreten, die Du nicht bewusst programmiert
> hast, und dann wird's unscharf oder unsynchron.
>
> Ich würde dazu einen PWM Timer benutzen.

er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht 
möglich.

Ich würde eine Timer für die Periode nutzen und dann mit einen delay 
arbeiten.

Es kommt nun auf das Programm an, eine nicht schöne aber einfache lösung 
ist das delay in die ISR vom Timer schreiben. (ist ja noch ein sehr 
kleines Delay)

[X2 (Gast)]

Peter II schrieb:
> er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht
> möglich.

Also ich kenne die Atmel µCs nicht, aber es wird doch wohl möglich sein 
das Tastverhältnis einer PWM einzustellen. Oder meinst du mit On/Off 
Zeiten was anderes?

[Peter II (Gast)]

X2 schrieb:
> Peter II schrieb:
>> er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht
>> möglich.
>
> Also ich kenne die Atmel µCs nicht, aber es wird doch wohl möglich sein
> das Tastverhältnis einer PWM einzustellen. Oder meinst du mit On/Off
> Zeiten was anderes?

Das hilft für diese Aufgabe aber nicht weiter.

Er muss ja aller X ms eine LED für eine kurze Zeit einschalten. Wobei es 
möglichst wenig Abweichung Jitter für den Startpunkt geben darf.

Also muss man mit einem Timer den Startzeitpunkt festlegen. Und dann 
dort kurz die LED einschalten. Man könnte es mit dem 2. Compare machen. 
Aber ich denke da bekommt man Probleme beim On zu Off Verhältnis.

[PhoeBee (Gast)]

WOW! habe jetzt einfach allem zum trotz die Werte der Delays für 
"HIGH"(1) und "LOW"(40) (Stromzufuhr zur LED im Arduino Programm 
"Blink") deutlich unterschiedlich definiert. In meinem Buch stand, diese 
Werte dürften nicht voneinander abweichen ... (?)

Jedenfalls, die Animation funktioniert jetzt um längen besser - das ist 
SUPER!

Wie präzise das Timing dieses Setups ist, kann ich natürlich nicht 
sagen.  Muss erstmal was Größeres mit mehreren LEDs zusammenlöten, damit 
es heller wird. Und ein wenig kann ich auch noch an der Geschwindigkeit 
des Schallplattenspielers drehen.

aber ich bin doch schon mal einen großen Schritt weiter.

dank!

[Chris S. (schris)]

sowas:

unsigned signed long nextTime = 0; // last time update
long interval = 2000; 
#if 1 // 1=ms, 0=us
#define currTime (signed long)millis()
#else
#define currTime (signed long)micros()
#endif

void setup(){
nextTime=currTime+interval;
}

void loop(){
  if(((signed long)(currTime-nextTime))<0) continue;
 
    // do something
 
  if((lastTime+interval)<lastTime) while(currTime>lastTime);
  lastTime+=interval;
}

[Rolf Magnus (Gast)]

Peter II schrieb:
> X2 schrieb:
>> Peter II schrieb:
>>> er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht
>>> möglich.
>>
>> Also ich kenne die Atmel µCs nicht, aber es wird doch wohl möglich sein
>> das Tastverhältnis einer PWM einzustellen. Oder meinst du mit On/Off
>> Zeiten was anderes?
>
> Das hilft für diese Aufgabe aber nicht weiter.
>
> Er muss ja aller X ms eine LED für eine kurze Zeit einschalten. Wobei es
> möglichst wenig Abweichung Jitter für den Startpunkt geben darf.

Weniger Jitter als mit einem PWM-Timer wird man nicht hinbekommen.

> Also muss man mit einem Timer den Startzeitpunkt festlegen. Und dann
> dort kurz die LED einschalten. Man könnte es mit dem 2. Compare machen.
> Aber ich denke da bekommt man Probleme beim On zu Off Verhältnis.

Du brauchst halt einen Timer, dessen TOP-Wert man verstellen kann. Dann 
kannst du problemlos PWM-Frequenz und Pulsdauer getrennt von einander 
einstellen. Das ist jitterfrei, und mit einem 16-Bit-Timer mit Prescaler 
1 und einem Prozessortakt von 1 Mhz geht das für Raten von bis runter zu 
ca. 15 Blitzen pro Sekunde taktzyklengenau.

[Axel R. (Gast)]

http://www.youtube.com/watch?v=3-rPn0a56WE

[c-hater (Gast)]

Peter II schrieb:

> er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht
> möglich.

So ein Blödsinn. Die Änderung des Tastverhältnisses ist sogar die 
Hauptanwendung für PWM. Deswegen geht das immer problemlos.

Was u.U. etwas problematisch ist, ist die Änderung der Zykluszeit, in 
diesem Fall also der Stroboskopfrequenz.

[Peter II (Gast)]

c-hater schrieb:
> Peter II schrieb:
>
>> er will aber die On und Off zeit beeinflussen, mit PWM ist das nicht
>> möglich.
>
> So ein Blödsinn. Die Änderung des Tastverhältnisses ist sogar die
> Hauptanwendung für PWM. Deswegen geht das immer problemlos.

er muss aber die PWM Frequenz anpassen und nicht nur das 
Tastverhältnisses.

[stefanus (Gast)]

> er muss aber die PWM Frequenz anpassen

Das ist bei AVR auch gar kein Problem, nämlich über den TOP Wert und ggf 
zusätzlich den Clock-Prescaler.

[Peter II (Gast)]

stefanus schrieb:
>> er muss aber die PWM Frequenz anpassen
>
> Das ist bei AVR auch gar kein Problem, nämlich über den TOP Wert und ggf
> zusätzlich den Clock-Prescaler.

das ist mir klar. Aber je nach TOP-Wert hat man nur noch eine kleiner 
Auflösung für das An-Aus Verhältnis.

Bei Top=2 schafft man es kaum ein AN zu AUS von 1:10 zu erreichen.

[Conny G. (conny_g)]

Peter II schrieb:
> stefanus schrieb:
>>> er muss aber die PWM Frequenz anpassen
>>
>> Das ist bei AVR auch gar kein Problem, nämlich über den TOP Wert und ggf
>> zusätzlich den Clock-Prescaler.
>
> das ist mir klar. Aber je nach TOP-Wert hat man nur noch eine kleiner
> Auflösung für das An-Aus Verhältnis.
>
> Bei Top=2 schafft man es kaum ein AN zu AUS von 1:10 zu erreichen.

Dann nächste Stufe Prescaler.

[Moritz A. (moritz_a)]

Peter II schrieb:
> das ist mir klar. Aber je nach TOP-Wert hat man nur noch eine kleiner
> Auflösung für das An-Aus Verhältnis.
>
> Bei Top=2 schafft man es kaum ein AN zu AUS von 1:10 zu erreichen.

Bei einem geforderten Minimum von 18Hz sind das 55,555…ms pro 
PWM-Zyklus, somit bei einem Prescaler von 8 und 16bit-Counter 1MHz 
respektive 1µs Auflösung.

Damit sind es bei einem Top von 0xD904 55.556ms pro Zyklus, das sollte 
wohl mehr als reichen. Das ganze muss natürlich noch in an- und 
auszeiten geteilt werden.

Einziges "Problem" ist eventuell die minimale Abweichung von 0.04%, da 
muss im Zweifelsfall der Plattenspieler irgendwie auf die Blitze 
synchronisiert werden.

Moritz

[Rolf Magnus (Gast)]

Peter II schrieb:
> Aber je nach TOP-Wert hat man nur noch eine kleiner Auflösung für das An-
> Aus Verhältnis.
>
> Bei Top=2 schafft man es kaum ein AN zu AUS von 1:10 zu erreichen.

Der wird hier aber überhaupt nicht gebraucht. Im Ursprungsposting war 
die Rede von:

PhoeBee schrieb:
> 25 "Blitzen" pro Sekunde (später auch 30 und 18 Blitze pro Sekunde)

Da muß man den Timer schon enorm langsam takten, daß er bei TOP=2 nur 25 
mal pro Sekunde überläuft. Warum sollte man das denn machen? Bei 1 Mhz 
Timer-Takt stelle ich TOP=40000 ein und bekomme damit 25 Überläufe pro 
Sekunde. Ich kann dann die Pulsdauer immer noch mit einer Schrittweite 
von 1 µs einstellen. Wenn diese Auflösung für den Anwendungsfall nicht 
reicht, weiß ich auch nicht...

[Peter II (Gast)]

Rolf Magnus schrieb:
> Peter II schrieb:
>> Aber je nach TOP-Wert hat man nur noch eine kleiner Auflösung für das An-
>> Aus Verhältnis.
>>
>> Bei Top=2 schafft man es kaum ein AN zu AUS von 1:10 zu erreichen.
>
> Der wird hier aber überhaupt nicht gebraucht. Im Ursprungsposting war
> die Rede von:
>
> PhoeBee schrieb:
>> 25 "Blitzen" pro Sekunde (später auch 30 und 18 Blitze pro Sekunde)

ok, das hatte ich schon wieder vergessen. Ich dachte er will es sehr 
"frei" einstellen können.

[Sean G. (atmega318)]

PhoeBee schrieb:
> In meinem Buch stand, diese
> Werte dürften nicht voneinander abweichen ... (?)
Kannst du den Ausschnitt mal posten? Weil entweder du hast da was falsch 
verstanden (Zusammenhang...) oder Arduino geht endgültig zu weit.
Nimmt mich irgendwie schon wunder.

[PhoeBee (Gast)]

Sean Goff schrieb:
> Kannst du den Ausschnitt mal posten? Weil entweder du hast da was falsch
> verstanden (Zusammenhang...)

die Passage im Buch hatte ich definitiv falsch verstanden. Es bezog sich 
auf ein konkretes Projekt mit dem LilyPad und sagte sowas wie: "probier 
es aus, aber ändere beide Delay Zeiten immer auf denselben Wert ... " 
das machte im Zusammenhang Sinn. Ich hatte es irrigerweise so 
interpretiert, dass es nur auf diese Weise funktioniert ... also: 
Arduino kann nichts dafür ;-)