Forum: Mikrocontroller und Digitale Elektronik Hilfe bei Propeller Uhr

Hi,
Das Thema meiner Microkontroller Prüfung am Montag war eine Propeller
Uhr :) Daher denke ich, ich kann ich Dir ein wenig weiter helfen.
-Ich messe die Zeit einer Umdrehung, und weiter?
Also ein guter Anfang ist es mithilfe einer lichtschranke festzustellen
wann sich die LED's an einem bestimmten Punkt befinden. zb. auf 12Uhr.
Ist das der Fall giebst du die gewünshten Muster nach einer bestimmten
Zeit aus aus (je nach dem an welcher Position es erscheinen sollen)
Als Beispiel: wenn sich deine LED's mit 25 Umdrehungen pro sekunde
drehen ergiebt sich  bei einer millisekunde daraus ein Winkel von
9grad. Wenn Du also einen Zeiger anzeigen möchtest musst du den
gewünschten Winkel ausrechnen und aus der Umdrehungsgeschwindigkeit
ergiebt sich eine bestimmte Zeit nach der du die LED's einschalten
musst.
Nochmal ein Beispiel:
Ein Zeiger auf 3Uhr bedeutet 90 Grad von 12uhr aus gesehen. wenn deine
Lchtschranke also den Drchgang bei 12 uhr feststellt musst du nach 10
millisekunden die LED's einschalten.(bei einer Umdrehung von
25/sekunde)(-Ich hoffe ich habe diese werte noch richtig in erinnerung
von meiner Prüfung-habe es nicht nochmal nachgerechnet)

-Das Problem liegt darin, das mir die Drehzahl nachregelung zu ruckelig
erscheint.
Wenn Du 2 Lichtschranken einbaust musst du dich nichtmal um eine exakte
Umdrehunsgeschwindikeit bemühen und kannst sie ungeregelt lassen. Du
ermittelst einfach jede Umdrehung die drehgeschwindikeit und passt die
Zeiten für die Ausgabe dementsprechend an. Ist aber nur nötig wenn der
Motor wirklich sehr in seiner Geschwindikeit schwankt, denke ich.

Hoffe das hilft dir weiter.
Gruß!

Hallo,

soweit erstmal danke.

Mit der Drehzahlnachregelung meinte ich,
das ich, egal bei welcher Drehzahl, ein immer an der selben Stelle
stehendes Bild erzeugen will.

Das ganze soll, wie einigen schon bekannt sein sollte,
eine Rotorblattbeleuchtung für meinen Modellhelikopter werden,
und da leider mit unterschiedlichen Drehzahlen,
bzw mit Drehzahlschwankungen zu tun habe,
würde ich gerne wissen, wie man ein möglichst stillstehendes Bild
erzeugen kann.

Dazu kommt, das ich ein 120 cm Rotorkreis habe.
Diesen wollte ich mit 64 LEDs beleuchten, welche von HC595
per SPI geladen werden sollen.

Pro Umdrehung benötige ich mehr als 360 Schritte (Anzeigen),
da sonst meine äußersten LEDs keinen Punkt, sondern einen Strich
erzeugen.
Ich dachte da eher so an 600-720 Schritte pro Umdrehung.

Bei Armins Propeller Uhr ist das Problem, das ich nicht mehr als 360
Segmente hin bekomme, desweiteren zuckt und springt die Anzeige am Ende
einer Umdrehung zu viel.

Vielleicht weiß noch jemand Rat?

Ich hatte es mir so vorgestellt:

Zeit einer Umdrehung messen,
diese durch die Segmente teilen,
bei der nächsten Umdrehung alle x-tel der Umdrehungszeit
meine Leds ansteuern.

Ist das so falsch?

Armin nutzt zb. einen Spaltenzähler.
Er zählt die Spalten einer Umdrehung,...

und da hört mein Verständniss auf! leider.


Gruß Toby

