mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Universelles Eingabegerät mit Drehencodern


Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
Ich plane ein Eingabegerät für Musikgeräte und andere Anwendungen auf 
der Basis von Drehencodern.  Gedacht ist es u.a. zur Steuerung von 
Synthesizern. Für diesen Zweck gibt es zwar Geräte, aber die, die ich 
bisher benutzte (Döpfer), sowie die meisten anderen (M-Audio, 
Behringer)haben mir zu kleine Abstände zwischen den Knöpfen, haben oft 
auch zu kleine Knöpfe, sind zu grob und unempfindlich, bzw nicht gut 
genug entprellt. Die vom Hersteller mit dem grossen Behringer haben auch 
nicht so die Qualität.

Generell sind die Controller auch zu grob gerastert - man hat immer nur 
wenige LEDs und auch keine vernünftige Beschleunigungsfunktion, zudem 
haben MIDI-Geräte protokollbedingt zu gringe Auflösungen für viele Apps. 
Im Zuge eines Selbstbaus liessen sich solche Problemchen leicht 
wegzuräumen.

Ich möchte gegenüber den konventionellen Controllern folgende 
Verbesserungen haben:

- Abstände zwischen den Achsmitten ca. 40mm
- Bedienknöpfe ca 15mm - 20mm Duurchmesser, geriffelt
- Rastfunktionen mit programmiertem Vortrieb
- Auflösung von 10Bit Positionen
- Anzeige von mehr, als 30 Positionen
- Ausgabe per seriellem Protokoll mit MaxSpeed
- reduzierte Ausgabe der Werte per MIDI
- gfs MLAN
- Anzeige der Werte am Rechner

Ich habe mich umgeschaut, was es sonst so gibt und kam auf zwei 
Möglichkeiten: Eine Webseite bietet für $14,- eine kleine Platine an, 
die einen Encoder mit SPI-Ansteuerung enthält, diese hat aber zu wenige 
LEDs. Ein fernöstlicher Hersteller hat einen Encoder mit 30 LEDs im 
Programm, dieser ist aber mit 25,- zu teuer. Daher habe ich überlegt, 
sowas mit einem FPGA und einer Platine selber zu machen. Geplant sind:

8 x 6 Bedienregler, 32cm breit, 24cm hoch

32 LEDs mit 31 Zwischenpositionen, d.h. 63 virtuelle Positionen, 
angedeutet durch 2 schwach leuchtende benachbarte LEDs

Alternativ Duo LEDs mit 2 Farben (= Vor- und Nachkommastelle), Blättern 
der Vorkommastelle nach Umrunden der Nachkommastelle - Einstellen durch 
2 Modi - aktiviert durch Drehencoder mit Tastfunktion (Feintrieb)

Bei Duo-LEDs kann ein symmetischer Modus aktiviert werden, dabei werden 
rot/grün verbaut und negative Werte in rot angezeigt, positive Werte in 
grün

Ein FPGA interpretiert die Encoder und steuert die LEDs im 
Multiplexbetrieb:

(8+6) x2 Leitungen für die Encoder, weitere 8+6 für die Taster
zusätzlich 8x2 weitere Taster auf dem Board

32/64 + 48 Leitungen für die LEDs,
Zwischensumme 138 pins

Wiederholrate für LEDs und Taster = 1/(48+16) oder 1/(112+16) x 50MHz = 
300 kHz

Entprellung der Encoder mit FPGAs - erfahrungsgemäss reicht Rate von 
10kHz

48/96 Tansistoren bzw LED-Treiber-Kanäle -> 12 CMOS INVs

Die Raststellungen der Encoder können 1,2,3 oder mehr digits Differenz 
(programmierbar) betragen.

Encoder werden in die Platine geschraubt, per Stecker verdrahtet oder 
eingelötet.

Plexiglasabdeckung mit Bohrungen in Grösse des Gewindes zum 
Durchstecken.

-------------------------------------------------------------------

Hätte jemand Interesse, sich zu beteiligen?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jürgen S. (engineer) Benutzerseite

>- Rastfunktionen mit programmiertem Vortrieb
>- Auflösung von 10Bit Positionen

Über eine Umdrehung? Na dann mal viel Spass. Kannst du ja gleich 
Präzisionsdrehgeber von Haidenhain & Co kaufen. ;-)

>LEDs. Ein fernöstlicher Hersteller hat einen Encoder mit 30 LEDs im
>Programm, dieser ist aber mit 25,- zu teuer.

Denkst du, dass du es selber deutlich billiger schaffst? Wenn man es 
richtig rechnet?

> Daher habe ich überlegt,
>sowas mit einem FPGA und einer Platine selber zu machen. Geplant sind:

FPGA für so nen Krümelkram? Die LED-Ansteuerung incl. PWM machen TLC5940 
& Co, das Auslesen und dekodieren der Drehgeber ein mittelgroßer 
AVR. Fertig.

>8 x 6 Bedienregler, 32cm breit, 24cm hoch

Naja, ist schon recht viel, aber ich denke mit gescheiter Programmierung 
schafft das ein AVR, schließlich reicht 1ms Abtastinterval, weil kein 
Mensch so tierisch schnell die Regler bedienen wird/kann.

>32 LEDs mit 31 Zwischenpositionen, d.h. 63 virtuelle Positionen,
>angedeutet durch 2 schwach leuchtende benachbarte LEDs

Mit PWM kann man das nahezu analog machen mit deutlich mehr als 1 
Zwischenstufe.

>(8+6) x2 Leitungen für die Encoder, weitere 8+6 für die Taster
>zusätzlich 8x2 weitere Taster auf dem Board

Kein Problem. 8:1 ode 6:1 muxen ist vor allem bei Schaltern belanglos.

>32/64 + 48 Leitungen für die LEDs,
>Zwischensumme 138 pins

Du willst 6 x 8 x 32 LEDs ansteuern, macht die stolze Summe von 1536 
Stück.
Du willst/kannst eher nicht 48:1 muxen. Eher 8:1, vielleicht 10:1. Macht 
bei DUO-LEDs 64 x 6 = 384 Leitungen. Und die wollen auch verdrahtet 
sein. Nicht sinnvoll. Viel besser das ganze modular für einen Drehgeber 
mit seriellem Eingang zu machen, 2x TLC59xx und fertig. Deutlich 
verringerter Verdrahtungsaufwand. Und hat den deutlichen Vorteil, dass 
man erstmal einen Prototypen bauen kann, ausgiebig testen und 
(kosten)optimieren und dann einfach  N x M Stück in ein Gehäuse baut.

>Wiederholrate für LEDs und Taster = 1/(48+16) oder 1/(112+16) x 50MHz =
>300 kHz

Totaler Overkill.

>Plexiglasabdeckung mit Bohrungen in Grösse des Gewindes zum
>Durchstecken.

Mal sehen wie weit das Projekt kommt, oder ob es in der 
Brainstormingphase stecken bleibt, wie so viele Projekt e hier.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich fange mal hinten an zu antworten:

- ja, es wird gebaut

- overkill: es geht um die Abschätzung, dass es vom Tempo her reicht. 
Nur der Vollständigkeit halber erwähnt. Fürs FPGA heisst das, dass man 
noch stark sequenzialisieren kann

- TLC59xx hatte ich auch schon überlegt, aber ein FPGA von der Spartan 3 
A-Serie ist für unter 5 Euro zu haben und mit maximal 2 davon habe ich 
alle Leitungen im Griff. Das wird - wenn es vom Muxen her reicht - in 
jedem Fall billiger. Gfs kann man auch 2-4 Gruppen machen, um die 
MUX-Lst zu divideren. Dann kommt man auf 48 Leitungen x 64 LEDs /4 = 
16tel -> 6% on. Mit einem 70mA-Puls leuchten die wie mit 5mA, was 
reichen sollte.

- "31 Zwischenpositionen", damit war gemeint, dass ich nicht nur 8-10 
Positionen anzeigen will, sondern 63! Ich habe mir ein gleitendes 
Leuchten der LEDs überlegt, die jeweils 2-3 zum Glimmen bringen, sodass 
32+31+62=125 Positionen eindeutig anzeigbar sind. Wenn ich dort eine 
Zehnerteilung auflege, kann ich mit 11x10 insgesamt 10 Teilbereiche 
anzeigen und habe noch LEDs für die Trenner. Das sähe dann so aus : 
rot-10x grün - rot - 10xgrün. Damit wäre eine dezimale Teilung möglich. 
Ähnlich bekomme ich mit 9 leuchtenden LEDs Trenner für 8 Felder hin, um 
2x8 = 16 Teilungen anzuzeigen. Angedacht, ist eine milchige Scheibe zu 
nehmen. Die LED Anzeige kriecht dann quasi analog und ist nicht mehr 
eindeutig einer LED-Position zuzuordnen - gleichzeitig wird die Skala 
eingeblendet.

- "Mit PWM kann man das nahezu analog machen mit deutlich mehr als 1
Zwischenstufe."
PWM geht ja nur innerhalb oder ausserhalb des Multiplexzyklus - damit 
stehen dann nicht so viele Stufen zur Verfügung. Ich brauche aber 
eigentlich auch nur 2, maximal3.


- "mit gescheiter Programmierung schafft das ein AVR"
Mit kaum weniger Programieraufwand schafft das auch der Spartan und der 
ist kaum teuer, als der AVR. Der Spartan packt aber locker auch noch ein 
Midi-Protokoll und streamt mir die Positionsdaten 10 Bit + Steuerinfos + 
Kanalinfos x 64 = 1kBit in weniger als 1ms an ein anderes board.

- billiger
Nun, der besagte Encoder mit den 30 LEDs reicht nicht an meine 
Funktionalität heran, kostet aber schon so viel, wie die Hälfte der 
Encoder. Die habe ich von EBAY zu 0,49 das Stück und die sind richtig 
gut. (ALPS) - verschiedene Ausführungen. Die 30 LEDs kosten definitiv 
keine 25 Euro :-)  Der Rest ist Vogelfutter. Ich spare pro Kanal sicher 
15 Euro und eine Ansteuerung bräuchte ich im anderen Fall auch.

- FPGA für so nen Krümelkram?
auf den ersten Blick, nimmt man keinen FPGA. Aber: Besagter Spartan A 
ist eine billige Krücke, im Prinzip sind das nur Schaltfunktionen, also 
ein Haufen IOs und das ist genau das, was man braucht. Für solche 
Schaltaufgaben mit wenig Intelligenz ist das der optimale Chip.

>- Auflösung von 10Bit Positionen über eine Umdrehung?
Nein, insgesamt. Die MIDI-Geräte die ich zum Vorbild nehme und als 
käufliche Alternative hätte, liefern 127 digit und differenziell 
irgendwas, das entweder weit über einem digitl liegt, also zu grob ist 
oder zu gering steigt, um rasch auf 1024 blättern zu können, weil es 
dafpr nicht gebaut ist. Man braucht eine eigene Beschleunigungsfunktion 
oder eine mehrstufige Einstellung Vorkomma/Nachkomma mit virtuelem 
Feintrieb. Beides kann ich in VHDL leicht machen, wenn die Encoder 
Taster haben oder eine intelligente Beschleunigun reinprogrammiert wird.

Ich will mit dem Geber sowohl sehr fein einstellen, als auch einen 
weiten Bereich haben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jürgen S. (engineer) Benutzerseite

>- TLC59xx hatte ich auch schon überlegt, aber ein FPGA von der Spartan 3
>A-Serie ist für unter 5 Euro zu haben und mit maximal 2 davon habe ich
>alle Leitungen im Griff. Das wird - wenn es vom Muxen her reicht - in
>jedem Fall billiger. Gfs kann man auch 2-4 Gruppen machen, um die
>MUX-Lst zu divideren.

Das schon eher, z.B. 6x1 Reihe pro FPGA

>16tel -> 6% on. Mit einem 70mA-Puls leuchten die wie mit 5mA, was
>reichen sollte.

OK.

>- "mit gescheiter Programmierung schafft das ein AVR"
>Mit kaum weniger Programieraufwand schafft das auch der Spartan und der
>ist kaum teuer, als der AVR. Der Spartan packt aber locker auch noch ein
>Midi-Protokoll und streamt mir die Positionsdaten 10 Bit + Steuerinfos +
>Kanalinfos x 64 = 1kBit in weniger als 1ms an ein anderes board.

Naja, stimmt auch wieder, wenn man den S3 für 5 Euro bekommt.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der kleine 50er, den ich mal verbaut hatte, lag unter €3,- bei 
Stückzahlen.

Ok, dann nochmal zu den Kosten:

Reichelt hat einen solchen ALPS Drehgeber mit 31 LEDs, zu 17,95: 
"EC11B1524B-LED".

Ein gleichwertiger Drehgeber kostet maximal 2,50. Die 30 LEDs haben 
einen Wert von maximal 6 Euro. Macht 10,- gespart. Bei 48 Kanälen wird 
schnell klar, dass man im Selbstbau auf 850,- Materialwert für die 
beleuchteten Encoder kommt.

Ich setze dagegen ein: Duo-LED, PLCC4, €0,29 sind belastbar mit 150mA 
bei 10% ED. Durch die angestrebte 1/16 Teilung in der Abtasttung ist die 
ED 6,6%. Also darf ich die 150mA ohne Bedenken draufgeben. Angenommen, 
ich fahre die voll, so komme ich auf 10mA "effektiv" - das wäre die 
halbe nominelle Stromstärke. Müsste man Testen, wie hell das wird / 
wirkt. Wenn ich vor die LEDs einen Treiber setze, kann ich mir die 
Transistoren sparen und die Leuchtstärke garantieren. Designen wir also 
sicherheitshalber noch 2x4 SIPOs je Kanal, macht einen €2,- und etwas 
Platzbedarf.

Ich kann also im Bezug auf die Steuer- und Anzeigegenauigkeit den 
Leistungsumfang des Drehgebers glatt verdoppeln und bin trtzodem noch 
locker unter €14,-! Für das gesparte Geld (€190,-!!!) bekomme ich schon 
die Platine und die FPGAs. Noch billiger wird es mit bedrahteten LEDs, 
damit wird aber der Kranz grösser - ca 50mm.

Ich schaue mal, was der Spartan so an Leistung kann. Gfs kann man mit 
gekoppelten Ausgängen noch etwas machen und jeweils eine 8er LED-Gruppe 
auf eine Teilplatine setzen und mit einem FPGA direkt bearbeiten. Dort 
leuchten maximal 2LEDs x 8 x 20 mA = 320mA. Das packt der in Summe und 
auch jeweils pro Kanal (5mA bei Doppelbelegung). Die Treiberchips würde 
ich aus Platzgründen gerne weglassen.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du die Werte der Drehencoder nach dem Aus- und wieder Einschalten 
erhalten willst, fehlt da aber noch ein Speicher a la EEPROM oder 
ZeroPower RAM.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jürgen S. (engineer) Benutzerseite

>Der kleine 50er, den ich mal verbaut hatte, lag unter €3,- bei
>Stückzahlen.

In Stückzahlen. Welchen Stückzahlen? Ereichst du die mit dem 
Hobbyprojekt?

>Reichelt hat einen solchen ALPS Drehgeber mit 31 LEDs, zu 17,95:
>"EC11B1524B-LED".

>Ein gleichwertiger Drehgeber kostet maximal 2,50. Die 30 LEDs haben
>einen Wert von maximal 6 Euro. Macht 10,- gespart. Bei 48 Kanälen wird
>schnell klar, dass man im Selbstbau auf 850,- Materialwert für die
>beleuchteten Encoder kommt.

Äpfel und Birnen. Du vergleichst einen Verkaufspreis incl. Fertigung mit 
reinen Materialkosten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Warum so aufwendig?

Ich würde einen ATtiny25 nehmen, der ist vollkommen ausreichend.
2 Pins lesen den Encoder ein.
2 Pins steuern per M5450 bis zu 34 LEDs (SW-PWM möglich).
2 Pins zur Ausgabe des Wertes als I2C-Slave.
Fertig.

Man könnte noch nen Bootloader vorsehen, damit man ein Update per I2C 
machen kann, falls die Funktion mal erweitert, geändert werden soll.


Peter

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Matthias Sch. schrieb:
> Wenn du die Werte der Drehencoder nach dem Aus- und wieder Einschalten
> erhalten willst, fehlt da aber noch ein Speicher a la EEPROM oder
> ZeroPower RAM.

Braucht man in der Regel nicht, weil ein Einschalten meist "Bedienung 
eines neuen Geräts" gleich kommt. Die Zustände des Geräts stimmen dann 
eh nicht und können auch nicht schlagartig auf den Stand gebracht 
werden.

Im Falle des MIDI Controllers würde ohnehin der Sequenzer den Dump 
abfangen und man würde alles von dort laden, wie üblich. (Die 
angeschlossenen Geräte haben auch keinen Ausfallschutz).


Falk Brunner schrieb:
> Äpfel und Birnen.

ok, man müsste die LEDs löten und gfs die Buffer/Controller und der 
Encoder ist schneller verdrahtet. Das war aber auch nur ein 
Rechenbeispiel, denn ich ich werde den Geber nicht nehmen, weil er keine 
Farben kann. Die Zahl der LEDs hätte gut gepasst, aber ich brauche den 
Anzeigebereich.

Mit den 31 LEDs kann ich:

0...31, 0...62 (mit einer Hilfsfarbe noch eins mehr)

0...16 (16 Positionen + 17 Trennstriche) - s.o.
1...10 (10 Positionen a 2 LEDs mit 11 Trennstrichen) - s.o.

und die Teiler - also 3,5,6,8 direkt anzeigen.


Mit 3 Farben rot, grün, gelb kann ich die Trennstriche jeweils in einer 
anderen Farbe gestalten. Ich habe auch Kontrolle über die Balken und 
kann mich entscheiden, ob ich nur eine Positions-LED anmache, oder den 
ganzen Strang. Bei Mono-Stereo z.B. kann ich links/recht faden und die 
Mitte in Grün anzeigen.

Vor allem kann ich mit 3 Farben 3 Stellen markieren und damit bis 0xFFF 
und 999 zählen.

Über einen Controller

Das liefe dann auf eine Einzelmodulbauweise hinaus mit eigenständigem 
Controller. So macht das ja das  eine Modul im Netz. Hat einen 
Controller und I2C soweit ich mich erinnere.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ich würde einen ATtiny25 nehmen, der ist vollkommen ausreichend.
> 2 Pins lesen den Encoder ein.
> 2 Pins steuern per M5450 bis zu

Ok, einen Controller könnte man setzen, um sich die Chips zu sparen wenn 
er sich rechnet. Erste Recherche ergab: 3,10 pro Stück und soweit ich 
das ersehe, ist er dann immer noch am multiplexen.

Da ich ohnehin den FPGA brauche (z.B. für den schnellen Logarithmus beim 
VU-Meter am Lautstärkeregelknopf) kann man die i2C auch gleich in den 
FPGA tun und den Tiny absorbieren.

