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