Hm, hab zwar selber noch keine gebaut aber ich geb dennoch mein Senf
dazu.

Als erstes nach dem einschalten auf nen Impuls warten. Dann nen Counter
starten und auf den 2ten Impuls warten. nun hat man die Dauer einer
Umdrehung. Nun kannst du die durch "600-720" teilen. Dann wartest du
wieder auf einen Impuls und startest nen Timer der dir im erhaltenen
Intervall die ISR startet. In der gibst du per SPI die passenden Daten
aus. Im Hauptprogramm lädst du in die Register die Daten aus nem
Array.
Das Array ist "600-720"*64bit. Da steht alles drin. Du brauchst dann
immer nur die nächste Spalte holen.

Einziges Problem ist die Geschwindigkeit. Eine Umdrehung dauert ja eine
1/2000s. Wenn du nun 720 mal pro Umdrehung was Anzeigen lassen willst,
musst du also 1/((1/2000)/720) mal die ISR anspringen. Das sind
1.440.000 mal pro Sekunde. Bei 8Mhz ist das quasi jeder 6te Takt. Das
ist zu wenig. Du brauchst mehr als das doppelte die Drehzahl anzupassen
und die Daten zu holen.

Seb

@Sebastian,
ich glaube deine Rechnung stimmt nicht ganz.
Er will einen ATMega mit 16 MHz nutzen, und kann mit 8MHz SPI arbeiten.
Das SPI haut pro Takt 1 Bit raus = 8MBit/sec. 8000000 / 720 = 11.111 Bit
pro Schritt pro Sekunde. 11.111 / 64 Led pro Schritt = 173 Umdrehungen
pro Sekunde wären möglich. 173 * 60 = 10416 U/min, 10416 / 2000 = 5. Er
benötigt also pro Schritt für das SPI 1/5'tel der Rechenpower die
maximal möglich wäre. Beim letzten Posting ging es noch um 360 Schritte
und da hatten wir ja schon ausgerechnet das nur 1/10'tel der Power
nötig wären.

16MHz/720 Schritte = 22222 Takte pro Schritt pro Sekunde. 22222 / 33U/s
= 673 Takte Zeitfenster um 64Bit aus dem Speicher zu laden, ans SPI zu
übergeben und darzustellen. Von diesen 673 Takten benötigt er ca. 10*8
= 80 Takte um die SPI-ISR und das Laden der Bytes aus dem Flash
ablaufen zu lassen. Das SPI selber schiebt ja dann die 64Bit per
Hardware im Hintergrund raus. Übrig bleiben 593 Takte um nun die Daten
der Schiftregister zeitsynchron über deren Enable Leitung in die
Latches zu übertragen und anzuzeigen.

Dein Fehler liegt in der Annahme von "1/2000s", der Rotor macht aber
2000 Umdrehungen pro Minute = 33 U/s = 1/33s. 1/2000s wären aber schon
120000 U/min.

@TobyTetzi,
auch ich kann nur meinen theoretischen Senf dazu abgegeben, aber
vielleicht hilfts.

Du hast 3 quasi parallele Aufgaben in der Software:

1.) SPI füttern. Dies kann Interrupt gesteuert erfolgen.

2.) Enable Leitung der Schieberegister Zeit-exakt steuern, ebenfalls
eine Timer-ISR. Diese ISR setzt Enable der Schieberegister von High auf
Low und wieder auf High, danach füttert sie das 1. Byte der nächsten
Daten ans SPI. Die SPI-ISR wird dann interruptgesteuert die restlichen
7 Bytes nachschieben, und hätte dann noch 4/5 der zeit übrig bis zur
nächsten Timer-ISR.