Ich bin auch nicht sicher, wie schnell man den Chip updaten kann. Um 
schneller, als das Auge zu sein, brauche ich (experimentell bestimmt) 
60-70 updates der Anzeigen. 70x50 = 3500 kHz update-Frequenz. Mit etwas 
Umschalterei also rund 250us für den Zustand der 30 LEDs. Der Chip wird 
es können, aber der Tiny sicher nicht :-)

Autor: Duda (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Braucht man in der Regel nicht, weil ein Einschalten meist "Bedienung
> eines neuen Geräts" gleich kommt. Die Zustände des Geräts stimmen dann
> eh nicht und können auch nicht schlagartig auf den Stand gebracht
> werden.

Ich finde das Projekt ansich nicht uninteressant. Jedoch würde ich bei 
einem Projekt, welches ja auch andere interessieren und zur Mitarbeit 
motivieren soll, nicht "gewünschte" Features als "braucht man nicht" 
abtun. Das machen schon die großen Betriebssystemhersteller zur Genüge.

Einschalten bedeutet immer erst, das System auf einen definierten 
Zustand zu bringen (also erst einmal alles auf "aus"). Danach wird der 
letzte Zustand geholt und das System auf diesen Stand gebracht.

Ich würde als Projektleiter gerne die Wünsche anderer einflechten - 
zumindest soweit es sinnvoll ist und im Rahmen bleibt.

Jürgen S. schrieb:
> soweit ich
> das ersehe, ist er dann immer noch am multiplexen.

Klar, ist aber auch kein Problem, das zu tun. Oder willst Du jede LED 
einzeln ansteuern?

Auch darf man nicht unbedingt die Preise bei Reichelt als Maß nehmen. Es 
gibt noch günstigere Quellen die auch noch mehr Auswahl haben.

Autor: Roman (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Jürgen,

dann schau doch mal bei Sparkfun:

Rotary Encoder LED Ring Breakout Board - Blue
COM-10407

Sieht gut aus mit Beispielcode. Die "paar" LED mehr bekommst Du doch 
bestimmt noch unter als engineer.

Gruss

Roman

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Duda schrieb:
>Oder willst Du jede LED einzeln ansteuern?
"Wollen" nicht, aber es scheint das zweckmässigste zu sein, sie per 
Latch zu treiben und das Updaten zu multiplexen:

Ich habe jetzt einen routing-Versuch gemacht und komme zu dem Ergebnis, 
dass es zu viel Platz kosten wird, die Leitungen alle auf ein zentrales 
FPGA zu führen, auch wenn es vom Multiplexen (Zeit- und 
Strom-Randbedingungen) her klappen könnte. Daher gibt es zwei 
Möglichkeiten:

1) Entweder, man nutzt eine Luftverkabelung und führt alles auf ein 
entsprechendes FPGA-Evalboard. Dazu könnte man LED-Testplatinen 
erwerben, die es bei LED-TECH.DE zu 6,95 gibt und auf denen man bis zu 
60 LEDs ringförmig dicht verlöten kann und akzeptiert den grösserem 
Radius. Dummerweise haben die die Bohrungen longitudinal angeordnet. Bei 
transversaler ANordnung könnte man die flachen Rechteck-LEDs verbauen.

Gfs ginge es auch mit der kleineren Platine zu 4,95, wenn man selber in 
den Massering reinbohrt.


2) Oder, man fasst die Leitungen lokal zusammen und multiplext die 
Information weiter vorne. Die Ansätze oben mit dem LED Chip und den 
Platinen von Sparkfun und der anderen, die ich schon nannte, laufen ja 
darauf hinaus, wobei ich definitiv ein Schieberegister bevorzugen würde, 
wie ich es hier auch schon mal beschrieben hatte: 
Erweiterung von digitalen IO-Ports.

Dafür brauche ich aber keinen weiteren AVR mehr oder I2C sondern schiebe 
die Daten in high speed rein. Damit brauche ich dann 1x den Takt sowie 2 
Leitungen (enable, daten) je Decodereinheit, die sich auch noch 
verketten liessen: Wenn das Schieberegister die LEDs transparent 
treibt(latch enables einsparen), wären das für die 32 DUO-LEDs 64 Bit = 
8 chips, die auf die Rückseite der Platine passen. Wenn man alle 8 
Einheiten einer Reihe verkettet, müsste man 512 Bits schieben, was bei 
EMV-freundlichen 5MHz nur 100us dauerte und praktisch unsichtbar wäre. 
Die LEDs würden dann z.B. 900us statisch sein und man hätte praktisch 
eine update-Frequenz von 1kHz, was auch für PWM noch reichte.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duda schrieb:
> Jedoch würde ich bei
> einem Projekt, welches ja auch andere interessieren und zur Mitarbeit
> motivieren soll, nicht "gewünschte" Features als "braucht man nicht"
> abtun.
Da hast Du natürlich vollkommen Recht. Ich bin natürlich für Vorschläge 
offen. Ich würde das mal gleich diskutieren:

> Einschalten bedeutet immer erst, das System auf einen definierten
> Zustand zu bringen (also erst einmal alles auf "aus"). Danach wird der
> letzte Zustand geholt und das System auf diesen Stand gebracht
Absolut, allerdings denke ich funktionell immer so, dass ich in allen 
Geräten die Eingabe, Verarbeitung, Steuerung, Ausgabe und Überwachung 
von einander trenne. Die LEDs sind Teil der Anzeigefunktion und somit 
für mich eindeutig ein Monitor des Gerätezustands, da eben die konkreten 
Werte des Gerätes angezeigt werden und nicht etwa die abstrakten 
Reglerpostionen, die meistens sinnfrei sind.

Dies genau ist aber der grosse Unterschied zwischen den fixen Positionen 
eines Potis in Grad, bzw eines fest beschrifteten Reglers und der hier 
verwendeten virtuellen Ausgabe von Werten: Sie sind die Folge der 
Reglereinstellung = Reaktion im bedienten Gerät und daher von diesem 
abhängig. Denken wir dabei z.B. mal an die Lautstärke, die man 
einstellt: Man dreht selten auf einen absoluten Wert "5", sondern auf 
den Wert, den man subjektiv will und die Anzeige sagt mir dann bitte 
schön, wie es mit der realen Aussteuerung aussieht.

Bei realen Geräten ist das festgelegt, daher steht auch etwas an den 
Reglern dran. Bei einem frei programmierbaren Gerät ist das aber nicht 
so. Abstrakt gesprochen ist die Funktion "Reglerskalierung" damit eine 
Eigenschaft des Gerätes und nicht eine des Encoders. Als geplantes 
Eingabegerät muss es daher den Zustand und die Funktion des Reglers 
nicht speichern.

Daher ist es nach meiner Einschätzung die Aufgabe des angesteuerten 
Gerätes, zu entscheiden, was es denn zur Anzeige bringt, wann es die 
aktualisiert und wo es die Daten eventuell speichert.

Im Midi-Umfeld macht das wie gesagt das Mischpult oder der Sequenzer - 
konkret kann man z.B. die Reglerdaten aus einer Software in ein 
Mischpult laden und das fährt dann die Motorfader dort hin. Mit den 
Drehencodern will ich dasselbe machen, wobei ich die ja nicht mechanisch 
positionieren muss.

Ich gehe sogar noch einen Schritt weiter in die Methodik "Funktionelle 
Anzeige":

Bei Synthesizern z.B. interessiert es mich eigentlich nicht wirklich, ob 
ich einen ADSR-Wert Attack von 3 eingestellt habe, sondern, ob es 
klanglich passt und wie gross die dabei erzeugte Aussteuerung ist. Diese 
hängt nämlich vom Basissignal und dessen Phase ab. Daher stellt man nie 
einen Wert zielgerichtet ein, sondern probiert das Passende und merkt 
sich den dafür benötigten Wert. Dabei hilft eine Pegelanzeige aber 
wesentlich besser, als die Anzeige der Reglerposition.

Was also dort als eingestellt und gespeichert werden soll, muss die 
Steuerung des Endgerätes für jeden Regler neu festlegen. Wenn das 
Eingabegerät beim Start alte Werte hochholen würde, wären die oft nicht 
nur sinnfrei sondern kontraproduktiv.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Braucht man in der Regel nicht, weil ein Einschalten meist "Bedienung
> eines neuen Geräts" gleich kommt. Die Zustände des Geräts stimmen dann
> eh nicht und können auch nicht schlagartig auf den Stand gebracht
> werden.

Meine erste Idee, als ich von dem Projekt las, war, das ich damit 
endlich Parameter bei der Programmierung von Synthies (z.B. meinem DX7) 
gleichzeitig im Griff habe, ohne umständlich auf der Folientastatur 
rumzutasten und darüber zu vergessen, welche Sorte Sound ich denn 
eigentlich machen wollte.
Da wäre das 'letzte Einstellung speichern' Feature genau das richtige 
gewesen. Ansonsten fällt mir gerade nicht ein, wofür man das Ding denn 
nun benutzen soll? Nenn mal bitte Beispiele.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Roman schrieb:
> Rotary Encoder LED Ring Breakout Board - Blue COM-10407

Der hier?

Diese Platinen haben schon was für sich, ja. Aber die Sparkfun ist recht 
teuer und soweit ich das sehe, nur einfarbig. Komplett kostet das Teil 
mit der LED-Einheit und Encoder über $20,- und damit wäre ich teurer und 
kaum weiter, als mit dem ALPS-Komplett-Encoder, der zudem kompakter 
wäre. Mit der SF-Lösung könnte ich gegenüber dem ALPS zwar flexibel 
ansteuern, hätte aber wieder eine Platine, die ich wieder in eine andere 
Platine einlöten muss, oder es doch wieder auf eine Luftverkabelung 
hinaus.

Was mir sehr gut gefällt, ist der LED-Aufsatz alleine: Den würde ich zu 
dem Preis ($9,99) direkt einlöten, wenn es Duo-LEDs wären, denn damit 
entfiele das aufwändige Bestücken der kreisförmig angeordneten LEDs.

Aber ich habe mich jetzt halt auf DOU festgelegt.

Meine Haltungist, wenn man den Standard haben will, braucht man nichts 
zu bauen, sondern kauft einfach. Ich möchte mit meiner Schaltung aber 
mehr machen und ich bin auch der Ansicht, das bessere Konzept zu haben:

Mit dem schnellen Schieben und dem FPGA habe ich alles in der Hand, die 
Anzeigen so zu bedienen, wie ich es brauche, kann es aber auch von der 
Steuerung des User-Gerätes machen oder kommandieren lassen. Vor allem 
kann das Ding autark laufen und viel mehr anzeigen, als alles andere, 
was ich bisher gesehen irgendwo habe, weil sich die Anzeigen mit dem 
Konzept der farbigen Trenner konfigurieren lässt. Nur ein Beispiel dazu:

Ich hatte schon einmal ein ähnliches Konzept ausgearbeitet das mit 4 
LED-BARs arbeitet, die wie ein Quadrat das Poti umranden sollten. 
Problem: Welche Farben nimmt man? Bei der klassischen Volumen-Bar hat 
man immer nur einige wenige Anzeige-LEDs und ist auf die Farben 
festgelegt, weil es eine feste Anzahl von gelben und roten gibt.

Mit meinem Konzept der DUO-LEDs kann ich die Anzeige verschieben: Hält 
sich das Signal z.B. im Mittel bei -20dB auf, blende ich einfach nur die 
gelben LEDs als Maximum ein und habe alle anderen als grüne LEDs zur 
feinen Anzeige des Pegels. Geht der Pegel langsam hoch, kann ich die 
Anzeige sofort virtuell verschieben und blende die roten mit ein. Der 
Übergang von grün nach gelb (-12 dB-Grenze) bleibt immer sichtbar und 
man hat eine Orientierung. Sowas geht mit keiner anderen Anzeige im 
Markt.

Eine weitere Möglichkeit ist das Anzeigen zweier Werte gleichzeitig: 
Durch Einblendung des Restpegels in Grün und eines Verlustes in Gelb, 
kann man die Wirkung eines Kompressors visualisieren, wobei die Summe 
der Gesamtpegel ist. Sowas gibt es nur in Software auf Monitoren und bei 
Mischpulten brauchen sie immer 2 LED-Ketten.

Was man machen könnte, wäre einen solchen Rahmen als Träger zu nehmen 
und die LEDs selber zu bestücken. Das wäre aber auch wieder aufwändig 
und kaum eine Ersparnis. Die rüde Methode, die mir noch eingefallen ist:

Man klebt die LEDs mit klarem Kleber direkt auf die Plexiglasscheibe und 
verdrahtet selber per Hand nach hinten. Als Test werde ich das gfs mal 
machen oder einen solchem LED-ring benutzen, aber langfristig scheint 
mir die Lösung mit den Schieberegistern das Beste. Gfs bekommt man ein 
taugliches 16-bit SR, das genug Strom treiben kann.

Was ich mir von der SPARKFUN-Version aber mitnehme, ist die Idee des 
beleuchteten Enconders. Damit lässt sich schön anzeigen, welcher Regler 
in einer Signalkette einen Datenüberlauf erzeugt.

Falls jemand weitere Quelle für LED-Ringe kennt, die manleicht verbauen 
kann, nur her damit. Ziel ist wie gesagt eine DUO-LED-Ring rot-grün mit 
32 Stück (31 geht auch) der möglichst klein gebaut ist. Optimal wären 
flache rechteckige LEDs.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Ganze irgendwann mal vielleicht in Kleinserie läuft, wird das 
doch eh maschinell per SMD bestückt. Du macht dir schon viel zuviel 
Gedanken über eher nebensächliche Details und verrennst dich in billigen 
Bastellösungen. Für einen Prototypen ist der BEstückungsaufwand 
nebensächlich, wenn gleich bei ~1500 LEDs schon etwas Arbeit 
dahintersteckt. Aber auch hier kann man SMD machen, Heißluft aus dem 
Baumarktfön wirkt Wunder.

Beitrag "Re: Zeigt her eure SMD löt-Kunst !"
Beitrag "Re: Zeigt her eure SMD löt-Kunst !"

