Beiträge von synvox

    Ich habe gelesen, dass ich die LEDs mit dem zum Multiplexing passenden n-fachen Pulsstrom treiben muss, um gute Helligkeitsergebnisse zu bekommen


    Naja, dieser Satz impliziert, dass die Rechnung schon korrekt gewesen ist, zumindest so wie es sich der TE wohl vorgestellt hat. Er hat nämlich schon den jeweiligen Reihen-Strom mit 8 multipliziert, damit am Ende ein mittlerer Strom pro LED und Farbe von 20 mA für das ganze Panel rauskommt.


    Damit ergäbe sich ein Peak-Strom von 160 mA pro LED und Farbe. Das Problem ist aber, dass sehr viele PLCC6-LEDs 'nur' Peak-Ströme von max. 100 mA, und das bei Pulsweiten < 1/10 und Pulsbreiten < 100 µs pro LED und Farbe auf Dauer vertragen. Also muss man die max. Bestromung entsprechend anpassen.


    Ausserdem ist je nach Pixel-Abstand (je kleiner desto kleiner die Gesamtfläche) häufig schon eine deutlich geringere Bestromung absolut ausreichend, um auf eine annehmbare und angenehme Leuchtdichte zu kommen. Ich habe gerade kürzlich hier im Forum ein Beispiel vorgerechnet, finde aber den Thread nicht mehr so auf die Schnelle.


    Gruss
    Neni

    Hallöchen,


    man kann sich die zu erwartende Leuchtdichte ja auch ungefähr ausrechnen. Da es sich bei den LED Chips ohne Linse (auch die mit diffusem Epoxy gefüllten) praktisch um lambertsche Strahler handelt, ist so jeder PLCC6-Pixel insgesamt auch ein lambertscher Strahler in seinem Flächenelement.


    Wenn man nun die ganze Matrix als Leuchtfläche betrachtet (obwohl man natürlich je nach Betrachtungsabstand und ohne diffuse Plexi-Front die einzelnen Pixel noch deutlich wahrnimmt), kann man die Leuchtdichte der ganzen Matrix grob bestimmen, wenn man annimmt, dass jeder Pixel das Quadrat des Pixelabstandes als Fläche hat.


    Eine dieser PLCC6-LEDs von Turi wird bei 20 mA Bestromung pro Farbe (bzw. nach dem Weissabgleich 20 mA für die am stärksten zu bestromenden Farbe) bei Weiss sicherlich locker 2000 mcd in Abstrahlrichtung bringen. Bei 8 - 10 mA wird man also sicher gute 1000 mcd (= 1 cd) erreichen.


    Dein Pixelabstand beträgt nun (aufgrund des Layouts geschätzt) ca. 25 mm. Jeder Pixel hat also eine Fläche von 625 mm^2 (= 0,000625 m^2). Es ergibt sich also für die gesamte Matrix bei Weiss und 8 - 10 mA eine Leuchtdichte von ca. 1 cd / 0,000625 m^2 = 1600 cd/m^2. Ein heller TFT-Bildschirm hat bei Weiss ca. 500 cd/m^2, viele haben weniger. Somit dürftest du mit 8 - 10 mA im Innenbereich auch bei Tageslicht keine Probleme haben. Ich würde sogar vermuten, dass du auch mit deutlich weniger mA gut auskommst. Ohne diffuses Plexi vorne dran wirst du die einzelnen Pixel natürlich noch viel heller (aber eben auch deutlich als Pixel) wahrnehmen, da die Leuchdichte der ganzen Matrix natürlich eine Mittelung über die ganze Fläche darstellt.


    Mit diffusem Plexi ändert sich übrigens die Berechnung nicht, da die angestrahlte Fläche wiederum selbst einen lambertschen Strahler bildet. Das Licht wird einfach besser über die Fläche verteilt, so dass man die einzelnen Pixel nicht mehr so gut erkennt. Die Leuchtdichte insgesamt bleibt aber die gleiche, natürlich abzüglich der Verluste durch das Plexi. Bei stark lichtstreuendem Plexi mit trotzdem hoher Transmission (Satinice oder Satin Ice) betragen diese Verluste aber 'nur' ca. 10 - 17 %.


    Übrigens solltest du unbedingt einen dunklen (schwarzen) Hintergrund für deine LEDs wählen, wenn du wirklich genügend Kontrast und vivide Farben für die Matrix auch bei Tageslicht haben möchtest. Das gilt übrigens auch dann, wenn du Kästchen für die Pixel mit diffusem Plexi drüber planst. Dann sollten auch die Wände der Kästchen möglichst schwarz sein. Es verbieten sich dann auch allzu milchige Plexi-Sorten, da diese im Tageslicht einfach zu hell sind und somit auch den Kontrast negativ beeinflussen. Als Plexi eignen sich die von mir oben erwähnten Sorten, eben mit guter Streuung und trotzdem hoher Transmission. So wird auch das Tageslicht kaum reflektiert, sodern geht durch das Plexi und wird grösstenteils vom schwarzen Hintergrund geschluckt. Da deine Platinen weiss sind, könntest du sie z.Bsp. mit matt-schwarzem Deko-Papier (mit Ausschnitten für die LEDs) bedecken.


    Gruss
    Neni

    Eine mögliche Methode wäre es auch, zwei Stück vom MSGEQ7 zu nehmen und mit den frequenzgebenden Bauteilen (R und C) den Clock des einen etwas unter der Nominalfrequenz (so 0,75 oder so) und den Clock des anderen passend dazu über der Nominalfrequenz (so 1,25 etwa) einzustellen. Da die Bandpässe (Switched Capacitor Filter) der Oszillator-Frequenz folgen, würde sich, die Frequenzen geschickt gewählt, so ein 14-Band-Analyzer ergeben. Natürlich überlappen die Bandpässe dann auch mehr, aber ich denke, durch Kombination einzelner Band-Resultate (Messungen auf zwei ADC-Kanälen) würdest du schon brauchbare 8 Frequenzwerte rausholen können.


    Gruss
    Neni


    EDIT: mit den oben angegebenen Faktoren würden sich folgende 14 Bänder ergeben (in Hz): 47, 79, 120, 200, 300, 500, 750, 1250, 1875, 3125, 4688, 7813, 12000, 20000

    Hallöchen,


    schau mal hier, das könnte etwas für dich sein. Der MSGEQ7 hat leider 'nur' 7 Frequenzbänder, aber meines Wissens gibt's sonst keine entsprechend integrierte Lösung am Markt, welche eine ähnlich vollständige, analoge Signalaufbereitung mit digitaler Steuerung in einem Chip bietet.


    Die Firma Mixed Signal Integration hat auch noch weitere kleine Schmankerl (im Bereich integrierter, analoger Signalaufbereitung) in ihrem Programm.


    Gruss
    Neni

    (interessantes Featur, dass gibts beim AVR nicht)


    Doch, etwas ähnliches gibt's auch beim AVR, also zumindest bei den Mega, bei den Xmega weiss ich's nicht. Im ADMUX Register gibt's das ADLAR Bit (AD Left Adjust Result). Wenn dieses auf 1 gesetzt wird, dann wird das 10 Bit Ergebnis eben 'linksbündig' gemacht. Dann stehen die 8 höher wertigen Bit in ADCH und die zwei niederwertigen in ADCL (allerdings dort dann an Position 6 und 7, also auch 'linksbündig').


    Gruss
    Neni

    Hallo Katja,


    wie teuer darf denn die Lampe sein? Ein wunderschönes (natürlich absolut subjektiv), modernes und elegantes Design hat z.Bsp. die Z-BAR Tischleuchte von Koncept. Die Leuchte hat 6 HP-LEDs mit zusammen 9W bei 3500 K, was ich als sehr gute Lichtfarbe für Arbeitsbeleuchtung empfinde (nicht so warm wie übliches Wohnzimmerlicht, aber auch nicht zu kalt).


    Aber eben, gutes Design hat seinen Preis, die Lampe kostet im oben verlinkten Shop 275 €. Ob's die sonst wo in DE günstiger gibt, habe ich nicht recherchiert.


    Im selben Shop findet man eine ganze Palette von Koncept LED Leuchten.


    Gruss
    Neni

    Das coole daran ist insbesondere, dass die Idee so bestechend einfach und auch sehr simpel zu realisieren ist. Und dennoch ist der resultierende Effekt einer interaktiven LED-Wand wunderbar lebendig.


    Dreimal :thumbsup: für die fast schon geniale Einfachkeit.


    Gruss
    Neni

    Was sich für mich letztens als absolut sicherste und schnellste Methode für so fine-pitch Hundertfüsser ((T)SSOP, (T)QFP etc.) herausgestellt hat, ist folgendes:


    1. Chip mit etwas gelartigem Sekundenkleber (eher Minutenkleber) unten am Gehäuse versehen, auf PCB leicht andrücken und korrekt auf Pads ausrichten.


    2. Eine dünne Wurst Lötpaste mittels Spritze am äusseren Rand der Chip-Beinchen längs der Pad-Reihe(n) quer über die Pads auftragen.


    3. Die 'amtliche' ;) Hohlkehlen-Lötspitze (trocken) langsam (so dass die Lötpaste dabei schmelzen kann) entlang der Lötpasten-Wurst ziehen und das sich in der Hohlkehle sammelnde, überschüssige Lot danach am Schwamm (oder besser am Messingspanknäuel) abstreifen.


    4. Vorgang 3 evtl. noch 1 - 2 mal wiederholen, bis das Ergebnis ok ist (Bei den Wiederholungen kann schneller gezogen werden).


    Da in der Lötpaste schon mehr als genügend Flussmittel drin ist, braucht man kein zusätzliches. Allerdings ist es von Vorteil, zumindest eine Stirn-Lupe zu verwenden, weil eine gute Detail-Sicht nicht nur bei dieser Methode das A und O für ein kontrolliertes, gutes Löten von Hand ist.
    Ich habe mir deswegen letztens sogar eine Stereo-Lupe (bzw. ein Stereo-Mikroskop) mit Schwenkarm-Stativ geleistet, und ich muss sagen, der Unterschied ist wie Tag und Nacht. Was ich vorher nie für möglich gehalten hätte, ist nun fast mit Leichtigkeit von Hand machbar. Es ist schon erstaunlich, was eine entsprechende Vergrösserung ausmachen kann, das hätte ich vorher nie gedacht.


    Gruss
    Neni

    So wie ich das sehe, sind die Daten spaltenweise angeordnet. Wenn der Zeichensatz höher als 8 Pixel ist, dann werden zwei Byte, also 16 Bit pro Spalte benötigt. Angeordnet sind die Daten jeweils als oberes Byte (die oberen 8 Pixel der Spalte) zuerst, dann unteres Byte, wobei das most significant Bit im Byte jeweils den untersten Pixel des vom Byte dargestellten Spaltenteils bezeichnet. Das erste Byte des Zeichens gibt dann noch die tatsächliche Zeichenbreite an (von Anfang der Definition bis zur letzten Spalte, welche nicht leer ist), damit eben Zeichensätze mit variabler Zeichenbreite dargestellt werden können.
    Ich kenne weder die Interna der X-GLCD Lib von mikroe noch die genaue Anordnung der Bytes im jeweiligen Display, also kann ich nicht sagen, ob die Zeichen-Definition notwendigerweise in dieser Art geschehen muss bzw. ob es möglicherweise von der Darstellungsgeschwindigkeit her sinnvoll ist, es eben so zu definieren, damit möglichst auf zeitaufwendige Daten-Umformatierungen vor der Ausgabe verzichtet werden kann.


    Gruss
    Neni

    Naja, ein gut gemachtes Download-Proggi würde die "UserAgent"-Angabe einfach faken. Der HTTP-Request-Header ist ja nix anderes als Text, welcher per TCP/IP übertragen wird. Da kann ein Proggi im Prinzip angeben, was es will, wenn es direkt selbst einen TCP/IP-Socket öffnet.


    Am Besten ist immer noch, wenn man in der Schweiz wohnt ;) . Hier darf man sich alles runterladen, auch von 'illegalen' Quellen, wenn man es selbst nicht weiter verbreitet.


    Gruss
    Neni

    Ich habe es selbst erst vor ca. 2 Monaten entdeckt und bin immer noch in der Rumspiel-Phase ;) .


    Aber nur schon durch's 'Rumspielen' konnte ich enorm schnell Erfolge mit ersten kleinen GUI-App-Tests auf meinen beiden Android Devices (Samsung Galaxy SII Phone und ASUS Transformer Prime Tablet) feiern.


    Mit dem Android Kalender habe ich noch keine Erfahrungen, aber wenn etwas nicht in der Core Library zu finden ist, dann fast sicher in einer der Zusatzlibraries. Scroll mal unter Documentation etwas runter, da werden alle momentan verfügbaren Zusatzlibraries gelistet. Es gibt fast nichts, was es nicht gibt.


    Bzw. schon gefunden, hier: calendar2


    Gruss
    Neni

    Gerade was die schnelle Entwicklung von Android-Apps zur Steuerung mittels Bluetooth, WiFI (TCP, UDP etc.) oder auch via. USB OTG (bei den Geräten und Android-Versionen, die dies unterstützen) betrifft, kann ich Basic4android nur wärmstens empfehlen. Es ist eine vollständige RAD (Rapid Application Development) Plattform mit einem WISIWYG-GUI-Editor und einem entsprechend ereignisorientierten Objekt- und Funktionsframework ähnlich z.Bsp. Visual Basic für Windows. Am Besten sieht man sich mal den Link "Features and benefits" und "Screenshots" an.
    Für 99$ bekommt man die Vollversion inkl. 2 Jahre Upgrades; Vollversion inkl. 2 Monate Upgrades kostet 49$.


    Seit ich dieses RAD habe, mache ich mir eigentlich keine Gedanken mehr zu irgendwelchen mobilen Controller-Systemen mit TFT-Displays, weil ja eben entsprechende Android-Geräte so weit verbreitet sind und zum Teil auch für sehr wenig Geld vertackert werden.


    Gruss
    Neni

    nochmals O.T.


    Ich habe schon recht viel mit der mbed-Plattform rumgetestet, so dass ich da ( bzw. generell zum LPC1768 ) bei konkreten Fragen behilflich sein könnte.


    mbed basiert eben auf dem 32 Bit ARM Cortex M3 "LPC1768" von NXP. Mit dem Kauf eines mbed-Entwicklungsmoduls hat man auch automatisch Zugriff auf den auf Keil µVision basierenden Online-Compiler und auch auf die Peripheral Library (besonders wichtig). Mittlerweile ist man aber nicht mehr nur auf den Online-Compiler angewiesen, sonder kann seine Projekte jeweils inkl. Library auch für Keil MDK ARM und für diverse GCC-Toolchains exportieren und dann in diesen weiter arbeiten. Insbesondere durch die wirklich gute und umfangreiche Peripheral Library (von den ARM-Leuten selbst entwickelt und gepflegt) macht die mbed-Plattform den Einstieg in die ARM-Welt meiner Meinung nach besonders einfach. Jedenfalls war es bei mir so. Wenn man sich danach in die entsprechenden Datenblätter zum LPC1768 reinkniet, kann man auch die Register direkt ansprechen und konfigurieren für komplexere Aufgaben.


    Der Code, den man auf der mbed-Plattform entwickelt, ist auch auf einem LPC1768 alleine lauffähig, so dass man mit der Plattform sehr gut Code für eigene Projekte mit dem LPC1768 entwickeln kann.


    Gruss
    Neni

    Genau, die Light Emission Normalized Versionen halten die Lichtemission bei fixem Brightness-Wert konstant. d.h. es gibt weniger bis kein 'Helligkeitspumpen' beim Rainbow-Fading und auch Saturation-Fading nach Weiss, was vor allem bei RGB-Mood-Beleuchtungen häufig einen homogeneren Eindruck macht. Ausserdem wird der maximale, mittlere LED-Stromverbrauch auf etwa ein Drittel reduziert. Man kann dann eine entsprechend weniger leistungsfähige Stromversorgung einplanen, wenn die PWM-Frequenz hoch genug gewählt und eine ausreichend gute Pufferung der LED-Versorgung mit low ESR Elkos vorgesehen wird.


    Die Normalized-Varianten eignen sich hingegen nicht für Video-Wände etc., da der Dynamik-Umfang deutlich verringert ist, was einer realitätsnahen Bilddarstellung entgegen wirkt.


    Gruss
    Neni

    Zitat

    Das Beispiel von Neni benutz übrigens auch Festkommaarithmetik, auch wenn es nicht so genannt wird


    Ja, natürlich ist es im Prinzip Fixkommaarithmetik, da ja mit einem bestimmten Faktor vormultipliziert wird, allerdings mit dem kleinen Unterschied, dass nicht auf Rundungen geachtet wird (intentionell).


    Zitat

    Programmtechnisch ist die Division durch 256 sicherlich einfacher als durch 255, allerdings bekommt man damit niemals die maximale Helligkeit (da 255*255 / 256 = 254)


    Naja, das stimmt für diesen Fall, aber nicht für meine Umrechenfunktionen ;) . Überall wo das Produkt aus Saturation und Hue_Teilwert (0-255) ins Spiel kommt, wird dieses eben erst von 65280 (255 * 256) abgezogen und dann durch 256 geteilt, also eben (255 * 256 - Hue_Teilwert * Saturation) / 256. Man kann's nun durchspielen, wenn man den Hue_Teilwert und die Saturation von 0 bis 255 variert, wobei man feststellen wird, dass der resultierende Wertebereich ebenfalls genau 0 - 255 und nicht 0 - 254 (oder 1 - 255) ist. Das liegt eben daran, dass bei der Division (bzw. Rechtsschieben oder High-Byte) nur der ganzzahlige Anteil ungerundet übrig bleibt.
    Bei der Skalierung für die Helligkeit (V) wird dann etwas anderes gemacht: ((V_Wert + 1) * Farb_Wert) / 256. Da wirkt sich der 'Vorteil' der fehlenden Rundung auch wieder positiv aus.


    Alle diese Optimierungen sind natürlich für einfache 8-Bit µCs wie den AVR gedacht, wo eben eine 'echte' Division sehr kostenintesiv (benötigte Takte) ist, insbesondere auch für die MEGA-AVRs, welche zwar eine HW-Multiplikation aber keine HW-Division anbieten. Bei einem 32-Bit ARM Cortex M (HW-Multiplikation und - Division) z.Bsp. würden solche Verenkungen wenig bringen.


    Gruss
    Neni


    PS: Hier übrigens nochmal zusammengefasst die ganzen HSVnachRGB-Umrechenfunktionen für versch. PWM-Bittiefen (vielleicht sollte man daraus mal einen Sticky oder sowas machen):

    Ich werfe da mal noch ViaCad 2D/3D von PunchCAD in den Raum. Es ist zwar nicht kostenlos, aber mit 99$ doch recht günstig für ein CAD-Tool dieser Leistungsstufe. Ich persönlich finde es das bisher für mich am einfachsten zu erlernende 3D-Modelling-Tool. Ich habe damit recht einfach und schnell schon ein paar einfachere Konstruktionselemente designen können. Mit den bekannten, grösseren Programmen hatte ich jeweils auch meine Probleme, weil 3D-Modelling eben nicht meine Hauptbeschäftigung ist und ich einfach keine Zeit habe, mich in komplexe 3D-Programme einzuarbeiten, und mögen sie noch so leistungsfähig sein. Mieine Designs sind auch eher einfacher Natur, und da kommt man mit ViaCAD eben wirklich sehr schnell zu guten Ergebnissen. Komplexere Designs kann man damit auch machen, aber da wird man sich dann wahrscheinlich ebenso in alle Funktionalitäten einarbeiten müssen, wie bei anderen Programmen auch. Besonders gelungen finde ich die Möglichkeit, 3D-Objekte zu generieren, indem ich Umrisse mit den ebenfalls sehr umfangreichen 2D-Konstruktionsfunktionen zeichne und dann extrudiere. Mittels solcher Objekte kann ich dann mit versch. 3D-Berabeitungsfunktionen und vor allem durch Addition und Subtraktion von Objekten zu komplexeren Designs kommen. In der Version 8 gibt es nun neu das Push-Pull-Design , bei dem sich Teilbereiche des 2D-Objektes verschieden extrudieren lassen (siehe Video auf der Produktseite). Sehr gut finde ich auch die Programm-Hilfe, welche auch eine rechte Anzahl an Tutorial-Videos zu bestimmten Funktionsbereichen beinhaltet.
    Das fertige Design kann man dann als STL-Datei exportieren, welche die meisten 3D-Printing-Dienstleister verwenden können.


    Als 3D-Printing-Dienstleister kann ich Shapeways (schon selbst genutzt) und Ponoko (bisher selbst nur Laserschnitt-Dienstleistungen dort genutzt) empfehlen. Seit neuestem bietet anscheinend auch Beta-Layout (PCB-Pool) einen 3D-Prototyping-Service an.


    Gruss
    Neni

    Ja, ich bin noch hier ;) , habe aber nicht mehr so viel Zeit für's Forum. Die Tests von mir mit dem IS471F waren eher als proof-of-concept zu verstehen. Ich wollte damit zeigen, dass es prinzipiell möglich ist, den IS471F als recht einfach zu beschaltenden Touch-Sensor zu verwenden, trotz der Nachteile, die der IS471F hat.


    Genaueres, und auch meine Erkenntnisse kannst man in diesem Post von mir nachlesen, wozu auch das Video entstanden ist.


    Freaky91 hat dann das Konzept für seinen 64px RGB-Couchtisch umgesetzt. In seinem Thread findet man die Informationen über seine praktische Implementation.


    Gruss
    Neni

    Ja, genau so Pesi, Abwürgen ist das richtige Wort dafür ;) . Es ist dann eben nicht mehr so schädlich, dass man das Zyklusende nicht genau treffen kann, wenn man sicherstellen kann, dass man einen vollen Zyklus hat. Beim dann maximal möglichen Wert von 7FF werden die Ausgänge dann sowieso ausgeschaltet. Man hat also einen linearen Zusammenhang für die 11 Bit (0 - 7FF) ohne Fehlzyklus. Die zusätzlichen Clocks bis zum Reset und Zeilenumschaltung wirken sich dann zwar als leichte Reduzierung der Gesamthelligkeit, aber nicht mehr als sonst mögliche Fehldarstellungen (Blitze, Aussetzer etc.) aus.


    EDIT: Ja, so sehe ich das auch Pesi, das hier wäre einfach ne Notlösung, wenn man unbedingt auf den TLC5947 angewiesen ist. Sonst würde ich auch dringend dazu raten auf eben nen anderen TLC (wie die oben erwähnten Typen) auszuweichen.