3.) Synchronisation und ausrechnen der Timer-ISR Intervalle, d.h. das
Messen der Umdrehungen pro Sekunde/720. Dieser Wert sollte meiner
Meinung nach mit dem AVG berechnet werden, sprich einer
Durchschnittsberechnung. Dabei wird wiederum eine ISR benutzt, eine
Lichtschranke an INT0. Die ISR lädt den aktuellen 16Bit Timer1 Wert und
setzt TCNT1 auf 0. Timer1 hat Prescaler 16, somit hast du die MCU
Taktzyklen/16 pro Umdrehung ermittelt. Nun musst du diesen Wert zum
Durchschnittswert addieren und durch 2 teilen. Danach dividierst du den
Durchschnittswert durch 720. Dabei ergeben sich ZWEI Werte,
a.) Ganzzahlteil der Division == Takte pro Schritt
b.) Nachkommateil der Division == Korrekturwert

Angenommen 16Mhz  16 Prescaler  33.3 U/s rund 30030 Ticks pro
Umdrehung. Der 16 Bit Timer1 kann also pro Umdrehung bei 2000U/min
nicht überlaufen. Nun 30030 / 720 = 41 +510. Die 510 = 30030 - 720 * 41
sind der Korrekturwert. D.h. in den ersten 510 Schritten muß die
Synchronisationspause bis zum nächsten Schritt exakt 42 Timerticks
dauern, die restlichen 210 Schritte dürfen nur 41 Ticks synchronisiert
werden. Wir haben 510 * 42 + 210 * 41 = 30030 Ticks pro Umdrehung.
Diese Korrektur ist also ganz wichtig.

Bei dem Wert 42/41 handelt es sich nun um den TCNT0 Wert für die
Timer-ISR aus Schritt 2.) Aber die INT0 ISR muß auch noch den 1.
Schritt starten !! D.h. exakt zum Impuls der Lichtschranke wird immer
zangsweise das SPI für den 1. Schritt gestartet und TCNT0 auf 256-42
gesetzt. Der nächste Timer0-ISR in Schritt 2.) wird also den 1. Schritt
anzeigen. Sogesehen wird also die Darstellung um exakt 1/720 leicht
versetzt dargestellt. Wenn also die Lichtschranke bei 0° ist, so wird
dieser Impuls die 0.5° Zeile synchronisieren.

Leider musst du beim ATMega8 die Bitdaten der LEDs aus dem Flash laden,
da du ca. 6KByte pro Umdrehung benötigst. Ein ATMega8 könnte demzufolge
auch nur EIN Bild speichern.

Gruß Hagen

Hallo Hagen,

das hört sich alles sehr kompliziert an.

Verstehen tu ich es noch nicht ganz, werde es nochmal lesen müsssen!

Denkst Du nicht, das die SPI mit 8Mhz zu schnell ist?
Immerhin habe ich vom Mc bis zum letzten Hc ca 40cm Leitung.

Wenn der Mega nur ein Bild speichern kann, wäre es nicht möglich,
weitere Bilder in einem weiterem EEProm zu speichen, ggf. in einer
MMC Karte oder Ähnlichem?

Gruß Toby

Tatsache da hab ich wohl Minute und Sekunde verwechselt. schäm

Ich weis allerdings nicht wie du auf 6kb pro Bild kommst. Eine
Umdrehung hat doch "nur" 720 verschiedene Zustände und das bei
4*8byte Das sind rund 2,8kb oder irre ich mich da schonwieder?

Außerdem ist da noch was in der ISR. Wenn ich dem SPI ein Byte
übergebe, läuft das Programm weiter. Es sind aber 4Byte zu übergeben
und damit er das 4. reinschreiben kann müssen ja erst die anderen 3
gesendet worden sein. Also dauert die ISR doch ein wenig länger.

Zu der Geschiwndigkeit des SPI: Bei 34 Bildern pro Sekunde und 2,8kb,
sind das insgesamt 95,.. kb die rausgejagt werden müssen. Das ganze mal
8bit sind wir bei rund einem Mhz. Bei dieser Geschwindigkeit dauert aber
auch die ISR wieder länger. Die Bilder extern zu holen wird möglich
sein, aber das dürfte ganz schön eng werden.

