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/rotordispl...

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

Dann kann man aber nur global das ganze Display dimmen, oder ?

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.t...
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) ?????

Ja.

@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

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

Und hier noch der zweite Teil der Videos.

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 ...

Danke, habs kapiert - einfach und doch genial :-)

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