Autor: Duda (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Daher ist es nach meiner Einschätzung die Aufgabe des angesteuerten
> Gerätes, zu entscheiden, was es denn zur Anzeige bringt, wann es die
> aktualisiert und wo es die Daten eventuell speichert.

Ok, Du trennst also Eingabe und Anzeige. Es soll also kein, sagen wir 
mal, Poti-Ersatz darstellen, welcher von sich aus die letzte Einstellung 
beibehält. Verstehe. In diesem Fall braucht man keine 
Zustandsspeicherung.

Liefert Dein FPGA einen eingestellten Wert an die Steuerung oder dient 
er nur zur Anzeige? Du schreibst, dass er auch gleich MIDI machen 
könnte.

Hierzu müsstest Du den FPGA ja noch einige variable Parameter 
übermitteln (Min-/Maxwert; Schrittweite; Beschleunigungsfaktoren und 
welchen Wertebereich die LED anzeigen müssen).

Sehe ich das richtig?

Was spricht dagegen, ein kleines EEProm einzubinden, welcher die 
Parameter speichert (man muss sich ja nicht verwenden)?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Du macht dir schon viel zuviel
> Gedanken über eher nebensächliche Details und verrennst dich in billigen
> Bastellösungen.
inwiefern? wo habe ich eine bastelösung vorgezogen?

Es geht um Machbarkeit und Kosten.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Moin,

mal ein paar Ideen.

Woran das ganze Projekt IMHO krankt, ist der monolithische Ansatz mit 
dem vergleichsweise riesigen 8x6 Block. Ich würde so etwas viel 
modularer planen. Im Extremfall ist jeder Drehgeber samt zugeordneter 
Anzeige ein einzelner Block. Man kann aber auch Grüppchen von 4 o.ä. 
bilden. Ziel der Modularisierung wäre zum einen Flexibilität gegenüber 
dem Anwender ("wir können ihnen ein Eingabefeld NxM anbieten für 
beliebige M und N aus [1..16]") und zum anderen die Möglichkeit der 
Massenfertigung.

Jedes dieser Module wäre logisch ein Eingabegerät und eine eigenständige 
Anzeige. Die Zuordnung zu Funktionen ist Software, damit hat so ein 
kleines Modul gar nichts zu schaffen. Insbesondere würde das Modul nicht 
selber eine Verknüpfung von Eingabe und Ausgabe vornehmen, sondern das 
anzeigen, was der Controller vorgibt.

Elektrisch müßte jedes Modul eine bidirektionale Schnittstelle haben. 
Wegen der Routingproblematik würde man sicher etwas serielles wollen. 
Und für die Skalierbarkeit etwas schnelles. Also evtl. I²C, vielleicht 
besser SPI. SPI hätte auch den Vorteil, Module physikalisch lokalisieren 
zu können (MISO, MOSI, SCLK durchgeschleift, aber jedem physischen 
Modul-Platz ein eigenes SS). Dann könnten sich Module gegenüber dem 
Controller identifizieren. Und man könnte verschiedene Typen von Modulen 
verwenden. Z.B. mit numerischer Anzeige (2 oder 3 Stellen 7-Segment) 
statt des LED-Rings. Oder ganz ohne Anzeige. Oder mit Absolutwertgeber. 
Oder nur Anzeige.

Auf jeden Fall bräuchte ein Modul auch eine (besser mehrere) Status-LED. 
Zum einem um Betriebszustände anzuzeigen ("Locked"). Aber insbesondere 
auch für eine "Locator" Funktion: "den gewünschten Parameter ändern Sie 
am Knopf mit der blinkenden LED".


XL

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Axel:

Das mit der Modularisierung hatte ich schon überlegt und wollte ich wie 
folgt lösen:

Jedes Anzeigemodul kann einzeln verdrahtet werden, sodass man sich 
aussuchen kann, ob man es mit einem einzigen Block durchschleift oder 
gruppenweise. Die gelben Punkte sind das Data-In der Register, die 
violetten das letzte Bis Q8. Die lassen sich auf der Platine und auch 
platinenübergriefend durchschleifen. Auch die Encoder können ja als 
Matrix ausgelesen werden, indem man jede einzelne Leitung aktiviert, 
oder z.B. A und B zusammenfasst und zwei Signale gleichzeitig ausliest.

Schaltungstechnisch muss man dann entweder jeweils eine eigene Leitung 
ziehen oder eine kleine Brücke einlöten, also vor allem von den 
Ausgängen der SRs auf das jeweils erste des nächsten Chips. Pro Platine 
gibt es ja 8 Stück. Modulübergreifend wird dadurch festgelegt, wieviele 
Encoder-Anzeigmodule aus elektrischer Sicht in einer Reihe arbeiten und 
wieviele in einer Spalte. Z.B. könnte man jeweils 8 Bit parallel über 
ein Byte schreiben und damit in nur 8 Takten alle LEDs setzen, was 
insbesondere für langsame Controller günstiger wäre.

Die Encoder möchte ich eigentlich direkt von hinten anschliessen und 
nicht auflöten, da sonst eine zu grosse Bauhöhe und damit Abstand der 
LEDs zur Frontplatte erzeugt wird. Die LEDs sitzen für mich direkt 
hinter der Frontplatte.

Geometrisch kann man die Platinen widerum anordnen, wie man möchte. Auf 
dem Nutzen werden zunächst wahrscheinlich 6 Stück sitzen - da es bis zu 
50x50mm sind und ich mit Euroformat plane.

Es gibt allerdings ein Platzproblem, die LEDs geben einen gewissen 
Mindestradius vor und die Chips (grau) und Widerstände nehmen auch noch 
etwas Raum weg. Ich hatte überlegt, die Module in 70x50 zu bauen, aber 
wenn man den Platz dann ausnutzen würde, z.B. für einen Controller, wäre 
man darauf festgelegt, die Platine auch so zu betreiben und man würde 
sich die Möglichkeit vergeben, sie dichter und vor allem quadratisch 
anzureihen. Das genau ist eines der Probleme der käuflichen Module. Wenn 
jemand mehr Platz auf der Frontplatte über einem Encoderblock haben 
will, um dort was zu beschriften, kann das ja immer noch leicht durch 
künstlichen Abstand erzeugen.

Mit der 3x2 Konfiguration hat man alle Opionen auf 3x4, 3x6, 3x8, 6x6 
und die angestrebten 8x6 ohne die Platine zusägen. Ausserdem wäre der 
Einstiegspreis nicht so hoch. 12,- für die Chips und ca 75,- für die 
Duo-LEDs. Die Hauptfrage ist, was die Platine kostet.

Wer einen Controller haben möchte (es mag Anwendungen geben, wo man das 
braucht - ich sehe das momentan nicht) könnte den Huckepack hinten drauf 
schrauben und dort auch gleich den Encoder einlöten. Man wäre dann auch 
frei, es so zu gestalten, dass ein Controller mehrere Module fährt.

Ich denke, dass der Vorschlag mit Controller I2C und SPI in jedem Modul 
zu sehr in Richtung autarke System ginge. Das Mehr an Intelligenz kostet 
Platz und Geld und ist eigentlich nur für langsame CPUs wirklich nötig. 
Der Aufwand an Takten bei einer I2C Kommunikation wird ja eher steigen 
und im Grunde will ich ja nur LEDs schalten, davon aber viele. Daher 
soll das so einfach wie möglich bleiben. Komplexe Module mit 
Kommunikation gibt es ja bereits. Wie schon dargestellt, würde ich am 
Liebsten sogar die Schieberegister weglassen, aber es gibt dann ein 
Problem, sehr viele Module zu multiplexen und vor allem durch die Luft 
oder gar über die Leiterplatte zu verdrahten und gfs möchte man doch mal 
mehr, als nur 2-3 je Anzeigemodul anschalten, womit es ein Stromproblem 
gibt.

So, wie ich es jetzt plane, sind das ausser zwei Leitungen für Power nur 
die 4 Encoder-Signale und die beiden Steuersignale CLK, DAT (für 
langsame CPUs braucht man gfs noch ein latch enable), weil die jeweilgen 
Signale einer Platine parallel und seriell verkettet sind (orange).

Nimmt man z.B. 8 Module, liessen die sich immer noch in Kette betreiben, 
die Encoder als Matrix -> 8 Eingänge für die linken Schalterseiten der 
Encoder, von denen einer aktiv und die anderen tristate sind sowie zwei 
Ausgänge für A und B. Bei 32 Modulen könnte man dann einfach 8 Leitungen 
parallel zurücklesen, in einem Byte speichern und nacheinander 
verarbeiten.

>Status LED
Da musste ich jetzt echt schmunzeln: Ein Modul, dessen Hauptaufgabe es 
ist, LEDs anzumachen mit soviel Interligenz zuzustopfen, dass man noch 
einen Funktionsindikator braucht, finde ich cool. Mir reicht es, wenn 
die LEDs selber glühen :-)

Richtig ist natürlich, dass das timing passen muss. Da darf sich nichts 
verzählen oder vertakten, sonst glühen die falschen LEDs. Anderseits 
wäre das im PWM-Betrieb gar nicht so dramatisch, meine ich. Trotzdem 
würde man ausreichend niedrig takten.

Autor: Joern G. (joern_g83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe ich das richtig, dass bei der Realisierung mit Fpga noch serieller 
Flash (für PROM) und 3 Spannungen dazukommen? Also 5v (grüne und blaue 
LED), 3,3V (max. FPGA-IO) und 1,2V (FPGA intern). Wenn es dann noch 
evtl. 2 FPGAs sein sollen, dann werden dass doch schnell 20,- bis 30,- 
nur für die 2 FPGAs mit Drumherum?
Oder sollen die kleineren Spannungen einfach linear realisiert werden um 
Geld fur DCDC zu sparen.

Cu joern

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den paar mA für den FPGA tuns einfache Linearregler für eine 
Handvoll Cent.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn der FPGA auch Stromausgänge wie die Ansteuer-ICs (M5450, 
MAX7219)?

Ansonsten brauchst Du ja für jede LED noch nen Vorwidersand.


Peter

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joern G. schrieb:
> Sehe ich das richtig, dass bei der Realisierung mit Fpga noch serieller
> Flash (für PROM) und 3 Spannungen dazukommen?
Ich habe jetzt die Ansteuerung ausgeklammert, da das Modul auch von 
einem UC angesteuert werden können soll. Das geht ja nun, weil ich die 
LEDs mit den Schieberegistern statisch mache und das update beliebig 
langsam erfolgen kann. Wenn es mit einem FPGA gemacht wird, muss 
irgendeine Plattform dran, nämlich die, die auch die Steuerung enthält.

Da eignet sich vom Timing her auch ein Spartan 3A Starterkit zu 39,-.

Wenn man die Funktion dem Gerät zurechnen möchte, weil man einen eigenen 
FPGA nur fürs Ansteuen verwenden will, muss man, wie Du richtig 
vermutest, das FPGA und die Umbeschaltung rechnen, also Flach, JTAG, gfs 
auch RAM und Regler. Macht irgendwas zwischen 20,- und 50,-. Angesichts 
der Kosten für die Kanäle ist das aber unerheblich, da nur einmal 
benötigt.


Peter Dannegger schrieb:
> Hat denn der FPGA auch Stromausgänge wie die Ansteuer-ICs (M5450,
> MAX7219)?

Das ist das Problem! Die Ausgänge des FPGAs können zu wenig treiben, um 
eine ausreichend grosse Anzahl von LEDs gleichzeitig bedienen zu können, 
sodass der FPGA bei wenigen Modulen die günstigste Lösung ist. Darum bin 
ich ja auf die Schieberegister gekommen. Die nehmen zwar Platz weg, 
bzw. müssen auf die Gegenseite der Platine, aber sie entschärfen die 
Multiplex-Problematik und Stromtreiberproblematik - machen das Modul 
damit aber autark genug, um es einzeln oder in Gruppen nutzen zu können.

Die Mehr-FPGA-Lösung, wie ich sie weiter oben angedacht hatte, wäre für 
den Fall denkbar, dass man gleich 8 Gruppen von LEDs mit einem FPGA 
multiplext. Dieses träte dann an die Stelle der Anzeigentreiber. Das 
wäre auch günstig genug gewesen, widerspräche aber der Modulbildung. Die 
ist aber nötig, damit auch die vielen Benutzer von Microcontrollern und 
die, die nur wenige Kanäle haben wollen, das Modul nutzen können.

>Vorwiderstände
Genau wie die FPGAs brauchen auch die SR natürlich Vorwiderstände und 
zwar zwei unterschiedliche je LED (rot /grün) = 2 x 32. Klar, könnte man 
jeweils eine je GND-Pfad nutzen, dann dürfte man aber auch nur eine 
anschalten. Ich rechne daher mit 64 Rs je Platine.

>MC5400
Einen Anzeigentreiber mit Stromausgang wollte ich nicht nehmen. Der 
MICREL 5400 z.B. sieht auf den ersten Blick nett aus und spart auch 
Leistung, weil er stromgeregelt ist und auch genau 2 Kanäle passend zur 
DUO-Geschichte hätte, er fällt aber wegen der Kosten weg, denn er kann 
nur 2x8 LEDs treiben - man bräuchte daher 4 Stück und jeweils noch einen 
Transistor - siehe Datenblatt.

Vom Platz wäre es nicht wesentlich günstiger da er SO28 ist - zudem 
leistet er auch nichts anderes, als Schieberegisterfunktion. Die 
Standard-SR bringen zwar nur 8Bit - die (32 LEDs * 2Farben / 8Bit) = 8 
Bautsteine kosten aber nur je 0,25, zusammen also 2 Euro.

Gesucht wäre also ein oder mehrere Chips, die Stromausgänge haben, 
insgesamt 64 LEDs treiben können und in Summe weniger, als 2 Euro 
kosten. Ich denke, das ist nicht zu finden :-)

An der Stelle muss man aber genau auf die Kosten schauen, weil sie je 
Kanal einmal anfallen. Was ich im Markt gefunden haben kann maximal 34 
LEDs und kostet minimal 4,-. Das waren 6 Euro mehr für jeden Kanal.

Die Platine ist ohne einen FPGA auch einfacher herzustellen und selber 
zu bestücken. Ich selber werde dennoch einen FPGA dranbringen und auch 
testweise die SRs nicht bestücken, um das mal zu testen. Der FPGA wird 
aber der sein, der auch die Hauptaufgabe des Zielgerätes leistet. Für 
noch einen lokalen FPGA oder einen Mikrocontroller sehe ich keinen 
Bedarf.

So, wie ich es derzeit plane, kommt der Normalanwender allein mit der 
Anzeigenplatine aus, in der der Encoder eingeschraubt wird. Die 
Ansteuerung ist simpel und kann beliebig langsam erfolgen. Im 
einfachsten Fall braucht man 2 Leitungen zum Schreiben und 3 zum Lesen. 
Das kann man an jeden Controller dranhängen. Mit einem Europanutzen hat 
man 6 Platinchen, die jeweils mit Bauteilen zu unter €15,- bestückt 
werden, was ein sinnvolles Verhältnis von Platinenkosten und Bauteilen 
ergibt.

Ich denke, das ist für Viele interessant und eine gute Ergänzung zu 
vielen Bastelprojekten. Wie gesagt, besteht das Interessante aus der 
logischen Trennung der Anzeige und der Eingabe. Damit kann man das 
direkt verknpüfen, muss es aber nicht, sondern kann auch die Wirkung 
des Drehreglers darstellen, wie ich das oben bereits angedeutet habe.

Meines Wissens gibt es noch kein Gerät am Markt, dass das so leistet, 
bzw nutzt. Alle Systeme, die mit beleuchteten Encodern arbeiten, stellen 
den Reglerwert indirekt dar und dies auch viel zu ungenau. Mit meinem 
Konzept, drei Farben zu nutzen, kann ich ohne die Nutzung der 
Zwischenstufenlösung 32*32*32 Werte = 15 Bit direkt zielführend 
einstellen - mit Zwischenstufen sind es 18 Bit. Und ich kann sie auch 
darstellen.

Wenn man die dezimale Teilung verwendet, kann man sie auch sehr leicht 
interpretieren und beim Multiplexen der Stellen sogar direkt ablesen. 
Wie eingangs erwähnt, ziele ich auf die Wertevorgabe von 0 ... 999, die 
ich in die 10 Bit verpacken will. Siehe die 10er Teilung im Bild
Beitrag "Re: Universelles Eingabegerät mit Drehencodern"

Wenn man die Anzeigen nicht farbmultiplext, kann man immerhin noch 2 
Farben darstellen, also rot und grün überlagert. Dann sind wenigstens 
32x32 = 10 Bit in Hex direkt einstellbar. Ablesen und interpretieren 
kann man zumindest einen Hexwert von 0..FF.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Gesucht wäre also ein oder mehrere Chips, die Stromausgänge haben,
> insgesamt 64 LEDs treiben können und in Summe weniger, als 2 Euro
> kosten.

Den MAX7219 kann 64 LEDs, kostet allerding 3,40€ (Schukat).
Man kann ihn sehr einfach kaskadieren.


Peter

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip. Der Chip kann neben 8x7Segemnt in der Tat auch 64 
einzelnen LED-Bits - wie genau sie adressiert werden, muss ich nochmal 
schauen. Das Protokoll wäre gfs etwas aufwändiger, bei 10MHz Datenrate 
aber sicher kein Problem, die gewünschte updaterate zu erreichen. Der 
Chip hätte den Vorteil, dass er die Helligkeitsregelung selber macht und 
damit keine PWM benötigt wird. Damit kann auch von langsamen 
Mikrocontrollern eine Helligkeitsmdulation betrieben werden. Ausserdem 
ist er im bastelfreundlichen DIP verfügbar. Der Mehrpreis wäre zu 
tolerieren, denke ich.

Die Helligkeitsregelung, die ansonsten nur mit einem FPGA machbar wäre, 
ist nämlich schon wichtig, denn mit etwas Geschick kann man ja die drei 
Farben zeitlich/optisch mischen, um "giftgrün" und orange darzustellen. 
Gerade merke ich nämlich, dass ich noch 1-2 Farbstufen gebrauchen 
könnte, um Werte, Bereichsgrenzen von einander abzugenzen. Für meine 
dB-Anzeigen hätte ich nämlich gern die beiden Farben gelb und betontes 
gelb, sowie orange und betontes orange für die beiden Seiten links und 
rechts.

Ich denke, den sollte man eindesignen.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Den MAX7219 kann 64 LEDs, kostet allerding 3,40€ (Schukat).
Hättest Du einen link? Ich kann den chip (auch sonst nirgends) finden.

Inzwischen habe ich noch etwas in der Bucht gefunden: Einen kompletten 
Krankz zum Multiplexen für angenehme $3,89. Liesse sich für eine 
vereinfachte Version nutzten. Auch nur monochrom und mit nur 16 LEDs, 
aber schon mal erheblich billiger, als die blaue Platine von oben.

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Projekt interessiert mich. Wie weit ist es bisher gediehen? Wie wird 
die Schnittstelle realisiert werden, kann ich da mit einer hardware 
dran?

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das Projekt interessiert mich. Wie weit ist es bisher gediehen?

Der TO scheint sich auf die Rückkehr zum Boden der Realität zu befinden.

MfG Spess

Autor: A. S. (rava)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
ich bastel gerade an etwas Ähnlichem:

- low-cost drehencoder von pollin (0.75€ incl. Taster, dafür hässlich 
wie die nacht finster)
- LED-Kranz mit 31LEDs
- 8Bit Auflösung (aber natürlich nicht in einer Umdrehung)
- inkrementeller Datenoutput über SPI
- absoluter Dateininput über SPI
- ATMEGA88-basiert (20MHz --> 10MHz SPI)
- Konstantstromquellen mit minimalem Spannungsverlust (etwa 1V) für 
weiße LEDs
- beliebig anreihbar über Jumperverbindungen
- edit: ich habe mich für THT-LEDs entschieden, weil der Encoder eine 
recht hohe Bauhöhe hat. So können die eckigen LEDs direkt auf Höhe der 
Frontplatte gebracht werden
- SMD-Bauteile nur einseitig bestückt, weil das sonst im Ofen fummelig 
wird!

Mein Ziel ist 45mm x 48mm - etwas zu groß für meinen Geschmack, aber 
irgendwo müssen die Leitungen ja hin! Kleiner wird es nicht - gerade die 
KSQs brauchen Platz.

geschätzte Materialkosten:
gut 6 EUR + etwa 3 EUR für die Platine (je nach Stückzahl)

aktueller Projektstand:
- Schaltplan ist fertig
- Board braucht noch routing, wird aber sehr eng
- Software: 0%

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> low-cost drehencoder von pollin (0.75€ incl. Taster, dafür hässlich
> wie die nacht finster)

Hmmm, Low-cost-Drehencoder von Alps, die überhaupt nicht hässlich sind, 
bekommt man hier:
http://stores.ebay.de/Logo-s-Elektronik-Kiste/Enco...

...

Autor: Mw En (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guckmal bei itead vorbei, da gibs nen 10er packen 2 layer Platinen für 
bis zu 50x50mm für 9 dollar.

Wozu so viele KSQs? Vorwiderstand hätte doch auch gereicht.

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Mein Ziel ist 45mm x 48mm - etwas zu groß für meinen Geschmack
Wieviele willst Du denn verbauen? Bekommt jeder seinen eigenen 
Controller?

Ich finde den Abstand von 45mm nicht unbedingt zu gross. Viel kleiner 
geht es ohnehin nicht, wenn man zwei benachbarte Regler gleichzeitig 
bedienen will. Die Finger brauchen schon 1cm Platz und einen weiteren 
zum Rangieren. 2x2 = 4cm. Ausserdem liessen sich so grosse Knöpfe 
installieren.

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein modularer Ansatz wäre vermutlich sinnvoll, man könnte module aus 
einem drehgeber mit LED-kranz bauen. Die würden dann an jeder Kante eine 
normale Buchsenleiste haben, Verbinden zw. Modulen erfolgt per pinheader 
der zwischen die beiden seiten gesteckt wird. Wenn jedes Modul dann noch 
"return" Bahnen vorsieht könnte man dann einfach ein gitter aus modulen 
bauen und die ecken mit "terminierungs-stecker" (einfach die 
Datenleitungen auf die return-leitungen geschalten) abgrenzen. (also 
quasi wie ne daisy-chain beim jtag).
Dann würde jedes Modul mit einem (sehr billigen) AVR aus dem 
Tiny-segment auskommen (einen Ring zu mpxen is locker drinne). man 
könnte dann in eine Ecke eine Art "Interface" (USB, MIDI, DMX, AUDIO, 
wasauchimmer) setzen das die tinys konfiguriert und ausliest.
Das verbessert die nachbaubarkeit (einen Tiny proggen kann quasi jeder) 
und reduziert die initialkosten (man muss nichgleich ein riesiges Borad 
kaufen).
Wenn du das Design richtig machst dann würde sich da vmtl. sogar auf 
Kickstarter was machen lassen.
Die Front kann man ja dann aus einem beliebeigen Material machen (die 
leute können sogar einfach plexi zuschneiden (lassen ?) und löcher 
reinbohren.
Wenn du das ganze Open-Sourced wird sich die Community sicher freuen.

PS: Sowas in der Art hatte ich auch schon einmal vor, bin dann aber an 
den hohen Kosten für PCBs zurückgeschreckt und jetzt wo ich mein 
Ätzlabor hab hab ich was anderes zu tun....

Autor: Max D. (max_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag (seit wann kann man nurnoch 15 mins editieren ?) :
es reicht eigtl. wenn man nur in eine Richtung durch die Module fädelt 
(z.B. mit nem 10 Pin Header) an den Aussenkanten des Ganzen kann man ja 
die Zeilen verbinden.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> ich bastel gerade an etwas Ähnlichem:

[schnipp]

Ja, das sieht wesentlich vernünftiger aus als das, was der TE vorhatte.

> - low-cost drehencoder von pollin (0.75€ incl. Taster, dafür hässlich
> wie die nacht finster)

Hauptproblem dieser Encoder ist IMHO der Schaft mit ~11mm Durchmesser. 
Dafür gibts keine Knöpfe (falls einer der Mitlesenden eine Quelle kennt: 
her damit!). Außerdem haben die Teile eine für meinen Geschmack zu harte 
Rastung.

Die Alps-Teile bei ebay gibts mit 4mm Achse (abgeflacht)

> - LED-Kranz mit 31LEDs

Hier ist das weit größere Problem die mechanische Konstruktion. 
Rechteckige LED sehen zwar optisch gut aus, aber die Durchbrüche in der 
Frontplatte sind wohl nur als Spritzgußteil sauber hinzubekommen. Runde 
LED entschärfen dieses Problem, sehen aber nicht so schön aus.

> - Konstantstromquellen

Warum? Der Controller braucht ohnehin eine halbwegs stabile 
Betriebsspannung. Vorwiderstände reichen. Dimmen kann man ja per 
Software noch.

> Mein Ziel ist 45mm x 48mm - etwas zu groß für meinen Geschmack

Ich schließe mich einem Vorredner an: kleiner wird zu fummelig zu 
bedienen. Und größere Knöpfe sind auch bedienfreundlicher.


XL

Autor: A. S. (rava)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
die Begründung für die KSQs ist mal hier zu finden:
Beitrag "gefährlich kleiner Vorwiderstand vor LEDs"

ich habe mich zwar von der Schutzdiode getrennt und bin auf 15mA 
heruntergegangen (das Ganze ist am Ende eh dimmbar, also dunkler kann 
man schnell werden, heller nicht).

Trotzdem habe ich nur 1.0V... 1.4V Spannung zur Stromregelung übrig - 
meine Bedenken sind, dass das die Toleranzen (hier also fast 20% in U 
und I) so schlimm werden, dass man Unterschiede zwischen den LEDs 
wahrnehmen kann!

Die Herstellung der Frontplatte ist tatsächlich ein Problem - meine Idee 
war, eine dünne, schwarze Plexiglasplatte (1mm) zwischen LEDs und 
Gehäuse zu kleben - da geht dann wieder Helligkeit verloren, was aber 
bei 15mA ok sein dürfte. Runde LEDs müssten <1.5mm Durchmesser haben, da 
der THT-Beinchenabstand auf der Platine 2mm sind. Je größer die Teile, 
desto größer der Ringdurchmesser

Ich lasse mich gerne von anderen Encodern überzeugen - die Änderungen am 
Layout sind vergleichsweise schnell gemacht. Allerdings kann ich mich 
nicht auf eBay-Schnäppchen verlassen. Da habe ich den Anspruch, dass 
etwas mehr Verfügbarkeit vorhanden ist! Wenn der Posten weg ist, gehen 
die Preise wieder hoch.


Ich möchte hier auch nicht Jürgens Thread für meine Zwecke kapern; ich 
wollte nur einen Vorschlag für ihn bringen... Manche Aspekte helfen ihm 
vielleicht (welcher Encoder) - andere eher nicht.
Jürgen's FPGA-Projekt finde ich unheimlich interessant. Da ich mit VHDL 
nicht helfen kann, gilt: bei Interesse an den Encoder-Platinen PN an 
mich :)

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe so ein Layout, 26 Leds + optional 4  je zwei links und rechts 
oberhalb des Ledkreises oder der komplette Kreis.
Zwei Befestigungsbohrungen innerhalb des Ledkreises. uC ist ein Tiny.

Autor: Chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Schaltplan

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> geschätzte Materialkosten:
> gut 6 EUR + etwa 3 EUR für die Platine (je nach Stückzahl)

Was schätzt Du an gesamten Kosten inklusive Controller? Käme das 
billiger?

Deine Schaltung verwendet ja keinen Anzeigentreiber, daher muss das 
alles der Contoller schaffen. Kann der dann auch Helligkeitsregelung der 
LEDs?

Hast Du ebenfalls zweifarbige LEDs vorgesehen? Mit gefällt die Idee, 
damit direkt die Werte auszugeben und die Farben verschieden nutzen zu 
können - hätte da auch einige Ideen. Wenn man das open source macht, 
gibt es sicher viele Interessenten. Ich habe das mit einem Kollegen 
diskutiert - es gäbe sogar ein Einsatzgebiet. Es müsste aber schon die 
Farblösung sein, da es ja fertig Platinen mit solchen Ringen gibt. Auf 
spark-fun sind die zu erwerben.

Mir persönlich würde als Frontplatte so eine Plexi-Scheibe reichen, 
wobei die nicht billig sind und auch nicht so einfach zu bearbeiten. In 
der Hobbythek gab es mal ein Beispiel, da haben sie unter Wasser gebohrt 
um die Scheibe zu kühlen.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> die Begründung für die KSQs ist mal hier zu finden:
> Beitrag "gefährlich kleiner Vorwiderstand vor LEDs"

Nicht ernsthaft, oder? Wieso müssen die LED für dieses Projekt weiß 
sein? Und was ist mit "maximaler Helligkeit"? Stinknormale grüne 
low-current (bzw. high efficiency) Typen nehmen und mit 10mA Pulsstrom 
betreiben. Wird für eine Statusanzeige mehr als hell genug werden. Oder 
müssen die Teile auch draußen im prallen Sonnenlicht betrieben werden?

> Die Herstellung der Frontplatte ist tatsächlich ein Problem - meine Idee
> war, eine dünne, schwarze Plexiglasplatte (1mm) zwischen LEDs und
> Gehäuse zu kleben - da geht dann wieder Helligkeit verloren, was aber
> bei 15mA ok sein dürfte.

Ja, so langsam wird mir klar, warum du möglichst helle LED haben willst. 
Weil du die Helligkeit gleich wieder vernichten willst :(

> Runde LEDs müssten <1.5mm Durchmesser haben, da
> der THT-Beinchenabstand auf der Platine 2mm sind. Je größer die Teile,
> desto größer der Ringdurchmesser

Ich hab gerade mal ein bisschen gerechnet. Wenn man runde 2mm LED nimmt 
(z.B. "LED 2MM FT GN" von Reichelt) mit 31 LED auf 270° (= 40 auf 360°) 
und mit 100mil zwischen den Innenpins rechnet, dann kommt man auf 
~32.5mm für den Innenkreis. Die LED-Köpfe liegen dann auf einem Kreis 
von knapp 35mm Durchmesser und einzelnen 2mm Bohrungen hätten 2.7mm 
Abstand. Das wäre noch halbwegs hinzukriegen. Und würde zu einem ca. 
50x50mm² Gesamtmaß führen.

Rechteckige LED 5mm x 2.5mm kannst du auch nicht dichter packen. Und du 
hast das Problem mit rechteckigen Durchbrüchen in der Frontplatte.

Sonst halt weniger LED nehmen.

Man hat mit Einzel-LED sowieso noch das Problem der gegenseitigen 
Einstrahlung: wenn du zwei LED direkt nebeneinander setzt und nur eine 
einschaltest, sieht die andere nicht "aus" aus, weil LED nicht 100% nach 
vorne abstrahlen, sondern immer auch etwas zur Seite. Du müßtest die 
LEDs also optisch entkoppeln. Die Profis nehmen da halt einen 
Lichtschacht (Spritzgußteil) der nicht nur die LED-Chips entkoppelt, 
sondern das Licht auch gleichmäßig nach vorn auf die Diffusorfolie 
leitet.


XL

Autor: A. S. (rava)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Klaus

wie meinst du mit "an gesamten Kosten"?
Die Bauteile kosten etwa 6 EUR, darin sind der ATMEGA88, die weißen
LEDs, die ich herausgesucht habe, der pollin-encoder, die pins und das
halbe Kilo Hühnerfutter, das da verbaut ist. Bestücken wollte ich sie
hier im Pizzaofen. Einen fertigen Controller, der das kann, was ich 
möchte, habe ich nicht gefunden! Es geht ja um SPI-Slave mit Ein- und 
Ausgabe!

Die Platinenkosten (3EUR) sind klar. Ich hatte aber nicht vor, bei einem
Chinesen zu bestellen - da es ein Hobby ist, kann ich mir das aus
Idealismus heraus leisten.
Es kann nicht sein, dass ich mich in einem Thread über miese Qualität
beschwere und die Umweltschutzflagge hisse, und dann hintenrum meine
Platinchen um die halbe Welt fliegen lass. Da zahl ich lieber in
Deutschland für die artgerechte Entsorgung der Chemikalien mit.


Die Idee mit den zweifarbigen LEDs gefällt mir auch unheimlich gut. RGB
wäre natürlich noch lässiger. Das wird aber mit dem ATmega ziemlich
knapp, da ich nur 23 I/O-Leitungen habe (mehr wird auch wieder ein
Platzproblem). Klar kann man Schieberegister benutzen. Aber erstens mal
fehlt der Platz und zweitens mal leidet die Geschwindigkeit - das müsste
ja dann in Software geschrieben werden - die Hardware SPI wird ja von
der Kommunikation nach draußen belegt.
Und beim Thema Geschwindigkeit sind wir beim der Helligkeitsregelung.
Das sollte der Atmega mit 20MHz schon hinbekommen. Im Moment steht da
eine 8x4 Multiplexerleitung und sonst macht er nicht viel: etwas
Tastenentprellung, SPI Slave geht automatisch, da wird doch das
Multiplexen so schnell laufen, dass man noch eine PWM einbaun kann...

Ich habe jetzt übrignes schon einen 2x3 Line-Decoder diskret aufgebaut,
da mir ein Ausgang fehlt. Ziemlich ärgerlich - aber immerhin bin ich
kurz vor einer ätzbaren Lösung. Ab und zu müssen halt Kompromisse her.

Für mich ist die einfarbige Lösung auch nicht weiter tragisch, da das
ein Midicontroller wird - Midi hat eben immer nur einen Wert pro
Controller. Daher kann ich damit leben.

Ich habs mal kurz durchgedacht. Mehrfarbig würde heißen
- SMD-LEDs sitzen etwa 5mm unterhalb der Oberkante vom Encoder. Das
verwischt doch hinterm Plexiglas, oder? Würdet ihr dann von 31 auf 15
LEDs runtergehen?
- RGB: 8x12 Multiplexing --> noch viel mehr Leitungen, auch wenn die
Unterseite dann nicht durchbohrt ist
- KSQs müssen mindestens für die blauen LEDs weiterverwendet werden. R&G
geht wohl mit Vorwiderstand; bei RGBW noch mehr KSQs
- Datenrate: je nach PWM-Auflösung braucht man dann pro Encoder mehrere
Bytes um sie anzusprechen (z.B. 4Bit-PWM, 31 RGB-LEDs = 3*1/2*31 = 48
Bytes). Eine große Encodermatrix (32 Stück) bräuchte dann 1,5kB. Das ist
nicht zwingen ein Problem - hängt aber von der Anwendung ab, was noch
alles in der SPI-Kette ist!

@Axel
Es kann sogar tatsächlich vorkommen, dass die Teile mal im prallen 
Sonnenlicht betrieben werden - ist aber eher die Ausnahme. Mich gegen 
"weiß" zu entscheiden, nur weil es etwas schwieriger ist (aber nicht 
merklich teurer), kommt irgendwie für mich nicht in Frage. Das 
Hühnerfutter für die KSQs kostet gut 60ct.

Auch die Sache mit den runden LEDs gefällt mir deutlich besser. Loch 
bohren und gut!
Aber denkt bitte auch dran, dass man oben die Löcher ins Gehäuse bohren 
muss. Alles was dünner als 1mm ist, zählt für mich nicht als fertigbarer 
Steg. Vielleicht käme man mit 1.5mm Löchern hin...
Oder unterschätze ich da die Herren an der Bohrmaschine?


Woher bekommen denn die Profis ihre "Lichtschächte"? Das würde mein 
Problem mit der Bauhöhe lösen - wir könnten dann einfach SMD-LEDs 
verwenden und alles herausführen. Eine schöne Farbmischung hätten wir 
dann auch gleich!

meine LEDs haben 2x3mm aber leider 100° Abstrahlwinkel. Eventuell kann 
man die rechteckigen LEDs so manipulieren, dass sie nicht gegeneinander 
einstrahlen: Oberseite abkleben und in schwarze Farbe tunken, damit sie 
nicht zur Seite wegstrahlen! Das geht mit runden nicht...
nur so als Idee!
Stellt sich halt immer die Frage, wie industriell der Anspruch ist. Wenn 
man das ein paar hundert mal gemacht hat, ist man bedient

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Hier der Schaltplan

Der Anschluß des Encoders sieht ja abenteuerlich aus. Hast Du das mal 
getestet?
Und Reset als Ausgang ist auch mutig, Du vertraust also dem ersten 
Schuß.

Ist ein ATtiny2313 denn zu groß?

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, habe ich und die Platine läuft auch, habe sie nicht hier, sonst 
hätte
ich ein Bild gemacht.

Der Taster wird nur über ADC gemessen. War ein Kompromiss meinerseits.
Ansonsten funktioniert das mittels der internen Pull-ups.
Dier zwei Solderbridges am Decoder lassen sich 4 I2C Adressen
einstellen, welche zum programmierten I2C Offset addiert werden.
R12 = R6 , R7 = 2x R6   . Getestet wurde es mit R6,R12=2k2 und R7=4k7
und R11 = 1Mohm . Die Werte werden im EEprom gespeichert.
Durch R12 bekommt der uC sein Deltawert für die Addressen raus, den
Wert des Tasters wird einfach abgespeichert/kalibriert, und er könnte 
auch
einen Wert von 100k oder 10k haben, dann könnte man bei der aktuellen
SW aber während des drückens den Encoder nicht drehen.

Ein ATtiny2313 hat keinen ADC. Die Pins IO1/2 sollten neben PWM auch
ein Poti einlesen können.

Man hätte die Schaltung auch anders lösen können, es hing halt damit 
zusammen daß man mehr Funktionalität zu einem späteren Zeitpunkt 
reinbringen
wollte und man dies mit minimalen Zeitaufwand, sprich routing gemacht 
hat.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reset ist natürlich als IO gefust, hatte ich vergessen reinzuschreiben.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Ansonsten funktioniert das mittels der internen Pull-ups.

Neben Exemplarstreuungen sind die auch noch temperatur- und 
spannungsabhängig.
Ein zuverlässige Lösung würde ich das nicht nennen.
Ist für nen definierten Pullup wirklich kein Platz mehr?

Chris schrieb:
> Ein ATtiny2313 hat keinen ADC.

Dann eben ATtiny861

Chris schrieb:
> Reset ist natürlich als IO gefust

Die LEDs daran werden aber deutlich dunkler sein, denn der ist nur ein 
schwacher Ausgang.
Figure 21-27: max 1mA bei 2V internem Abfall.

Update dann per Bootloader?

Autor: Chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
> Update dann per Bootloader?
Ja, HV Programmierung ist eventuell auch möglich.

> Ein zuverlässige Lösung würde ich das nicht nennen.
> Ist für nen definierten Pullup wirklich kein Platz mehr?
Beim Encoder ist im Prinzip wie ein OC Ausgang. Der interne Pull-up 
reicht.
Wenn die HW Addresszuweisung und der Encoderbetrieb bei gedrückter Taste
nicht gefordert wären, dann würde der Encoder an zwei Leitungen sein,
eine davon Reset und A wäre mit D sowie B mit E verbunden.

> Die LEDs daran werden aber deutlich dunkler sein, denn der ist nur ein
> schwacher Ausgang.
Im gepulsten Betreib geht es, trotzdem wird diese 6 Leds 5x mehr 
refresht
als die anderen leds.

Zurück zum Schaltplan, er gliedert sich in 4 Bereiche, einmal die 
gemultiplexten Leds, wo es für 4 Leds zwei Bestückungsmöglichkeiten 
gibt.
Oberhalb der Encoder. Unter dem uC die optionale PWM Filterung und als
letzer und wichtigste, der uC.

Angenommen ATtiny2313 , da würde ich den Taster auf den Reset Pin geben
und die zwei Encoder auf interruptfähige Pins. Keine Widerstände,
Masse geht auf C+D , E auf Reset oder ein freier IO Pin.

Reset, vcc/gnd sowie spi mit 6 pin micromatch Stecker,
Encoder direkt angeschlossen, 3 Pins (davon 2 Int) oder wenn man den 
Encoder nicht braucht, währen man die Taste drückt, dann genügen zwei 
Pins.

Es bleiben 12 übrig. Entweder 9 Pins für Led Mux und 3 für I2C Addresse,
klassisch, oder Adresse muss programmiert werden, und 2x 6 Pin Mux für
die doppelte Helligkeit.

Warscheinlich würde ich eine Alternativbestückung machen, einmal 2 
Leitungen für den Encoder, und Reset auf Pull-up oder 3 Leitungen auf
den uC. Eventuell alternativ anstelle des Reset Pins auch auf einen
I2C Adress Pin wenn man 9 Pins für das Mux benutzt.

Im Anhang ein Beispiel mit 36 bicolor Leds und dem Attiny2313, mal
als konkrete Diskussionsgrundlage. Es sind noch Solderjumper, um den
Taster routen zu können, die Defaulteinstellung ist eingezeichnet, um
das Signal auf PA2 (Reset) zu bekommen.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Schaltplan hat sich ein Fehler eingeschlichen,
SJ8 sollte von PD1 auf PRG gehen.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Spess53 schrieb:
>>Das Projekt interessiert mich. Wie weit ist es bisher gediehen?
> Der TO scheint sich auf die Rückkehr
Keineswegs, meine offline Zeit hat gänzlich andere Gründe.

Zum Thema:

Schön, dass es noch mehr Interessenten gibt. Wie ich weiter oben bereits 
ausgeführt habe, sehe ich es durchaus als praktisch an, die Anzeigen 
lokal zu verwalten. Der vorgeschlagene Chip von Peter wäre eigentlich 
ideal, da er die LEDs zweifarbig steuern kann (RGB sehe ich nicht als 
nötig, würde auch den Platz gfs sprengen) und zudem auch eine 
microcontrollerfreundliche Schnittstelle hat. Wenn sich das mit einem 
ATMEGA oder alternativem AVR machen liesse - um so besser.

Ich möchte nochmal ausführen, worum es mir bei der Geschichte überhaupt 
geht und worin sich die Idee von den käuflichen Lösungen unterscheidet:

- es gibt preiswerte Lösungen für 16 und 32 Stufen, sogar mit 
Frontplattenfähigkeit, diese sind aber nicht zweifarbig. Die 
Zweifarbigkeit ist aber nötig, um die impliziten Anzeigenskalierungen 
vorzunehmen, Anzeigenüberläufe darzustellen und die Layertechnik zu 
ermöglichen, wie ich es bei dem Stereopanner dargestellt habe, mit der 
mehrere Darstellungen möglich sind. Sowas gibt es derzeit nicht. Ich 
habe bisher überhaupt keine zweifarbige Lösung irgendwo gefunden.

- Ich benötige eine feinere Auflösung, als die käuflichen Lösungen 
ermöglichen. Diese kann man durch Software lösen oder 
hardwareunterstützt. Die favorisierte Lösung wäre eine 
Drucktastenfunktion in den Encodern, mit denen man das umschalten kann. 
Bezüglich der Nachfrage oben: Nein, die 1024 Schritte müssen NICHT in 
einem Dreh erzielt werden, es sollte aber möglich sein. Mit einer 
softwaregesteuerten Umschaltfunktion lässe sich das mehrstufig 
umschalten oder temporär mit gedrückter Taste gröbere Sprünge machen. 
Das ist auch in keiner der erhältlichen Lösungen integriert, obwohl 
einige mit Mikrocontrollern arbeiten. Auch dort kommt dann nur AB 
heraus. Ob man die selber programmieren kann, weiss ich nicht. Eine 
eigene Lösung ist da definitiv besser. Wenn man schon einen Controller 
nimmt, muss dann dort auch die Intelligenz rein.

- zum Thema FPGA: Auch wenn ich es nicht so deutlich dargestellt haben 
sollte, ein FPGA wird man brauchen oder einen Ersatz-Chip, dann die 
Verwaltung mehrerer Module wird kein Klacks. Es geht im Weiteren nämlich 
auch darum, die Daten rüberzuschauffeln und mit MIDI 30kBaud werde ich 
nicht anfangen. Ich verwende ein MIDI Protokoll, dass mit 25MHz 8Bit 
fährt, ich habe also eine 200 MBit Bandbreite. Um das vernüftig zu 
mangagen braucht man wenigstens USB2.0. Das Genau ist derzeit auch der 
favorisierte Standard im MIDI Bereich. Mit einem USB Controller im FPGA 
oder als Chip könnte man das Gerät dann überall dranhängen.

- RGB wäre natürlich superideal, aber vom Platz wohl nicht machbar, 
derzeit prüfe ich, ob es RGB-beleuchtete Drucktaster gibt. Das wäre noch 
eine Option. Die auf spark-fun angebotene Lösung kann zwar RGB, aber ist 
wohl keine Taste. Wenn da jemand was hätte, nur her damit.

- billige Encoder: Der Einwand der Wiederbeschaffbarkeit ist für den 
Punkt opensource ein Thema, wenn man aber einen Standardencoder 
vorsieht, sind die teilweise austauschbar, wenn es derselbe Hersteller 
ist. Von daher wird man im ersten Schuss schauen, dass man genug Teile 
erhält - egal woher - und wenn sie dann auf dem Tisch liegen die Platine 
beauftragen. Es müssten halt genug Bestellungen vorliegen, um vorab die 
Teile zu ordern. Richtig ist aber, dass man sich überlegen muss, welche 
Encoder man nimmt.

- dies betrifft auch die Qualität! Einige der EBAY-Dinger protzen mit 
gigantischen Schaltzeiten von 15000. Bei einem typischen 
MIDI-Controllerbetrieb mit 5-10 mooves per gewünschter Einstellung und 
10-50 Einstellungen pro Session wären die Dinger nach wenigen Wochen 
kaputt! Ich würde daher zu guten Encodern raten, die es in einer teuren 
und einer billigen Ausführung gibt. Gute Encoder kommen mit bis zu 2Mio 
Drehungen, d.h das Gerät würde auch bei extremer täglicher Nutzung fast 
10 Jahre halten - bei vielen Modulen entsprechend weniger. Das sollte 
man schon anvisieren, denn dies ist ebenfalls ein wesentlicher Grund, 
warum ich etwas Besseres haben will, als das, was es im MIDI Markt so 
gibt.

- die Frontplatte ist kein Problem. Selbst dunkle, rauchglasfarbene 
Plexiglasplatten lassen das Licht zu wenigstens 50% durch und dies 
reicht - es geht ja um die Abgrenzung zum Hintergrund. Da sind dann nur 
die Reflexionen von Aussen ein Problem und ja, das Gerät wird durchaus 
"draussen" verwendet, da Musiker auch mal einen Auftritt haben, wie man 
so hört. Bei Nutzung einer anderen Platte ist auch ein Durchbohren nicht 
nötig, wenn man die LEDs dicht anreiht und einen Ausschnitt für das 
Plexi vorsieht. Man bohrt einfach ein kreisrundes Loch in die 
Frontplatte (gfs eine Metallplatte) und öffnet damit ein Sichtfenster 
auf den Encoder und die LEDs. Dann kommt ein Stück Plexi unten drunter, 
dass nicht einmal kreisrund sein muss, sondern nur ein Loch für den 
Encoder hat. Wer dann will, kann den Encoder mitsamt Innenkreis wieder 
mit einer Scheibe abdecken. Es dürfte auch reichen, ein helles 
Plexiplaselement als Ganzes zu nehmen, um es zu unterlegen. Zudem ist es 
leicht möglich, dieses dann mit einer lichtdichten Folie zu bebleben. 
Damit kann man statt der Metallplatte die unerwünschten Teile abdecken 
und hat das Ganze in Leichtbau. Der initiale Gedankenschritt war dabei 
natürlich der in der MIDI-Welt übliche, nämlich den Austausch der 
gedruckten Folien gegen andere, um die Controller zu benennen und dann 
die verschiedenen Softwareprogramme nutzen zu können. Das hatte ich 
jetzt als bekannt vorausgesetzt.

- nochmals zur Intention der Anzeige mit LEDs an sich: Plexi als 
Milchglas ausgeführt lässt die Konturen der LEDs verschwimmen, Damit ist 
es möglich, durch eine Art von dithern mehrere benachbarte LEDs 
anzuschalten und den Kern des Lichtes langsm zu schieben, so wie das bei 
einem geglätteten wandernden Punkt auf einem Monitor passiert, der auch 
nicht notwendigerweise von TFT-Rasterpixel zum nächsten hüpft, sondern 
kriecht. Dazu müssen dann immer 2-3 LEDs gleichzeitig mit der 
angepassten Helligkeit betrieben werden. Aussen, hinter dem Milchglas 
sieht es dann so aus, als ob der Lichtkegel fein und stufenlos kriecht. 
Dies würde man z.B. in der Farbe grün machen, während die roten LEDs 
statisch an sind und die Teilungsstriche der Skalierung anzeigen. Auch 
sowas gibt es bisher nicht, weder als Funktion in einem Gerät noch als 
Option in einem Controller.
Damit wäre es erstmals möglich, mit LEDs Werte stufenlos anzuzeigen, 
wenigstens wäre es um Klassen genauer, als das was man bisher findet. 
Mit den käuflichen Teilen wird sich das nicht machen lassen, weil die 
LEDs nicht dicht sitzen und/oder man nicht an die SW rankommt - bez es 
dann doch alles händisch lösen muss.

- zu den Abständen: Ich habe einen Döpfer MidiController, bei dem man 
praktisch immer zwei Knöpfe gleichzeitig bedient, weil die keinen 
Fingerbreit Abstand haben. Das ist komplett untauglich und davon will 
ich weg. Das Gerät kann ruhig eine gewisse Grösse erlangen. Dann passt 
es wenigstens zu den Geräten, die damit gesteuert werden sollen. 5cm 
Rastermass halte ich für nicht übertrieben. Ein 4x8 System hätte dann 
gerade eine Dimension von 20cm x 40cm. Das ist nicht viel. Die Knöpfe an 
meiner Micro Q und dem Virus sitzen kaum dichter. Es ginge also nur um 
den Platinennutzen, derzeit operiere ich mit einem 2x3 System a 5x5cm, 
was gut auf eine Europakarte passt.

- zur Steuerung: Man könnte sich überlegen, wie man es schafft, die 
Controller einzeln anzusprechen. Entweder verpasst man ihnen eine 
codierbare Adresse oder man nutzt eine auto config Option, sodass sich 
die Controller selber in eine Adressreihe setzen. Dazu braucht jeder 
zwei Eingangs- und zwei Ausgangsleitungen, Nord, Süd, Ost und West. 
Jeder Controller liest auf West einen seriell gesendeten Code und sendet 
diesen um eins erhöht nach Osten ab. Wenn er keinen Code bekommt, nennt 
er sich Nummer 0. Das Ganze dann in Nord-Süd nochmal und man hat nach 
einem Einschwingvorgang eine (m x n) Matrix. Das klingt auf den ersten 
Blick komisch läuft aber in einer Applikation in der Praxis bereits 
bestens!

- Ich habe inzwischen eine lauffähige Animation des Controllers, die 
auch einige Lichtaktivität zeigt. Im Animator ist das allerdings nicht 
ganz einfach hinzubekommen, aufzuzeigen, wie man das Licht über die LEDs 
schieben kann. Mal schauen. Werde es auf YT hochladen.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achtung, es ist vieles eine Preisfrage.
Bei Bicolor Leds ist es vielleicht günstiger, Leds mit gemeinsamer 
Anode,
z.B. KINGBRIGHT ELECTRONIC L-119EGWT  anstelle von einer bicolor led mit
zwei Anschlüssen. Auf die Schnelle hatte ich keine gefunden, nur eine
Ovale, war aber um einiges teuer als die ca 8€cent teure Kingbright.

Vielleicht widerspricht mir aber jemand. Beim Muxen wird es eine 3 Chip
Lösung, sprich die Leiterplatte wird größer, bei TH Led, bei SMD Led
ist es irrelevant.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine LED mit gemeinsamem Anschluss wäre mir auch lieber, da man dann 
diesen Anschluss nach innen legen und, wie in einer Skizze angedeutet, 
den Kreis sehr viel enger ziehen kann. Trotz Unterschreitung der 
DRC-Abstände gäbe es keine Kurzschlussgefahr beim Löten. Wenn man es 
fürs "Bastellöten" auslegt, könnte man sogar auf Wärmefallen verzichten 
und nur eine Ringleitung entlang der Pads legen.  Damit wandern die LEDs 
noch weiter rein. Aussen wären auch mehr Platz für die Vorwiderstände. 
In der Animation habe ich die benötigten LED Treiber drin, von denen 
lassen sich die Leitungen relativ kreuzungsarm verlegen. Wie es bei den 
AVRs aussieht, weiss ich nicht.

Eine spontane Idee wäre, dass man auf 2 AVRs zurückgreift, was a) genug 
Rechenpower fürs Multiplexen schafft und b) die Verdrahtung entspannt, 
weil man die doppelte Zahl an IOs hat.

Es gibt dazu noch einen Punkt: Wenn man die LED Anzeige voll nutzen 
will, muss man unterstellen, dass weitgehend alle DOU-LEDs aktiv sind. 
Damit wären wir bei 32 x 2 x 10 mA = 640 mA, wobei die 10mA die 
gemittelte Stromstärke gemäss ED / Multiplexing darstellt. Könnte ein 
Problem werden.

Wenn man es 1:4 Multiplexed käme man mit moderaten Umschaltzeiten aus 
und bräuchte 40mA peak-Strom, was auch billige LEDs die locker können.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Eine LED mit gemeinsamem Anschluss wäre mir auch lieber, da man dann
> diesen Anschluss nach innen legen und, wie in einer Skizze angedeutet,
> den Kreis sehr viel enger ziehen kann.
Welche Skizze, welchen Kreis, wieso enger ziehen ?
Die Led ist 2mm breit, also sind es 26-30mm Außendurchmesser bei 32 
Leds.
Bei SMD sieht es aber anders aus.
Welche Led-Treiber, welche Led-Vorwiderstänbe und Animation?
Was habe ich da verpasst ?
Widerstände, es sind maximal 9 Stück, die sollte man doch unterbringen 
können. Wärmefallen, für was ?

> Es gibt dazu noch einen Punkt: Wenn man die LED Anzeige voll nutzen
> will, muss man unterstellen, dass weitgehend alle DOU-LEDs aktiv sind.

> Damit wären wir bei 32 x 2 x 10 mA = 640 mA, wobei die 10mA die
> gemittelte Stromstärke gemäss ED / Multiplexing darstellt. Könnte ein
> Problem werden.

>
> Wenn man es 1:4 Multiplexed käme man mit moderaten Umschaltzeiten aus
> und bräuchte 40mA peak-Strom, was auch billige LEDs die locker können.

Ein uC Port schafft 20-30mA. Wenn man 8x 4 Leds multiplext, dann sind es
8x 25mA = 200mA, bzw 240mA. Da die Led jedoch nur Rot/Grün/Orange ist,
halbiert sich der theoretische Strom von 240mA auf 120mA.
Weiters gibt es da die dot correction, also sind weitere 20mA weniger,
also 100mA was bleiben, wenn alle Leds an sind, was ca 3.6mA je Led 
bedeutet. Bei den Werten verzichtet man auf Widerständen.

Nehmen wir mal die Leds, bei der oben gemachten Rechnung sind es dann

Helligkeit der roten Farbe   1.6-4mcd
Helligkeit der grünen Farbe   1-3mcd

Ansonsten muss man mit 120-140mA 800µS pulsen und dann 200µS Pause,
sprich 1.2A peak ca, dann hat man mehr Leuchtkraft.

Wenn du die Leds nebeneinander hättest, sowie genügend Spannung, könnte
man mehrere Module vereinen, und ein Steuerchip verwenden und so kosten
sparen.

Was willst du? SMD, TH, Welche Größe, welche Leuchtkraft usw.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Leuchtkraft: Was geht und der Treiber (LED Treiber oder ATMEGA eben 
packen) - dimmen kann man immer.Sie sollten mindestes so hell sein, wie 
die im Bild mit den blauen LEDs. Das ist die Platine von MATHEWLABS.
http://www.pjrc.com/teensy/projects.html

Kreis: Ich habe in der Anim ganz oben einen Elementarabstand von 50mm 
für die Achsen aufgrund der Platinengrösse. Das bestimmt die Dichte mit 
der man die Module anreihen kann. Wesentlich wachsen sollte es nicht. 
Habe nochmal nachgemessen: Virus hat 34mm bei kleinen Knöpfen, was das 
Limit ist, weil man mit den Fingern die Nachbarknöpfe berührt. Bessern 
wären etwas grössere Knöpfe und etwas mehr Platz, also 40. Der Kreis der 
LEDs sollte deshalb so klein wie möglich sind, dass die Zwischenräume 
zwischen den Kreisen grösser werden, damit die Stege in den Bohrungen 
der Fontplatten / der Löcher in den Folien ausreichend gross sind.



Hier habe ich jetzt etwas gefunden: Die führen Encoder mit 
RGB-beleuchtbaren Knöpfe, die auch Tastfunktion haben.

http://www.cliffuk.co.uk/products/encoders/index.htm

Die von sparkfun meine ich auch gefunden zu haben:
http://www.archithings.com/new-led-illuminated-enc...
Leider nur 20000 Schaltungen und damit viel zu wenig. Siehe die 
Betrachtung im Beitrag weiter oben.

Schick sind auch die geöffneten Knöpfe in dem Bild:

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe nochmal etwas gesucht. tme hat RGB LEDs in 0603 Bauform. Das 
Gute: Die Spannungen liegen zwischen 2.0V und 2.8V. Damit könnte man die 
KSQs wegwerfen oder versuchen, auf 3.3V zu gehen (**troll**).
Leider werden das 10-12 cent pro Diode. Zweifarbige kosten auch schon 
die Hälfte. Trotzdem tendiere ich in "wenn-dann-richtig"-Mentalität zu 
RGB. Ich muss nochmal nachdenken, ob ich mein gesamtes Design neu machen 
werde. Die Idee ist es aber vermutlich wert. Und ohne KSQs dürfte sich 
der Aufwand zeitlich schnell rechnen - die Löterei von dem Hühnerfutter 
würde nämlich sicher widerlich werden.

Die Sache mit den Lightguides (Lichtleitern) ist platzmäßig und 
kostenmäßig nicht akzeptabel. Die Lösung mit einer einzigen 
Plexiglasplatte scheint mir aber machbar, was ebenfalls für die 
SMD-LED-Lösung spricht.

Ich denke derzeit an eine 4x12 Multiplexerlösung mit 4to16 Decoder. So 
kommt man mit nur 8 Ports des uCs hin (und hat noch Luft für andere 
Spielereien). Flaschenhals wird hier der Strom. Mehr als 6mA pro LED 
sind da nicht drin. Wenn man Platz für zwei 3to8-Decoder findet, lässt 
sich der Wert verdoppeln.


Jürgen, super dass du nach Encodern suchst. Ich stehe aber unheimlich 
auf metallische Kappen - leider gibt's die oft nur mit Indexstrich :(
Es sollte aber kein Problem sein, sowohl Lötstellen für die 
polling-dinger als auch für eine weitere Variante vorzusehen.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn wieder Decoder draufkommen, könnte man auch wieder eine Lösung 
benutzen, wo man den UC nicht bestückt und alles an FPGAs hängt. 
Wenigstens für wenige Module müsste das zu machen sein.

Der RGB Knopf muss nicht unbedingt sein, wenn die LEDs an sich schon 
genug Farbe bringen. Wichtig ist die Tastfunktion. Optimal wäre halt ein 
Layout mit flexibel bestückbaren Deocdern. Ich gehe mal davon aus, dass 
man das mit einem Hersteller machen können müsste: LED-oder nicht nicht 
wäre dann eine Frage von Bestückung.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frage:
Hast du eine Led mit definierter Leuchtkraft (Datenblatt) oder mehrere,
welche du an ein Arduino/Avr/Pic dranhängen kannst, einige Widerstände
sowie eine variable Spannungsquelle, lm317 zur Not.

Damit könntest du herausbekommen, wie hell denn die Led sein muss.
So Hell als Möglich, heisst 30mA Dauerleistung, denn ansonsten sind
nur 24mA möglich z.B. bei ogbenannter TH Led.

32 Leds * 30mA *2 (Farben) * 10 (Encoder) = 19.aA, weit entfernt von den
40mA*10 = 400mA welche du eingeplant hattest.

Ein 8 Channal Led-Driver kostet ca 43€Cent, 16 pin glaube ich.
Bei 32 dual color braucht es 8 Chips, RGB sind es dann schon 16.
Dies für die maximale Helligkeit, dafür braucht es nur vier Widerstände.

Puls driving heisst drei Led Driver und vier high side Mosfets.
Die Mosfets brauchen ca die größe eines halben ic.

Das blöde ist nur, 4x 16pin Chips sind nicht ohne, das geht nur bei
SMD Leds und doppelseitiger Bestückung.

Wenn man Led-driver nimmt, dann braucht man auch kein uC, kann man
gleich and das FPGA oder den uC dranhängen.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> ich habe nochmal etwas gesucht. tme hat RGB LEDs in 0603 Bauform.

RGB, also mindestens 4 Pins. Wie willst du das gerouted kriegen? 0603 
ist sicher nett für die Packungsdichte. Aber wenn du nicht gerade 
4-layer mit Mikrovias machen willst, sehe ich keine Chance, das zu 
layouten. Von der Ansteuerung (Platzbedarf, Strombedarf) reden wir 
besser gar nicht erst.

> Das Gute: Die Spannungen liegen zwischen 2.0V und 2.8V.
> Damit könnte man die KSQs wegwerfen oder versuchen, auf 3.3V zu gehen

Wohl kaum. Die Flußspannung einer blauen LED liegt nur bei winzigsten 
Strömen unter 3V. Oder anders gesagt: wenn so eine 0603 SMD-LED mit 2.8V 
für den blauen Chip zurecht kommt, dann beim gleichen Strom auch jede 
andere blaue LED. Der Unterschied ist, daß so ein 0603 Lichtpünktchen 
heller wirkt als eine 3mm LED. Nur ist das in deiner Anwendung Wumpe. Da 
zählt nur noch, wieviel Licht am Ende vorne ankommt.

> Leider werden das 10-12 cent pro Diode. Zweifarbige kosten auch schon
> die Hälfte. Trotzdem tendiere ich in "wenn-dann-richtig"-Mentalität zu
> RGB.

Ich sehe schon, das wird das nächste Projekt, das totgequatscht ist, 
bevor es überhaupt angefangen hat. Weil so lange weitere Sonderlocken 
dazu gepackt werden, bis es unrealisierbar ist.

> Die Sache mit den Lightguides (Lichtleitern) ist platzmäßig und
> kostenmäßig nicht akzeptabel.

Im Gegenteil. Lichtleiter oder Lichtschacht ist das einzige, was zu 
akzeptabler Optik führen wird. Wobei Lichtleiter noch den Charme haben, 
dem Entwickler zusätzliche Freiheitsgrade bei der Plazierung der LED auf 
der Platine zu geben.

Was daran nicht akzeptabel ist, ist die Tatsache daß man sie nach 
eigenen Vorstellungen nur in zig-tausender Stückzahlen bekommen kann 
(bzw. bezahlen will).


XL

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay. Wo kriegen wir eine akzeptable Lösung aus Guides her?
Die Stückzahl wird bei der erstne Bestellung bei 1000 liegen.

Ich habe zwei größere Elektronikversandhäuser durch.
Ich konnte sie nicht ringförmig angeordnet finden, also müsste man das 
aus Einzelteilen zusammensetzen. Ungeachtet des Preises (>20ct pro 
Stück) kann man sie nicht am PCB festmachen, weil diese eine viel zu 
große Grundfläche besitzen.

Höchstens so etwas käme in Frage (sogar >40ct pro Stück):
http://www.tme.eu/de/Document/f970b0cc8f38d62b0361...
Die werden einfach ins Frontpanel gequetscht, oder?


Axel, meinst du nicht, so wie das Jürgen vorschlägt, mit Plexiglas 
könnten wir hinkommen? Wo siehst du Probleme? Nur beim Verschlucken des 
Lichts? Schon mal ausprobiert?


die 2.8V der 0603RGBs sind bei 5mA gemessen. Sie sind aber (und ist das 
nicht wichtiger?) in der Größenordnung der grünen LED.
http://www.tme.eu/de/Document/314718caa47227d55208...
Eine gescheite Strom-Spannungskennlinie spuckt das Datenblatt leider 
nicht aus! In der Hinsicht war meine erste Wahl (weiß, rechteckig, THT) 
besser :P

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lightpipes finde ich für nicht bezahlbar.

SMD: da kann ich mir auch was zum Tiefziehen bauen, würde dann was 
zweiteiliges als Minimum. Warscheinlich werden dann aber auch zwei 
Platinen,
eine für die Leds und eine für den Encoder, da dieser ja tiefer sitzen 
muss.

TH: Quadratische Leds wie die von mir gefunden, 2x5mm würde ich als 
passend
ansehen. Im Prinzip würden diese auf Klebeband plaziert und dann mit
Silikon/... vergossen.

Ich habe langsam das Gefühl, daß es auf zwei MM5450 in PLCC Bauform
rausläuft, 2.7€ je Stück und Kosten ca 15€ je fertigen Encoder.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Chris schrieb:
> 32 Leds * 30mA *2 (Farben) * 10 (Encoder) = 19.aA, weit entfernt von den
>
> 40mA*10 = 400mA welche du eingeplant hattest.

Ich bezog mich auf einen Controller, denn das ist die Last, die ein 
Microcontroller sieht. Da die LEDs nicht ständig an sind, kalkulierte 
ich mit 25%ED je LED.

Axel Schwenke schrieb:
> Im Gegenteil. Lichtleiter oder Lichtschacht ist das einzige, was zu
> akzeptabler Optik führen wird.

Das ist eine Frage der Betrachtungsweise und dies in doppelter Hinsicht:

Ich halte meinen Vorschlag für durchaus optisch ansprechend, es gibt 
zahllose Designs, die den Blick auf das Innenleben zulassen - zudem habe 
ich aufgezeigt, wie man das mit Folie lösen kann.

Zur Art der "Betrachtung": Entscheidend ist, wie nahe die LEDs an der 
Plexi sitzen. Ich habe dazu Versuche gemacht und gefunden, dass 5mm-10mm 
Abstand ideal sind, um an einer milchigen Plexiplatte den oben 
beschriebenen Schmiereffekt oder nenne wir es Weichzeichnereffekt zu 
erzeugen. Der Abstand ist auch allemal noch tauglich, um bei klarer 
Scheibe die LEDs in schräger Sicht voll erkennen zu können, wenn das 
Gerät maximal 60cm breit is und man von oben reinschaut. Alles real 
durchgecheckt!!

Zur Veranschaulichung:

Dies ist ein Bild mit einer virtuellen Plexiplatte mit 70% 
Durchlässigkeit und 10% Eigenfarbe, beklebt mit relektierender 
Alu-"Folie", wie sie im Frontplattendesign üblich ist und einem blauen 
Abdeckring, wie ich mir das vorstelle, wenn man keine Folie für innen 
nutzt.

Der Encoder wird durch die Platine durchgesteckt, damit sind 
allemöglichen Encoder verschiedenster Typen montierbar und die LEDs 
rücken nahe genug an die Oberfläche. Lichtleiter werden nicht benötigt. 
Die Plexiplatte braucht nicht ausgeschnitten zu werden, sondern nur eine 
simple Bohrung für das encoder-Gewinde, die noch nicht einmal besonders 
sauber sein muss, weil sie abgedeckt wird.

Das sollte von jedem einfach zu reproduzieren sein. Hunderte Bohrungen 
in eine Metallplatte bohren dürfte eher abschrecken. Wer Angst hat, die 
Plexiplatte nimmt zuviel Licht weg, nimmt eben eine helle.

Einzige Anforderung: Das Encoder-Gewinde muss lang genug sein und die 
Platte ausreichend stabil. Ich rechne mit der Platinendicke 2mm + 
U-Scheibe + Mutter + 5mm-Plexiplatte + U-Scheibe + Mutter = 12 mm.


Hier gibt es eine Animation mit Lichteffekten der alten Version, die 
noch eine Zusatzplatine vorsah.
Youtube-Video "animation of a rotary encoder with a multi colour led display"

Diese kann entfallen, wenn man den Controller (mitsamt Treibern etc) auf 
die Hauptplatine drauf bekommt. Da wir nach obigem Vorschlag nur die 
Bohrung für das Gewinde benötigen und nicht den Platz für die 
Printmontage, ist auch wieder etwas Platz für Bauteile gewonnen.

Bitte nicht an dem riesigen Bauch des Encoders stören, die Animation 
basiert auf einer alten Anim, die ein Poti darstellte.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:
> Chris schrieb:
>> 32 Leds * 30mA *2 (Farben) * 10 (Encoder) = 19.aA, weit entfernt von den
>>
>> 40mA*10 = 400mA welche du eingeplant hattest.
>
> Ich bezog mich auf einen Controller, denn das ist die Last, die ein
> Microcontroller sieht. Da die LEDs nicht ständig an sind, kalkulierte
> ich mit 25%ED je LED.
>
Ob du nun 20mA bei 100%ED oder 200mA bei 10%ED rausgibst, die Led hat
immer 20mA Konstant, die Peak änderst sich leicht.

Ok, man kann eine Led in SW limitieren, daß sie nicht mehr als 20mA 
bekommt.
20mA x 32 Leds = ca 650mA worst schon gedimmt. warscheinlich muss man 
aber
mit 30mA rechnen, also ca  1A im Dauerbetrieb.
Klar daß nicht immer alle Leds immer an sind, aber es gibt schon 
Situationen,
wo alle Led eine Farbe haben können.
Bei Pulsbetrieb sieht es so aus, 4x8 Leds, aber die drei Leds (RGB)
werden gleichzeitig gepulst. Das macht dann ca 250mA bei SW-limitierung.
 worst case. 250mA x 8 = 2A peak worst case, zwar nur für 0.4mS.
Wenn es da eine Möglichkeit gibt, die Zeiten zwischen mehreren Encodern
zu syncronisieren, dann würden sich zwei Encoder 2 A teilen, und man
kommt auf dieselbe 1A, ansonsten sind es aber das Doppelte, ohne Sync.

Also, wenn du wirklich 20mA brauchst, und 6mA reichen nicht, dann
können die Leds niemals am uC angeschlossen werden, der uC steuert dann
nur die externe Ansteuerung. Und wenn du 1:4 Multiplext, dann musst
du normalerweise ein 1:10 Multiplexing fahren, also 200mA für 0.1mS 
wovon
du dann einfach nur 4 Slots der 10 möglichen benutzt. Normalerweise
deshalb, weil es auch andere Ansteuerarten gibt, da verliert man dann
aber die Garantie beim Ledhersteller, deshalb macht man so was nur bei
großen Projekten und mit Rücksprache des Herstellers, oder wenn es
günstige Leds sind, welche gar kein Datenblatt haben.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ein normaler Encoder, http://www.mouser.com/ds/2/54/pec11-57757.pdf
kostet ca 1€. Die Dicke ist 6.5mm, kannst du dir nicht vorstellen, daß
man den Encoder und die Leds auf einer einzigen Platine drauflötet ?
Laut deiner Aussage passt der Abstand ja auch, auch wenn ich mir das
bei einem Abstrahlwinkel von angenommenen 110 Grad nicht vorstellen 
kann.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochwas, als Sammelbestellung kann man auch ein Edelstahlblech lasern 
lassen.
Dürfte auch viel billiger sein, als ein CNC Auftrag.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Ob du nun 20mA bei 100%ED oder 200mA bei 10%ED rausgibst, die Led hat
> immer 20mA Konstant, die Peak änderst sich leicht.
Sicher, nur darf man die Rechnungen nicht vermischen - es reicht eine 
der beiden Betrachtungen. Nohmal:

ich schrieb:
> Wenn man die LED Anzeige voll nutzen
> will, muss man unterstellen, dass weitgehend alle DOU-LEDs aktiv sind.
> Damit wären wir bei 32 x 2 x 10 mA = 640 mA, wobei die 10mA die
> gemittelte Stromstärke gemäss ED / Multiplexing darstellt.

Die 10mA sind der equivalente Strom - mit ED25% also 40mA, mit ED10% 
100mA.

Der Controller "sieht" also im Mittel alle LEDs zu 10mA oder eben 8x2 zu 
40mA. Es bleibt bei im Mittel 640mA für die Erwärmungsbetrachtung. Hinzu 
kommt natürlich die Spitzenwertbetrachtung und die leifert eben die 16 
Kanäle zu je 40mA. Der Controller muss auch in diesem Fall 640mA Ausgang 
bringen. 40mA je Pin sind kein Problem. Aber an 3,3V sehe ich da an die 
2 Watt. Daher der Vorschlag den Controller zu "teilen". Angenommen, man 
nähme 4 Stück, dann blieben 500mA + Rechenbedarf. Das müsste hinhauen.

Damit bestünde die Option nur 2 Controller zu bestücken und jeweils 
einfarbige LEDs zu nutzen, wer das mag.

Wenn man aber zusätzlich zu den Controllern noch Ausgangstreiber 
braucht, kann ich auf die Controller verzichten und einen Chip nehmen 
und/oder lande doch wieder bei der externen Ansteueerung per FPGA und 
Schieberegister/Latches als Treiber. Die hätten den Vorteil, dass man 
nichts multiplexen muss sondern sie im Schneckentempo beladen könnte.

Also, zu klären wäre:

1) Viele AVRs braucht man parallel, um 32 LEDs mit 3 Farben, bzw 2 
Farben und 1 Farbe OHNE zusättzliche Treiber zu steuern?

2) Rechnet sich das noch, oder ist eine Lösung mit einem AVR und 
Schieberegiter besser? Schafft er bezüglich seiner Rechenleistung gfs 
druch alternierendes Überspringen eines time slots beim Multplexen für 
einzelne LEDs, insgesamt 64 LEDs in PWM so zu fahren, sodass wenigstens 
3 Helligkeitsstufen entstehen?

