LED-Darstellungs Idee mit ein paar Hindernissen

[Crazy Harry]

ich hab mir diesbezüglich auch schonmal gedanken gemacht und bei der größe könnte man doch den motor in die kugel bauen. mit einem Schrittmotor sotte man auch die synchronisation einfacher hinbekommen.

[Ratber]

Ja,wenn man ihn mit 2-4 Khz ansteuert ist das scheinbar kein Akt aber man sollte sich fragen warum es nur wenige machen wenn die Auflösung nach oben geht

[SprinterSB]

So ganz kann ich die Berechnungen oben nicht nachvollziehen... Was meint ihr mit "Pixelgeschwindigkeit"?

Die Spalte kann man schlecht multiplexen, weil sich die LEDs weiterbewegen. Um saubere Spalten (Meridiane) zu erhalten müsste man also alle LEDs gleichzeitig und in möglichst gleichen Zeitabständen synchronisieren.

So eine ganze Spalte im 20kHz-Takt schreiben geht mit guter Software, 40 U/min sollten also kein Thema sein. Bei 40 U/min wird man es noch deutlich flackern sehen. Das liegt auch daran, daß das Display selbst nicht träge ist (im Vergleich zB zu einer floureszierenden Röhre).

Die eigentliche Frage ist also, wie man die 64 LEDs (fast) gleichzeitig aktualisieren will. Ein 8:8 MUX käme evtl in Frage, allerdings geht dadurch recht viel Helligkeit verloren, weil die sich zudem noch über die Breiten verteilt. Je heller, desto mehr verzieht sich die ganze Geometrie... Ein µC mit 70 Ports ist *fett*, scheidet also auch aus...

Portexpander scheint mir die beste Option, evtl. der 8*8 MUX. Mit den Portexpandern hat man zusätzlichen HW-Aufwand, hat aber die Möglichkeit, jeder LED ihren eigenen R zu geben. Dadurch könnte man Helligkeitsunterschiede, die durch die unterschiedliche Umfangsgeschwindigkeit bedingt sind, ausgleichen.

Wie auch immer, die 64 LEDs samt R müssen verdrahtet und ausgewuchtet werden.

Bei r=65mm und f=40Hz Rotation ergibt sich eine Äquatorialbeschleunigung (a = r·(2·pi·f)²) von ca. 420g *Taschenrechner-schüttel* ...scheint zu stimmen das *schluck*.

[Ratber]

So ganz kann ich die Berechnungen oben nicht nachvollziehen... Was meint ihr mit "Pixelgeschwindigkeit"?................usw.

Ja,wenn die komplette Elektronik im Rotor sitzt mag man ,öglichst parallel arbeiten können aber das wäre für die Anzahl der LED's fast unwirtschaftlich.

Man setzt normalerweise die Zentrale Steuerung in den sockel und nur die Anzeigeeinheit in den Rotor.

Dazwischen erfolgt dr Datenaustausch.
Klar,wenn du 8 Bit Parallel überträgst dann ist die Datenrate niedriger aber wie will man das machen ?

8 Schleifer ?
Monströs

8 Infrarot strecken ?
Nicht zu schaffen

8 Funkmodule ? (Ein Multiplexmodul ist wieder eine einzelne Serielle Leitung )
Wird auch wieder umfangreich.

Deswegen die Datenraten wenn alles Seriell geht.

Wie schon gesagt,wenn er nur ein festes Muster darstellen will dann ist das alles kein Problem.
Bei 64 LED und 2400 Upm sowie angenommene 128 Muster pro Umdrehung hat man bei Byteweiser Übertragung 40960 Bytes pro sekunde zu übertragen.
Dazu kommen die Operationen für die Adressierung also nochmal ein Byte pro Segment was dann schon 81920 Bytes/s entspricht.
Soweit wenn man es ganz einfach aus nem Speicher zieht.
Mit Controller wirds aufwändiger.
Der Controller muß sich diese Daten erst aus dem Speicher holen also nochmal eine Adressierung.
Das sind dann 122880 Bytes/s

In der Rechnung nicht enthalten sind andere Berechnungen für Synchronisation und Verwaltung sowie Features.

Kommen jetzt noch Farben dazu dann explodiert die Datenrate.



Ja,deswegen ist bei dem letzten Projekt von ISPF.de nix mehr zu höhren gewesen.
Bei der Zahl von Features ist schnell Ende oder man muß einen recht großen Aufwand treiben.
Letztens lief irgendwo ne Sendung wo einer ne Propellerklock in die Felgen gesetzt hatte.
Sah nett aus und war auch recht gut in der Auflösung.