seb

720 * 64Bit / 8 = 5760 Bytes.

8000000 Bits pro sec SPI  720  64 = 174, d.h. 174 mal in der Sekunde
kann man per SPI alle 64*720 LEDs ansteuern. Benötigt werden aber nur
33 mal in der Sekunde.

Die Schieberegister können weit weit mehr als 8Mhz.

Die ISR benötigt pro Byte ca. 5 Takte Aufruf, 2 Takte LPM, 1 Takt SPI
Output, 1 Takt SPI enablen = 9 Takte pro Byte * 8 = 72 Takte a 16Mhz =
0.5 SPI Takte werden benötigt um 1 Schritt zu füttern. Das SPI selber
benötigt dann nochmal 8*8*2 = 128 MCU Takte um die Daten im Hintergrund
rauszuschieben. Somit haben wir 128 - 72 = 56 MCU Takte gewonnen im
Vergleich zu einer Soft-Lösung.

Die MCU mit 16Mhz hat 16000000  720  33 = 673 Takte stehen pro
Schritt zur Verfügung. Das sollte also ausreichend sein um alle ISR's
für jeden Schritt abzuarbeiten. Von diesem 673 Takten benötigen wir für
das SPI nur ~9 Prozent.
In der Timer0 ISR, die ja zur Zeitgerechten Ansteuerung der Enable
Leitung der Schiftregister dient, benötigen wir 5 + 3 + 2 + 4 +x ~ 20
Takte. Diese ISR wird die Enable Leitung der Schiftregister auf Low und
gleich wieder auf High ziehen. Danach stehen in den Latches die Bitdaten
und werden durch die LEDs angezeigt. Desweiteren muß diese ISR den TCNT0
Wert updaten = x Takte für TCNT0. Desweiteren lädt diese ISR das 1. Byte
des nächsten Schrittes für das SPI und schickt es raus. Grob geschätzt
dürften pro Schritt also ca. 200 Takte ausreichend sein. Es verbleibt
eine Reserve von 473 Takten.

So, alle 720 mal fällt nun noch die Berechnung der Drehzahl an damit
die Schritt-Ticks für den Timer0 berechnet werden können.
Diese Berechnung wird ja durch die Lichtschranke in der INT0 ISR
ausgelösst. Nach Abarbeitung dieser ISR wird das SPI + Timer0
synchronisiert.

Sofort nachdem die Timer0 ISR, die die Latches der Schieberegister
gefüttert hat, kann das SPI schon den nächsten Schritt a 64Bit beginnen
zu senden.

Gruß Hagen

Hallo Hagen,

ich habe mir deine Sache mal durch den Kopf gehen lassen.

Wenn ich also 1500 U/min habe sind das ja 25 Hz.
Das macht 40 ms pro Umdrehung.

Nehmen wir mal einen Mega8L mit 8Mhz. (Mega8L, weil braucht keine
Spannungsstabilisierung, erspart mit Bauteile und Gewicht!)

Nun starte ich per Ext.Interrupt (Hall Geber) den 16 Bit Timer.
Dieser hat den Vorteiler 8, und zählt aufwärts.
Da ich bei einem Vorteiler von 8 im Sekundentakt bin (1Mhz
Zählfrequenz) kommt der zweite Ext.Interrupt (nach einer Umdrehung),
wenn der Timer einen Wert von 40000 hat.
Dann stoppe ich den Timer, lese dem Timerwert aus, und starte den Timer
mit 0 neu.
Die 40000 teile ich durch, sagen wir mal, 720 (da 720 Anzeigen pro
Umdrehung).
40000/720=55,... . Da ein Mc aber keine Kommerstelle hat, kommt also 55
dabei raus.
55*720 sind aber nur 39600, also habe ich einen Rest von 400.
Diese 400 ziehe ich von 720 ab, macht 320.
Nun könnte ich einen 8Bit Timer mit 55 us laden, und 320 Schritte mit
dieser Zeit anzeigen.
Die Restlichen 400 Schritte zeige ich mit einer Zeit von 56us etwas
an.
Ist das soweit richtig?