Ich rechne wie folgt:

ROT GRUN

 0%  0%   aus
 0%  33%  dunkel grün, ca 3,3 mA equivalent
 0%  66%  mittel rot
 0%  99%  hell grün ca  10mA equivalent

25%  0%   dunkel rot
25%  25%  dunkel gelb
25%  50%  mittlere gelb grün
25%  75%  grünes gelb grün

die anderen entsprechend

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> auch wenn ich mir das
> bei einem Abstrahlwinkel von angenommenen 110 Grad nicht vorstellen
> kann.
Natürlich kann man die auch direkt auflöten, aber der Abstand könnte zu 
gross werden. Das Plexi muss schon direkt auf die LEDs. Wenn man höher 
geht, müsste man doch wieder bedrahtete nehmen, die weit genug 
rausstehen.

Was vielleicht ginge, wäre durchkontaktierte Pads zu nehmen und die 
Anschlüsse hochzubiegen. Die Mouser sehen mir so aus, als ob das ginge.

Die Lichtproblematik haben ja alle Encoderlösungen, die derzeit auf 
Platinen verkauft werden. Mit versenkten Drehencoder kommt man sicher am 
Besten hin. Der Spalt muss eben gross genug sein. Ich persönlich brauche 
gar keinen Spalt sondern nur die Plexi.