8 oder 16 Bit Propeller mit vieleicht etwas Farbe (3x8 Bit RGB) ist da mit 8-Bit Controllern noch gut zu händeln.

Für mehr kann man sich gleich mit 16 oder 32-Bitern (zb. Arm) anfreunden.

[SprinterSB]

Wenn man in die Anzeige hineinsendet/überträgt, dann muss innen ja was sein, zum Empfangen/Auswerten/Ansteuern/Treiben... ...warum dann nicht gleich nen µC reinsetzen?

Wenn man ein 8*8 MUX mit superhellen LEDs macht, sollte die Helligkeit ausreichend sein, ohne daß man einen externen Treiber hernehmen muss. Anstatt Treiber 2 AVR-Ports +2R parallel und man ist bei 5mA, das ist kräftig hell mit geeigneten LEDs, bevorzugt grüne (520nm). Wobei ich 64 LEDs bei r=65mm schon sehr reichlich ist!

Von der Darstellungsgeschwindigkeit ist es dann IMHO kein Problem, selbst wenn Features dazukommen wie ne Uhr oder Lauftext und der Globe "nur" ein Bilschirmschoner ist. Andererseits...wegen dem Krach kommt ein Dauerbetrieb eher weniger in Frage.

[kalledom]

Hallo,
ich habe das gleiche Problem, LEDs gleichzeitig zu steuern, allerdings nicht 64, sondern 600...1000 Stück !!!
Dazu baue ich mit einem µC (PIC16F877 ??? oder 80C166 !!!) einen 8-Bit / 16-Bit-Bus auf, also 8 / 16 Bit Daten und 8 Bit Adressen (= 256 * 8 bzw. 256 * 16 LEDs).
Dann nehme ich für jeweils 8 / 16 LEDs oder LED-Reihen eine Platine mit:
1 x 74HC686 (8-Bit-Vergleicher für Card-Select),
1 bzw. 2 x 74HC373 (8-Bit-Latch),
1 bzw. 2 x 74HC273 (8-Bit-Latch mit Reset),
1 bzw. 2 x ULN2803A (Treiber).
Mit dem 80C166 habe ich schon so einen Bus aufgebaut, dazu Platinen mit jeweils 64 Ein- und 64 Ausgängen zur konventionellen Steuerung von Modellbahnen, ähnlich einer SPS. Die Software ist bisher nicht fertig geworden.

Der Vergleicher sorgt nach Anlegen der 8-Bit-Adresse für die Auswahl der gewünschten Platine / Latch und der 'auserwählte' 74HC373 übernimmt nach einem kurzen Write-Impuls die 8 / 16 Daten-Bits.
Die 74HC273 haben einen gemeinsamen Reset, damit beim Einschalten alles Low ist und haben einen gemeinsamen Latch zur Übernahme der im 74HC373 befindlichen Bits.
Das ist alles

Quatsch. Ein weiteres Problem wird sein, wo hole ich die ganzen Bit-Muster-Daten her und wo lege ich sie im PIC ab ??? Beim 80C166 ist etwas mehr Platz.
Wie erzeuge ich meine erforderlichen Bit-Muster für die vielen vielen LED's. Es müssen ja nicht immer alle 600...1000 Bits übertragen werden. Wenn z.B. 8 / 16 LEDs eine Zeit lang dunkel oder hell bleiben und am gleichen 74HC273 hängen, muß dieses Byte / Word nicht neu übertragen werden.
Die andere Frage ist, wieviel Probleme gibt es beim seriellen Schieben von bis zu 1000 Bits auf einer Bus-Länge von bis zu 3 m ?
Bei Parallel-Betrieb ist das nicht so problematisch, weil der Datenwechsel im Mikrosekunden-Bereich liegt.
Ja ja, und mit welcher Taktgeschwindigkeit muß ich letztendlich die Bits parallel oder seriell 'transportieren' ?
Also, es fehlt mir noch eine Idee zur Berechnung und Reduzierung der Bits.

[Jakob L.]

Hallo Strahleman,

bist du sicher, dass du die Kugel mit einer Geschwindigkeit von 40 U/s rotieren lassen willst? Dabei bewegen sich die äusseren Teile der Kugel mit einer Geschwindigkeit von knapp 70 km/h. Die Fliehkraft ist etwa 480x so stark wie die Erdbeschleunigung. Wenn die Kugel ein Gewicht von 0.2 kg hat (und das Gewicht zum grössten Teil aussen ist), dann wirkt eine Fliehkraft von 950N (ca. 95 kg). Wenn die Kugel nicht stabil genug ist, dann fliegen Teile davon mit 70 km/h durch den Raum. Die Kugel muss natürlich möglichst exakt symmetrisch sein, da auch eine kleine Unwucht die Konstruktion zerstören könnte.