Wenn ja, wie teile ich eine 16Bit Zahl durch eine 16Bit Zahl?
Woher bekomme ich den Rest?

So weit so gut. was dann?

Ich lade also den 8it Timer mit 55us. und lasse die Zeit 320 mal
ablaufen.
Bei jedem Timer Überlauf schalte ich meine LEDs an.
(Ich nehme erstmal 8-16 Leds direkt am Mc.)

Nach 320 Schritten lade ich den Timer mit 56us und lasse diesen 400
mal durchlaufen.

Nun bin ich Zeitlich einmal rum, was kommt dann?

Weiteres Problem,
wenn ich außen einen Ring darstellen will, der allerdings aus einzelnen
Punkten(720 Stück) bestehen soll,
muß ich da nicht das Doppelte an Schritten nehmen?
Damit ich einen Schritt die LEDs an, den 2. Schritt die LEDs aus habe?

Sehr hilfreich wäre evtl. auch mal ein wenig Programmierhilfe!

Gruß Toby

Hi Toby,

@Timer:

Das was du schreibst ist schon fast ganz richtig. Der 16Bit Timer
sollte im Free Running Mode laufen. Der Timer selber wird
"zurückgesetzt" indem du einfach TCNT1 = 0 setzt. Du musst den Timer
also nicht jedesmal ein/ausschalten.

Du nimmst am besten eine globale Variable "uint16_t
TicksProUmdrehung". Nach jedem Umdrehungsimpuls =
Hallgeber/Lichtschranke in dessen Interrupt Routine liest du Timer1 aus
und setzt diesen sofort mit TCNT1 = 0; zurück. Den ausgelesenen Wert
addierst du auf TicksProUmdrehung drauf und teilst duch 2.

 uint16_t Timer;
 Timer = TCNT1H << 8 + TCNT1L;
 TCNT1L = 0;
 TCNT1H = 0;
 if (TicksProUmdrehung == 0) TicksProUmdrehung = Timer
   else TicksProUmdrehung = (TicksProUmdrehung + Timer) / 2;

So, nun haben wir erstmal in TicksProUmdrehung den Duchschnittswert
ermittelt.

@Division:

JEDE Division zweier Ganzzahlen = Integer dividiert Divisior / Divident
= Quotient + Rest. D.h. normalerweise wird jeder Divisionalgo. die eben
den Quotienten UND den Rest der Division ermitteln.

Somit 40000 / 720 = 55 +400.

In C muß man diese Division durch 2 Divisionen erschlagen, da eine
Funktion nur EIN Rückgabewert haben kann.

TicksProSchritt = TicksProUmdrehung / 720;
TicksRemain = TicksProUmdrehung % 720;  -> modulo
if (TicksRemain > 0) TicksProSchritt++;

oder wenn Multiplikation schneller ist

TicksRemain = TicksProUmdrehung - TicksProSchritt * 720;

In Assembler wiederum liefern dir die Divisions Funktionen beides ->
Quotient und Remainder.

Eventuell wären 512 oder 1024 Schritte "effizienter", diese lassen
sich sehr schnell dividieren durch einfache Shift-Operationen und AND
Masken.

Die ersten 400 Schritte der 720 Schritte wird mit 56 Ticks
synchronisiert, die restlichen 720 - 400 mit 55 Ticks synchronisiert.
In deinem Falle hast du also wiederum 2 globale Variablen:

uint8_t TicksProSchritt = 56;  55 + 1 da TicksRemains > 0
uint16_t TicksRemains = 400;

In der Timer0 ISR wird also TCNT0 zum Synchronisieren benutzt:

  TCNT0 = TicksProSchritt;
  if (--TicksRemains == 0) then TicksProSchritt--;