Eine Überlegung wäre noch, einen Ring aus Spiegelfolie um die LEDs zu 
ziehen, um das seitliche Licht nach oben zu reflektieren. So könnte man 
das noch nutzen. Die Lichtleiter nutzen ja auch nur das nach oben 
austrende Licht. Vielleicht gibt es da aber was Preiswertes, als 
kompletter Ring.

Die von Dir gelinkten Encoder haben wieder nur 20.000 Zyklen. Stell Dir 
mal vor, wie oft man drehen muss, um einen Wert korrekt einzustellen, 
wie oft man den pro Nutzung ändert und wieviele Tage da rauskommen.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmals:
Diese 20.000 Zyklen sind Umdrehungen, jeder Kontakt hat 1 Mio 
elektrische
Schaltungen. 1 Mio  24  2  = abgerundete 20.000.
Wenn du mehr haben willst, als 1 Mio dann wird Opto oder
Magnetische Encoder gefordert, die kosten dann aber nicht 1€ sonder 4-5€ 
und
diese rasten auch nicht ein, sprich es gibt dann auch kein taktisches
Feedback, bzw muss man dies durch Stahlkugeln erreichen wenn 
erforderlich.
Eine Alternative ist anstelle von 24 steps 16 oder 12 oder 8 oder 6 
Stellungen zu haben, da erhöht sich die Lebensdauer in Umdrehungen, die
Auflösung ist aber beschissen, die 1 Mio bleiben aber.

