Announcement: there is an English version of this forum on Hallo, ich stelle euch hier die Bauanleitungen für ein Rotor-Display rein. Ich hoffe, es gefällt euch und finde ein paar Nachbauer :) * 2 gegenüberliegende Anzeigepanels mit je 9 Leuchtdioden * Anzeige mit 200 x 18 Pixeln * "Interlaced"-Anzeige * Durch PWM mehrere Rotstufen möglich: Aus, dunkel, heller, an * Umdrehungsgeschwindigkeit einstellbar * Elektrische Energieübertragung zum Rotorkopf über (Eisen-)Kernlosen Trafo * Drahtlose Datenübertragung mit > 115200 kbits/s * Standardbauteile, (fast) alle bei Reichelt Elektronik zu beziehen * Grafische PC-Benutzeroberfläche in Java * Text- und Bildmodus * Scriptmodus, dadurch z.B. Laufschrift und Animationen möglich * Bildwiederholrate > 10 Bilder/s * Einfacher 12V-Gleichstrommotor * Stromversorgung: 12..13,8V * RS232-Schnittstelle * 3 AVRs Mega8 http://storage.kuldisch.de/rotordisplay/rotordisplay-current.zip Viel Spass! Fragen und Kommentare sind erwünscht! Stefan
Schönes Projekt ! Wie hast du das mit der PWM gemacht ? Das Display dreht sich doch weiter, da würde man eine PWM als Punkte/Strifenmuste sehen.
Ja, man sieht auch in der Tat Punkte/ Streifen, wenn man ganz nah ran geht. Aber aus einer Entfernung von 5-10 cm stört das nicht mehr. Treibt aber die Prozessorlast auch derbe nach oben :)
Du hast die LEDs direkt am AVR angeschlossen, richtig ? Wenn du deren MASSE bzw. VCC über einen MOSFET angeschlossen hättest dann wäre das PWM Problem einfacher zu lösen, vorausgesetzt man kann eine sehr schnelle PWM bewerkstelligen. Gruß hagen
Hallo Hagen, so ganz verstehe ich nicht wie du das meinst. Kannst du das mal genauer erklären?
Also alle LEDs gehen nach GND über einen N-Mosfet und nach VCC steuert sie der AVR an. (mal ohne Treiber und in parallel betrachtet). so lange der MOSFET durchgeschaltet ist, zb. bei Dauerbetrieb ergäbe sich die volle Helligkeit der LEDs. Wenn du nun den MOSFET per PWM mit sehr hoher Frequenz betreibst, also so hoch das es kein Flimmern mehr gibt, dann kannst du damit das komplette Display in der Helligkeit dimmen. Die Ansteuerung der LEDs bleibt dabei so wie sie jetzt schon ist, also vom Timing her gesehen. Du kannst das auch umdrehen falls der AVR eher den LED Strom sinken statt sourcen soll. Dann wird ein P-Mosfet benutzt. Angenommen dein Display hat 256 Spalten und dreht sich mit 1200U/min = 20U/sec dann dauert die Leuchtphase einer Spalte also 195µs = 5128Hz. Wenn du nun den N-Mosfet mit einer PWM von sagen wir mal 82Khz ansteuerst dann hättest du 16 Helligkeitsstufen. Aber dann muß diese PWM auch synchron zum Multiplexing der LED Spalten sein, das wäre das beste. Letzendlich kommst du auf das gleiche raus als wenn du die LEDs per AVR in Zeitrastern a 16 Schritte pro Spalte ansteuern würdest. Allerdings wird das eben mehr Rechenpower benötigen als die PWM Methode mit dem MOSFET, der kann nämlich in der AVR-Hardware von selber laufen ohne Software. In diesem Beispiel reduzierst du die Last für den AVR in Sofwtare auf 1/16'tel. Gruß Hagen
Jo natürlich nur das, aber das ist es ja was er nachfragte. Wichtig ist eben das man so den Aufwand in Software reduzieren kann, teilweise beträchtlich. Aus Sicht einer LED wäre die gesammte Ansteuerung eine hardware PWM modulierte Software PWM ;) Gruß Hagen
Hallo Hagen, die Idee ist gut, allerdings hätte man nur eine globale Dimmung des Displays. Die Idee finde ich aber gut. Also so eine Art UND-Verknüpfung zwischen PWM-Generator und dem AVR. Problem ist aber nur, dass man wirklich nur die Helligkeit global verändern kann. Ein weiteres Problem, was ich vorher nicht wusste, ist dass das die empfundene Helligkeit nichts mit dem PWM-Verhältnis zu tun hat. Man sieht kaum einen Unterschied zwischen einem Tastverhältnis von 50% zu 100%. Die dunkelste Graustufe hat nur 10% Tastverhältnis, obwohl es nur 2 Graustufen gibt. Überhaupt ist ein AVR für so eine Aufgabe nicht soo gut geeignet. Ein programmierbarer Logikbaustein mit Speicher könnte hier einfacher und schneller zum Ziel führen.
Ja, ein FPGA mit einer Highspeed PWM wäre nett (so 100-500kHz PWM Frequenz sollte eigentlich nicht als PWM zu erkennen sein). Ich hatte schonmal darüber nachgedacht, ein 512x64xRGBx8bit Display zu bauen. Momentan läuft ein 512x64 Display mit blauen 0603 SMD LEDs. Sieht nett aus, aber leider ist nichts dimmbar, da das ganze per Schieberegister angesteuert wird.
Man könnte auch ein SRAM nehmen, dessen Ausgänge die LEDs steuern. Manche SRAMs haben auch recht kräftige Ausgänge, sodass man die LEDs eventuell direkt dranhängen könnte. In das SRAM füllt man einfach die LED-Daten, inklusive PWM. Das hört sich nach Speicherverschwendung an (ist es irgendwie auch), ist aber halb so wild. Bei 256 Spalten mit 8 Bit PWM braucht man 2^16 Byte platz, also gerade mal 64kB. Der Adresszählertakt muss dann bei 20U/s mit 65536*20 rund 1.3MHz laufen. Problematischer wird da das Einspielen der Daten, denn so schnell wird der AVR die Daten nicht liefern können (sonst könnte er sie ja on-the-fly berechnen). Wenn man kein Dual Port RAM hat, dann müsste man wahrscheinlich die Anzeige ein paar Umdrehungen "aussetzen" lassen. Vorteilhaft ist, dass man quasi zur Laufzeit entscheiden kann ob man eine niedrigere Auflösung und mehr Helligkeitsstufen oder umgekehrt haben will. Und mit 3 SRAMs ist der Aufwand nicht viel höher, da der Rest fast gleich bleibt und man hat Full-Color. mfg Wiesi
Nachdem ich jetzt so ein Teil gebaut habe, sind mir noch tausende Möglichkeiten eingefallen, wie man das hätte besser machen können. Also besser geht immer, aber der Aufwand ist mir einfach zu groß. Ich habe auf dem rotierenden Teil der Anzeige zwei AVRs. Einer ist sozusagen der Anzeige-AVR. Er nimmt ein Bitmap entgegen und zeigt es an. So ist die Übertragung dann nicht mehr zeitkritisch. Der andere AVR empfängt die Daten aus der Spule und leitet sie dann seriell an den Anzeigechip. Ziemlich stolz/zufrieden bin ich echt mit der Spulenübertragung, weil die echt einiges an Strom liefert und sich keine Übetragungsfehler leistet. Allerdings glaube ich dass die Technologie für den Heimgebrauch mit 60kHz Frequenz zur Datenübertragung schon am oberen Ende angekommen ist. Für ein leistungsfähiges Farbdisplay bräuchte man schnellere Datenübertagungsraten, damit die Chose Spass macht. Dazu würde ich die Energie wie bisher über einen Trafo übertragen, die Daten allerdings optisch. Ich stelle mir dazu eine Rotornabe aus Plexiglas vor, die mittig mit einer Fotodiode/Transistor versehen ist. Vom stehenden Teil wird dann die Plexiglasnabe von einer oder mehreren Infrarot-LEDs angeleuchtet. Das ganze könnte man bei entsprechender mechanischer Konstruktion auch resistent gegen Fremdlicht machen. Dann das ganze ans UART anschließen und fertig ist die fies schnelle drahtlose Datenübertragung... Also falls jemand vorhat so ein Display neu zu entwerfen, einfach mal fragen, ich habe bestimmt ein paar Tipps wie man es machen/nicht machen sollte ;)
auch von mir erstmal : respekt !! schön realisiert. aber sicherlich auch teuer oder ? (bei den ganzen platinen, und vor allem RUND ....)
Ich würde garnicht mit PWM arbeiten, also für ein fettes RGB Display. 1.) als Treiber kommen einstellbare Konstanstrom-Shiftregister in Frage die über einen RExt Widerstand im Strom justierbar sind 2.) die Farbkanäle werden durch separate Shiftregister-Kaskaden angesteuert 3.) Decodierung der Farbpixel-Datenbytes erfolgt durch MUX'e. Angenommen wir möchten 15 Bit Farbtiefe, also jeweils 5 Bits für Rot,Grün,Blau. Pro Pixelspalte im Display müssen wir diese in 5 Zeitscheiben unterteilen. Ein 512 Spalten Display hat also 512*5 reale Spalten. Betrachtet man mal ein solches RGB-Pixel-Word Bit/Pin 01234-56789-abcde-f Farbe rrrrr-ggggg-bbbbb-x Zeitscheibe 01234-01234-01234 Die Bits 0 bis 4 sind Rotbits, 5-9 Grün und a-f also Blau, Bit f ist frei. Wir legen diese 16 Bit Word an einen 16 Bit Port, oder eben 2x 8Bit beim AVR (der aber wohl die falsche Wahl ist). Darunter die Zeitscheibe innerhalb einer komplette Multiplexphase zu einer Pixelspalte. Durch geschickte Programmierung des DDR Register können wir drei 5 zu 1 MUX'e aufbauen. Die Pins 0 bis 4 werden extern zusammengeschaltet und gehen auf den Dateneingang der Rot-Shiftregister-Kaskade, die Pins 5-9 ebenfalls zusammengeschaltet und gehen auf Grün-Shiftregister-Eingang, Pin a-e das Gleiche für Blau. In Zeitscheibe 0 wäre also vom Port Pin 0,5,a auf Ausgang alle anderen auf Eingang. Schreiben wir in den Port einen 16 Bit Pixel so werden nur die Bits 0,5,a als Datenbits in die Shift-Register geschoben. Eben drei 5 zu 1 Multiplexer per PORT+DDR. Man gibt nun zb. 64 Pixel einer Zeile auf diese Weise pro Zeitscheibe aus. Bei jeder Zeitscheibe rotiert man das DDR weiter, und das 5 mal, dann hat man eine Pixelspalte im Display fertig dargestellt. Nun kommt der Trick. Die RExt Widerstände für die Shiftregister sind einstellbar. In Zeitscheibe 0, also Bit 0 der RGB Daten, werden sie so eingestellt das sie 5mA an die LEDs abgegeben. In Zeitscheibe 1 auf 10mA, dann 20mA, dann 40mA, und 80mA. Wenn man diese Stromwerte anderst wählt so kann man die LED Helligkeitsreglung auch leicht logarithmisch anpassen. Mit 5 Bits für jeweils RGB kommt man so auf 2^15 darstellbare Farben hat aber nur ein Multipexingfaktor von 5 mal höher als zu einem monochromen Display, ganz ohne PWM. Die Dekodierung der Pixelwörter ist auch sehr einfach und ohne extra Hardware zu machen. Wichtig ist dabei aber das die Stromregelung innerhalb der Shiftregister sehr schnell einpegeln muß. Das müsste man nochmal in deren Datenblättern nachlesen. Solche Shiftregister gibts schon einige. Die Gesamthelligkeitsreglung, der Fabkontrast usw. ließe sich über entsprechend Widerstandwerte an den RExt der Register machen. Also auch das gesammte Display ließe sich einfach mit wenig Hardware einstellen. Das einzigste Problem bei dieser Methode ist das Layout. Denn zb. für 64 RGB LEDs würden wir 3 * 4 a 16 Bit Shiftregister benötigen und an jede der RGB LEDs kommen Leitungen von jeweils 3 dieser Register. Also schon ein ziemlicher Layoutaufwand. Gruß Hagen
ich muss sagen, Stefan, du hast die Sache mit der Datenübertragung und Spannungsversorgung (Motor und Elektronik) genial gelöst.
Hallo Stefan, das ist echt eine geiles Projekt. Könntest du mal kurz die Funkrionsweise von der Energieübertragung und der drahtlosen Datenübertragung zum Rotorkopf erlklären. Ich habe das Ganze folgendermaßen verstanden: die äußere Spule ist fest, die innere Spule dreht sich mit dem Rotorkopf. Die Energie- und Datenübertragung wird durch die Basisplatine initiiert und über die Spule übertragen. Stimmt alles soweit? Gruß Sascha
Hallo Sascha, ja, das ist soweit richtig. Ich pole die feststehende Spule über die H-Brücke immer um. Je nachdem, ob ich jetzt eine Null oder eine Eins senden will, ändere ich die Zeit bis zum nächsten Umpolen. Dann kann ich eine Eins senden (kurzer Impuls) oder eine Null (langer Impuls). Die Datenübertragung initiiere ich mit einem Startbit, wie bei seriell. Außerdem habe ich noch ein 9. Nutzbit, mit dem ich zum Beispiel "Display Reset" senden kann. Obwohl ich noch ein Byte bei der Übertragung hinzufüge, ist das Nadelöhr immer noch die Verbindung PC-Rotordisplay über RS232. @Hagen: Ich habe mir deine Ausführungen durchgelesen, und zumindest zur Hälfte durchschaut. Das Problem ist denke ich auch der ernorme Hardwareaufwand. Deshalb denke ich dass man mit programmierbarer Logik und PWM besser dran ist. Also wenn das "Programm" für jede LED getrennt abläuft, ist das ja kein Problem. Auch bei PWM könnte man natürlich die Kennlinie anpassen. Eine Frage die bei richtig großen Displays (egal ob PWM oder nicht) bleibt ist die Versorgung mit Saft und Daten. Meiner Meinung nach war der Aufwand für die Katz' wenn man nur mit 2-3 FPS pro Sekunde rumdümpeln muss. Also, meiner Meinung nach muss man schon ne Animation flüssig darstellen können (was ich mit meinen 10 FPS halt auch noch nicht kann). Und rechnen wir mal alles zusammen kommmt man auf 512 Zeilen * 32 LEDs 15 Bit 25 FPS = 768kByte/s. Also da kommt man schon in einen Bereich, wo man sich ernsthaft Gedanken machen muss, wie man die Daten überträgt. Und, 32 LEDs 3-Farb-LEDs ziehen auch stromtechnisch was weg. (Das soll jetzt nicht heißen, dass ich es für nicht machbar oder schlecht halte, sondern nur dass man solchen Aspekten auch Beachtung schenken muss!) Grüße Stefan
@Stefan: Es gibt eigentlich nur ein Problem mit der Methode aus meinem Posting: Durch den geänderten Konstantstrom verändert sich die spektrale Farbe der LEDs. Das ist der einzigste Nachteil gegenüber der PWM Methode. Ansonsten nimmt man ja fertige Konstantstrom Shiftregister, die gibt es auch mit 12 Bit PWM pro LED Kanal. Damit reduziert sich der Aufwand wirklich auf die Bitschieberei übers SPI und das geht meistens mit bis zu 20Mhz. Vom Stromverbrauch her wird man am Ende effektiv bei jeder Methode das gleiche benötigen vorausgesetzt die abgestrahlte Energie ist auch gleich. Je höher die Displayauflösung wird, also Farbanzahl und Dimension, desto schlechter wird eine reine PWM Lösung werden. Denn wir müssen mit immer schnelleren PWMs und Multiplexing arbeiten. Aber LEDs haben eine rel. große Kapazität die hohe Impulsströme benötigt um die LEDs sauber ansteuern zu können und die zusätzlich beim Umschalten immer größere Leckströme beim Umschalten im Multiplexing fließen lässt. Gerade letzteres führt zu einem ungewollten Nachleuchten der vorherig eingeschalteten LEDs mit dem neuen Pixelmuster, Geistereffekt. Lies ma das http://focus.ti.com/analog/docs/techdocsabstract.tsp?familyId=480&abstractName=slva271a durch, TLC5924 Gruß Hagen
Hallo Hagen, von solchen Phänomenen wusste ich nichts, man sollte das ganze mal in der Praxis testen, ob es wirklich was ausmacht. Bist du in realen Planungen für so ein Display oder sind das eher nur grundsätzliche Überlegungen? Stefan
Ja ich hatte vor mal so ein Teil zu bauen aber bisher scheitert es an der Zeit und am nötigen Layout. Bisher habe ich schon so einiges zusammengetragen, zb. Power/Datenübertragung per Induktor mit bis zu 256KHz ist schon fertig simuliert, Die spule arbeitet wie ein Induktor eines Stepup Wandlers, Ferromagnetische Kopplung und auf Sekundärseite die "Hochspannung" mit Pseudo-StepDown wieder runter. Die Spulen liegen also nicht ineinander sondern übereinander in ferromagnetischen Halbschalen. Die LED Treiber habe ich schon getestet, eine Schaltung für die RExt Anschlüsse ist ausklabustert und so einige Timing Überlegungen für die Software. Motor würde ein CD-ROM Motor sein da diese einen Unwuchtsausgleich enthalten, Brushless. Rotorpositon wird per Hallsensor erfasst. Ich werde aber mit diesem Projekt solange warten bis ich mich mit ARM7 oder AVR32 befasse, da es wenig Sinn macht einen AVR für so "große" Displays zu benutzen. Bei hoher Farb- Displayauflösung möchte man ja auch bessere Animationen etc.pp. darstellen und nicht nur einen Font und par Schriftzeichen. Ich gehe dabei davon aus das die "Hauptintelligenz" des Displaycontrollers auf dem Rotor sitzt und nicht auf der Hauptplatine die per Datenübertragung dann die Rotorplatine steuert. CPLDs oder FPGAs kannste vergessen, viel zu kompliziert, und viel zu Stromhungrig. Falls ich das jemals bauen werde dann mit den TLC5924 Shiftregistern. Eine besondere Idee dabei wäre es die LEDs nicht nach aussen sondern nach innen zeigen zu lassen, Kugelform vorausgesetzt. Gruß Hagen
>von solchen Phänomenen wusste ich nichts, man sollte das ganze mal in >der Praxis testen, ob es wirklich was ausmacht. Naja, wenn TI extra eine spezielle Hardware fertigt um sowas zu umgehen, dann denke ich kann man sich auf deren Experten verlassen. Also gäbe es den Effekt nicht oder wäre er vernachlässigenbar dann gäbe es also den TLC5924 nicht. Die Stromlast, also die Kapazität beim schnellen Schalten von LEDs kann man einfach simulieren und ist bei höheren PWMs fakt. Je schneller man muliplexen muß desto höher werden die nötigen Impulsströme um die LEDs sauber zum leuchten zu bringen. Die nötigen PWM-Pulszeiten kann man sich ja selber ausrechnen, das geht schnell in den ns-Bereich, wenn man Farbhelligkeiten haben möchte. Gruß Hagen
Besteht denn theoretisch die Möglichkeit, durch die Rotations-Bewegung ausgenutzt ein dreidimensionales Objekt darzustellen (evtl. andere Anordnung der LED "Zeile", z.B. diagonal) ?????
@Wegstabenverbuchsler: Das geht, damit bin ich auch gerade beschäftigt (Zumindest zwischendurch, wenn ich gerade etwas Zeit habe). Das ist dann eine Matrix aus 8 x 8 LEDs, angesteuert von einem ATmega16. Funktioniert eigentlich nicht schlecht, allerdings sieht es nicht so toll aus, da die LEDs nur nach vorne leuchten. Ich hatte mir schon überlegt, zwei LEDs in die entgegengesetzte Richtung dranzubauen, aber dann muss ich sie entweder parallel schalten oder der Aufbau wird relativ kompliziert (Habe alles "fliegend" aufgebaut, also 8 Kupferdrähte mit jeweils 8 SMD-LEDs dran, die anderen Pins sind mit Lackdraht angeschlossen).
Hallo Hagen, schau Dir mal den MBI5031an, der kann 12 Bit PWM mit Scrambling ... aber nur 25 MHz statt den 30 von TI .. nur/und der ist (als smd) auch lieferbar ;-) Ich hab "sowas" damit gemacht und bin bei ca. 300 us zur Datenübertragung für 16 RGB-Leds mit 3 MBIs und einem 16 MH Atmega leider an der Grenze .. bei ca. 1,8m LEDS auf einem "Propeller", der sich mit ca. 400 U/min dreht .... @Stefan - alle Achtung super gelöst! Wieviel Strom ist wohl über die Induktion möglich zu übertragen? MfG Vajk
Hallo Vajk, in dieser Konfiguration kann ich ca. 1,5-2A übertragen. Die Spule ist wirklich überdimensioniert, weil ich eigentlich nur ca. 400mA maximal brauche. Nach oben hin sehe ich da eigentlich kaum Grenzen, wenn man die Spule entsprechend dimensioniert. Damals hatte ich das alles rein experimentell bestimmt, heute würde ich das bestimmt besser auslegen können. Aber auch für große Displays sehe ich keine Probleme Energie auf diese Weise heranzuschaffen. Stefan
Hallo, muss auch mal ein Lob loswerden: Die Energie- und Datenübertragung ist echt super gelöst. Ich arbeite gerade an einem ähnlichen Projekt für die Fahrradspeichen. (72 SMD RGB LEDs) Und ich kann euch zustimmen, dass es echt eine Menge Daten sind! Realisiert habe ich das ganze wie Hagen Re schon vorgeschlagen hat mit Konstantstromtreibern, was auch soweit recht gut funktioniert, allerdings habe ich 4 ATmega8 verbauen müssen um die Datenmengen speichern zu können und auch wegen der SPI Übertragungsgeschwindigkeit schnell genug zu sein. Verbaut habe ich den MAX6957, den ich aber nicht wirklich weiter empfehlen kann. An Strom brauche ich übrigens bis zu 4,3A was aber durch mitdrehenden Akkupack kein Problem sein sollte Gruß Kai
Hallo Stefan, mir gefällt deine Java- Software sehr gut, ich wollte fragen ob du vielleicht den SourceCode offenlegen würdest. Ich bin mir durchaus bewusst , dass dort sehr viel arbeit hintersteckt. Aber mich würde einfach interessieren wie du bestimmte Sachen gelöst hast um daraus lernen zu können. Gruß André
Hallo André, ich kann die RotorDisplay-Software gerne offenlegen. Ich habe die Software hauptsächlich in 2005 entwickelt und vieles würde ich heute natürlich anders machen. Das war damals mein erstes größeres Projekt und ich habe viel dabei gelernt. Es wird allerdings noch ein paar Tage dauern da ich im Moment leider viel zu tun habe. Ich werde dann einen Link zur Software hier im Thread posten. Viele Grüße, Uwe
@Dietrich - Verzeihung die Propelleruhr ist zwar gut gelungen, aber ganz und garnicht mit dem Projekt von Stefan vergleichbar. Deinen Kommentar empfinde ich als off Topic.
Vajk Von ipolyi wrote: > @Dietrich - Verzeihung die Propelleruhr ist zwar gut gelungen, aber ganz > und garnicht mit dem Projekt von Stefan vergleichbar. Deinen Kommentar > empfinde ich als off Topic. Wenn dem so ist: OK. Ich bitte um Entschuldigung und habe meinen betroffenen Beitrag soeben gelöscht. Ich lausche gespannt weiter auf die Beiträge zum rotierenden Display, welches auch mich sehr interessiert. Weiter so! Gruß Dietrich
So, hier kann man nun den Source Code der Java-Anwendung zum Steuern des RotorDisplays runterladen: http://www.uweschmidt.org/software/rotordisplay/ Viele Grüße, Uwe
Wiesi wrote: > Man könnte auch ein SRAM nehmen, dessen Ausgänge die LEDs steuern. > Manche SRAMs haben auch recht kräftige Ausgänge, sodass man die LEDs > eventuell direkt dranhängen könnte. Uh, das wird aber immer seltener. Naja, ein paar SMD FETs oder integr. Treiber sollten das ganze nicht wirklich größer machen. > > ... > Problematischer wird da das Einspielen der Daten, denn so schnell wird > der AVR die Daten nicht liefern können (sonst könnte er sie ja > on-the-fly berechnen). Wenn man kein Dual Port RAM hat, dann müsste man > wahrscheinlich die Anzeige ein paar Umdrehungen "aussetzen" lassen. Da sehe ich kein Problem. Wenn man 64kB einbaut, kann man auch 128kB einbauen und im Hintergrund aktualisieren. Oder, da man kaum bezahlbares DP-RAM bekommt, kann man auch zwei 64kB RAMs nehmen und eines auf die Anzeige und das jeweils andere an den AVR schalten zum beschreiben. Dann Umschalten. So gibt es keine Aussetzer und keine Zeicheneffekte. Das erinnert an Apple ][ oder CBM Zeiten.... Die Verwendung von zwei RAMs hat auch den Vorteil, dass das Layout symmetrisch ist, damit also ausgewuchtet. Gruß, Ulrich
Angehängte Dateien:
-
index_01.jpg
210 KB
Hallo Kai, sehr nette Sache, die Du da machst. Mal eine Frage an alle: Ich würde gerne meine einfarbige Version auch zu RGB umwandeln. Also, für alle "Falschversteher" neu entwickeln. Wie geht man denn nun am Besten vor? Vorraussetzung ist, das ich gerne kaskadierbare LED Module zu je 8 RGB LEDs haben würde. 1. Man könnte füe je 8 RGB LEDs 3 Schieberegister hintereinander schalten. Das erste für Rot, das zweite für grün, das dritte für blau. Vorteil, man bleibt bei 5 Leitungen für Eingang und Ausganz je Modul. Nachteil, will man nur rot darstellen, müsste man auch grün und blau mit "nichts" ansteuern. 2. Man könnte die Schieberegister für jede Farbe einzeln mit einem SPI Bus versehen. Also, rot-rot-rot, grün-grün-grün, blau,blau,blau Vorteil, jede Farbe einzeln steuerbar. Nachteil, 2 weitere CS Leitungen notwendig. 3. für je 8 RGB LEDs einen eigenen Prozessor (ATmega16), diese dann per UART verbinden, falls das geht, um die Daten für jedes 8 LED Modul zu übertragen. Was meint ihr, wie könnte man so ein RGB Projekt relativ einfach lösen? Mein größtes Problem ist halt der Platz, und die unterschiedlichen Blattlängen, bzw, LED Anzahlen bei den Helikoptern. Anliegend noch mal ein Bild meines derzeitiges einfarbiges System mit 32 LEDs pro Rotorblatt. Gruß Toby
Hallo zusammen Hab hier auch noch ein älteres Projekt aus meiner Sammlun das auf seine Fertigstellung wartet. Sollte ursprünglich in Rotorblätter für einen RC-Heli eingeharzt werden. Dein beitrag hat mich wieder wachgerüttelt. Die PWM Idee hatte ich auch schon verfolgt aber auf grund der hohen Drehzahl von ca. 2000 U/min am Rotorkopf bekomme ich logischerweise auch nur Striche. Hier noch die URL vom damaligen Eintrag. Beitrag "Das passiert wenn..." Rotor-Clock ist eifach immerwieder faszinierend. Werde die dinger nun doch endlich mal fertig bauen. Danke für die Anregung und weiter so. Habe als Anhang noch ein kleines Video beigepackt. Muss das Video auf 2-mal schicken war zu groß. Hier also der erste Teil. Gruß Jens
Hallo Jens, oder besser Danny?! Nun ja, sehr weit bist Du ja bis lang nicht gekommen. Immerhin gibt es deine Platine wohl doch, und drehend sieht man diese nun auch. Das sollte einiges Misstrauen, welches in deinem Beitrag entstanden ist, zu Dir beseitigen. Zum Einbau in Blätter kann ich nur sagen, teuer teuer! Ich habe mir je 2 Formen für 470er und 600er bauen lassen, aus denen nun die ersten Serienreifen Blätter gebaut werden. Formen und Blätter kommen von einem deutschen Blatthersteller. In die 470er Blätter kommen 32, ind die 600er komen 48 LEDs. Leider habe ich nur eine einfarbige Version, versuche aber auch eine RGB Version zu fertigen. Ich bevorzuge allerdings eine Modul-Bauweise, um mit der LED Anzahl variabel zu sein, um verschiedene Blattlängen bestücken zu können. Falls Interesse an einer Gemeinschaftsarbeit oder so besteht, kannst dich ja mal melden. Gruß Toby
Hallo Toby Kooperationsintresse besteht allemal. Hast du schon Erfahrung im Platinen einlaminieren??? Ein guter Bekannter von mir stellt Hauptberuflich Blades her. Er meint das das kein grösseres Problem sei. Die Blaätter sind aber höchstwarscheinlich nicht voll 3D tauglich (haarrisse auf Platine durch Torsion und so...) Hast du schon Erfahrungen diesbezüglich. Mein Layout ist auch längenveränderlich. Hab die Länge auf meinen Raptor 50 ausgelegt. Zu "teuer teuer" kann ich nur sagen das das Projekt nur an Materialkostern bis heute schon über 1/2 k€ verschlungen hat (für einen Satz). Was ich sagen will ist ---> Die Dinger müssen nu unbedingt mal fliegen lernen. Gruß Jens
Hallo Jens, ich habe 4 Sätze Prtotypen gebaut. Einen 325er (Holz) mit 24 LEDs, flog schon auf Messen in Friedrichshafen, Leipzig, Indoorgala und im Melle, Landesbergen,.... Der Satzt hat bereits etliche Flüge hinter sich. Einen 470er Satz, modifizierte CFK Blätter mt 32 LEDs. Einen Satz 600er mit 16 Leds und einen mit 48 LEDs beide in Holz. Bis lang sind keine Auffälligkeiten bezüglich Ausfällen bekannt. Ich schlage vor, du meldest dich mal per E-Mail, denn das folgende ist etwas Offtopic. Gruß TobyTetzi at t-online.de
Ach Jens, Danny, wie auch immer,... ;-) Schau dir das mal an: http://www.nightgraphix.net/assets/multimedia/NGX-1-big.wmv Gruß Toby
Guten Abend Ich bin auch gerade dabei, mir ein Rotor Display zu bauen. Ich wollte 50 RGB SMD LEDs verwenden und diese mit den Schieberegistern "AS1110" von Austria microsystems ansteuern. Als Steuereinheit will ich einen AVR nehmen. Den Strom wollte ich per einfachen Schleifkontackten in den Kopf übertragen. Dort sitzt dann der Haupt AVR und sendet seine daten zu den Treibern, die auf der LED Platine auf dem Ausleger sitzen. So habe ich unter 10 Pole(dank Bus), die vom AVR zum Ausleger gehen müssen, Stromversorgung mit eingeschlossen. Die Schieberegister stelle man mit einem externen Widerstand ein. Ich wollte eine recht hohe Drehzahl nehmen und dann die LEDs nicht bei jeder Umdrehung aufleuchten lassen. So kann man ja die LEDs ja "dimmen". Ich wollte einen Schrittmotor verwenden, da dieser ja eine Stabile Drehzahl hat. Wenn die 64kB Speicher auf dem AVR nicht für Animationen reichen, wollte ich einen externen Flashspeicher mit ein paar MB an den Bus anschließen. Als Datenübertragung zum PC wollte ich einfach einen SPI Stecker auf das Board machen, sodass der AVR dann per PC programmiert wird und dann unabhängig vom PC läuft. Viele Grüße Tobias
Hallo Tobias! Zugegeben, das synchronisieren auf eine Drehzahl ist ein wenig Aufwand, aber ich fürchte, dass Du mit Schrittmotoren wenig Glück haben wirst. Denn diese Motoren haben ihre Stärken in der Positionierung, also Genauigkeit und Kraft eine Position anzufahren, leider unter massiven Einbußen an Geschwindigkeit. Ich fürchte, das wird damit nix. Außerdem stelle ich es mir problematisch vor Schleifkontakte und hohe Drehzahl unter einen Hut zu bekommen. Das geht nicht ohne Verluste. Hier ist die magnetische Kopplung aus den oberen Bauvorschlägen doch besser geeignet. Aber bevor man alles auf einmal anders macht, als man es sich vorgestellt hat, starte ruhig mal mit Schleifkontakten und dann kann man das Schritt für Schritt erweitern / verbessern. Gruß, Ulrich
Was für Motoren empfehlen sich denn? Und wie soll man es denn sonst machen außer auf eine Drehzahl synchronisieren? Gruß Tobias
Es eignen sich alle Motoren, nur eben nicht Stepper. Es gibt sehr viele unterschiedliche Motoren, alle haben ihre Vor- und Nachteile. Die kleinen handelsüblichen Motoren haben durch ihre Schleifer und die 'schnelle' Umschaltung der Kollektoren ein recht hohes Laufgeräusch. Dafür legt man lediglich eine Spannung an und kann sie so sogar ganz gut regeln. Allerdings machen sich Vibrationen recht leicht auf dem Rotordisplay sichtbar, weil es Wellenlinien erzeugt. Bürstenlose Motoren, wie die aus den modernen Lüftern, sind nur mit einem Chip zum Laufen zu bewegen. Da gibt es allerdings welche mit Drehzahl Steuerung oder / und Tachosignal. Das Problem ist aber das Layout und die Wicklung der Spulen und passende Magneten für den Rotor Teil. Da ist es dann einfacher einen Lüfter zu nehmen und alles weg zu schnippeln, was man nicht benötigt. Ich habe jedenfalls noch keinen Bürstenlosen ohne Ansteuerung gefunden, was aber nichts heißen will, weil ich noch nie danach gesucht habe. Naja, man kann nicht nur auf einen Motor synchronisieren, sondern natürlich auch erst mal den Motor auf einer Solldrehzahl halten. Man benutzt z.B. eine PWM Stufe eines ATmegas zur Steuerung des Motors und einen Counter-Eingang für die Erfassung der realen Drehzahl. Das kann man mit einem Optosensor machen bei einem Kollektor-Motor, oder mit der Tacholeitung eines Bürstenlosen. Mit dieser Regelung kann man das Teil optimal beschleunigen, damit der Vorzeigeeffekt auch nicht zu lange auf sich warten läßt. Es gibt aber auch noch andere Optionen mit konventioneller Technik was zu machen. So kann man einen Kollektormotor über einen Riemenantrieb den Rotor antreiben lassen, so filtert man mechanisch die Vibrationen raus. Außerdem hat man nun mechanoisch Platz unter der Rotormitte. Dort kann nun eine Spule zur Energieübertragung für die Anzeige und, via Modulation, die Daten übertragen werden. Aber das hatten wir doch schon weiter oben.
Ic hab jetzt nicht alles durchgelesen aber bei meiner Uhr löse ich das Drehzahlproblem so: Ich messe per Input Capture die umdrehungszeit und teile diese durch die anzahl der spalten (Idealerweise ne 2er Potenz). Diese Zeit kann man dann als reload-wert für nen CTC Timer nehmen, der die Daten rausschreibt. Man sollte jedoch 16 Bit timer für CTC und Input Capture nehmen, da man sonst die auflösungsschritte auf dem Display sehen kann (Die anzeige verschiebt sich je nach drehzahl um einen pixel) Der Einzige Atmel der diese vorraussetzungen hat ist glaub ich der mega162, zumindest hab ich mir den für die nächste version rausgepickt.
Die Varianten mit Zeitmessung für eine Umdrehung und Veränderen eines Spaltentimers hatte ich auch versucht ... das Regelverhalten fand ich durch Rundungsfehler als sehr unschön. Es geht einfacher und effektiver. Also löste ich das ohne Rundungsfehler - voraussetzung ist ein natürlich wie immer ein Referenzpunkt via Hallsensor, Lichtschranke oder sonstwie ... Voraussetzung ist natürlich die Spaltenanzahl ist immer die selbe oder zumindest bekannt, Ich rechne mir also einmal aus, welche Zeit eine Spalte (für eine Solldrehzahl) haben sollte (nehme das als Startwert) und passe einen crc-Timer so an, daß er einen weiten Regelbereich zur Verfügung hat für Drehzahländerungen ... Ich zähle dann die Spalten einer Umdrehung ab dem Referenzpunkt und korrigiere nur durch ++ / -- den Zähler, falls der Vorgabewert nicht erreicht wird (ggf auch ein += 10 / -= 10 oder andere Schrittweiten). Somit gibt es keine Rundungsfehler, nur ein Timer notwendig und einen, ich finde, schönen Fächereffekt beim Hochfahren der Drehzahl .. (... ggf. kann man den Teiler des Timer noch Umschalten) Hierbei hab ich z.B. einen Regelbereich ab 60 U/min bis über 600 U/min Viel Spaß beim Probieren... Vajk
Kannst du da einen Codeschnipsel anbieten? Wo kommt da der Timer zum Einsatz? Mit was und wie vergleichst du den Timer um zu entscheiden ob + oder -? Gruß, Simon
> Kannst du da einen Codeschnipsel anbieten? muss ich erst zusammenstellen ... ist aber ganz einfach :-) > Wo kommt da der Timer zum Einsatz? Nun .. ich gehe davon aus, daß Du folgendes kennst, weil Du das Ding ja baust: 1. "Breite" einer Spalte Unter Breite verstehe ich die hier die Zeitdauer der Spalte Und unter Spalte verstehe ich das Kreissegment ... also die LED-Reihe 2. Die gewünschte Umdrehungsgeschwindigkeit daraus läßt sich die Spaltenzeitbreite errechnen > Mit was und wie vergleichst du den Timer Ich stelle den Timer auf eine Spaltenbreite ein, die er bei der Normdrehzahl haben muß, damit eben eine Spalte rauskommt ... > um zu entscheiden ob + oder -? Na und dann zähle ich die Anzahl der Spalten (also pro Timerinterrupt ein spacnt++). beim nächsten Int des Hallsensors vergleiche ich den Spaltenzähler spacnt mit der Anzahl der Spalten, die ich haben will ... .. ich hatte damals 408 Spalten gewählt, weil ich einen Zeichensatz von 16 LEDs x 12 verwendet habe .. so kommen 34 Zeichen raus. Und es läßt sich durch 8 teilen .. besser als die 360° eines Kreises. Überschreitet der Zähler also die 408 so muß der verlängert werden und umgekehrt ... wobei die Schrittweiten der Änderung eben anpaßbar sind ... je nach gewünschten Regelbreich abhängig der Drehzahl ... Idee verstanden ?
Hallo, ich habe es mal so gemacht. Leider dauerte mir das nachregeln viel zu lange. Schön an dieser Variane war das "einrasten" des Bildes, wenn die richtige Spaltenzahl erreicht wurde. Gruß Toby
Die Regelung mache ich in Stufen, d.h. ich verwende 10er Schritte, wenn die Differenz über 10 ist, 20er Schritte, wenn Differenz über 20 ist ... usw. das beschleunigt den Regelvorgang natürlich. Hatte ich bei der Erklärung oben weggelassen. @Toby, hast Du das auch gemacht ... .. bei kleinen Drehzahlschwankungen find ich die Regelung schneller, als die Doppel-Timer-Variante. Das System muß natülich auf den Drehzahlbereich angepaßt sein, d.h. erst mal eine Runde rechnen, welche Werte optimal sind ...
Hallo Vajk, ich habe mit der Art der Regelung nicht weiter gemacht. Könnte mir aber denken, es nochmal zu testen. Poste doch mal deine schrittweise Abstufung bitte, oder noch mehr?! Gruß Toby
Anbei wesentlicher Code zum Verständnis ... .. ich hoffe ihr kommt klar ...
Doch, die mittlere Lichstärke hängt direkt mit der PWM zusammen, allerdings sind die Augen nicht linear... daher siehst du zwischen 50% und 100% keinen großen Unterschied. Gruß von Andy
Hallo, weil ich denke dass die Spulenübertragung eine interessante Technik für ähnliche Projekte ist, habe ich eine Simulation der Energie- und Datenübertagung in Simulink geschrieben und hochgeladen. Ich hoffe, ihr benutzt es. Ich freue mich auf Kommentare und Anregungen :) Grüße Stefan
Hallo! Wirklich eine bemerkenswerte Leistung dieses Gerät. Es erfordert ja nicht nur die geschickte Kombination aus Elektronikwissen, sondern auch eine Menge an handwerklichem Geschick. Mit deinem Aufbau, den Schaltplänen, den Quellcodes und der Simulation in der Hinterhand werde ich mich bestimmt nochmal an das Projekt heran trauen. Vorausgesetzt die vorlesungs- UND klausurfreie Zeit fällt lang aus und ich habe in der Zeit keine Freundin ;-) Die halten einen doch nur von solchen Sachen ab... Mich würde jedoch noch interessieren, wo du die ganzen mechanischen Teile herbekommen hast. Die elektronischen zu beschaffen ist kein Thema- kann ich über meine Uni abwickeln, jedoch wo bekommt man gut und günstig diese Plexiglasrohre (sind doch welche, oder?), dann lagerst du scheinbar alles auf Gummi, damit es nicht vibriert. Bekommt man das alles im Baumarkt oder hattest du da spezielle Quellen? Auch der Motor. Über gehabt oder neu? Was sollten so die Kenndaten sein? Aber ich glaube beim Motor probiere ich es einfach mal aus. Was mich bei dieser Diskussion über die max. Framerate hier wundert ist, dass noch niemand auf die Idee kam, das die Bitrate, die ihr berechnet die unkodierte ist. Bei einer Datenübertragung wird zumeist vorher eine Kodierung durchgeführt, damit der Kanal nicht zu stark belastet wird. Ich möchte mal ein paar Anregungen geben, die die Möglichkeiten von RGB-Displays vielleicht wieder ein wenig näher rücken: Nehmen wir als Grundlage ein Display mit 64 (also 2x32) LEDS und 512 Spalten. Wir wollen volles RGB, das macht 64*512*3 Byte. Das sind 96kB für ein Vollbild. Ich schlage eine einfache Idee vor: Die Reduktion des Bildes auf 256 dynamisch gewählte Farben (vielleicht sogar noch weniger), eine sog. Farbpalette, sieht bei dem Aufbau mit Sicherheit niemand. Schließlich sind die LEDs nicht so genau wie TFT Displays. Man legt also eine Farbpalette mit 256 Farben an. Zu jeder Farbe gibt es in dieser Tabelle einen Wert für das Tastverhältnis für R, einen für G, einen für B. Die Tabelle ist also nur 768 Byte groß. Diese Tabelle kann von der "Bodenstation" geändert werden. So kann man sich die Farben, die das nächste Bild oder die nächste Sequenz benötigt aussuchen. Das Vollbild hat nun eine Größe von 32kB statt 96kB. Also eine "Komprimierung" von 1:3. Reduziert man die Farbpalette noch mehr, dann ist noch mehr rauszuholen. Hinzu kommt der Pluspunkt dieser Lösung: Es ist eine reine Softwarelösung. Man kann sie jederzeit nachrüsten, auch mit einem 8-bit AVR sollte das drin sein. Auch ein "Ausblenden" des Bildes ist jetzt super einfach möglich: Man ändert dazu einfach die Werte der Farbtabelle langsam nach null und das Bild verschwindet. So kann man es auch einblenden oder auf andere Farben blenden oder die Farben verzerren. Schwieriger wird es dann schon, wenn man weiter komprimieren will. Da wird ein 8-Bit Controller nicht mehr ausreichen, aber belehrt mich ruhig eines besseren. Man überträgt bei einem Video nun nur noch zu Anfang des selbigen einen Vollframe. Alles weitere wird dann als Deltawert übertragen. Mit ein paar weiteren Befehlen wie z.B. scrollen des Displays in eine der vier oder acht Richtungen, läßt sich hier massiv an Daten einsparen. Man könnte gleichzeitig auch mal überlegen, ob andere Codierverfahren z.B. ein Huffman-Code, hier einen Vorteil bringen können. Letztlich gibt es noch eine sehr schöne Variante. Ihr alle kennt sicher den PING-Standard. Das sind diese kleinen Bilder mit der Endung png. Die können beliebig viele Farben verlustlos speichern und sogar Transparenz und noch eine ganze Menge mehr. Das Format ist so umfangreich, das selbst ein gewisser Browser aus dem Hause Microsoft dieses bis heute nicht vollständig versteht (nachdem er lange brauchte es überhaupt darzustellen). Da dieses Format sehr umfangreich ist unterteilten es die Entwicker in drei Teile. Der unterste Teil beschreibt Features, die ein System mit wenig Hardwareresourcen trotzdem erfüllen sollte. Der Vorteil ist, das dieses Format frei ist. Es steht unter der GPL. Aber das PING-Format ist eigentlich weniger interessant. Interessanter ist das MING-Format (Endung mng), welches quasi das selbe wie PING ist bloß mit Animationsmöglichkeiten. Die Dateien, die da raus kommen sind wirklich klein. Da sollten selbst 25 Frames/s drin sein. Da die meisten Devices nur 20U/s haben sollte es eigentlich dicke reichen. Man müsste natürlich auf einen 32-bit Prozessor umsteigen und viel Zeit in die Portierung der libmng investieren. Aber möglich wäre es. Vielleicht fallen euch ja jetzt noch mehr Möglichkeiten ein. Die Kanalkapazität zu vergrößern geht natürlich immer. In meinem Ursprungsentwurf wollte ich mich mal mit Bluetooth auseinandersetzen (nicht, weil es geeignet wäre, sondern um das mal kennen gelernt zu haben). Jedoch scheint das auch nicht die Kapazität zu besitzen. Was mit einer Infrarot-Lösung möglich ist, würde ich gerne mal wissen. Grüße!
Hallöchen, wenn es ein neues Projekt geben wird, bin ich dabei. Mich interessiert diese Uhr schon sehr lange, da ich aber mit Mikroprozesoren noch wenig Erfahrung habe, lies ich die Finger davon. Deshalb würde ich gern in ein Gemeinschaftsprojekt mit einsteigen, da die Platinen in der Einzelfertigung ja sowie so teurer sind. Wer ist mir dabei? MfG Hicki
Angehängte Dateien:
-
PropClock.png
18 KB
Ich hab vor diese Platine hier fertigen zu lassen, wer will noch? ^^ PS: ISP anschluss ist atm nicht drauf, ich denke ich werd dem controller vor dem Verlöten nen Bootloader (über IR) einprogrammieren, um nachher das richtige programm drauf zu bekommen. PPS: Verbesserungsvorschläge erwünscht, eagle-file auf wunsch auch ;) PPPS: Die platine ist auf grund der Eagle light version so zerstückelt, entweder ich such mir vor der Fertigung jemanden, der mir beide Hälften zusammenfügen kann oder ich lasse so fertigen und löte später beide hälften zusammen.
Hallo Hauke, ich bin dabei. Ist es nicht besser, wenn Du den ISP-Stecker drauf lasst, um spätere Korrekturen vor zunehmen. Am Layout wäre ich interessiert, vielleicht kann ich da was machen, zwecks der Zusammenführung. MfG Hicki
Hier das Eagle Projekt. Ich probier auch noch mal den ISP stecker draufzubasteln.
Hallo Hauke, ich danke Dir, werde es gleich einmal versuchen zu verbinden. So bis später. MfG Hicki
Hauke, mal noch eine Frage - wie baust Du die Uhr - einfarbig oder RGB? MfG Hicki
Die Version dort ist erst noch einfarbig, eine RGB version hab ich aber auch schon als layout (aber da sieht die platine noch nicht so schön aus, und in der eagle light version ist der platz wegen der Länge doch SEHR begrenzt)
... also ich hätte ggf. Interesse an einer Platine, kommt auf den Preis drauf an. Ich kann microcirtec oder HAKA-Electronic empfehlen. Ist eine Sache der Stückzahlen ...
Hauke Radtki wrote: > Die Version dort ist erst noch einfarbig, eine RGB version hab ich aber > auch schon als layout (aber da sieht die platine noch nicht so schön > aus, und in der eagle light version ist der platz wegen der Länge doch > SEHR begrenzt) Hallo Hauke, die RGB-Version ist doch besser, Oder? Ein Kollege von mir arbeitet mit Target. Da gibt es bedeutend mehr Möglichkeiten. Schicke mir doch mal den Schaltplan. Das bekomme ich schon hin. Bis dann - MfG Hicki
Hallöchen, ich noch einmal. Übrigens sind hier http://www.eurocircuits.com/ die Platinen sehr kosten günstig. MfG Hicki
Hallo Hauke, wann wollen wir anfangen? MfG Hicki
So bald wie möglich ;) Ich hab jetzt mal die ISP pins auf testpunkte auf die Platine gebracht, da kann man dann kleine kabel anlöten oder wenn man hat kleine federkontakte andrücken. Nen RC glied hab ich auch ncoh an den Reset gelegt, bei den störungen von der Spule kann da ja sonst vielleicht doch was schief laufen ;) Schaltplan ist auf m notebook, lade ich so bald wie möglich hoch.
Super Hauke, daß hört sich gut an. Ich warte. Vielen Dank und bis später. MfG Hicki
Danke Dir, mache mich gleich an die Arbeit. MfG Hicki
Hallo Hauke, bin bald fertig, aber ich habe ein Problem. Du hast im Schaltplan nur teilweise die Bezeichnung(Werte) der Bauelemente mit drin. Kannst Du mir diese noch schicken? MfG Hicki
Die Werte ergänze ich nach möglichkeit noch heute abend.
Hallo Hauke, danke für die Antwort, wäre schön, dann kann ich das Layout mit Bezeichnung fertig machen. Übrigens habe ich den Propellerplatine mit Target im ganzen gestaltet. MfG Hicki
Hier ... jetzt mit bauteilwerten. Der Strom durch die LEDs wird absichtlich nicht überschritten, man könnte zwar davon ausgehen, dass ja eine LED nie immer an ist und sie deswegen mit höherem strom treiben, aber ich denke das bringt auch nicht viel, und so ist die Stromversorgung entlastet.
Oh die hab ich tatsächlich vergessen einzutragen ;) LS E67B von Reichelt, hab gerade nicht meh rim kopf, welche marke das ist ;) Im prinzip geht aber jede LED mit 20mA und dem Gehäuse. PS: Bis wann kann ich dich denn anrufen?
Hauke danke für Deine Antwort. Anrufen kannst Du mich jeder Zeit. Wirst ja sehen auf welcher Nummer ich erreichbar bin. MfG Hicki
Hallo, ist kein Problem mit der Stückliste. Hast Du vor diese Uhr zu bauen. Wenn Ja, dann schließe Dich uns an. Es baut sich in der Gemeinschaft doch besser, ODER? Vor allem hat der ein oder andere doch noch eine bessere Idee. MfG Hicki
Hallo, das ist die Liste für die Prop Uhr von Hauke Radtki. Gruß Toby
Hallo Marius, der Schaltplan und die Liste ist nur vom Propellerdisplay. In der Bauteilliste ist noch ein Fehler drin. Der IC3 ist ein Atmel 162. Möchtest Du Dich dem Projekt anschließen? MfG Hicki
Theoretisch bin ich mit immer bereit irgendetwas zu basteln. Wollte halt erst das Rotor Dislay nachbauen
Hallo, ich plane derzeit auch ein Rotordisplay. Beim durchforsten des Beitrags sind einige IC's genannt worden die doch sehr interessant währen. Die Lösung mit den Konstantstrom-IC's mit Dot-Korrektion klingt gut, nur bin ich der Meinung das man die veränderte Lichtfarbe schon bemerkt. Meine Idee währe es die IC's mit integriertem Grey-Scale zu verweden. Die max. PWM Frequenz der IC's beträgt 30Mhz! Diese Frequenz ist im Rotordisplay so gut wie nicht mehr sichtbar. Ich habe ein paar Überschlagsrechnungen gemacht: Wenn ich 3 LED-Leisten drehen lasse, komme ich auf eine Gesamtumdrehungszahl von 15 U/s (900 U/Min). Durch die 3 LED-Leisten wird jede Spalte mit 50Hz refresht. Wenn ich nun den Kreis in 200 Spalten unterteile, beträgt die Zeit für eine Spalte 200µs. Bei 256 Graustufen würde die LED 23x innerhalb dieser Zeit angesteuert werden. Ob das noch sichtbar währe?
> Wenn ich 3 LED-Leisten drehen lasse, komme ich > auf eine Gesamtumdrehungszahl von 15 U/s (900 U/Min). Du meinst 3 Arme - die Umdrehungszahl ist immer die gleiche ;-) > Durch die 3 LED-Leisten > wird jede Spalte mit 50Hz refresht. nur? > Wenn ich nun den Kreis in 200 Spalten unterteile, > beträgt die Zeit für eine Spalte 200µs. das kann so nicht ganz stimmen, gefühlsmäßig 200 us sind zu wenig Zeit ! > Bei 256 > Graustufen würde die LED 23x innerhalb dieser > Zeit angesteuert werden. Ob das noch sichtbar währe? Damit es sichtbar ist, muß innerhalb einer Spalte ein PWM-Zyclus voll durchlaufen werden! Das IC von TI macht 30 MHz bei glaub 4096 Graustufen ... jedoch solltest Du in x^2 Stufen schalten (1,4,16,64,...) damit ein Farbwechsel fürs menschliche Auge sichtbar wird, einzelschritte sinds nicht nötig. Du mußt auch bedenken, daß die ICs Ladezeiten haben. Bei der 25MHz-IC-Variante komm ich so auf ca. 600 U/min, die bei 408 Spalten möglich sind. Was mir gut gefällt sind die 3 Arme zur Farbmischung, Viel Spaß beim synchonisieren.
Hallo @vajk Das mit der Umdrehungszahl wahr, das muss ich zugeben, schlecht formuliert. Klar dreht sich alles mit der gleichen Geschwindigkeit. Ich sollte auch erklären wie die Arme aufgebaut sein sollen. Alle 3 Arme sollen mit 16 RGB-LED's bestückt werden. somit wird bei einer Umdrehungsfrequenz von 25 U/s jede Spalte mit ca. 45Hz "abgetastet" (Ups, grad 'nen Fehler entdeckt -> Umdrehungsfrequenz soll 25 U/s sein) Zur Timerzeit: 25Hz / 200 Spalten => 5kHz => 200µs In diesen 200µs würde, ein mit 30Mhz getakter PWM, 6000 "Impulse" reinbekokmmen. Man könnte jetzt den 128-Stufigen IC verwenden. Damit würden über 46 PWM-Zyklen in die Spalte passen. Beim 4095-Stufigen währen es nur ca. 1,5 Zyklen. Das würde meines Erachtens auffahlen (Austastung). Das mit dem quadrieren des Einstellungswertes für einen linearen Helligkeitseindruck kenn ich bereits.
Hallo Stefan mit grossem Interesse habe ich Deine bauanleitung studiert. Wir haben eine Projektanfrage wo ein solches Display in ein Serviertablet (Bar) eingebaut werden soll. Da wir wenig Zeit zur Verfuegun haben moechte ich Dich anfragen ob Du bei Deinem Marketresearch schon auf fertige Bausatz Anbieter gestossen bist? Jeder Hint ist sehr willkommen. Freundliche Gruesse Peter Hunziker
"ein sich drehendes Serviertablet?" Wieviele LEDs sollen es den werden, ich hab aus meinem Auftrag damals noch 8er oder 16er Platinen übrig, wenns nicht zu viele sein sollen. Module sind in C programmiert.
Ein neues Projekt... , ich bin auch dabei. HAt schon jemand fertige Platinen? Oder gibt es schon eine verbesserte Version? MfG Hicki
Ich suche noch eine schöne Propelleruhr-Schaltung mit ca. 30 bis 60 LED`s. Einen Anbieter der größere Platine machen könnte und vielleicht sogar Bausatz anbietet habe ich bereits in Aussicht. Könnt ihr geeignete Schaltung empfehlen?
@ Pfiffikus ... also ich habe zwei unterschiedeliche Module - eines mit 8 RGB LEDs und einmal mit 16 RGB LEDs. Bei der 8er ist ein ATmega 32 drauf, pro LED also 3 geschaltete Konstanstromquellen. Bei der 16er ist ein ATmega 128 drauf und 3 PWM Oszillatoren mit 25 Mhz. Beide Modulreihen sind kaskadierbar. Die Schaltungen sind erprobt und wurde jeweils zur Textanzeige genutzt mit "Propellern" mit ca. 1,8m Durchmesser und bis 500 U/min. Entsprechend optimiert ist die Software.
Die 16ner Lösung würde mich interessieren. Kannst du vielleicht mal Bilder&Schaltplan posten? Die AVR Controller können ja nur bis max. 200mAh belastet werden, wie löst du das?
na bei der 8er wird über jede EinzelLED via Konstanstromquelle mit 20mA versorgt .. bei der 16er übernimmt das das PWM-IC (sind 3 Stück drauf a 16 Kanäle - also ein Oszi je Farbe). Weitere Info bitte per eMail.
Hallöchen, @ Vajk .v.i. würde mich der Sache anschließen. Auch über die Schaltung. MfG Hicki
So .. hab hier mal die 8er-Platinen zum Ansehen hochgestellt http://www.uCtier.de/dreh8ers1.pdf http://www.uCtier.de/dreh8ers2.pdf http://www.uCtier.de/dreh8ersboardbottom.pdf http://www.uCtier.de/dreh8ersboardtop.pdf und den Basiscode zum Ansehen http://www.uCtier.de/dreh8er.c wenns gefällt, dann packe ichs die Tage zusammen. Gruß Vajk
Vajk .v.i. wrote: > So .. hab hier mal die 8er-Platinen zum Ansehen hochgestellt > http://www.uCtier.de/dreh8ers1.pdf > http://www.uCtier.de/dreh8ers2.pdf > http://www.uCtier.de/dreh8ersboardbottom.pdf > http://www.uCtier.de/dreh8ersboardtop.pdf > und den Basiscode zum Ansehen > http://www.uCtier.de/dreh8er.c > wenns gefällt, dann packe ichs die Tage zusammen. > Gruß Vajk Hallöchen, daß sieht ja super aus. Hast Du noch ein Foto Deiner fertigen Uhr? Also ich hätte großes Interesse an der Uhr. Würde mich freuen, wenn Du das Paket fertig machst. MfG Hicki
@Hicki, also Uhr ists "noch" nicht nicht, daß mußt Du dann im Code umsetzen - von der Programmierung her, hab ich den Vollkreis durch 408 "Spalten" geteilt, ist durch 8 und 12 teilbar, bei Font 12 x 16 - sprich zwei Module machen eine Textzeile :-) und ein paar Striche anzeigen und zwischendruch was spielen dürfte kein Prob sein :-) Den Regelcode zur Geschwindigkeitsanpassung hab ich auch recht simpel und wirkungsvoll gelöst, im Gegensatz zu Umdrehungszeitmessung und ausrechnen der Zeitlänge für eine Spalte - ich weiß viele Spalten es sein müssen und fange mit irgend einem Timerwert an und korrigiere den bis die Spaltenzahl paßt. Netter Hochlaufeffekt und sprungfreiere Regelung. Foto(s) maile ich Dir LG Vajk
Vajk .v.i. wrote: > @Hicki, also Uhr ists "noch" nicht nicht, daß mußt Du dann im Code > umsetzen - von der Programmierung her, hab ich den Vollkreis durch 408 > "Spalten" geteilt, ist durch 8 und 12 teilbar, bei Font 12 x 16 - sprich > zwei Module machen eine Textzeile :-) und ein paar Striche anzeigen und > zwischendruch was spielen dürfte kein Prob sein :-) Den Regelcode zur > Geschwindigkeitsanpassung hab ich auch recht simpel und wirkungsvoll > gelöst, im Gegensatz zu Umdrehungszeitmessung und ausrechnen der > Zeitlänge für eine Spalte - ich weiß viele Spalten es sein müssen und > fange mit irgend einem Timerwert an und korrigiere den bis die > Spaltenzahl paßt. Netter Hochlaufeffekt und sprungfreiere Regelung. > > Foto(s) maile ich Dir > LG > Vajk Hallöchen Vajk, danke für Deine Antwort. Würdest Du mir beim Coden der Uhr helfen? Bin auf die Fotos gespannt. MfG Hicki
Was nehmt ihr denn für Spulenkörper und wie wickelt ihr die Spule. Bislang hab ich´s nicht sonderlich sauber und gleichmäßig hin bekommen. Mir fehlt ihrendwie was rundes mit Rand.
Pfiffikus wrote: > Was nehmt ihr denn für Spulenkörper und wie wickelt ihr die Spule. > Bislang hab ich´s nicht sonderlich sauber und gleichmäßig hin bekommen. > Mir fehlt ihrendwie was rundes mit Rand. Ich habe damals ganz einfach diese Abflussrohre genommen aus dem Baumarkt, geht super.
@Simon K wieviel Strom kannst Du über die Luftspulen übertragen? (RGLs sind 24 LEDs x 20 mA = sind schon rund 500 mA für eins meiner Module
Ich habe heute mal etwas experimentiert. Luftspule: Primär 100 Windungen / Sekundär 150 Windungen Bis 500mA Übertragung ist kein Problem ich habe die Frequenzen 500 Hz bis 31khz schrittweise um 1khz erhöht. Die beste Übertragung erfolgt mit 1 bis 2 khz. Darüber und darunter fällt die Spannung Sekundär erheblich ab! Ich frage mich wie das bei einigen mit 20khz klappen soll, da kommt bei mir nix mehr rüber!
Schwingkeis / Resonanzfrequenz und so .. vermutlich auch abhängig von der Anzahl der Windungen und dem Verhältnis von Sekundär und Primärwindungszahl! Ist bei höhere Spannung auch mehr Leistung übertragbar ? Empirisch ermitteln oder theoretisch berechnen?
Ich habe am Sekundärwicklung ein 20 Ohm Lastwiederstand ran gehängt! Die Spannung war bei 1500 hz am höchsten. Somit auch Leistung! geschaltet wurde primär mit FET 1405. Daten mit Oszi ermittelt.
Der übertragbare Strom ist im Prinzip durch nichts begrenzt. Problematisch ist nur der verdammt schlechte Wirkungsgrad der Luftspulen. Für 2,5Watt sekundär muss man also sicher um die 5Watt primär bereitstellen.
Hallo, als Störfaktor für unteren "Transformator" klönnte ich mir metallische Komponenten im Bereich des magnetischen Kreises vorstellen. Gerade ferromagnetische Materialien (Kugellager?) könnten sehr störend wirken. Aber auch elektrisch gut leitende Materialien können stören, da sie wie eine kurzgeschlossene Sekundärspule unseres Transformators wirken. Um diese Einflüsse auszuschließen, würde ich vorschlagen, die Anordnung mal weiter ab jeglicher metallischer Komponenten zu testen. Im Prinzip müsste ja die übertragbare Energie mit steigender Frequenz ansteigen? Läßt sich durch eine passende Kapazität parallel zur Spule ein resonanzeffekt positiv nutzen? Ansonsten könnte ich mir vorstellen, dass ein Transformator aus 2 Hälften eines Ferrit-Schalenkerns mit je einer Spule drin gut funktionieren könnte. Der Luftspalt kann dann ja auf wenige Zehntel mm beschränkt werden, wenn der Schalenkern auf der Propellerachse liegt? Gruß Dietrich PS: Auch ich bin interessiert an einem Paltinensatz, sobald die restlichen Probleme gelöst sind.
Es ist nicht so einfach die Spulen in so einem kleinen Abstand zu montieren. In der Praxix bekommt man die Wicklung nur etwas eiförmig hin. In meinem Beispiel habe ich im Schnitt noch einen Abstand zwischen 5 bis 8 mm zwischen den Spulen. Dennoch klappt es bei 1500 Hz. Welche Kondensatorgröße (Anhaltspunkt) empfielst du mal auszutesten? Diese wirken ja im Wechselfeld wie Parallelwiderstand, darf dann auch nicht zu groß sein. In meinem Fall ist die innere Spule direkt um den Rotor eines PC Lüfters gewickelt. Da alles aus Plastik ist, könnte dort nur der eigentliche Lüftermotor stören. Es wäre allerdings sehr schwierig den Abstand zum Lüftermotor zu erhöhen, würde dann auch unangenehm große werden. Also noch mal die Daten: Luftspule: Primär 100 Windungen / Sekundär 150 Windungen Frequenz ideal bei 1500 Hz (leider leichter Pfeifton), sowohl von Leistung als auch Wirkungsgrad 12 V /800mA dürten Sekundär für 6V Ac /500mA gerade mal ausreichen Nur der Pfeifton stört!
Die der Kondensator darf Theoretisch beliebige Werte haben, aber sinnvoll ist es, Spule und Kondensator aufeinander abzustimmen. Ich habe durch Luftspulen bis jetzt etwa 25W übertragen, das ist aber eher Theorie, da die Spulen einen ziemlich engen abstand hatten (<1mm) und etwas größer im Druchmesser (etwa 4cm) waren. Außerdem wird die Primärspule relativ schnell Warm, da in ihr etwa noch mal 20W verheizt wurden (jaja der Wirkungsgrad :P) Ausnutzung von Resonanz bringt folgende Vorteile: -Gleichrichter wird effektiver, da nicht mehr so hochfrequente Signalanteile wie bei Rechteckansteuerung vorhanden sind -Wenn man die ansteuerung Variabel aufbaut, kann die übertragene Leistung durch ändern der Ansteuerungsfrequenz (näher dran oder weiter weg von der Resonanzfrequenz) angepasst werden -Weniger breitbandige Störungen des Umfeldes
>Ich suche noch eine schöne Propelleruhr-Schaltung mit ca. 30 bis 60 >LED`s. Beitrag "Re: Propeller Uhr und schwebender Trafo" Beitrag "Re: Auftragsarbeit - RGB-LED-Lauflicht"
Wie ist der Stand bei euch in Sachen Stromübertragung. Ich habe noch mit diversen Spulen und Frequenzen experimentiert aber bin noch nicht so recht zufrieden. Mehr als 4000 khz war nicht effektiv. Und darunter konnte ich bestenfalls 5V bei 500mA übertragen Ich würe gerne aber die doppelte Leistung übertragen, hat das schon jemand hin bekommen? Wenn ja, wären ein paar Angaben zu Drahtquerschnitt, Spulendurchmesser, Windungszahl, Frequenz hilfreich. Obere Links haben mich da auch nicht weiter gebracht.
Tipps zur Spule gibts hier in der PDF: http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=391 Sogar ne fertige Platine gibts
@ Pfiffikus (Gast) >Wie ist der Stand bei euch in Sachen Stromübertragung. Ich habe noch mit >diversen Spulen und Frequenzen experimentiert aber bin noch nicht so >recht zufrieden. Mehr als 4000 khz war nicht effektiv. >Und darunter konnte ich bestenfalls 5V bei 500mA übertragen Auch wenn der Post schon etwas alt ist. Siehe Royer Converter >Die Spannung war bei 1500 hz am höchsten. Somit auch Leistung! >geschaltet wurde primär mit FET 1405. >Daten mit Oszi ermittelt. Einfach mit nem dicken FET ne Spule einschalten ist kein Schaltnetzteil, schon gar nicht mit Luftspulen! MfG Falk
Thread beobachten
Seitenaufteilung abschalten