> Nach 320 Schritten lade ich den Timer mit 56us und lasse diesen
> 400 mal durchlaufen.

Ich würde es umgedreht machen ;) 400 mal 56 und 320 mal 55, so wie oben
im Codefragment.

> Bei jedem Timer Überlauf schalte ich meine LEDs an.

Nicht ganz, du schaltest das NEUE Bitmuster das per SPI in die
Schieberegister gelangt ist per Strobe Leitung der Schieberegister in
deren Latches durch. D.h. das Bitmuster ist zum Zeitpunt der Timer0 ISR
schon längst draußen, aber eben noch NICHT sichtbar. Nach dem obigen
Timer0 Code muß nun noch folgendes stehen.

  PORT = PORT ^ (1 << SHIFT_STROBE_PIN);
  PORT = PORT ^ (1 << SHIFT_STROBE_PIN);

Wir toggeln also das Pin an dem du die Enable-Leitung der Shiftregister
angeschlossen hast von LOW -> HIGH -> LOW. Danach leuchten die LEDs im
entsprechendem Muster.

Wir du siehst in der Timer0 ISR passiert nicht viel, pro Schritt nur
ganz wenige Taktzyklen.

>wenn ich außen einen Ring darstellen will, der allerdings aus
> einzelnen Punkten(720 Stück) bestehen soll,
> muß ich da nicht das Doppelte an Schritten nehmen?

Nicht unbedingt. Dieses Feature, also das Dunkelschalten der LEDs
kannst du auch über die Shiftregister erschlagen. Die von dir gewählten
Typen erlauben einen 3-State. Die LEDs leuchten in diesem State nicht.
Die Dunkelschaltung sollte ja nur minimal pro Schritt sein, also würde
ich erstmal obige Timer-ISR so umbauen das sie ein paar feste
Taktzyklen zwischen

  PORT = PORT ^ (1 << SHIFT_~OE);
--> hier
  PORT = PORT ^ (1 << SHIFT_~OE);

wartet und die Shiftregister auf 3-State schaltet. Über die ~OE Leitung
wird ja im Falle eines H-Pegels die Ausgänge auf Z gesetzt, siehe
Datenblatt.
Oder aber du schaltest nach dem Senden der Bitdaten über das SPI dieses
~OE Pin entssprechend. Da ja das SPI pro Schritt immer mit der gleichen
Geschwindigkeit arbeitet, bleibt dies synchron. In diesem Moment würden
die LEDs nur so lange leuchten wie es von der Timer0 ISR bis zur letzten
SPI ISR = 8 Byte dauert, der Rest der Zeit bis zu nächsten Timer0 ISR
bleiben die LEDs dunkel. D.h. beim letzen SPI Byte wird ~OE auf HIGH
gesetzt. In der Timer0 ISR nach dem STROBE wir ~OE auf LOW gesetzt.
Damit beginnt das neue Bitmuster zu leuchten.
Erst wenn alles läuft kannste dann die Timer0 ISR erweitern, so daß sie
eben x * 720 Schritte aufgerufen wird. Nur in jedem X'ten Schritt
schaltet sie das neue Bitmuster durch, im X-y'ten Schritt schaltet sie
den ~OE Pin. Somit hättest du dann eine variable Leuchtdauer von
y/X'tel Schritten. In diesem Falle benötigst du dann:

  uint8_t TicksProSchritt_On;
  uint8_t TicksProSchritt_Off;

  TicksProSchritt_On + TickProSchritt_Off = TicksProSchritt;


Auf alle Fälle bringen dir die Shiftregister einiges an Vorteile, auf
sie verzichten würde ich an deiner Stelle nicht.
Aber, du weist ja das ich meine das die 74HC595 viel zu wenige Strom
pro LED erlauben, ~6mA nur.