Mir genügen diese Encoder. Weiters würde ich vorschlagen, solche Leds
zu verwenden, OSRG0603C1C (tme.eu), Abstandshalter einzusetzen (0.5mm)
und eine Metallmaske auf den leds aufzubringen, vor dem Reflow.
Wenn man auf die diffusen Leds dann noch eine diffuse Plexischeibe 
draufsetzen will, soll ja gehen. Diese Leds können dann über 
Charliplexing
angesteuert werden, mir würde es genügen, oder auch über Treiber, Platz
auf der Platine besteht und die Treiber kosten nicht viel, beides geht
aber nicht, man muss sich auf eine Lösung entscheiden.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bin ich nicht so sicher ob da alle gleich rehnen. Ich habe auch 
Angaben mit wesentlich mehr Umdrehungen gesehen, vom selben Hersteller 
gibt es unterschiedliche Qualitäten. 20000 wären wenig.

Bei einem Einstellvorgang werden durchaus schon einige komplette 
Umdehungen gemacht, bis der Wert stimmt - wenn der Wertebereich gross 
und die Steps klein sind.  Bei 24 Rastpunken = Kleinwinkel sind es zu 
12, um allein von 0 auf 255 zu kommen, wenn man linear zählt. Sagen wir 
im Schnitt 5. Wenn damit permament etwas geregelt werden muss, sind es 
40 Einstellvorgänge je Nutzungstag. Macht 200 Umdrehungen und 100 Tage.

Ok, wenn die Encoder nur eingeschraubt werden, könnte man auch andere 
Typen verbauen, gfs sogar magnetische. In jedem Fall behandle ich das 
jetzt mal als Verschleissteil. Das scheinen auch manche Hersteller zu 
tun, denn unter denen, die ich geordert hatte, gabe es einige, die 
bereits mit Stecker daherkommen und einfach ausgetauscht werden können.


Chris schrieb:
> diese rasten auch nicht ein, sprich es gibt dann auch kein taktisches
> Feedback,
Auf das taktische feedback kann ich gut verzichten, da wir ja ein 
optisches feedback haben, nämlich den Wert oder eben die Wirkungs des 
Wertes. Man kann, um das langsame Vorwärtszählen anzuzeigen, gerne auch 
die LEDs zusätzlich kurz zucken lassen, wenn man das möchte, oder 
bedarfsweise die des Knopfes, wenn man einen leuchtenden nimmt. Das 
Geknackse ist unnötig.

Die Rastungen verhindern ja nur, dass der Regler sich bei 
Erschütterungen verstellen kann und dies auch nur dann, wenn die Rasten 
zwischen den AB-Übergängen liegen, was bei vielen Encodern 
lustigerweise gar nicht der Fall ist. Dort unterstützen die Rastungen 
noch das Prellen.

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da der thread am sterben ist, wollte ich mich mal melden, dass ich 
gerade an einem kompletten Redesign sitze. Da ich aber seit März in 
Vollzeit beschäftigt bin, wird es jetzt eher langsam voran gehen.

Für das neue Konzept sehe ich folgendes vor:
- kleiner Mikrocontroller (PIC@64MHz oder ATMEGA@20MHz)
- 31 RGB LEDS
- Line-Decoder als Matrix-Treiber (Transistoren bräuchte man sonst eh 
für den Strom)
- beliebig versenkbarer drehencoder (ALPS EC11 oder PANASONIC); montage 
wie von Jürgen vorgeschlagen möglich aber nicht Pflicht
- 2 Platinen-Layout (für routing + Versenken)
- verschiedene Protokolle, über SPI in einer Init-Phase wählbar
- Signalverarbeitung (Entprellen, Ereignisgenerierung,...)
- manuelles Daisychaining, Anreihbar in 2 Dimensionen
- geschätzte Kosten 15EUR inkl PCBs



vermutlich brauche ich etwa 2-3 Monate für die Teileauswahl, den 
Schaltplan und vor allem das Routing
Dann nochmal 2 Monate für die Software

