Beiträge von synvox

    Irrlicht:
    Das kann man sicher machen, ist auch sicherlich kein Problem. Ich wollte eben einfach nur einen kleinen Umsetzer entwickeln, den man 'nur' auzubauen und einzustellen braucht ohne eine zusätzliche Firmware brennen zu müssen. Sonst könnte man auch einen CPLD, GAL etc. nehmen.


    Leider bin ich langsam auch der Meinung, dass es mit dem 4538 wohl für den Fast Mode nicht geht. Ich habe jetzt selbst mal die Teile bestellt, so dass ich mal testen kann, ob man wirklich nicht Pulsweiten von 250 ns (allerdings wohl knapp) erreichen kann. Nachdem ich mir aber auch das Datenblatt von TI (neben NXP) zum 74HC(T)4538 genauer angeschaut habe (insbesondere die Graphen), ist es wohl tatsächlich ein Grenzfall. 500 ns erreicht man wohl noch einigermassen gut, darunter wird's dann schwierig. Das Design des 4538 ist ja auch schon etwas älter, auch wenn er mit den HC(T)-Typen mittlerweile auch in modernisierter Technik vorliegt.


    Ich habe auch schon eine Alternative parat. Bzw. hatte ich die schon am Anfang im Kopf. Aber weil der 4538 das einzige Monoflop ist, bei welchen das /CD bzw. /R Signal neben der Reset/Disable-Funktion nicht auch noch selbst eine Trigger-Funtion ausübt, habe ich dieses Monoflop gewählt, da der Rest der Schaltung dann mit nur einem zusätzlichen Gatter-Typ (XOR) realisiert werden konnte.
    Die Alternative wäre eben, den SN74AHC123A als dual Monoflop zu verwenden. Dieser kann laut Datenblatt (Graphik) Pulsweiten von bis unter 100 ns locker erreichen. Da sich aber aus den oben genannten Gründen dessen /CLR Signal nicht entsprechend verwenden/verschalten lässt, braucht man drei verschiedenartige Gatter (1 x 2-Input-AND, 1 x 2-Input-AND mit EINEM invertierten Eingang und 1 x 2-Input-XOR) als Zusatzbeschaltung. Glücklicherweise gibt es die "Little Logic"-Bausteine (TI und andere), welche jeweils nur ein bis zwei Gatter des jeweiligen Typs enthalten und somit auch sehr platzsparend sind. Das Ganze wird man dann aber auf jeden Fall nur noch in SMD aufbauen können.
    Wenn ich Zeit habe, werde ich dieses WE schnell mal die Schaltung zeichnen.


    Gruss
    Neni

    Hallöchen,


    hast du trotzdem auch mal geringere C-Werte getestet, 470, 220 oder sogar bis 100 pF runter? Dann hast du automatisch höhere R-Werte, wenn eben der 4538 bei Rs unter 1 kOhm problematisch reagiert. Das kann natürlich schon sein (hatte ich bei meiner Antwort an Florian nicht bedacht, mea culpa), denn die Cx/Rx-Pins haben intern jeweils einen MOSFET, welcher die Cs zum entsprechenden Zeitpunkt gegen Masse entladen soll. Wenn der externe R aber klein genug wird, dass der ON-Widerstand des MOSFETs den C nicht mehr vollständig entladen kann, bzw. dass der sich bildende Spannungsteiler (R und Ron) den unteren Spannungs-Schwellenwert für das IC nicht mehr erreicht, dann funktioniert das Ding nicht mehr.


    Der Nachteil der tieferen C-Werte ist natürlich wie schon gesagt der Einfluss der parasitären Kapazitäten. Wenn man das Ganze aber auf jeden Fall (nicht nur in der Testphase, sondern auch in der Endschaltung auf PCB oder so) mit Trimmpotis für die R-Werte ausstattet, kann man die Pulsdauer jeweils einstellen und die sich je nach Aufbau durch die genannten Einflüsse etwas ändernden Kapazitäten so kompensieren. Weniger als 100 pF würde ich aber auf jeden Fall vermeiden, und die Endschaltung sollte dann so auf- und eingebaut werden, dass die zeitgebenden R- und C-Bauelemente möglichst nahe am Cx/Rx-Pin platziert und mit möglichst wenig Kupferfläche mit diesem verbunden sind. Die Einstellungen an den Trimmpotis macht man dann am Besten mit einem Kunststoff-Schraubendreher (wie man ihn häufig für die Kompensations-Einstellung von Oszi-Tastköpfen findet).


    Gruss
    Neni


    PS: ausserdem solltest du den 74HCT4538 nehmen (also nicht HC sondern HCT)

    Es ist im Prinzip auch so, dass die 400 kHz bzw. 800 kHz die jeweiligen Maximalwerte für die beiden Modi sind. D.h. man kann z.Bsp. im Fast Mode die Bits auch mit niedrigerer Frequenz als 800 kHz raushauen, solange die Pulsdauern für 1 und 0 dem Mode entsprechend bleiben und die Bitfrequenz nicht so langsam wird, dass ein Reset mitten im Datenstrom ausgelöst wird. Natürlich begrenzt man damit die maximale Frame-Rate für eine LED-Kette bestimmter Länge zusätzlich.


    Wenn es also 'nur' darum geht, einen seriellen Eingangs-Stream jeglicher Art in einen seriellen Ausgangs-Stream für WS2811-LEDs zu wandeln (mit einem ATmega oder was auch immer), dann würde ich immer noch eher auf Bitbanging setzen, da es in einem solchen Fall problemlos umsetzbar und flexibler ist.


    Wenn hingegen der µC viele zusätzliche Aufgaben erledigen muss und vielleicht auch noch Effekte/Animationen selbst berechnet bzw. wenn man dann eben auch DMA verwenden möchte und/oder das verwendete System mit einem RTOS läuft, dann wird zeitkritisches Bitbanging schwierig. Andererseits sind dann solche Systeme/µCs meist auch deutlich leistungsfähiger und komplexer und haben eine oder mehrere PLLs und flexible Teiler-Register für die integrierten Peripherie-Schnittstellen, so dass sich dann die SPI-Frequenz recht genau und ziemlich unabhängig vom CPU-Takt einstellen lässt. Und diese Schaltung ist primär für solche Fälle konzipiert.


    Gruss
    Neni

    Hallo Florian,


    wenn du im Datenblatt von NXP nachschaust, dann steht zwar dort: Rext ab 2 kOhm, aber in den Figuren ab Fig. 11 werden die Kurven für bis 1 kOhm runter angegeben. Man sieht auch recht gut aus den Figuren, was bei niedriegeren Widerständen passiert. Der Faktor für die Multiplikation mit R und C (rechts auf der y-Achse angegeben) wird grösser, also nicht mehr 0,7 sondern 0,9 oder je nachdem auch über 1. Man kann die Widerstände schon nicht beliebig klein wählen, da die Kurve gegen unten (kleinere Widerstände) relativ steil ansteigt, d.h. irgendwann steigt der Faktor so stark an, dass man trotz kleinerem Widerstand keine kürzeren Zeitkonstanten mehr erreicht. Wenn ich mir Figur 12 (geht bis 1 kOhm runter) links weiter denke, dann sollte bei Rext etwa 100 Ohm der Faktor auf ca. 1,5 (oder eher weniger) ansteigen, also immer noch gut verwendbar.
    Meine Rechnung von oben war also insofern falsch, als ich immer noch den Faktor 0,7 gewählt und die Daten aus den Kurven nicht berücksichtigt hatte. Deshalb ist es aber um so sinnvoller, Trimmpotis zu verwenden und die effektiven Werte für R mittels eines Oszis oder Logic Analyzers einzustellen. Ev. könnte man auch ein C von 630 pF nehmen, dann könnte man ein etwas grösseres R nehmen (z.Bsp. Trimmpoti mit 2,2 kOhm), hätte dann aber Schwankungen von ca. 10 % zu erwarten (wohl immer noch ok) und der Faktor steigt bei Kapazitäten unter 1 nF in Abhängigkeit der sinkenden Kapazität teilweise noch stärker an als bei sinkenden Widerständen (bei höherem C) (Fig. 11).


    Gruss
    Neni

    Hallöchen,


    ein Kollege aus unserem Hackerspace in Zürich hat die Schaltung getestet und mir bestätigt, dass sie funktioniert, zumindest im Slow-Modus (welchen er benötigt und somit auch getestet hat). Ich selbst habe die Schaltung noch nicht aufgebaut, da bei mir gerade andere Projekte (als solche mit WS2811-LEDs) im Vordergrund stehen.


    firefox0815
    Rein rechnerisch sind die gewählten Werte für R und C für den Fast-Mode (ich nehme an, du benötigst diesen) ok, aber trotzdem sind sie praktisch kaum geeignet. Mit Kapazitäten von 8 und 18 pF bewegst du dich im Bereich der parasitären Kapazitäten von IC-Eingängen, Leiterbahnen, Steckverbindungen, Verbindungslitzen etc. Je nachdem wie du die Schaltung aufgebaut hast, könntest du effektive Kapazitäten von einem Mehrfachen der eingesetzten Werte haben, was natürlich dann zu massiv längeren Pulsen bzw. je nach SPI-Taktfrequenz zu einem praktisch unveränderlichen Pegel am Ausgang führen kann.
    Ich würde dir deshalb vorschlagen, dass du die C-Werte um etwa den Faktor 100 grösser machst und dafür die R-Werte 100 mal kleiner. Zum Bsp. wäre für den Fast-Mode ein C-Wert von 1nF und ein Trimmpoti von 1 kOhm für den R-Wert für beide RC-Zeitkonstanten sinnvoll, wobei für R1 dann ca. 860 Ohm und für R2 ca. 360 Ohm eingestellt werden sollten. Damit bist du dann weit genug vom Bereich der parasitären Kapazitäten entfernt, so dass die eingestellte Pulsweite um vielleicht max. 5 % aufgrund der parasitären Kapazitäten schwanken kann. Klar sollte auch sein, dass die SPI-Taktfrequenz für den Fast-Mode 800 kHz betragen sollte, damit vom Timing her alles stimmt.


    Gruss
    Neni

    Naja, zweilagig wird bei mir definitiv nicht gehen, da ich ja auch noch die komplette 'Intelligenz' (ARM Cortex M3 plus notwendiges Beigemüse) pro Modul auf der Platine haben werde, also 256 RGB-LEDs mit Matrix-Ansteuerung (4 x TLC5971 plus 16 Reihen-Treiber) plus Cortex M3 plus 4 I2C-IR-Proximity-Sensoren plus all das andere Zeug (RS485-Transceiver, SPI-FRAM-Speicher etc.) auf 80 x 80 mm. Ich verwende zwar kleinere LEDs (PLCC4-2020) mit 2 x 2 mm, aber trotzdem geht's nur mit 4 Lagen und blind vias auf beiden Aussenseiten (also Lage 1 und 2 und Lage 3 und 4 durchkontaktiert) und natürlich ein paar wenige through hole vias. Glücklicherweise sind PCBs mit entsprechenden Spezifikationen bei den chinesischen PCB-Fabs lange nicht mehr so teuer wie früher, insbesondere bei Stückzahlen ab 15 oder 20 Stück, da kostet ein PCB ca. 11,5 bzw. 10 $ (ab 100 Stück dann nur noch 6 $). Es kommen natürlich noch Tooling-Kosten von ca. 350 $ dazu, aber die würden auch bei grösseren Stückzahlen gleich bleiben (und dann nicht mehr ins Gewicht fallen) bzw. fallen bei Nachbestellungen der gleichen Platine dann weg.


    Gruss
    Neni

    Naja, diese Chinakracher-Display-Module sind ja schon seit längerem auch via Ebay und versch. US-DIY-Shops verfügbar, z.Bsp. Adafruit (Lady Ada) 32 x 32 mit 4mm Pixel-Pitch. Die Ansteuerung ist wirklich grausam rückständig, aber wie Andre schon sagt, für die Zielanwendung als Videowand-Elemente wohl ok.


    Was mich persönlich auch sehr stört, ist dass ich bei solchen Modulen keine Kontrolle über die verwendeten LEDs bzw. deren Selektion habe. Diese mag ja zwar innerhalb eines Modules eng genug sein, es könnte aber bei Verwendung von zwei oder mehr solcher Module sichtbare Unterschiede zwischen den Modulen geben. Bei einer grossen Videowand aus vielen Modulen (insbesondere im Outdoor-Bereich) mag das vielleicht nicht wirklich stören, aber bei den von mir angestrebten Anwendungen schon.
    Deshalb setze ich persönlich immer noch auf selektierte Reels von auch mal etwas teureren Marken-LEDs, welche man dann selbst zu Modulen bestückt.


    Und wenn man auch noch einzelne Interaktionselemente (wie IR-Abstands-Sensoren etc.) bei einem Pixel-Pitch von 5 mm mit auf's Modul integrieren möchte (wie bei meinem aktuellen Projekt), dann kann man solche Fertigmodule sowieso nicht verwenden.


    Aber eben, je nach Anwendung kann man durchaus auch solche Chinaböller verbauen ;) , wie z.Bsp. bei dem Kickstarter-Projekt (PIXEL), was ich schon mal hier im Forum verlinkt hatte.


    Gruss
    Neni

    Da ich mir ja selbst letztens eine Rolle WS2811-RGB-LEDs zum Rumspielen gekauft hatte und weil in unserem CCCZH (CCC Zürich) Hackerspace noch jemand mit WS2811-Stripes experimentieren wollte (am liebsten mit dem Raspberry Pi), habe ich zur einfachen Ansteuerung solcher LEDs (bzw der WS2811 Chips) über die SPI-Schnittstelle eine kleine Logikschaltung als Umsetzter entwickelt. Dabei war das Ziel, dass die Hardware-SPI-Schnittstelle eines µC direkt verwendet werden kann, ohne Bitbanging und ohne die SPI-Datenworte künstlich zu verbreitern (mehrere SPI-Datenbits entsprechen einem WS2811-Datenbit). Es sollte einfach eine direkte Umsetzung der per SPI gesendeten Datenworte in das WS2811-NRZ-Format erfolgen, und zwar Bit für Bit (also 8 Bit SPI = 8 Bit WS2811-NRZ etc.). Damit sollte es dann auch möglich sein, bei µCs mit integriertem DMA direkt den SPI via DMA anzusteuern, ohne die Pufferspeicher-Grösse durch Datenwortverbreiterung unnötig vergrössern zu müssen. Ausserdem kann man dann auch entsprechend der Datenrate beim WS2811 low speed SPI von 'nur' 400 oder 800 kHz (je nach Speed-Mode) verwenden.

    Die hier gezeigte Schaltung verwendet ein Dual Monoflop ( 74HCT4538 ) und ein 4 x 2-Input-XOR ( 74HCT86 ). R1, C1 bestimmen die Pulsdauer bei einem 1-Bit und R2, C2 diejenige bei einem 0-Bit. Im Slow-Mode (bei den meisten WS2811-LEDs implementiert) ist die Pulsdauer für ein 1-Bit ca. 1,2 µs und für ein 0-Bit ca. 0,5 µs, im Fast-Mode jeweils die Hälfte. Die Werte für R und C lassen sich laut NXP-Datenblatt zum 74HCT4538 folgendermassen bestimmen: Pulsdauer(s) = 0,7 x R x C. Die beiden XOR-Gatter U1.1 und U1.2 sind als nichtinvertierende Puffer geschaltet und wären somit rein von der Logik-Funktion her nicht unbedingt nötig. Ich habe sie aber extra mit eingeplant, damit es zu keiner signifikanten Laufzeitverzögerungsdifferenz der SPI-Signale vor den Monoflops kommt. Durch Verwendung von HCT-Logik ist die Ansteuerung (SPI) sowohl mit 5V- als auch mit 3,3V-Pegeln möglich. Natürlich gehören noch 100 nF Entkoppel-Kondis an die Stromversorgungspins beider ICs (nicht im Schaltplan).


    Das das jetzt keine grossartige Sache ist, hab ich's mal ins TTT gestellt, aber vielleicht ist's ja für jemanden hier noch nützlich.


    Gruss
    Neni

    Mittlerweile muss man nicht mal mehr bei Sammelbestellungen mitmachen, um WS2811-PLCC6-RGB-LEDs für um die 0.13 - 0.14 $ pro Stück zu bekommen, schon ab 50er oder 100er Mengen, beim Chinesen seiner Wahl. Ich habe mir auch schon welche bestellt, einfach um sie mal bei relativ unkritischen Spielerei-Projekten einsetzen zu können.


    Allerdings sehe ich den Einsatz solcher LEDs etwas differenzierter als meine Vorposter.


    Für Matrix-Anwendungen mit geringem bis sehr geringem Pixel-Pitch würde ich auf jeden Fall eine echte Matrix-Verschaltung vorziehen, da man dadurch schon mal sehr viel Strom einsparen kann. Gängige, hochwertige RGB-LEDs namhafter Hersteller benötigen bei entsprechend enger Platzierung gerade mal 1 - 2 mA pro Pixel und Farbe im Schnitt (je nach Multiplexing um die 15 - 30 mA pro LED und Farbe in einer Zeile), um bei Weiss Leuchdichten von 1500 - 2500 Cd / m^2 zu erreichen, was auch in tageslicht-hellen Räumen gute Sichtbarkeit und Kontraste ermöglicht. Für Outdoor-Anwendungen braucht es ca. 4000 - 5000 Cd / m^2 oder mehr, da müsste man dann höher bestromen.


    Leider kann man bei den mir bisher bekannten 'Digital-LEDs' den Strom nicht einstellen, da er fest auf um die 20 mA pro Farbe eingestellt ist. Damit kommen diese LEDs bei eng bestückten Matrix-Anwendungen eigentlich kaum in Frage. Ein grosser Nachteil ist diesbezüglich auch, dass man keinen Weissabgleich via Stromeinstellung für die drei Farben machen kann, sondern dafür u.U. PWM-Bittiefe opfern muss.


    Ausserdem ist bei mir auch immer die Frage der Selektion der LEDs eine entscheidende. Für den 0-8-15-Hobbyisten und je nach Anwendung mag das nicht so eine Rolle spielen, aber ich bin gerne bereit, mehr zu bezahlen, wenn ich dadurch z.Bsp. pro Reel selektierte LEDs mit einer garantierten Variantionsbreite von 'nur' ca. +/- 11 % (Lichtintensitätswerte) bekomme. Und sowas gibt's eben praktisch immer noch nur bei Markenware, leider.


    Gruss
    Neni


    EDIT: Ich muss mich korrigieren. Die APA-101-LEDs haben eine globale Stromeinstellung von 5 Bit, d.h. 32 Stufen. Damit wären sie auch für niedrigere Bestromungen verwendbar, bieten aber für den Weissabgleich keinen Vorteil, da es eben eine globale Einstellung ist.

    Also ich find' diese Heißklebepistole nich so cool. Den hier finde ich weitaus cooler.


    Naja, ich bin grundsätzlich kein grosser Fan von FDM 3D Printern ala RepRap, Makerbot und Konsorten. Meiner Meinung nach sehen die Druck-Ergebnisse auch bei den neueren, teureren Modellen und höheren Auflösungen bzw. dünneren Extruder-Öffnungen im zahlbaren DIY-Bereich immer noch nach 'eindeutig selbst gemacht' und recht unprofessionell aus. Das liegt einfach an den Limitierungen der FDM-Technologie. Beim 3Doodler spielt das ja keine Rolle, weil es da ja auch nicht um Exaktheit und professionellen Look geht sondern mehr um kreatives 'Rumspielen'. Ansonsten lasse ich bisher Konstruktionselemente, Gehäuseteile etc. lieber bei 3D-Printing-Anbietern wie Shapeways mit deutlich überlegenen Verfahren wie STS, SL etc. fertigen. Mit dem Form1 ist jetzt allerdings der erste zahlbare 3D-Drucker für den Consumer-Bereich mit SL-Technologie verfügbar (bzw. noch nicht, erst ab diesen Frühling/Sommer). Deshalb habe ich ja auch für den gebacked.


    Was Kickstarter betrifft, so muss man sicherlich bei der Auswahl der zu unterstützenden Projekte eine Prise gesunden Menschenverstand walten lassen, insbesondere wenn's dann höhere Beträge sind. Was ich bei Kickstarter allerdings auch gut finde, ist dass das Geld erst dann abgebucht und dem Projektersteller überwiesen wird, wenn die Pledge-Zeit abgelaufen ist und das Projekt erfolgreich vollständig gebacked worden ist, d.h. der vom Erstelller angepeilte minimale Goal erreicht worden ist. Wenn das Projekt nicht erfolgreich gebacked worden ist, wird das Geld von den Backern gar nicht erst abgebucht. Natürlich nützt das nichts, wenn ein erfolgreich gebacktes Projekt dann irgendwo in der Realisierungsphase stirbt. Zwar haben die Projekt-Ersteller gegenüber ihren Backern klare rechtliche Verpflichtungen, aber eben, diese müsste man im Streitfall dann auch durchsetzen können.


    Ob es sich bei Kickstarter um eine Art Verkaufsplattform handelt, hängt in meinen Augen sehr stark von der Art der Projekte ab. Technologische Projekte bieten als Reward natürlich meistens auch das zu erstellende Objekt selbst an. Hingegen gibt es viele Projekte im künstlerischen oder kulturellen Bereich, wo man als Reward entweder Merchandising-Artikel oder eine lobende Erwähnung bekommt (z.Bsp. im Abspann eines Dokumentarfilmes oder so) etc. Es ist eben eine Crowd-Funding-Plattform, also irgendwie schon auch eine Kategorie für sich.


    Gruss
    Neni

    hihi, ja, dieses "muss ich haben"-Gefühl hatte ich auch, darum hab' ich's natürlich auch gleich mit 99 $ bzw. 109 $ (wegen int. shipping) gebacked, das Projekt. Ist aber schon extrem, die haben das Projekt vor zwei Tagen reingestellt, und haben jetzt schon über ne Million $ zusammengebekommen (über 13000 Backers) :!:


    Das ist jetzt das zweite Kickstarter-Projekt, das ich backe. Das erste für mich war der Form1, wo ich rund 3000 $ investiert habe. Wenn alles nach Plan läuft, sollte ich meinen Form1 im April/Mai bekommen.


    Gruss
    Neni

    Ist der ADC vom AVR denn schnell genug, um damit direkt hintereinander die 7 Bänder einzulesen?


    Ja, das ist er. Das ist ja eben gerade der Witz an der Sache, dass man gar nicht so schnell einlesen muss, weil ja die DC-Werte pro Band über einen gewissen Zeitraum 'gespeichert' sind. Es reicht zum Bsp. vollkommen, wenn man die DC-Spannungen aller 7 Bänder jeweils einmal alle 10 ms ausliest (konvertiert). Damit definiert man auch gleich die vollständige Decay-Zeit für die DC-Peaks auf 100 ms (10% Decay pro einmal Auslesen). Ein Track mit 140 BPM (relativ schnell) hat ja ca. 2.3 Beats pro Sekunde, also reicht die obige Ausleserate bei weitem. Natürlich sind bei höheren Frequenzen durch schnelle Hihats etc. auch die Abstände der Levelunterschiede kürzer, aber der DC-Level muss ja auch nicht immer vollständig auf 0 gebracht werden. Man kann natürlich mit der Ausleserate etwas spielen, um die für die eigene Auswertung ideale Decay-Zeit herauszufinden. Dabei kann man sich die Decay Zeit auch als einstellbare Zeitkonstante (R C) bei einer rein analog aufgebauten Peak-Detektor-Schaltung vorstellen.


    Worauf man aber eben achten muss, ist dass der Eingang der Spannungsauswertung hochohmig sein sollte, damit die Settling Time der Ausgangsspannung nicht allzu lang wird. Deshalb empfehle ich bei Successive Approximation ADCs (weil diese zumindest während der Sample-Phase oft recht niederohmig sind) die Zwischenschaltung eines Impedanzwandlers.


    Gruss
    Neni

    Hallo Denis,


    wenn es dir nicht nur bzw. nicht spezifisch um den Lerneffekt beim Aufbau analoger Filterschaltungen geht, kannst du dir ja mal diesen Post anschauen, wo wir hier schon mal über Spectrum Analyzer diskutiert haben. Ich habe in diesem Post den MSGEQ7 vorgeschlagen, welcher in einem 8-Pin-Gehäuse einen kompletten 7-Band-Spectrum-Analyzer mit vorgeschaltetem Antialiasing Filter inkl. Gleichrichter- und Peak-Detect-Schaltung beinhaltet. Die externe Beschaltung ist sehr minimal gehalten, so dass man den Chip-Ausgang eigentlich nur an den ADC-Eingang zu legen braucht. Allerdings würde ich im Fall eines Successive Approximation ADC (wie beim AVR) eher noch einen kleinen Rail-to-Rail-Opamp als Impedanzwandler (Unity Gain) dazwischenschalten.


    Gruss
    Neni

    Übrigens bietet Microchip auch schon eine fertige Single Channel Proximity Lösung an: MTCH101 (auch im SOT-23-6)


    Die finde ich persönlich von der Verschaltung her einfacher als Atmels QTouch-Systeme, da kein Referenzkondi gebraucht wird. Auch die Sensitivitätseinstellung mittels Spannung (via Poti oder DAC etc. möglich) macht das Ding sehr flexibel einsetzbar, finde ich.


    Gruss
    Neni

    Also das Konzept ist mir auch nicht ganz klar, aber mir scheint auch, dass du (Matyr) es selbst möglicherweise auch nicht bis zum Ende durchdacht hast.


    Die Matrix sieht mir nach einem 64 Zeilen x 16 Spalten RGB-System aus (wobei hier die Spalten gemultiplext werden). Ob du's dann organisatorisch und vom Layout her als 32 x 32, 2 x 32 x 16 oder auch als 4 x 16 x 16 aufbaust, spielt im Grunde für die Ansteuerung keine grosse Rolle. Du fütterst ja die PWM mit 8 MHz, was bei 12 Bit (also 4096 Clocks) und einem vollständigen PWM-Zyklus pro Spalte dann eine Spaltenumschaltfrequenz von 1953 Hz ergibt. Bei 16 Spalten ergibt das eine Bildwiederholrate von gerade mal 122 Hz. Wie du da auf 500 Hz gekommen bist, ist mir schleierhaft.
    Wenn du allerdings 'nur' eine 16 x 16 RGB-Matrix aufbauen willst und diese eben organisatorisch in 4 x 4 Spalten x 16 Zeilen aufteilst, wobei jeweils immer 4 Spalten parallel durchgeschaltet werden und jeweils 16 Zeilen pro 4 Spalten verwendet werden (also insgesamt die 64 Zeilen), dann dürfte das mit den 500 Hz (genauer: 488 Hz) hinkommen. Du musst dann allerdings deine beiden Spalten-Schieberegister mit 0001000100010001 vorladen (vor dem automatischen Zyklisch-Schieben).


    Das Problem bzw. die Performance-Problematik wird aber aber sowieso nicht die Spaltenumschaltung sein (der du so viel Hardware gewidmet hast), das bekommt der µC problemlos hin. Die Zeilen-Daten für jede Spalte zeitig rauszuschieben und die Synchronisation mit der PWM-Clock bzw. den PWM-Zyklen und damit der Spaltenumschaltung ist die eigentliche Herausforderung. Wie willst du zum Bsp. die Synchronisation der Zeilen-Daten-Einschiebung mit der Spaltenumschaltung bewerkstelligen, wenn du schon die Spaltenumschaltung vollautomatisch (abgekoppelt vom µC) durchführen willst? Davon sehe ich nichts im Schaltplan.
    Wie mein Vorredner bereits geschrieben hat, musst du pro Spalte mindestens 192 x 12 = 2304 Bit rausschieben (wenn du noch Dot Correction für jeden Pixel machen willst, dann sogar 288 x 12 = 3456 Bit). Bei 4096 Clocks bei 8 MHz pro Spalte Zeit muss dein Daten Rausschieben mit mindestens wohl 6 MHz erfolgen, besser noch mit 8 MHz. Wie ich gesehen habe, hast du Serial In und Serial Clock mit einfachen Portpins am AVR verbunden. Bei den Geschwindigkeiten kannst du es eigentlich gleich vergessen, das mit Bitbanging machen zu wollen. Du solltest unbedingt die Hardware-SPI nutzen, und selbst dann wird's schwierig.


    Und da ist dann noch nicht einmal von den sonstigen Dingen die Rede, die dein µC 'parallel' machen muss. Und die Implementation von Doppel-Bildpuffern (Stichwort: PingPong) im RAM lasse ich auch mal beiseite, solange nicht klar ist, was du eigentlich wirklich erreichen willst.


    Gruss
    Neni

    Ja, ich habe gerade gesehen, dass die 32x32 Version bei adafruit einen Pixel-Pitch von 4 mm (ist 128 mm x 128 mm) hat und 120 $ kostet. Die 32x16 Version hat einen 6 mm Pitch (ist 192 mm x 96 mm) und kostet 45 $. Da scheint es sich also typischerweise um so China-Matrix-Verhaue zu handeln, welche in versch. Pixel-Pitch- und Modulgrössen-Versionen erhältlich sind, wobei die mit grösserem Pixel-Pitch wohl günstiger sind (macht wohl auch Sinn bei ansonsten gleichem RGB-LED-Typ und Ansteuerungselektronik). Da kann ich mir durchaus vorstellen, dass 32 x 32 Pixel-Versionen mit einem Pixel-Pitch von grob 7,12 mm (wenn die 9'' x 9'' Angabe korrekt ist) als Direktimport aus China wohl für um die 50 $ zu haben sind (entsprechende Abnahme-Menge vorausgesetzt).


    Ich muss zugeben, dass ich kein grosser Fan dieser China-Fertig-Matrix-Trumms bin. Das Ansteuerungs- und Treiber-System ist die absolute Billiglösung. Es werden lediglich einfache Schieberegister mit Konstantstrom-Ausgang als Spalten-Treiber und dann noch entsprechende Zeilen-Treiber in einer 32 x 8 bzw. 64 x 8 Anordnung für R, G und B verwendet. D.h. dass eine eventuelle PWM-Ansteuerung in Software erfolgen muss oder sonst eben per FPGA. Das ist auch der Grund, weshalb im DIY-Bereich (inkl. diesem Kickstarter-Projekt) solche Matrix-Verhaue unter Verwendung einfacher µCs mit maximal 4096 Farben (also 4 Bit PWM pro Farbe) angesteuert werden.


    Gruss
    Neni

    Wenn hier schon Kickstarter-Projekte besprochen werden, dann stelle ich mal das folgende zur Diskussion:


    PIXEL: Interactive LED Art


    Allerdings beschränkt sich die Eigenleistung der Entwickler bei diesem Projekt grösstenteils auf das Konzept (bzw. die Zusammenstellung geeigneter Komponenten) und die Programmierung der ANDROID-App. Sowohl die RGB-LED-Matrix (erhältlich als 32 x 32 oder 32 x 16 Pixel) als auch das IOIO-Controller-Board (aus welchen das System primär besteht) kann man schon länger z.Bsp. bei ADAFRUIT als Fertigkomponenten kaufen.


    Trotzdem finde ich die Idee an sich ja ganz nett.


    Gruss
    Neni

    modulierst Du dann BRI und SAT auch noch per Algorithmus, also dem Plasma-Algorithmus, oder rechnest Du das irgendwie um, also die Ausgabewerte vom Plasma dann in *Kombinationen* von HUE, BRI und SAT..?


    Es werden BRI und SAT auch moduliert per Algo, zwar schon in Abhängigkeit vom jeweiligen Hue-Wert, damit's zum Plasma-Muster passt, aber es sind ansonsten unabhängige Modulationen.


    da wird Neni bestimmt auch ne höhere Bittiefe verwenden, nehme ich mal an...?


    Eigentlich habe ich in Processing den Farbraum extra auf ca. 23.5 Bit (Hue: 6 * 7 Bit = 6 * 127 = 762, Sat: 7 Bit = 127, Bri: 7 Bit = 127) beschränkt, weil ich's am Ende im C-Code in je 7 Bit RGB (21 Bit) umwandle und eine 7 nach 10 Bit Gammakorrektur mache. Nach den Erfahrungen mit dem Processing-Code kann ich sagen, dass Farbauflösungen von 7 und 8 Bit Pro Farbe absolut ausreichend sind, man sieht da kaum Nachteiliges. Viel wichtiger ist aber wie schon gesagt die diskrete Auflösung der Trigonometrischen Funktionen. Diese hat extremen Einfluss auf die 'Weichheit' der Animationen und den sinnvollen Einstellbereich der Modulationstiefe und -geschwindigkeit.


    Gruss
    Neni