@Sourcen ???
Tja, dies dürfte wohl deine Aufgabe sein ;) Nichts für ungut, aber ich
baue und brauche das Ding nicht, und kann dir somit nur theoretisch
helfen. Ich sage ja auch nicht das meine Ideen tatsächlich auch
praktisch funktionieren !! Das wäre ja vermessen da ich sowas selber
noch nie praktisch gebaut habe ;)

@Hall-Sensor:
Kann der so kurze und schnelle Zeiten einhalten ?? Bei einer
Lichtschranke dürfte das wohl klar sein, aber ein Hall-Sensor hat doch
bestimmt einige Verzögerungen ??

Gruß Hagen

Hallo Hagen,

alles klar, und auch wieder nicht!

Was meinst du mit

-Du nimmst am besten eine globale Variable "uint16_t
-TicksProUmdrehung". Nach jedem Umdrehungsimpuls =
-Hallgeber/Lichtschranke in dessen Interrupt Routine liest du Timer1
-aus
-und setzt diesen sofort mit TCNT1 = 0; zurück. Den ausgelesenen Wert
-addierst du auf TicksProUmdrehung drauf und teilst duch 2.

???
Auf welchen wert addiere ich den Timerwert?

Der Timer Wert ist doch auch schon so groß, das ich fast 2 register
voll habe!

Versteh ich nicht.
Wie groß ist TicksProUmdrehung ?
Woher kommt dieser wert?

Gruß Toby

Hmmm,

ales eingeschlafen?!

Gruß Toby

Hi Toby,

tja, wie Guido schon sagte scheint obige Idee nicht zu funktionieren.
Warum ist mir auch nocht nicht so ganz klar. In deinem Falle mit den
wohl nötigen Schankungen in den Drehzahlen wird's dann wohl nicht
gehen. Leider habe ich eben noch keine Propelleruhr gebaut und dies
scheint wohl ein gravierendes Manko zu sein.

Gruß Hagen

kann mir bitte jemand einen Tipp geben zum mechanischen Aufbau ?
wie kommt die Stromversorgung oder eventuell steuersignale
von aussen auf den Propeller ?

Danke & Gruß,
Martin

Hallo,

hier wird einiges zur Stromversorgung Diskutiert.

http://www.mikrocontroller.net/forum/read-1-245003.html

Mit der Suche, zwischen "Threadliste" und "Neuer Beitrag" findest
Du noch einiges zum Thema Propeller-Clock etc.

Grüße

Quark

Mal eine andere Frage

Man sagt ja dass man 24 Einzelbilder pro Sekunde braucht um ein
sauberes Bild zu sehen.

Das würde 24u/s * 60s = 1440 u/min bedeuten.

Würde das nicht bedeuten dass man bei 1200 und ein paar Zerquetschte
ein flackerndes Bild erhalten würde?

Da ich aber nur mit Modellautos mit 3,5ccm Motoren arbeite kann ich
nicht sagen welche Drehzahlen ein Hubschrauber hat.

Soviel ich weis arbeiten die 3,5ccm Motoren alle weit jenseits der
10000 U/min
(Meißtens im Bereich von 30000 bis 40000 U/min)
Ob dass aber mit dem Darstellen so einfach wird weis ich nicht.

30000u/min = 500 u/s => alle 1/500s = 0,002s eine Umdrehung

mfg Sepp

Hallo,

ich habe mittlerweile, nun ja, das Projekt ist bei mir selber
"eingeschlafen",
eine Flugfertige Version gehabt.
Leider ist die Stromversorgung etwas schwierig.
Ich hatte mittig auf dem Rotorkopf ein 4Zellen 120mAh Akku montiert.
Eine weitere Idee war eine Luftspule, um damit den Strom zu
übertragen.
leider war es zu störend.

Bilder des Helis und der Blätter sind auf TobyTetzi.de zu sehen.
Der Heli ist allerdings nicht mehr vorhanden, da der Akku wohl doch
so schwer war, das ein Umlenkhebel aufgrund der höheren Belastung
gebrochen ist.
Seit dem ruht das Projekt.

Gruß Toby