Wer so lange nicht warten möchte, ist warscheinlich selbst schneller! 
Kein Problem; ich bin niemandem böse :)

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach vorher ein 6x Panel, mit dual color leds, aber pinkompatible
RGB Leds sind als Alternativbestückung auch möglich. Da es für Outdoor 
ist,
verwende ich Led-Treiber, also besonders hell.
Ich brauche 4 Stück, und bestelle 5 Platinen, Preis ca 45€, bei 10 
Platinen
würde für RGB derselbe Preis rauskommen, da Ersparnis von Platinen
und die Preisdifferenz von RGB auf Duoled annähernd gleich ist.

Wenn jemand die eine Platine will, oder es zu 10 Platinen kommen sollte,
einfach hier melden.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher schrieb:

> Die Rastungen verhindern ja nur, dass der Regler sich bei
> Erschütterungen verstellen kann und dies auch nur dann, wenn die Rasten
> zwischen den AB-Übergängen liegen, was bei vielen Encodern
> lustigerweise gar nicht der Fall ist. Dort unterstützen die Rastungen
> noch das Prellen.

Das ist nur dann der Fall, wenn der geneigte Benutzer nicht in der Lage 
ist, einen brauchbaren Quadraturdecoder zu programmieren.

Lustigerweise ist nämlich ein sinnvoll programmierter sozusagen "von 
Natur aus" völlig prellresistent. Es ist deshalb auch überhaupt keine 
"klassische" (also zeitbasierte) Entprellung der Kontakte nötig.

Der Trick dabei ist, daß man bekannte Informationen ausnutzen kann, 
nämlich die Tatsache, daß die zwei Kontakte mechanisch verbunden sind 
und gültige Wackelei dadurch zwingend nach einem bestimmten 
Signalmuster erfolgen muß.

Man merkt sich also pro Kontakt zwei Sachen:

1) hat irgendwann mal gewackelt
2) zuletzt hatte er diesen oder jenen Pegel

Also zwei Bit. Mal zwei Kontakte = 4 Bit.

Dazu kommen dann noch bei jedem Durchlauf des Algorithmus zwei neue 
Bits, nämlich der dann jeweils aktuelle Pegel der beiden Kontakte.

Der Rest des Software-Engineering besteht nun darin, eine Statusmaschine 
mit 2^6Bit=32 Zuständen zu schreiben, die die gemerkten vier Bits für 
den nächsten Lauf des Algorithmus aktualisiert und nebenbei die 
Information abzweigt, daß ein gültiger Schritt stattgefunden hat und in 
welche Richtung der geschah.

Hört sich sich ziemlich gewaltig an, ist aber in sehr wenigen Takten 
Assembler abzuhandeln.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist es und in einem FPGA ist es noch einfacher :-)
Mit einem FPGA kann man das schön pipelinen, weil man nur pro Kanal 
einen alten Zustand mitschleppen muss und ansonsten nur Inputs hat.

Autor: Siggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siggi schrieb:
> Sind das nicht die gewünschten farbigen Anzeigen:
> http://www.top-up.com.tw/front/bin/ptdetail.phtml?...

Hmm. Erinnert fatal an vorherige Beiträge in diesem Thread: schicke 
bunte Bildchen, aber unter der Oberfläche ... wenig bis nichts.

Prinzipiell sehen diese Displays fantastisch aus. OK, sie sind nicht 
zweifarbig, oder gar RBG. Aber das ist IMHO sowieso nur Spielerei.

Was mir aber richtig übel aufstößt, das sind die Widersprüche in den 
Bildern/Zeichnungen. Z.B. zeigen sie 32 Segmente auf einem 360° Kreis. 
Von der Innenschaltung und der Anzahl Pins können es aber nur 16 LED 
sein. Leuchten da vielleicht immer 2 Segmente gleichzeitig?


XL

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War mir noch gar nicht ausgefallen! In der Tat blinken bei der 
Video-Demo immer mindestens 2 LED-Nachbarn gleichzeitig. Bei der bunt 
gemischten Gruppe haben sie wohl 4 Farben abwechselnd eingebaut. Das 
sieht mir nach "ich baue mal, was ich habe" aus. Strategie sieht anders 
aus.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist nochmal ein Bild mit den geplanten Encodern und Knöpfen, wie 
sie schon in einem alten Projekt zum Einsatz kommen (reines encoding 
ohne LED-Rückmeldung).

Die Encoder haben ein vergleichsweise langes Schraubgewinde, das bei 
montierten Muttern und einer Trägerplatine noch 3mm Luft für die 
Plexiplatte lässt. Sie sind recht schmal und die Anschlüsse gut zu 
verlöten, auch wenn es eng wird. Das Raster der Anschlüsse ist leider 
ein 1,27; passt also nicht auf Bastellochraster. Die Encoder kosteten 
mit Alu-Knöpfen (über Riffelung fest verbunden) weniger, als €1,-.

Die Knöpfe gab es in Silber, Gold und Schwarz. Die Silbernen sind die 
Besten, weil sie keinen aufgedruckten Strich haben, sondern nur eine 
klein Kerbe, die man kaum sieht. (Striche bei Encodern sind ja etwas 
überflüssig).

Autor: A. S. (rava)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich heute mal etwas hingesetzt und habe gemalt.

Der Plan sieht vor, zwei Platinen übereinanderzusetzen, um genügend 
Platz für das Routing von 31 RGB-LEDs zu haben und den print-Encoder 
versenken zu können.

Ich habe mich nun doch für einen seriellen Treiberbaustein entschieden, 
da mit dem neuen Konzept noch Platz für einen zweiten IC ist.

Das was ich derzeit zeichne wird aber leider nicht mit den Encodern 
funktionieren, die du gepostet hast, Jürgen. Das Problem: Die Encoder 
sind gewinkelt. Da müsste die Platine ja weit ins Gerät hineinstehen. 
Die Encoeder die ich hier habe (Panasonic und mittlerweile auch ALPS) 
sind aber für die Gerade Montage.

Die obere Platine mit den LEDs ist jetzt fertig geroutet (bis auf 
kleinere Pinswaps, die noch nötig werden könnten). In der Mitte ist ein 
Loch, das mit 15mm Durchmesser auch den fest montierte Kappe des 
Panasonic Encoders durch lässt. Wem das zu groß ist, der darf natürlich 
auch den ALPS verwenden und sein Frontpanel nur mit einem kleineren Loch 
versehen (z.B. 6.8mm).

Anschlussbelegung:
Links kommen 5V rein, rechts GND.
Die beiden 2x3 Stiftleisten liefern 8xSpalten-Steuersignal, 3x SPI für 
den Treiber-IC und Enable (kommt dann an den Reset des µC)
Rechts oben sind noch 4 Stiftleisten, um die 32. LED anschließen zu 
können - wir hatten ja mal über beleuchtete Encoder geredet. Wer weiß, 
ob da noch jemand ein brauchbares Gerät findet!

Die Maße bleiben weiterhin bei 50x50 mm
Lasst euch nicht an den gelben Linien stören - das liegt an meiner 
miesen Arbeitsweise. Die Platine ist so fertig.
In den nächsten Wochen geht's an die untere Platine!

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Die Idee mit den zweifarbigen LEDs gefällt mir auch unheimlich gut. RGB
> wäre natürlich noch lässiger.
Ganz meine Meinung und wie ich sehe, hast Du Dich nun auch auf die RGB 
festgelegt. Allerdings sehe ich im Schaltplan für die Matrix nur 8xLEDs. 
Sollten das nicht 32 sein? Was spräche dagegen?

Die Positionen der LEDs scheinen auch nicht rund herum angeordnet.

Hast Du auch schon die zweite (erste) Platine angegangen? Ich habe ein 
wenig ein Problem, mir das vorzustellen, wie die Geschichte nun aussehen 
soll.

Ich nehme an, auf der zweiten sitzt der Encoder und der Controller?

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

ja, unten (noch nichts geroutet) sind Controller ein schneller 
Resonator, Encoder, Programmierschnittstelle, und Anschlüsse, um mehrere 
von diesen Platinen anzureihen.

auf dem Schaltplan sind 31 RGB-LEDs zu sehen. Vielleicht zu kleiner 
Bildschirm?
Die LEDs sind gleichmäßig auf 255° verteilt. Dieser krumme Winkelbereich 
hat mir einfach am besten gefallen.

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Dieser krumme Winkelbereich
> hat mir einfach am besten gefallen.
Wegen der 256? binär?

Wie sieht es aus mit der Helligkeit / PWM? Werden die LEDs 4fach, oder 
8fach gemuxt?

Was können deine LEDs ab?

Siehe dazu hier:
Beitrag "Re: Verschleiß bei LEDs im PWM-Betrieb?"

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8 Spalten x 12 Zeilen = 96 Kanäle
32 Chips x 3 Farben = 96 Kanäle

Da sie eine gemeinsmae Anode haben, gibt es keine andere Möglichkeit, 
sie zu verschalten. Außerdem kann der Treiber nur "sinken" und nicht 
"sourcen".
Ich werde 8 Zyklen wählen - außerdem macht der Konstantstrom-LED-Treiber 
nur so Sinn!
Meine Rechnung mit R_EXT = 470Ohm führt zu einem LED-Strom von 40mA. 
Laut Datenblatt verkraften die LEDs 100mA (bei 1:10 Tastverhältnis und 
maximal 100µs Pulsdauer). Der limitierende Faktor ist der Treiber - aber 
40mA werden genügen. Meinste nicht?

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> 32 Chips x 3 Farben = 96 Kanäle
32 LEDs x 3 Farben nehme ich an, waren gemeint.

>8 Zyklen
die 40mA / 8 wären dann "wie" 5mA?
Wenn die bei 1:10 100mA können, sind da bei 1:8 sicher 80mA drin. Soweit 
mir bekannt ist das Verhältnis der LED-Spannung zum Strom im Pulsbetrieb 
eine Hyperbel. Du könntest also auch 60mA für den Puls nehmen.

Autor: A. S. (rava)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

die untere Platine ist heute fertig geworden!

Ich habe mal berücksichtigt, dass eventuell 80mA in die LEDs gehen. Mit 
dem Multipleverhältnis ergibt sich dann im worst-case ein Strom von 1A 
pro Platine.
Um von diesen Dingern viele in einer Zeile anreihen zu können, habe ich 
versucht, die Versorgungsleitungen richtig dick zu bekommen. 12A waren 
mein Ziel. Wie viele gehen, wird sich zeigen.


Ich werde vermutlich in den nächsten Tagen die erste Ladung Teile 
bestellen und dann einen Satz Platinen in Auftrag geben...



hatten wir noch irgendwelche weiteren Footprints für Encoder? 
Irgendetwas, wo z.B. eine LED im Encoder verbaut ist? Die meisten waren 
zu windig, oder?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut schon mal gut aus - die Encoder (auch die mit LED) sind sicher 
kein Problem, das kann man zur Not mit Drähten machen.

1A pro Platine kann hinkommen und das ist auch gut so, denn es soll ja 
auch optisch was hermachen.


Falk Brunner schrieb:
>>Wiederholrate für LEDs und Taster = 1/(48+16)
>> oder 1/(112+16) x 50MHz => 300 kHz

> Totaler Overkill.

Overkill bezüglich welcher Applikation?

Wenn man einen schnellen optischen oder magnetischen Drehencoder, wie 
sie auf Wellen sitzen, abtasten will und Beschleunigungen sehen will, 
ist das gerade so ausreichend und auch für den manuellen Betrieb geht es 
nicht wesentlich weiter runter, als nochmal eine gute Dekade: Eine 
Drehbewegung eines Encoders, die man geschnippt ausführt, um schnell zu 
blättern, produziert gemessene Impuls-Frequenzen im kHz-Bereich. Tastet 
man das nicht wenigstens mit Faktor 100 ab, bekommt man keine korrekte 
Kurvenabbildung mehr hin, was ich aber für mindestens zwei APPs 
benötige.

Für eine Beschleunigungsmessung braucht man mal rund 5 Werte, macht >500 
Samples in der ca. 1/10 Sekunde der Drehbewegung und damit 5ksps 
minimale Auflösung. Für eine quasi nicht existente Verzögerung wäre mehr 
noch besser. Die Abtastung produziert ja Jitter. Ich kann jetzt hier 
nicht im Detail ausführen, welche Knopf-, Finger- und Handbewegungen 
damit letztlich noch so alles gesampelt werden sollen, aber es geht 
nicht nur um eine irgendwie geartete Steuerung, die die Information als 
solche überträgt, sondern auch um Messung und exakte Übertragung. Man 
könnte vielleicht noch einen Faktor 10 runter, ok, das war es aber auch. 
Wenn ich mit den kHz-Abtastungen und den Verzögerungen existenter Geräte 
leben könnte, müsste ich nichts bauen.

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soo, dann werde ich diesen Dinosaurier wieder aufwärmen:
kurze Info an Alle, die es interessiert: am Wochenende werde ich die 
ersten Platinen in Auftrag geben. Spätestens Ende August sollte also die 
Programmiererei losgehen :)

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann bin ich mal auf das Ergebnis gespannt. Vor allem in Sachen 
Helligkeit. Ich habe für mich inzwischen einige Tests gemacht und 
brauche einiges an Helligkeit- zumindest für eine spezielle Applikation. 
Mein FPGA-Design ist fertig, es hängt jetzt noch an dem Thema Treiber.

Autor: A. S. (rava)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ui, die Lieferung kma schneller als erwartet. Ich bestell noch eben 
Stencils, dann kann ich in spätestens 14 Tagen mit löten anfangen!

Autor: A. S. (rava)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
es war natürlich ein kleiner Fehler im Design, aber nichts Kritisches.
Eine der Querverbindungen zwischen den Platinen muss durch eine 
Drahtbrücke ersetzt werden.

Die Helligkeit kann ich mit meiner Kamera nicht wirklich zeigen. Im 
rechten Bild wird das Ding von der Schreibtischlampe (50W, Halogen) aus 
ca. 10-15cm Entfernung angeleuchtet (Die Wand soll aber z.B. weiß sein 
;-).

Subjektiv ist die Helligkeit recht gut, vor allem bei Mischfarben. Das 
Rot ist etwas schwach auf der Brust. Wen die Rechenleistung im PIC 
reicht, implementiere ich noch eine Farbkorrektur.

Derzeit werden die LEDs mit 12,6mA betrieben. Rechnerisch sind bis zu 
80mA drin (Multiplexbetrieb), allerdings muss man da mit der Wärme 
aufpassen, da der Treiber-IC pro LED nur 125mW verbraten kann. Rechne 
ich (im Schnitt) mit 2.5V Spannungsabfall, sind das 50mA.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut schon mal gut aus. Bei den Schrauben denke ich, könnte man kleine 
nehmen.

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja das sieht jetzt noch etwas klobig aus. Der ursprüngliche Gedanke 
war, dass da vorne das Frontpanel ran kommt und die Schrauben von außen 
dagegen.
Torx Senkkopf kann man natürlich auch verwenden, wäre sicherlich etwas 
eleganter!


Ich muss mir auch überlegen, ob man irgendeine Art Kunststoff-Diffusor 
zwischen Panel und das Modul bekommt. Der darf zwar nicht unnötig 
Helligkeit kosten, aber eine etwas saubere Farbmischung könnte den 
Aufwand wert sein!

Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt für einzelen LEDs lichtleitende Verbinder nach Aussen, ob es das 
auch in bekrümmter Form gibt, ist mir nicht bekannt. Sieht man denn die 
Vereinzelung der Farben so stark?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit 3-Farben-LEDs Test dazu gemacht, ja man sieht sie. :-(

Autor: NoName (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für die, die es nicht selber machen wollen:

http://www.exp-tech.de/Shields/LED-Controller/NeoP...

jede einzelne LED ansteuerbar, Alle farben die man will nur drauf achten 
dass Trafo genug Leistung hat und beidseitig einspeisen..

angesteuert kann das ding per arduino und mit Adafruit Neopixel Library

https://github.com/adafruit/Adafruit_NeoPixel

habe ich mir auch gegönnt so ein teil

Autor: Maddin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wurde der BCR2000 von Thomann hier schon genannt?

Aber es ist warscheinlich zu grob in der Auflösung der Stufen und mit 
3mm LEDs bestückt. Dafür hat man ein fertiges Gerät und das Midi 
Protokoll ist noch überschaubar...


Gruß,
M

Autor: Maddin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der BCR (von Behringer!) ist sehr weit weg von dem, was ich brauche. So 
etwa ein Lichtjahr. Darstellung zu grob, MIDI-Auflösung viel zu grob, 
Regler nicht fein genug, nicht schnell genug und auch viel zu eng 
gesetzt.

Autor: Dennis B. (dcfoto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's hier eigentlich was Neues?

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"rava" hatte ja bereits was aufgebaut. Was mich angeht, gibt es einen 
Prototypen. Leider ist die Resonanz nicht sonderlich hoch, bzw es gibt 
keinen gesteigerten Bedarf für meine Bestrebungen einen hochauslösenden 
Controller zu etablieren, wenigstens nicht beim Consumer Audio. Man 
möchte mit 8-Bit weiterwuseln. Von daher lohnt es nicht, das Projekt 
weiterzuziehen und über meinen Prototypen hinaus zu erweitern. Das 
heisst aber nicht, dass ich nicht für mich weiter daran arbeite :-)

Autor: Dennis B. (dcfoto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mich interessiert's. Vielleicht berichte ich mal von meinem eigenen 
Projekt, um nicht nur Fragen zu stellen :)

Ich bastele an einem digitalen Synthesizer, der auf einem in VHDL selbst 
entwickelten Signalprozessor basiert. Der Prozessor rechnet mit 18bit 
Fixkomma-Arithmetik massiv parallel (24 parallele synchrone 
Ausführungseinheiten jeweils mit eigenem Daten-RAM und eigener ALU). An 
einem eigenen Compiler dafür (für eine einfache Hochsprache) arbeite ich 
auch. Plattform für den Prozessor ist ein Spartan-6 FPGA.

I/O-Pins sind bei diesen Chips ja keine Mangelware; warum also nicht 
auch gleich Drehknöpfe integrieren. Bisher habe ich eine einfache 
Hardware entwickelt, die bis zu 32 Encoder entprellt und ausliest. Das 
passt prima noch mit in den FPGA, d.h. es ist außerhalb des Chips keine 
Elektronik nötig außer den Encodern selbst. MIDI-Anbindung fehlt noch 
bei meiner Lösung, aber das ist auch nicht so aufwändig.

Was die Auflösung der Encoder angeht, so gibt es zu günstigen Preisen 
scheinbar nur welche mit geringer Auflösung von bis zu 24 Schritten pro 
Umdrehung. Höher auflösende Encoder (schön wäre ja eine dreistellige 
Anzahl von Schritten pro Umdrehung) kosten rund das 20fache. Als kleines 
Experiment habe ich mir ein Getriebe gebastelt, um die Auflösung der 
günstigen Encoder mechanisch zu erhöhen. Mit einem Laser-Cutter habe ich 
aus Acryl zwei Zahnräder plus Grundplatte geschnitten. 
Übersetzungsverhältnis ist 1:3 (60 zu 20 Zähne). Meine Sorgen, das 
Getriebe könnte zu viel Spiel haben oder klemmen, haben sich als 
unbegründet erwiesen. Allerdings sollte man einen größeren Knopf 
verwenden, da man doch etwas mehr Kraft braucht als bei typischen Potis 
oder "rohen" Encodern. Ich habe somit nun 72 Schritte pro Umdrehung. 
Eigentlich hätte ich lieber eine noch höhere Auflösung. Würde ich 
allerdings das Übersetzungsverhältnis der 2-Achsen-Variante weiter 
erhöhen, dann würde das Zahnrad am Knopf natürlich auch größer und damit 
der Mindestabstand der Knöpfe auf der Frontplatte größer als 
praktikabel. Daher müsste eine dritte Achse her, wobei auf der mittleren 
Achse dann zwei Zahnräder säßen. Das probiere ich später mal.

Eine Anzeige der Werte wäre natürlich schön. Bisher habe ich vor, das 
über ein zentrales LCD zu machen (was aber natürlich heißt, dass man 
immer nur den Wert eines Knopfes anzeigen kann und dies auch nicht am 
Knopf selbst). Ein LED-Kranz wäre definitiv ziemlich cool. Es wäre auch 
überhaupt kein Problem, in VHDL eine Logik zu bauen, die viele einzelne 
LEDs um einen Knopf herum ansteuert. Dafür bräuchte man aber eine Menge 
I/O-Pins, und bei der Anzahl der Knöpfe die ich gern hätte, würden die 
nicht ausreichen. Demnach müsste eben zwingend ein Teil der Logik aus 
dem Chip raus zum Knopf hin wandern (im einfachsten Fall wohl ein 
Schieberegister). Denkt man diese Idee konsequent weiter, dann kommt man 
zu Jürgens Konzept mit den Modulen.

Daher habe ich gefragt. Synergien gäbe es ja...

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
How about diesem hier:

http://www.conrad.de/ce/de/product/179998/2-Kanal-...

Damit kannst du die Zähne eines M1 Zahnrads einwandfrei abzählen, wohl 
sogar unter Verwendung aller vier Quadratur-Phasen, und hast dadurch 
gleich mal eine sehr viel höhere Auflösung.
Und das ohne die angegebene Lebenszeit so eines Encoders in kürzester 
Zeit zu überschreiten ;)

Meine Wenigkeit verwendete übrigens zwei Getriebe hintereinander
2x 12:30  entspricht  1:6,25
http://www.conrad.de/ce/de/product/297402/Zahnrads...

Diese drehen ein weiteres Zahnrad, das mit dem OMRON ausgezählt wird
Ausgewertet werden dann sowohl Luft, als auch Zahn, bzw der jeweilige 
Übergang (M0.5 ich doch etwas klein), was einer Auflösung von 375 
Schritten ergibt, nur eben ohne Rastung.

Geht aber super

Durch drei geteilt währen das dann 125 Schritte, entweder um 7 Bit nahe 
zu kommen, oder um etwas weniger als eine Umdrehung für die Werte 0-100 
zu brauchen, für ein besseres Bediengefühl.

Mit einem 40er Rad hättest du pro Umdrehung 250 oder zweiphasig gezählt 
500 Schritte, aber diese feinen Schritte lassen sich wohl kaum noch 
zuverlässig halten ;)

