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
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
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 ;)
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
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
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
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
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
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
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
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
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
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.
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
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?
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 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
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.
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.
@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.
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
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.
@ 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
