Hallo, ich habe mich nun ein wenig it dem Thema Propeller Uhr beschäftigt. Könnte mir vielleich mal jemand den allgemeinen Programmablauf erklären? Ich messe die Zeit einer Umdrehung, und weiter? Teile ich diese Zeit in Segmente, oder wie? Irgendwie komme ich nicht weiter. Bin über jede Hilfe dankbar. Ach, um es vorweg zu nehmen, das Programm von Armin verstehe ich nicht so ganz. Habe damit zwar schon experimentiert, aber verstehen tu ich es nicht. Das Problem liegt darin, das mir die Drehzahl nachregelung zu ruckelig erscheint. Gruß Toby
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
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
@ Topy > -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? Auf den Wert der vorhergehenden Umdrehung. Schnapp Dir einfach mal Papier ud Bleistift und probiers aus. Sagen wir mal Deine Umdrehungszahen sind 1200 1205 1202 1207 1203 1209 ... dann errechnet das vorgeschlagene Verfahren folgendes: 1200 <- den Wert hatte TicksProUmdrehung schon vorher weil der Rotor ja schon eine Weile gelaufen ist ( 1200 + 1205 ) / 2 = 1202 ( 1202 + 1202 ) / 2 = 1202 ( 1202 + 1207 ) / 2 = 1204 ( 1204 + 1203 ) / 2 = 1203 ( 1203 + 1209 ) / 2 = 1206 der Sinn der Sache ist also, dass Umdrehungsschwankungen etwas ausgemittelt werden. Ob das was bringt oder nicht, musst Du einfach ausprobieren. Dein Rotor wechselt die Drehzahl ja schliesslich auch nicht ruckartig, sondern ...
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
Bei einem Hubschrauber hast Du eine Untersetzung. Auch wenn der Motor mit 7000/8000/9000 U/min dreht, dreht der Rotor mit irgendwas zwischen 1200 - 1600 U/min. (je nach persoenlicher Vorliebe des Piloten) Zudem wird in einem Heli viel Energie darauf verlegt, dass die Rotor-Drehzahl moeglichst konstant bleibt. Auch bei Lastwechsel. Die 24 Bilder/s brauchst nur dann, wenn Du eine Animation ablaufen lassen willst und kein Ruckeln mehr erkennbar sein soll.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.