Ich würde dir echt gerne den Prototypen zeigen, gefräst aus drei kleinen 
Blöcken Hartkunststoff, aber dieser liegt jetzt, und wer weiß wie lange, 
in irgendeinem von vielen Kartons in der Garage oder im Speicher.

: Bearbeitet durch User
Autor: Dennis B. (dcfoto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ui, interessant! Das würde ich ja gern mal sehen. Mechanisch bist Du 
also da schon deutlich weiter als ich. Ehrlich gesagt kannte ich diese 
Bauelemente gar nicht :)

Wie ist das hier zu verstehen: "Schlitz-Breite: (Mess-Spalt 0.3 mm) 2 
mm"? Heißt das der Zwischenraum ist 2mm breit und die beiden 
Lichtschranken sind 0,3mm versetzt? Das hieße dann ja, ein Zahn müsste 
nur breiter als 0,3mm sein (sonst kann man nicht unterscheiden, in 
welche Richtung gedreht wurde). Wenn ich das richtig interpretiert habe, 
dann bekommt man da ziemlich viel Auflösung auf wenig Platz unter.

Angenommen, der Abstand zwischen den Knöpfen soll max. 50mm sein und man 
möchte alle Zahnräder in einer Ebene haben (nicht vertikal versetzt, was 
mit mehr Aufwand ja auch ginge). Dann dürfte ein Zahnrad max. 25mm 
Durchmesser haben, was einem Umfang von 78mm entspricht. Bei einer 
Zahnbreite = Schlitzbreite von 0,5mm bekäme man 78 Zähne und Schlitze 
auf so ein Rad. Entspricht 156 Schritten pro Umdrehung, bzw. 7bit 
innerhalb des üblichen Drehbereichs. Da braucht man gar kein Getriebe 
mehr :) Acryl kann man mit einer Genauigkeit von ca. 0,1mm 
laserschneiden, das sollte also gehen (und lässt sich auf die Anwendung 
besser maßschneidern als fertige Zahnräder).

> aber diese feinen Schritte lassen sich wohl kaum noch
> zuverlässig halten ;)

Du meinst, man wird mit der Hand nicht genau einen gewünschten Wert 
einstellen können? Na gut, das ist der Preis der hohen Auflösung.

Nervig könnte sein, wenn so ein Knopf ständig zwischen zwei Werten hin- 
und her pendelt. Das müsste man evtl. algorithmisch herausfiltern.

An der Abtastfrequenz wird es jedenfalls nicht scheitern, denn die kann 
bei einem FPGA im dreistelligen MHz-Bereich liegen. So schnell kann 
niemand drehen.

Wie schließt man solche Doppel-Lichtschranken elektrisch an? Von 
Analogtechnik habe ich ja keine Ahnung, ich kann nur mit high und low 
etwas anfangen :)

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Sensoren haben einen Blendenschlitz von 0,3mm und diese sind Mitte 
zu Mitte 2mm auseinander

Zahn und Luft sollte die "beiden" Schlitze optimalerweise durchlassen 
oder sperren
da es eine einzelne Leuchtquelle in der Mitte ist, hat ein schwarz 
lackieren des M0.5er Zahnrades gereicht und die beiden Übergänge sind 
klar erkennbar

Ich denke da an einen Zähler, der jede der vier Phasen zählt, und wenn 
eine einzelne Bewegung um eine oder zwei Phasen sich nach einer halben 
oder ganzen Sekunde nicht ändert, diesen Zähler wieder zurücksetzen. so 
fallen die kleinsten Bewegungen schonmal weg

Oder lass sogar zwei oder drei echt gezählte Schritte überwachen, die 
bewegst du ja schon, wenn du den Knopf nur anrührst ;)

es sind NPN OpenKollektor Ausgänge
mit einem 10k an Plus, dann hast zwei Werte
oder anders rum g

solltest aber einen Schmitt-Trigger davor hängen, dein FPGA könnte mit 
langsamen Schaltflanken durchaus Probleme haben

Schaltplan siehe Seite zwei unten
http://www.produktinfo.conrad.com/datenblaetter/17...

wenn ich es dann echt mal praktisch umsetze, dann in einem Alu Gehäuse 
mit echtem Potikopf und einem 40er Rädchen maschinell bearbeitet für 
richtige Schlitze

: Bearbeitet durch User
Autor: Dennis B. (dcfoto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2mm Abstand... schade, dann muss ein Zahn größer als 2,3mm sein, was die 
Auflösung doch wieder deutlich reduziert.

Wenn ich nochmal scharf nachdenke, dann gibt es kein Problem mit Pendeln 
(den Absatz aus meinem vorigen Post also bitte vergessen). Denn 
mechanisch bewegt sich ja nichts mehr wenn niemand dreht. Nur elektisch 
kann ein Signal pendeln. Aber eben nur eins, denn durch die gewählte 
Zahnbreite steht das jeweils andere Signal immer stabil auf high bzw. 
low wenn eines der Signale auf der Kippe steht. Daher reicht zum 
Auswerten eine kleine State-Machine. Einen Zähler braucht man somit auch 
nicht. Einfach gesagt zählt man nur die erste Veränderung im Signal 
eines der beiden Pins solange sich das Signal am anderen Pin nicht 
verändert hat.

Hier ist das veranschaulicht:
http://www.xilinx.com/products/boards/s3estarter/f...

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auf die Art erfaßt du die Übergänge sehr gut, jo gg

nur mit einer vier Phasen Erkennung kannst du eben kleinste Bewegungen 
bzw Vibrationen herausfiltern

ich werde das mit einem Microchip DSPic lösen

vier Drehencoder per Software und die beiden Motorfader mit 
Encoderscheibe mittels den beiden im Chip integrierten Hardwareencodern
... aber das wird eine anderes Thema ;)

: Bearbeitet durch User
Autor: Dennis B. (dcfoto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal weiter gedacht: es muss ja nicht der gleiche Zahn sein, den 
die beiden Lichtschranken messen. Die Zahn- und Schlitzbreite muss 
lediglich so auf den Abstand zwischen den Lichtschranken abgestimmt 
sein, dass etwa (n+0,5) Zahnbreiten dem Sensorabstand entsprechen (mit 
n=ganze Zahl). Dadurch ist sichergestellt, dass die Sensoren ein 
Quadratursignal liefern, und mehr wollen wir ja gar nicht.
Beispiel: Sensorabstand = 2,5 Zahnbreiten


Schlitze:             | |                 | |

            _______         _______         _______         __
Zähne: ____|       |_______|       |_______|       |_______|


Beispiel: Sensorabstand = 3,5 Zahnbreiten


Schlitze:             | |                  | |

               _____       _____       _____       _____
Zähne:  ______|     |_____|     |_____|     |_____|     |_____|

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
interessanter Ansatz

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach nein, hab mich oben sowas von vertan !!!

also richtig ist, daß die Sensorschlitze selbst 0,3mm breit sind

haben aber einen Mitte zu Mitte Abstand von nur 0,8mm !!!!
deshalb klappte es auch mit meinen M0.5 Zahnrädern gg

die 2mm sind der Platz, den du durch die Gabellichtschranke hindurch 
hast, dementsprechend dünn muß das Rädchen sein

siehe Seite vier unten
http://www.produktinfo.conrad.com/datenblaetter/17...

: Bearbeitet durch User
Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias S. schrieb:
> How about diesem hier:
>
> 
http://www.conrad.de/ce/de/product/179998/2-Kanal-...

Viel zu teuer.

> Damit kannst du die Zähne eines M1 Zahnrads einwandfrei abzählen, wohl
> sogar unter Verwendung aller vier Quadratur-Phasen, und hast dadurch
> gleich mal eine sehr viel höhere Auflösung.

Klar. Optische Encoder kann man mit viel höherer Auflösung bauen. Eine 
triviale Erkenntnis aus der Vergangenheit.

Das Problem mit der geringen Auflösung haben nur die Encoder mit 
mechanischen Kontakten. Weil man die nicht beliebig klein bauen kann. 
Zumindest nicht wenn man eine sinnvolle Lebensdauer will.

Optische Encoder gehen deutlich besser für hohe Auflösung. Und auch in 
billig - schau halt mal in eine alte Rollkugelmaus. Es gibt sie 
allerdings nicht als fertige Bauelemente zu kaufen. Bzw. nur für 
professionelle Anwendungen mit z.B. Kugellagern, definiertem Rundlauf 
für hohe Geschwindigkeit.

Was man bräuchte, wäre eine Poti-Mechanik (Gehäuse, Achse, Lager) und 
angeflanscht so ein Spritzgußteil wie aus einer Maus. Dazu zwei 
billigste IR-LED und Fototransistoren auf der Platine. Kann man sich 
bestimmt bauen lassen, wenn man ein paar 10.000 Stück abnimmt.

Andererseits verstehe ich den Sinn der ganzen Sache nicht. Für manuelle 
Betätigung reichen Drehencoder mit 24 oder 30 Impulsen pro Umdrehung 
vollkommen aus. Alles was höher auflöst, kann man mit der Hand sowieso 
nicht mehr genau einstellen. Wenn es nur darum geht, die Einstellung 
anhand der Position des Drehknopfes direkt ablesen zu können: nimm ein 
Poti. Das wertet sich sogar noch leichter aus.

Autor: Tobias S. (picollo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. 1€62 zu teuer ???

2. Weil man mit dieser hohen Auflösung in einem Handumdrehen den ganzen 
Wertebereich eines Synthesizer- oder Mischpult-Parameters abgedecken 
kann, mit kaum bis garnicht wahrnehmbarer Abstufung.
Wir reden hier von Audio Anwendungen und nicht von Maschinensteuerung

Ja, oder man kauft sich natürlich einfach einen vollwertigen Synthesizer 
Axel, welcher eben auch nicht besagtes hat.
Aber deswegen sind wir nicht hier

... Potistellungen abspeichern, und wieder zurückrufen ??? ...
Das finde ich bei diesen Geräten auch immer so lustig

Von Alps gibts einen optischen mit 120 Schritten Auflösung, aber kuck 
mal an, wie teuer dieser ist ...
Naja, immerhin 10 Stück: gg
http://de.aliexpress.com/store/product/SA-ALPS-enc...
Die sind aber normalerweise, bzw. 'neu' sehr viel teurer

Es gab auch mal Avago Motorencoder mit Potiaufsatz, 500 Schritte und 
fühlen sich super an, kosteten aber 80€ das Teil
(oder 5€, wenn du mal wieder eines bei "eBay" findest ;-)

: Bearbeitet durch User
Autor: Klaus L. (klausi5000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seid ihr sicher, dass ihr bei Audioanwendungen so hohe Auflösungen und 
Winkelbereiche benötigt? Ein Poti am Analogsynthesizer geht ja auch nur 
bis 270 Grad.

Bei einem einfachen Encoder kann man noch einfach viele Umdrehungen 
benützen und weiter liesse sich auch noch eine Beschleunigung 
einprogrammieren, um die Geschwindigkeit zu steigern, wie bei der 
Computermaus.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ui, hier tut sich ja was. Zu dem Vorschlag des optischen Enceoders: Ja, 
das wäre optimal, aber auch ich habe bisher nur individuelle Aufbauten 
für die Industrie vorgefunden, die eben Eigenentwicklungen waren oder 
entsprechend gekapselte Hochleistungsprodukte. Für dazwischen gibt es 
offenbar keinen Markt. Die angeschriebenen Hersteller äusserten sich 
entsprechend.

Zu dem Thema Audio: Ja, die analogen Eingaben gehen nur bis 270 Grad mit 
einem Poti aber das hat eben unendlich viele Zwischenstufen. Ich habe 
mir schon überlegt, ein Poti zu sampeln, aber das ist mir ehrlich gesagt 
scon zu fein. Mechanisch sinnvoll sind etwa 6 Grad an Auflösung je 
Schritt, also wären 60 Schritte das Maximum. Man würde dann nur 30 
zulassen und den Rest mitsamt der Beschleunigungsinformation auswerten.

Als Encoder reichen mir daher eigentlich die 24 Schritt, ich hätte nur 
gerne etwas stabilieres und langlebigeres, als die typischen 1,95 
Encoder.

Die grobe Einstellung mache ich inzwischen wie oben schon beschrieben 
mit einer Zoomfunktion: Man drückt den Drehknop und betätigt damit die 
Taste, die ein 4 fach schnelleres Verstellen ermöglicht, oder zwischen 
den Betriebsarten umschaltet. Das ist nötig, wenn man wirklich feine 
Stufen braucht, um bestimmte Werte einzusellten oder im anderen Fall 
schnell und in Echtzeit einen Cut-Off-Filter betätigten will.

Ich möchte aber nochmals herausstellen, dass mein ursprünglicher Ansatz 
der war, durchaus ein universelles Gerät zu bauen, dass auch 
industrietauglich ist und eine entsprechene Auflösung ermöglicht. Und: 
Es ging mir um die optische Rückmeldung, weil gerade mit einem 
Drehencoder (optisch) die Schritte nicht sicher mitgezählt werden können 
und es auch keinen echten Anschlag gibt, dafür der Drehknopf aber 
mehrfach um die eigene Achse kann.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht wäre so etwas auch hilfreich?

Gefunden eben auf Ali.
Kostet unter $7.50 per Stück!
Kann Temperatur, Zeit etc...

Fragt sich nur, ob man es reprogrammieren kann.

Autor: Bimmerboy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.S. (Rava)

< Please excuse my German, it's not my native language >

Hi Rava,

Ich bin auf der Suche nach fast genau so was für mein Hobbyprojekt 
(MIDI controller) - nur mit etwas schmalerem Durchmesser (LED circle), 
weil ich möchte bei ung. 25-30mm bleiben statt dein ~40 mm.

Wenn du möchtest, könntest du bitte ein Paar Fragen klären die ich habe?
1) Hast du dieses Projekt jetzt noch aktiv weitergemacht, oder ist es 
hierbei geblieben?
2) Wieviel würdest du schätzen dass ein Unit kostet/für dich gekostet 
hat (wenn selber gelötet usw.), bei einem Stückzahl von 50?
3) Gibt es deine Designs irgendwo herunter zu laden, oder ist das genau 
dein "Intellectual Property" ;)

Jetzt die "n00b" Fragen (leider bin ich kein Techniker, eher 
Programmierer, und versuche irgendwie deine Schematics zu verstehen)

4) Das LED-Treiber IC kann nur 16 LEDs treiben habe ich gelesen, aber du 
hast mehrere pro Kanal geschaltet (3-4). Verstehe ich richtig dass du 
diese LEDs pro Kanal in der Zeit versetzt steuerst? Und dass damit die 
max. Output ung. 25% ist (PWM kodiert quasi)? Oder habe ich das ganz 
falsch verstanden?

5) Weil ich nicht mit Rotary Encoders, aber eher mit "normalen" Pots 
arbeiten möchte; habe ich richtig verstanden das die obere Platine nur 
die LED-Steuerung macht, und die untere Platine alles was mit dem Rotary 
Encoder zu tun hat? (Dann würde das bedeuten dass ich erst mal nur 
Interesse hätte an der oberen Platine)

Danke erst mal an allen für die Ausführliche Posts die hier schon mal 
geschrieben sind!

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Vielleicht wäre so etwas auch hilfreich?

Ich glaube ehrlich gesagt nicht, dass man das reprogrammiert bekommt. 
Eher schon könnte man sich beim Chinesen sowas wie oben angedacht bauen 
und bestücken lassen.

Autor: Pier S. (bigpier)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man könnte noch nen Bootloader vorsehen, damit man ein Update per I2C
> machen kann, falls die Funktion mal erweitert, geändert werden soll.
>
> Peter

Peter sag blos du hat auch einen I2c Bootloader?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.