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?
Angehängte Dateien:
@ 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.
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.
@ 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.
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.
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.
@ 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.
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
Angehängte Dateien:
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.
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 :-)
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.
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
Angehängte Dateien:
-
led-tech-ew-platine.JPG
36 KB
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.
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.
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.
Angehängte Dateien:
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.
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 !"
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)?
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.
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
Angehängte Dateien:
-
nutzen.JPG
69 KB
@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.
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
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
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.
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
Angehängte Dateien:
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.
Angehängte Dateien:
-
bucht-led-kranz.jpg
37 KB
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.
Das Projekt interessiert mich. Wie weit ist es bisher gediehen? Wie wird die Schnittstelle realisiert werden, kann ich da mit einer hardware dran?
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
Angehängte Dateien:
-
LEDenc.png
86 KB
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%
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/Encoder-inkremental-/_i.html ...
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.
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.
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....
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.
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
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 :)
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.
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.
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
@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
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ß?
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.
Reset ist natürlich als IO gefust, hatte ich vergessen reinzuschreiben.
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?
Angehängte Dateien:
-
encoder_9.png
23 KB
> 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.
Im Schaltplan hat sich ein Fehler eingeschlichen, SJ8 sollte von PD1 auf PRG gehen.
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.
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.
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.
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.
Angehängte Dateien:
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-encoders-from-greatecs/2009/08/23 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:
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.
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.
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.
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
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/f970b0cc8f38d62b03619404e9cbc16b/plp2-xxx.pdf 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/314718caa47227d552086b04e7cfc9de/OSTB0603C1C-A.pdf Eine gescheite Strom-Spannungskennlinie spuckt das Datenblatt leider nicht aus! In der Hinsicht war meine erste Wahl (weiß, rechteckig, THT) besser :P
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.
Angehängte Dateien:
-
encoderjsillum.jpg
62 KB
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. http://www.youtube.com/watch?v=gsrLaNSNW3A 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.
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.
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.
Nochwas, als Sammelbestellung kann man auch ein Edelstahlblech lasern lassen. Dürfte auch viel billiger sein, als ein CNC Auftrag.
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
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.
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.
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.
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 :)
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.
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.
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.
Sind das nicht die gewünschten farbigen Anzeigen: http://www.top-up.com.tw/front/bin/ptlist.phtml?Category=325301 http://www.top-up.com.tw/front/bin/ptdetail.phtml?Part=LED-CCL&Category=336089
Siggi schrieb: > Sind das nicht die gewünschten farbigen Anzeigen: > http://www.top-up.com.tw/front/bin/ptdetail.phtml?Part=LED-CCL&Category=336089 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
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.
Angehängte Dateien:
-
encoder_und_knoepfe.jpg
66 KB
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).
Angehängte Dateien:
-
RGB_ENC_TOP_SCH.png
55 KB -
RGB_ENC_TOP_BRD.png
88 KB
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!
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?
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.
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?"
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?
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.
Angehängte Dateien:
-
RGB_ENC_BTM_BRD.png
100 KB
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?
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.
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 :)
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.
Angehängte Dateien:
-
IMG_2849.JPG
320 KB -
IMG_2851.JPG
240 KB -
IMG_2855.JPG
260 KB
ui, die Lieferung kma schneller als erwartet. Ich bestell noch eben Stencils, dann kann ich in spätestens 14 Tagen mit löten anfangen!
Angehängte Dateien:
-
IMG_2892.JPG
180 KB -
IMG_2896.JPG
170 KB
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.
Schaut schon mal gut aus. Bei den Schrauben denke ich, könnte man kleine nehmen.
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!
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?
Ich habe mit 3-Farben-LEDs Test dazu gemacht, ja man sieht sie. :-(
für die, die es nicht selber machen wollen: http://www.exp-tech.de/Shields/LED-Controller/NeoPixel-Ring-24-WS2812-5050-RGB-LED.html 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
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
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.
"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 :-)
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...
How about diesem hier: http://www.conrad.de/ce/de/product/179998/2-Kanal-Miniatur-Gabellichtschranke-EE-SX1131-SMD-Omron-EE-SX1131-2-Kanal-Gabellichtschranke-Reichweite-2-mm 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/Zahnradsortiment-Modul-05?ref=list 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
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 :)
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/175000-199999/179998-da-01-en-2KANAL_GABELLICHTSCHR_SMD_EE_1131_2MM.pdf 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
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/files/s3esk_rotary_encoder_interface.pdf
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
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.
1 | Beispiel: Sensorabstand = 2,5 Zahnbreiten |
2 | |
3 | |
4 | Schlitze: | | | | |
5 | |
6 | _______ _______ _______ __ |
7 | Zähne: ____| |_______| |_______| |_______| |
8 | |
9 | |
10 | Beispiel: Sensorabstand = 3,5 Zahnbreiten |
11 | |
12 | |
13 | Schlitze: | | | | |
14 | |
15 | _____ _____ _____ _____ |
16 | Zähne: ______| |_____| |_____| |_____| |_____| |
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/175000-199999/179998-da-01-en-2KANAL_GABELLICHTSCHR_SMD_EE_1131_2MM.pdf
:
Bearbeitet durch User
Tobias S. schrieb: > How about diesem hier: > > http://www.conrad.de/ce/de/product/179998/2-Kanal-Miniatur-Gabellichtschranke-EE-SX1131-SMD-Omron-EE-SX1131-2-Kanal-Gabellichtschranke-Reichweite-2-mm 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.
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-encoder-12-the-number-of-120-positioning-10pcs-lot/346901_1807050956.html 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
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.
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.
Angehängte Dateien:
-
ledkitali.jpg
62 KB
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.
@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!
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.
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?
Angehängte Dateien:
Gibt es irgendwelche neuen Produkte in dieser Richtung? Ich bin zufälligerweise auf das alte Elektor Board gestoßen, was leider nicht mehr als Bausatz verfügbar ist.
Markus G. schrieb: > Gibt es irgendwelche neuen Produkte in dieser Richtung? Abweichend von der Lösung damals mache ich das jetzt anders: Es gibt programmierbare LED-Ringe mit bis zu 24/32 LEDs, welche einen Controller drin haben. Der wird wie SPI seriell angeschubst. Das ist vom FPGA aus einfacher. Mur das Lesen der Encoder erfolgt noch wie oben beschrieben mit SRs.
Jürgen S. schrieb: > LED-Ringe mit bis zu 24/32 LEDs, ... > Der wird wie SPI seriell angeschubst. WS2812(b) :) https://de.gearbest.com/lcd-led-display-module/pp_530256.html?wid=1433363¤cy=EUR&vip=4275440&gclid=EAIaIQobChMIloHD-cOk3AIVRtiyCh3Iiw2JEAQYAyABEgKjGvD_BwE 66mm kommt mir etwas groß vor. Täuscht mich das? Oder meinst du andre? PS: Schon besser. https://www.led-genial.de/DIGI-DOT-Ring-mit-24-x-WS2812B-LEDs
:
Bearbeitet durch User
Ja genau die, es gibt die aber von unterschiedlichen Anbietern in unterschiedlichen Durchmessern. 24 LEDs gibt es auch mit 55mm. Ich habe schon welche mit 72 LEDs gesehen.
Jürgen S. schrieb: > schon welche mit 72 LEDs gesehen. Da geht noch mehr. :) Wird auch als Leuchtmittel angeboten. Hab mir mal zum spielen, den kleinen da mal geordert. 16LEDs, 32/45mm. Wenn's taugt, passt das noch als Gimmick, in meinen Tussibelichetr. :) https://www.banggood.com/de/Ring-5V-16x-5050-RGB-LED-with-Integrated-Drivers-Module-For-Arduino-p-1199159.html?cur_warehouse=CN Jürgen S. schrieb: > 24 LEDs gibt es auch mit 55mm. Auch schon etwas kleiner gesehen (innen/außen?) aber ~17€ und keine echte Anwendung... :)
Teo D. schrieb: > Jürgen S. schrieb: >> schon welche mit 72 LEDs gesehen. > > Da geht noch mehr. :) Wenn man nicht die relativ grossen WS2812B-LEDs nimmt, sondern normale SMD-LEDs und die direkt ansteuert, z.B. als LED-Matrix, kann man viel mehr unterbringen. Nur ist halt der Aufwand auch viel höher, man muss wohl ein eigenes Bord mit einem kleinen Controller drauf designen. Georg
georg schrieb: > man muss > wohl ein eigenes Bord mit einem kleinen Controller drauf designen. he hhee, pssstt! gug ganz oben ... e i n g a n s p o s t! georg schrieb: > kann man viel > mehr unterbringen. Nur ist halt der Aufwand auch viel höher, Genau, hät ich zB. ne Soundanlage aus NGZ2981, würd ich das auch so machen. ;) Ne ich brauch grad ein paar WS2812b am Stück, zwecks SWE. Hier wirds halt eventuell noch ein Gimmick für den TussiBelichter draus. Is nich viel Platz und ob man den Ring beim bedienen verdeckt, ist auch egal.
Teo D. schrieb: > TussiBelichter Was soll das denn bitte sein? georg schrieb: > man muss > wohl ein eigenes Bord mit einem kleinen Controller drauf designen was den Aufwand umkehren würde. Ich finde diese programmierbaren Ringe interessant. Habe Preise um 2,90 für einen Ring gefunden. Billiger geht es kaum. Aber wie werden die genau angesteuert? Auf den Händlerseiten ist da nichts zu finden.
Angehängte Dateien:
-
Belichter_neu5.jpg
16 KB -
Belichter_neu3.jpg
190 KB
Der Hocko schrieb: > Teo D. schrieb: >> TussiBelichter > Was soll das denn bitte sein? Teil zum aushärten von so Fingernagel-Gedöns, umgebaut zum Belichter. (Gebraucht inkl. p&p 10€) Original. https://www.nd24.de/product/uv-lichthaertungsgeraet-basic.7205.html?p=16&gclid=EAIaIQobChMI8Jet55Cm3AIVS_lRCh15MQwKEAQYAyABEgLmFfD_BwE Der Hocko schrieb: > Habe Preise um 2,90 > für einen Ring gefunden. Billiger geht es kaum. Irgendwie ist das unhöflich... :´(
:
Bearbeitet durch User
Der Hocko schrieb: > Aber wie werden die genau angesteuert? Auf den Händlerseiten ist da > nichts zu finden. Die verwenden NRZ mit so ca. 1/3 zu 2/3 für die Phasen für 0 und 1 - in manchen Datenblättern auch 1/4 zu 3/4. Rausgeschoben werden alle Bits seriell für alle LEDs in der Kette ohne Pause. Es sind jeweils 8 Bit für die 3 Farben in der Reihenfolge R.G.B. mit jeweils MSB first. Also die ersten 24 Bit für die erste LED, die zweiten 24 Bit für die nächste, u.s.w. Am Ende braucht es 50us Pause, damit die LEDs wissen, dass es neu losgeht. Die maximale Datenrate sind gemäß DB wäre unter Anrechnung der Toleranzen theoretisch etwa 1MBit, aber da gab es vermehrt Probleme. Ich fahre die mit 768kHz x 16 mit 5/11 und 10/6 Takten und mache 64us Pause. Das sind bei 24 LEDs 750us und 32 Ringen 24ms -> 40 Hz update Rate. Mit 32 LEDs x 8 Ringen in 4 Reihen wie bei meinem Controller kommt man auf die spezifizierten 30fps. Dabei sieht man aber schon den update-Verlauf. Es wäre also anzustreben, weniger LEDs in einer Reihe zu verschalten. Zu bemerken wäre noch der Stromhunger: Um richtig zu leuchten brauchen die mindestens 10mA je Farbe und das Doppelte bei Vollaussteuerung. Das sind über 1 pro Ring! Da muss ein schnelles SNT oder ein fetter Elko hin, sonst sieht man bei der Beat Anzeige Pumpen. Für 32 LEDs würde ich 2 A auslegen! Wichtig ist auch eine gute GND-Verdrahung. Ich hatte anfänglich Probleme mit der Signalqualität, wenn viele LEDs gleichzeitig geschaltet haben. Bewährt haben sich kleine 1,2uF-Taltal-Elkos an VCC und GND direkt an den Ringen. Sonst geht bei starkem Aufleuchten des einen Rings der Nachbar optisch in die Knie. Wenn das zulässig ist, kann man auch auf den halben Strom auslegen und jede Kette mit einem China MINI-DC_DC-Wandler versorgen, damit voll angesteuerte Ringe nicht so hell werden. Ansonsten kämen bei Vollausleuchtung 60A zusammen! Ich löse es so dass die Helligkeit konstant bleibt, also Weiss z.B. 33%,33%,33% angesteuert wird, Zwei-Komponentenfarben mit 50%,0,50% etc und Einzel-Farben mit 75%. Trotzdem zieht das Ding weit über 10A! Was ich auch gesehen habe, ist, dass die Helligkeiten nicht den gleichen Verlauf haben. Zum einen streuen die LEDs zum anderen die Farben in den LEDs und sie haben nicht die gleich Kurve. D.h. 33% Blau haben weniger Helligkeit, als 33% Rot. Man könnte auch so ansteuern 30,35,40. Wenn man damit also Fernsehen machen möchte, müsste man sich nochmal genauer die Verläufe ansehen und eine Farbraumtransformation entwickeln. Jedenfalls sind die Dinge schon mal sehr bequem, weil sie keine Einzelleitungen und PWM mehr brauchen, wie der erste Prototyp. Letzllich braucht die PWM-Steuerung auch wieder Fläche im FPGA, besonders bei unterschiedlichen Werten. Ich mache da zwar nicht viel damit, aber volle Helligkeit für jeden Wert ist etwas zuviel.
Angehängte Dateien:
georg schrieb: > Wenn man nicht die relativ grossen WS2812B-LEDs nimmt, sondern normale > SMD-LEDs und die direkt ansteuert, z.B. als LED-Matrix, kann man viel > mehr unterbringen. Ja, absolut, ist mir aber zuviel Arbeit geworden. Ein Prototyp reicht. Das Auflöten der LEDs und Bauteilkonstruktion ist nicht so prickelnd. Die Ringe kann man einfach draufpappen und unter der Acrylfrontplatte platzieren. Für meine Zwecke wäre es prima, wenn es noch preiswertere, kleinere und schwächere gäbe, die man als Ringe kaufen oder zusammenfügen kann. Optimal für die MIDI-Zwecke wären flache LEDs, weil man die am engsten setzen kann. Damit bekommt man mit 24 Stück einen Durchmesser unter 2,5cm hin. Mit 32 klappt es perfekt für die idealen 3cm. Nutzt man die Ringe sind 45m fällig und die Drehgeber sitzen mit 5cm. Das habe ich aufgebaut, ist optisch auch schön, aber die Platznutzung unzureichend. Auch dreieckige LEDs wären praktisch, besonders für Anzeigen mit maximal 16 LEDs. Momentan ist es noch eine Animation, bzw. die Visualisierung auf dem Bildschirm. Habe die Chinesen mal angeschubst, dass sie das bauen sollen. :-) Aber vielleicht gibt es die auch schon? Bekannt ist mir nur die Lösung mit dem flachen panel von sparkfun, sowie die 16-fach Baugruppe vom Bild weiter oben. Die werden aber alle mit einem Controller angesteuert.
Zur Auflösung des Behringer BCR2000: Der kann definitiv 14 BIT Auflösung, (16384 statt 127 Schritte) Das kann beinahe jeder MIDI Controller. Es werden einfach 2 cc# (MSB/LSB) von einem Encoder gesteuert. Ist ganz normaler MIDI-Standard seit 1984.
Der Hocko schrieb: > Ich finde diese programmierbaren Ringe interessant. Habe Preise um 2,90 > für einen Ring gefunden. Billiger geht es kaum. > > Aber wie werden die genau angesteuert? Auf den Händlerseiten ist da > nichts zu finden. Für den Preis kannst du nicht mehr Support erwarten. WS2812B?
Wolfgang schrieb: > Der Hocko schrieb: >> Ich finde diese programmierbaren Ringe interessant. Habe Preise um 2,90 >> für einen Ring gefunden. Billiger geht es kaum. >> >> Aber wie werden die genau angesteuert? Auf den Händlerseiten ist da >> nichts zu finden. > > Für den Preis kannst du nicht mehr Support erwarten. > WS2812B? Ich denke die wären viel zu gross, aber es gibt gute Alternativen in kleineren Gehäusen wie z.B. die APA102-2020 (siehe Anhang). Die Ansteuerung ist im Datenblatt beschrieben und rel. einfach. Schafft ein STM32 mittels DMA sogar im Hintergrund ganz ohne Zutun der CPU.
:
Bearbeitet durch User
WS2812c-2020 im bequemen "neopixel" protokoll https://www.tme.eu/de/details/ws2812c-2020/led-dioden-smd-bunt/worldsemi/ juergen / a.s. - ich waer auch an einer weiterentwicklung interessiert
Paul schrieb: > juergen / a.s. - ich waer auch an einer weiterentwicklung interessiert Ich baue auch gerade was mit einem Ring auf. Lässt sich mit einem FPGA ja gut machen.
Habe jetzt mit Hilfe eines Profis ein PCB fuer die midibox-plattform entwickelt das ich gerade auch als bulk-order anbiete, falls jemand interesse hat. 4x ledring/encoder mit jeweils 36 ws2812 in 2020 bauweise und 74hc595. fgpa's schienen zu aufwendig um midibox-basiert schnell ans ziel zu kommen bzw haetten wir uns da erst komplett neu einarbeiten muessen. hier der link zum midibox-forum mit einer genaueren beschreibung und preisen: http://midibox.org/forums/topic/21095-lre-4x1-breakable-rgb-led-ringrotary-encoder-pcb-bulk-order/
Hab hier was in die Richtung gefunden zum fertig kaufen https://www.tindie.com/products/doubledutch/rotary-encoder-w-circular-leds/
Rolf Meurer schrieb: > Der kann definitiv 14 BIT Auflösung, (16384 statt 127 Schritte) > Das kann beinahe jeder MIDI Controller. > Es werden einfach 2 cc# (MSB/LSB) von einem Encoder gesteuert. > Ist ganz normaler MIDI-Standard seit 1984. Ja, das laut MIDI 1.0 in der Tat möglich. Aber die meisten Controller unterstützten das damals nicht und somit die Geräte auch nicht. Noch heute sind die meisten MIDI-Klangerzeuger darauf ausgelegt, bei wichtigen Parametern mit 7 Bits zu arbeiten. Somit bringt ein Eingabegerät mit 14 Bit zunächst nichts, wenn nicht auch die Hardware dahinter das verarbeiten kann. Das ist erst mit den PC-plugins anders geworden, die durchgängig höhere Auflösungen ihrer Parameter verarbeiten.
Tim schrieb: > Hab hier was in die Richtung gefunden zum fertig kaufen > > https://www.tindie.com/products/doubledutch/rotary-encoder-w-circular-leds/ Das wären immerhin 15,- für einen einzigen Kanal. Ich hätte ich Zweifel lieber soetwas gehabt: http://www.doepfer.de/de.htm Leider wurde dieser Controller schon vor Zeiten eingestellt. Für unter 100,- bekam man 16 gute Drehreglerkanäle. Müsste man eigentlich nachbauen können, meine ich.
Ich baue auch gerade ein Encoder-Modul mit LED-Ring. Meins hat 30 LEDs, wird seriell (über UART) angesteuert und ist kaskadierbar. Man braucht also nur zwei Pins (RX und TX) für bis zu 250 Regler. Insbesondere muss man nicht pollen und sich nicht mit I2C-Adressen herumärgern. Warum noch ein Modul? Weil keins der vorhandenen für meinen Zweck richtig taugt. Die sind entweder zu komplex und damit zu teuer (ich brauche keine mehrfarbigen LEDs), zu simpel (zu wenige LEDs wie bei diesem Tindie-Ding), zu groß oder was auch immer. Von meinem Modul werde ich auch ein paar mehr herstellen lassen. Was es genau kosten wird, weiß ich noch nicht, aber auf jeden Fall keine 15 Euro. Bei typischen Abnahme-Stückzahlen (also z.B. 8 Module) bekomme ich das sicherlich für den halben Preis hin.
Angehängte Dateien:
-
bcr32.jpg
280 KB
Behringer den BCR2000 als BCR32 neu aufgelegt, vllt. sogar mit Open Source Firmware, aber genaues ist noch nicht bekannt.
Anbei Bilder meines Encoder-Moduls. In der Mitte wird ein handelsüblicher Dreh-Encoder montiert. Die drei Pins sind für die üblichen Encoder-Signale (A, Common, B) und gegenüber sind noch zwei optionale Pins für einen Drucktaster, den nicht alle Encoder haben. Bei der Monatage sind zwei Varianten möglich: 1. Encoder wird von oben auf die Platine gesetzt und dann einfach auf der Rückseite eingelötet. Das funkioniert mit allen 12mm-Encoder-Typen. 2. Der Schaft des Encoders wird von unten in die Platine geschoben und oben mit der zugehörigen Mutter festgeschraubt. Das erlaubt eine Frontplatten-bündige Montage und erfordert Encoder mit Schraubgewinde um den Schaft. Dazu muss man die Pins am Encoder einfach nur nach oben biegen. Die runde Aussparung für den Schaft hat 9mm Durchmesser, die beiden Mulden rechts und links sind für Snap-In-Federn bei Montage von oben. Wie ich festgestellt habe, haben die meisten Encoder ein M9-Gewinde (so z.B. ALPS), Bourns allerdings M8. Encoder ohne Gewinde benötigen nur 7mm Aussparung. Ich habe versucht, break-away Tabs anzubringen, so dass man das Loch je nach Bedarf zwischen 7, 8 oder 9mm variieren kann. Aufgrund der engen Platzverhältnisse denke ich aber nicht, dass das gut funktioniert. Am universellsten ist insofern das 9mm Loch und sinnvollerweise verwendet man dann halt die passenden Komponenten. Alternativ könnte man aber auch kleine Adapterringe 3D-drucken. Der Ring besteht aus insgesamt 30 LEDs in einem Winkel von 270 Grad. Das sind herkömmliche einfarbige LEDs (viel günstiger als RGB-LEDs mit eigenem Controller). Spannungsversorgung ist wahlweise 3,3V oder 5V. Die Platine hat einen eigenen Spannungsregler, so dass die korrekte Spannung für die LEDs gewährleistet ist. Dann gibt es einen RX- und einen TX-Port für die UART-Schnittstelle zum externen Mikrocontroller. Wird der Encoder gedreht, sendet das Modul eine Nachricht. Indem man Nachrichten an das Modul sendet, kann man einen neuen Wert setzen. Bis zu 250 Module ohne Taster sind kaskadierbar. Sie erkennen beim Einschalten automatisch, ob und in welcher Reihenfolge sie verbunden sind und geben sich selbst eine numerische Adresse. Die erste Platine ist 0, die zweite 1 usw.. Eine Nachricht besteht immer aus einem Adressbyte und einem Datenbyte. Verwendet man Encoder mit Tastern, dann belegt jedes Modul zwei Adressen. Somit sind "nur" noch 125 Module kaskadierbar. Ich würde mich über Feedback freuen: - Wie gefällt Euch das Ding überhaupt so? - Was meint Ihr zum Formfaktor? - Die Anschlusspins habe ich bewusst als SMD-Pads ausgeführt, auf die man von unten Kabel anlöten bzw. einfach Lötbrücken zum benachbarten Modul setzen kann. Ich kann natürlich auch Löcher in die Pads setzen, aber das sieht dann von oben nicht mehr so schön aus und außerdem stehen die Drähte dann oben über, was evtl. bei der Montage einer Blende stört. Wären Euch die Löcher trotzdem lieber? - Ich könnte das Modul auch rund fräsen statt rechteckig. Das sieht sehr schick aus. Leider lässt es sich dann nicht mehr so gut panelizen und wird auch etwas teurer.
:
Bearbeitet durch User
Markus G. schrieb: > Behringer den BCR2000 als BCR32 neu aufgelegt, vllt. sogar mit Open > Source Firmware, open source firmware wäre interessant. Woher kommt diese Info? Dann würde man im Prinzip in der Lage sein, jeder Auflösung zu senden, also auch MIDI2 (16 Bit) für alle Standard-Controller.
Dennis (. schrieb: > Der Ring besteht aus insgesamt 30 LEDs in einem Winkel von 270 Grad. > Das sind herkömmliche einfarbige LEDs (viel günstiger als RGB-LEDs mit > eigenem Controller). Ich habe welche mit 50mm, 40mm und 30mm in 1 und 3 Farben. Die teuersten sind 5,95 das Stück. Das sind 20 Cent je LED. Welche verwendest du? Grundsätzlich kriegt man es mit einem Eigenbau enger, daher ja auch mein Vorschlag aus 2012. Allerdings musste ich lernen, dass das Auflöten der LEDs nicht so prickelig ist, wenn man einen Controller bauen will, der 4x8 solcher Ringe benutzt. Mir sind auch LEDs über den Jordan gegangen, teilweise vor- und auch kurz nach der Inbetriebnahme. Kann sein, dass meine Lötkünste nicht die Besten waren und die LEDs gestresst wurden. Dennis (. schrieb: > Ich könnte das Modul auch rund fräsen statt rechteckig. Das sieht sehr > schick aus. Leider lässt es sich dann nicht mehr so gut panelizen Es kommt drauf an, was man vorhat. Ich brauche in jedem Fall ein Panel das selber wieder mit anderen zu einem Panel zusammengefügt werden können muss, um z.b. eine n x 9 Config zu fahren. (8 Kanäle + Master Fade) Man könnte überlegen, die als echt modulare Einheiten zu fahren und sie erst gar nicht zu brechen, um sie aus dem Los zu bekommen, sondern gleich eine entsprechende Größe DIN A4 oder was auch immer günstig ist, anzulegen. Ich habe mein erstes System mit Eagle gemacht und eine 80 x 120 (mit 2x3) aufgesetzt. Durch die Feinfühligkeit, mit der die Industrie-App arbeiten sollte, mussten große Knöpfe her und das Raster von 40x40 war zu klein für normale Finger. Daher würde man ein 100x150 bauen (wenn es EAGLE sein sollte) oder Europakarten-Maß genommen wird. Die Module müssten dann maximal so 48 x 48 an wirksamer Fläche für Elektronik haben wenn der Encoder exakt mittig ist. Deine Anordnung ist ja nun flach, als Pseudo-Poti mit 270°. Daher kriegst du noch mehr Bruttofläche aus der Platine. Allerdings war mein Ansatz immer den Vollkreis zu nutzen, um mehr anzeigen zu können und auch die LEDs enger setzen zu können, bzw mit den angedachten 32 oder 36 einen kleineren Kreis zu haben. Ist aber Deine Sache. Als Tipp: - Die Platine massiv genug und nicht vorgebrochen, damit man sie auch so ohne weitere Montage als Panel nehmen kann und kein weiteres Gehäuse braucht. Die Encoder müssen stabil halten. - Die Dimension so, dass löt- oder schraubbare Encoder sowohl hart mit der Platine, als auch einer Frontplatte verschraubt werden können. Damit kriegt man die Querstabilität. Die Bedienung als Musiksteuergerät (meine Anwendung zwei) ist bei Encodern (besonders die Tasten) unhandlich, wenn die Angelegenheit zu sehr nachgibt. - Alternativ oder zusätzlich Bohrungen oder wenigstens Platz zwischen der modularen Elektronik, dass man Abstandsbuchsen durchbohren und das Ganze auf einen Träger setzen kann. Nimmt man nämlich die Verschraubung aus Punkt 2 her, so wie ich das mit meinem Vorschlag im Eingangspost mit der Plexiglasscheibe mache, muss das alles sehr stabil sein, um die Scheibe nicht springen zu lassen. Mehr, als 3mm kriegt man nämlich nicht hin, weil der Schaft der Encoder nicht genug Gewinde hat. Man muss ja die Scheibe mit Mutter und U-Scheibe gegenkontern. - Für Musikanwendungen haben sich die geriffelten Knöpfe mit 15mm - 18mm Durchmesser bewährt, wie sie als "Gitarrenknöpfe" verkauft werden. Wenn man die ohne Berührung mit gleitenden Fingern voll durchdrehen will, braucht man ein Elementar-Maß von min 45 mm als Abstand zwischen den Achsen. Ich plädiere inzwischen für 50mm. Damit kann man nämlich auch noch zwei benachbarte Regler gleichzeitig bedienen. Der Ring der LEDs hat idealerweise nicht viel mehr als 40mm Außenmaß, damit 1cm Abstand zwischen den Ringen ist.
Zur Programmierung: Der Vorteil der Encoder ist ein beliebiger Zahlenumfang. Dennoch braucht man mitunter ein exaktes feed back. Es ist daher sinnvoll, genau so viele LEDs zu nehmen, wie der Encoder Rasten hat und diese als Kommastellen anzuzeigen. Bei nur einer Farbe könnte man das wie mit einer Uhr tun und zwei Helligkeiten anbieten: Einen "großen Zeiger", der jeweils die Vorkommastellen hell leuchtend anzeigt und einen "kleinen Zeiger", der nur halbhell leuchtet. Macht der kleine eine Runde, springt der große entsprechend um 1 weiter. Bei einem 32-er Schalter, wäre das ein 2x5 = 10 Bit-System bis 1024. Ich hatte das bei einer Version mit zwei Farben gelöst. Die Schalter werden bei 1-Farb-LEDs mit XOR verknüpft, um sie bei Überlappung sichtbar zu machen. Dazu lässt man den "kleinen" zwischen 0 und 50% Helligkeit blinken. Die dafür nötige PWM müsste der Controller bringen. Kann der das? Will man einen Dezimalschalter bauen, lässt man die beiden äußeren LEDs weg und schaltet immer 3 gleichzeitig, wodurch sich 30/3=10 Stellungen je Schalter ergeben. Macht 10x10 = 100 Positionen. Bei einem 24er Drehencoder nimmt man auch 3 LEDs die eine Position zeigen, wodurch sich 8 ergeben, mit zwei verkürzen Position von nur 2 LEDs links und rechts hat man wieder 10. Alle anderen skalierten müsste man mit einer Schwerpunktbeleuchtung machen: Also einen mindestens 4 LEDs breiten Balken, deren Helligkeiten eine Haube bilden. Ich hatte das mal probiert, durch sehr eng sitzende LEDs einen quasi kontinuierlichen Zeiger zu bauen, aber das braucht dann eine sehr milchige Plexischeibe.
Danke für die umfangreichen Gedanken! Jürgen S. schrieb: > Deine Anordnung ist ja nun flach, als Pseudo-Poti mit 270°. Daher > kriegst du noch mehr Bruttofläche aus der Platine. Allerdings war mein > Ansatz immer den Vollkreis zu nutzen, um mehr anzeigen zu können und > auch die LEDs enger setzen zu können, bzw mit den angedachten 32 oder > 36 einen kleineren Kreis zu haben. Rein objektiv ist der der Vollkreis besser, weil der Winkel pro LED größer ist. Allerdings macht ein kleiner Spalt schon Sinn, um optisch Min und Max zu erfassen - und das Auge ist halt Potis mit 270 Grad gewöhnt. Ich habe auch größere Winkel versucht und das sah immer irgendwie komisch aus. Ich wollte auch nicht die Anzahl der LEDs maximieren, sondern einen sinnvollen Kompromiss finden, bei dem man mit vernünftiger Genauigkeit den Wert ablesen kann. 5 bit scheint mir angemessen. > Ich habe welche mit 50mm, 40mm und 30mm in 1 und 3 Farben. Die > teuersten sind 5,95 das Stück. Das sind 20 Cent je LED. Welche > verwendest du? Du hast auch einfarbige? War mir ganz entgangen. Ich verwende ganz normale SMD-LEDs mit 0603-Footprint in rot (für andere Farben braucht man ggf. andere Widerstände). Wenn man eine ganze Rolle kauft, kostet so eine LED knapp einen Cent (Markenhersteller) oder auch auch weniger (Noname). Mir geht es in erster Linie darum, günstig einen Drehregler mit Total-Recall-Funktion zu realisieren. Man braucht nicht mehrere Farben, um ein Poti nachzubilden. Aber Modul-Vielfalt ist doch prima. > Auflöten der LEDs nicht so prickelig [...] Mir sind auch LEDs über > den Jordan gegangen Ja, das geht besser industriell zu fertigen. Mit Lötpaste und Reflow kriegt man 0603 zwar auch hin, aber Spaß macht es nicht (schon allein weil die LEDs so leicht sind, dass sie gern wegspringen und man kaum noch die Polarität erkennen kann, sobald sie erstmal aus dem Tape raus sind. > Man könnte überlegen, die als echt modulare Einheiten zu fahren und > sie erst gar nicht zu brechen, um sie aus dem Los zu bekommen, sondern > gleich eine entsprechende Größe DIN A4 oder was auch immer günstig ist, > anzulegen. Ja, denn hergestellt werden sie sowieso als Panels. Allerdings ist mir nichts Schlaues für die Vorverdrahtung der Module innerhalb eines Panels eingefallen, daher wird man zumindest drei Lötbrücken von Modul zu Modul brauchen. Und das Verschicken von Panels ist halt auch nicht trivial. Wenn ich ein DIN-A4-Panel mit V-cuts nicht breche, dann bricht es der Postweg - oder ich muss für Verpackung und Porto mehr ausgeben als für die Platine. Bei 40mm-Modulen habe ich das Problem nicht. Aber wie wär's mit einem Makro-Modul von 2x2 Ringen? > Alternativ oder zusätzlich Bohrungen oder wenigstens Platz Sehr guter Punkt. Wahrscheinlich sind Bohrungen in den Ecken ganz gut. > Wenn man die [Knöpfe] ohne Berührung mit gleitenden Fingern voll > durchdrehen will, braucht man ein Elementar-Maß von min 45 mm als > Abstand zwischen den Achsen. Ich plädiere inzwischen für 50mm. Viele Geräte haben 25 - 40mm (ohne LED-Ring). 35mm funktionieren bei meinen Fingern noch prima. 25mm (Korg Minilogue) finde ich schon ziemlich eng. Aber hier noch ein Tipp: der vertikale Abstand kann durchaus kleiner sein als der horizontale. > auch MIDI2 (16 Bit) für alle Standard-Controller. Man könnte zwei Encoder pro Parameter vorsehen (Grob- und Feineinstellung) oder diese per Knopfdruck umschalten, damit man nicht 1300 Umdrehungen für den 16bit-Wertebereich braucht... grundsätzlich sehe ich aber keinen so großen Bedarf, überhaupt höher als 7 bit aufzulösen. Das mag in einigen Fällen Sinn machen (z.B. beim exakten Einstellen von Delay-Zeiten), aber in den meisten Fällen ist der Mehrwert vernachlässigbar. Ist aber auch kein Problem - die Software dazu gehört sowieso eher in die Gesamtanwendung als in jeden einzelnen Regler, und wenn die Module nicht zu unflexibel sind, dann kann jemand der das braucht es ja so machen. > Einen "großen Zeiger", der jeweils die Vorkommastellen hell leuchtend > anzeigt und einen "kleinen Zeiger", der nur halbhell leuchtet. Das ist ziemlich clever und passt auch gut zum vorigen Absatz. Allerdings glaube ich nicht, dass die breite Masse das kapiert. Hängt auch von der Anwendung ab. Wenn man die Option hat, den Wert des letzten Reglers noch auf einem Display zu zeigen (und damit leben kann, dass die anderen erst durch Anfassen exakt angezeigt werden), dann ist der "Sekundenzeiger" overkill. > 50% Helligkeit [...] Die dafür nötige PWM müsste der Controller > bringen. Kann der das? Solange wir nicht viele Helligkeitsstufen brauchen, kann man das ja mit jedem beliebigen uC manuell machen (man muss halt drauf achten, dass nicht irgendwelche ISRs oder Kommunikationsroutinen zu Flackern führen). > Alle anderen skalierten müsste man mit einer Schwerpunktbeleuchtung > machen: Also einen mindestens 4 LEDs breiten Balken, deren Helligkeiten > eine Haube bilden. Warum mindestens 4? Ich wollte zwischen 2 Benachbarten "überblenden" und habe schon überlegt, dass man vielleicht 3 bräuchte, um die wahrgenommene Breite konstant zu halten. Wofür mehr als 3?
:
Bearbeitet durch User
Zu dem Behringer BCR32 heißt es, dass es bald herauskommt. Bezüglich Open source Firmware ist noch nichts bekannt, Behringer arbeitet aber mit den Entwicklern von Zaquencer zusammen. https://www.amazona.de/namm-2021-behringer-bcr32-controller-zaquencer-nach-bcr2000/
Angehängte Dateien:
Dennis (. schrieb: > Man könnte zwei Encoder pro Parameter vorsehen (Grob- und > Feineinstellung) oder diese per Knopfdruck umschalten, Ja, so mache ich das mit meinen tastbaren Encodern. Ein bissl mehr Schmackes beim Drehen und es geht mehrfach schneller. Faktor 3 hat sich bewährt. Markus schrieb: > Zu dem Behringer BCR32 heißt es, dass es bald herauskommt. Wenn die den bringen, werde ich mir den holen. Für meine eigenen Zwecke werde ich aber wohl kein LED Grab mehr aufbauen, sondern es virtualisieren, als mit VGA einen Controller auf den Screen abbilden. Da habe ich dann alle Teilungen die ich will. Man kann auch die Werte direkt anzeigen und einen vertikale rollenden Encoder nehmen: Beitrag "Re: Drehgeber mit "Gangschaltung" = Beschleunigung"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.