Gruss
Jakob

[Ratber]

Wenn man in die Anzeige hineinsendet/überträgt, dann muss innen ja was sein, zum Empfangen/Auswerten/Ansteuern/Treiben... ...warum dann nicht gleich nen µC reinsetzen?

Ja,davon red ich doch die ganze Zeit.

wegen dem Krach kommt ein Dauerbetrieb eher weniger in Frage.

Überlegen wir mal über welchen Krach wir da reden.

Da kommen ja nur zwei Quellen in Frage.

Einmal der Motor und einmal die Luftverdrängung des Rotors.

Den Motor bekommt man rech schnell auf akzeptable Lautstärken wenn man zv. einen Kopfmotor aus nem Vodeorecorder nimmt oder was ähnliches.

Beim Rotor muß man schon auf die Aerodynamik achten denn jede Kante bringt ein Geräusch.
Eine Glaskugel drumrum ist nicht nur Schön,Pflegeleicht und schutz vor versehentlichem reingreifen sondern dämpft auch noch so nebenbei.
(Eine Möglichkeit von vielen)

Quatsch. Ein weiteres Problem wird sein, wo hole ich die ganzen Bit-Muster-Daten her und wo lege ich sie im PIC ab ??? Beim 80C166 ist etwas mehr Platz.

Ja deswegen der externe Speicher und die zusätzlichen Zugriffe.



@Jakob

Genau so isses und deswegen ja mein Vorschlag die Drehzahl auf die hälfte zu reduzieren.
Da hat man immernoch eine Wiedrholfrequenz von 20
Reicht doch auch.
Die Fliehkräfte reduzieren sich dabei erheblich.

[Strahleman]

Ich habe es mir so gedacht, dass man zwei Mega8 Controller nimmt, in dessen EEPROMS die notwendigen Daten schreibt ("Leuchtreihenfolge" der LEDs bei jedem Bit) und dem Controller einfach sagt, dass er das EEPROM lesen soll. Zusätzlich wird der interne Counter von den Controllern gesetzt, so dass er nach 128 Bit (also den 128 Schritten für eine Umrundung) wieder das Programm wiederholt. Geht das?

Zur Info: ich habe vor, als kleinen Showeffekt eine kleine Erde zu machen. Zuerst wollte ich die Kontinente in eine Plexikugel gravieren und diese dann von innen beleuchten. Aber dann kam die besagte Mathestunde und mir ist das mit den LEDs eingefallen. Das Teil muss sich nicht immer drehen, von daher stört die Lautstärke nicht unbedingt. Das Ganze soll an einem PC benutzt werden.

[Ratber]

Ich habe es mir so gedacht, dass man zwei Mega8 Controller nimmt, in dessen EEPROMS die notwendigen Daten schreibt ("Leuchtreihenfolge" der LEDs bei jedem Bit) und dem Controller einfach sagt, dass er das EEPROM lesen soll. Zusätzlich wird der interne Counter von den Controllern gesetzt, so dass er nach 128 Bit (also den 128 Schritten für eine Umrundung) wieder das Programm wiederholt. Geht das?

Mal rechnen:

2 Mega8 a 512 Byte EEProm also 1K für das komplette Muster.
64 LED's wolltest du pro Spalte haben also 8 Byte pro Spalte.
Auf jeden Mega 8 fallen also 4 Byte.
1K / 8Byte = 128 Spalten pro Umdrehung.
Dein "Bild" wäre also 128x64 Pixel groß.

Zeichne mal deine Weltkarte auf diese 128x64 Pixel und entscheide ob das reicht.

Technisch denke ich das es machbar wäre.
Genau kann ich es erst sagen wenn ich weiß wie schnell der Zugriff auf die internen EEProms ist.


Ja,könnte gehen.
Aber du kannst auch gleich nen einzelnen Mega32 nehmen der hat 1K EEProm bzw. nen M64 wo 2K Platz für 2 Motive bzw. eine höhere Auflösung bieten würde.

Spinnt man das mal aus Spaß weiter dann bietet sich ein M128 an der einen Bus mit bringt und wo man eben mal 64K Externene Speicher adressieren kann.
Als SMD nicht sehr groß beitet er für wenige Euros eine Menge Potential.

Nur mal so als Gedankenanstoss