Posts by durchflieger

Hallo MyLive,

ich hatte weiter oben im Thread schon einen konkreten Hardwarevorschlag gemacht der ähnlich deinen Überlegungen ist. Mein Vorschlag setzt nur parallel geschaltete AVR's ein (hier ATmega162 da meine Firmware mehr als 512Byte RAM benötigt). Auf einen Rückkanal habe ich verzichtet und stattdessen eine Handshakeleitung (CTS) eingeplant um den Datenfluss vom PC bremsen zu können. Als Rückmeldung käme ja nur Kommando erfolgreich/fehlgeschlagen in frage und bei einem Fehlschlag wäre dann ja zu überlegen was die PC-Software dann machen soll. Da fällt mir nur "Fehlermeldung ausgeben" ein da die "Störung" sehr wahrscheinlich einen manuellen Eingriff erfordert.
Ein visuelles Feedback könnte man aber auch über die RGB-Leds signalisieren.

Die (bereits existierende!) Firmware für meinen Vorschlag setzt ein Protokoll mit Broadcast-Telegrammen ein. Es gibt ein (DMX ähnliches) Kommando zu Übertragung der Helligkeitswerte dass mit dem Escape 0xFF beginnt und per Timeout überwacht wird. Alle weiteren Kommandos bestehen nur aus ASCII-Zeichen < 0x80 und werden mit <CR> und/oder <LF> abgeschlosssen ohne Timeoutüberwachung. Damit lassen sich alle Kommandos auch von "Hand" in einem Terminalprogramm einfach ausprobieren.

Die Idee mit einem Bootloader finde ich gut. Den könnte man in meiner Firmware durchaus noch nachrüsten.

Gruss
durchflieger

Adama

wäre schon klasse wenn wir über Weihnachten was hin bekämen.
Den Schaltplan habe ich noch ein wenig überarbeitet:

1. Im Teil1 (RS232/USB) ist R4 jetzt an die permanente Betriebsspannung angeschlossen.
2. Die Ports PD1 der ATMegas werden jetzt als CTS-Handshake benutzt und sind dazu über Dioden zusammengeschaltet. Einen serieller Rückkanal wird von der Firmware nicht benötigt. Dagegen ist ein "ausbremsen" des VDR per Hardware-Handshake sinnvoll da einige Kommandos (z.B. neuen Gamma-Wert im Controller setzen) doch recht lange benötigen. Wir ersparen uns dann im VDR unnötig lange Pauseschleifen.
2. Ich habe etwas Sorge dass die notwendigen 115KBaud bei der RS232 Variante über grössere Strecken fehlerfrei übertragen werden. Deshalb habe ich noch RS485 Pegelwandler zwischen Teil1 und Teil2 für die Sendeleitung vorgesehen. Jetzt kann man Teil1 nahe beim VDR plazieren und Teil2 nahe bei den RGB-Stripes. Das funktioniert natürlich auch mit der USB-Variante. Für die CTS-Leitung ist das nicht notwendig da hier viel kleine Frequenzen auftreten.

Im Teil2 habe ich die 1:1 durchgeschleiften Buchsen rausgenommen da ich im Target sonst das Limit von 250pins überschreiten würde. Die sollten aber natürlich noch vorgesehen werden.

Die neuen Schaltpläne als TIFF sowie Eagle-Projekt-Export gibts hier: http://www.halstenbach.de/public/atmo/ctrl2.zip

Gruss
durchflieger

Quote

Original von Adama
Für die Anwendung müssen wir sicher noch am Layout stricken, aber das war ohnehin klar... ich bin mir sicher dass wir mgl-weise mehr als ein layout stricken werden um unterschiedliche ein/anbaubedingungen erfüllen zu können.

Gibts schon was neues bezüglich eurer Überlegungen zum Layout? Die Firmware für den 10-Kanal Controller tuts bei mir schon prima im Simulator! Jetzt bräuchte ich halt ein Layout um es mal real zu testen.

Gruss
durchflieger

e9hack  Igor  Adama

danke für die Empfehlungen für eine geeignete Schaltplan/Routingsoftware. Wie schon gesagt hab ich das Target zum ersten mal verwendet und mir dabei erstmal keine Gedanken gemacht ob's was besseres gibt. Ich kannte es halt und der Download war schnell gemacht und der Schaltplan schnell erfasst

Ich hänge aber nicht dran und könnte das ganze auch in Eagle fortsetzen wenn gewünscht.

Adama
Hat das mit dem Export nach Eagle bei dir geklappt?

Quote

Original von samc
Hi,

anstatt der ULN... sollten MOSFET Treiber eingesetzt werden, da der Spannungsabfall an den Transistoren sonst mit einer Anpassung der Versorgungsspannung ausgeglichen werden muss. Gängige LED-Module ändern ihren Strom drastisch bei einer um 0,8V geringeren Versorgungsspannung...

Grüße,
Simon

ich betreibe zur Zeit meine Superflux LED-Stripes (12V Ausführung) an einer ULN2003 basierten Lösung und bin mit der Helligkeit sehr zufrieden. Eine Lösung mit diskreten MOSFET Treiber wird bei der hohen Anzahl benötigter Kanäle mir zu Bauteile intensive.
Da ja eine zentrale Stromversorgung vorgesehen ist könnte man natürlich darüber nachdenken z.B. mit einer Eingangsspannung von 9V zu arbeiten und daraus per Step-Up Wandler regelbare 12-30V zu erzeugen. Die 5V könnten dann mit einem einfachen 7805 erzeugt werden.
Alternative könnte man natürlich auch die Vorwiederstände auf den RGB-Stripes anpassen.

Edit:
Bei Conrad gibt es zwei interessante Steckerschaltnetzteile Art.Nr. 510524 - 62 (12V) und 510525 - 62 (24V). Bei denen wird die Ausgangsspannung über einen von außen steckbaren Widerstand festgelegt. Damit könnte man mit eigenen Wiederständen die notwendige Spannungserhöhung einfach einstellen. Vorsicht wäre allerdings bei der 24V Variante geboten da die Ausgangselkos hier laut dem verfügbaren Schaltplan nur 25V haben.

Quote

Original von Adama
durchflieger,

kannste die target-dateien auch als EAGLE-scheets speichern??
Wär hilfreich...

Adama

Also ich setze das Target zum ersten mal ein weil ich euch meine Bleistiftzeichnungen nicht mehr zumuten wollte Ist auch nur die discover Version die ein Limit bei 250 Pins hat. Deshalb ist jede Teilschaltung auch zurzeit in einem eigenen Projekt bei mir.
Unter Datenaustausch gibts einen Eagle-Export in Target. Ob der nur die geroutete Platine und/oder auch den Schaltplan exportiert weiss ich nicht. Zumindestens soll man alle Bauteile auf der Platine plazieren bevor man den Export macht.

Hier der Export: http://www.halstenbach.de/public/atmo/ctrl_eagle.tar.gz

Gruss
durchflieger

Hallo,

im folgenden möchte ich euch meinen Vorschlag des Schaltplan zu einem RGB-LED-Controller vorstellen.

Das Ganze setzt sich aus zwei Teilmodulen zusammen die auf verschiedenen Platinen(abschnitten) realisiert werden sollten.

Teil 1 implementiert die Schnittstellenwandler und Stromversorgung für alle Teilbereiche und wird einmal benötigt. Um die Fan's von USB ins Boot zu holen soll sich das Modul wahlweise mit USB oder RS232 Schnittstelle für die Kommunikation mit dem VDR bestücken lassen. Nach einigen Recherschen über Microcontroller mit integrierter USB-Hardware habe ich mich doch für eine Lösung mit einem FT232RL entschieden. Diese hat zwar den Nachteil dass es den nur im SMD-Gehäuse gibt. Aber ich denke die Vorteile wie preiswert, einfach zu beschaffen, USB-Treiber vorhanden usw. überwiegen einfach.
In der USB-Variante soll die 5V Stromversorgung vom USB-Bus erfolgen. Weiterhin wird auch die LED-Stromversorgung vom FT232 geschaltet so dass sich der gesamte Controller automatisch mit dem VDR ein-/ausschaltet. Die Bestückung mit dem LM2574 kann deshalb hier auch entfallen. Die Auswahl der Mosfets sowie deren Ansteuerung muss aber noch von jemand kompetenteren geprüft bzw. überarbeitet werden.
Die RS232 Variante mit 5V Stromversorgung habe ich weitestgehend von dem im VDR-Wiki beschriebenen Controller übernommen. Allerdings sollte die 5V Stromversorgung schon 500mA liefern können. Das müsste für bis zu 5 RGB-LED-Controller-Module reichen.

Teil 2 implementiert das kaskadierbare RGB-LED-Steuermodul mit 10 RGB-Kanälen auf Basis eines ATmega162.
Als LED-Treiber können alternativ ULN2803 oder UDN2981 eingesetzt werden um RGB-Stripes mit gemeinsammer Anode bzw. Kathode verwenden zu können. Entsprechend sind die Jumper K11,K13,K14 zu setzen.
Für die Verbindung zu den RGB-Stripes habe ich RJ11-Buchsen vorgesehen. Entsprechende Stecker und schönes flaches schwarzes 4 adriges Anschlusskabel gibts preiswert. Wer keine Crimpzange hat kann auch fertig konfektionierte Kabel kaufen (das sind die Telefonanschlusskabel) und diese teilen.
Für die Verbindung zwischen den Platinen habe ich je zwei 8polige Siftleisten/Buchsen vorgesehen um die Platinen gestapelt oder nebeneinander dann mit Flachbandkabel verbinden zu können. Das wäre die Variante wenn alles in eine Gehäuse käme. Alternative sollen auch RJ45 Buchsen bestückbar sein, wenn die Platinen in separate Gehäuse eingebaut werden sollen. Dann kann die Verbindung mit kurzen Patchkabeln erfolgen.
Auf jedem Modul lässt sich per Jumperblock eine Moduladresse einstellen anhand der die Firmware die auszugebenen Kanäle bestimmen kann.

Die Schaltpläne gibts hier: http://www.halstenbach.de/public/atmo/ctrl.tar.gz

Als nächstes (nach Klärung der noch offenen schaltungstechnischen Dinge) müsste man ein Platinenlayout erstellen. Hierzu benötige ich eure Hilfe da dass nicht mein Ding ist. Den Schaltplan habe ich im Target 3001 erfasst. Also wer macht mit???

Gruss
durchflieger

Quote

Original von Igor
Aber wollen wir wirklich wieder ein Gerät für die serielle Schnittstelle bauen? - diese stirbt nunmal aus?

Igor

dem kann ich nur zustimmen. Allerdings hat die serielle Lösung den grossen Vorteil, das sie auch
auf längere Stecken gut funktioniert. Der Abstand zwischen PC und Ambilight-Controller beträgt
bei mir ca 7,5m. Das wird mit USB ohne Repeater schon schwierig. Nach meinen Erfahrungen wirds
bei USB schon nach ca. 5m instabil.
Ich betriebe meine Lösung trotzdem am USB und verwende dazu ein fertig konfektioniertes
USB/Serial-Konverterkabel. Das gibts z.B. bei Reichelt für ca. 10€ und funktioniert gut wenn man
die RS232 Seite verlängert. Ohne spezielle IC's sei es z.B. FT232 oder Atmels/PIC mit USB-Hardware
wirds bei den benötigten Datenraten nicht gehen. Ich habe mal ein Projekt mit USB
Softwareemulation (USBtiny) auf dem Atmega8 realisiert. Die praktisch zu erreichende Datenrate ist
nicht sehr hoch.

Gruss
durchflieger

Quote

Original von daniel_k
Hallo durchflieger,

Die waren auf Superflux-Basis, oder?
Was ziehen die denn so an Strom pro Farbe, wenn mal die aufteilt?

Du willst es also mit Soft-PWM machen? Wie viel Hz schaffst Du denn mit
dem Controller bei 11 Kanälen? Ein Problem sehe ich irgendwann mit
der RS232 und der Baudrate: 44 Kanäle * 8 Bit * 4 (3 Farben + 1 Kanaladr.) * 50 Hz = ~70 kBaud,
die Start- und Stopbits und Framemarker noch nicht mitgerechnet.
Wie willst Du denn die Vielzahl der Controller programmieren? Alle mit nem
eigenen ISP-Adapter, oder gesockelt und bei jeder Firmwareänderung alle
raus und wieder rein?
Also ich würde eindeutig eine Lösung mit einem Controller, der quasi nur
USB->SPI-Umwandlung für TLCs macht, bevorzugen. Auch da könnte man
eine Platine machen, bei der man durch Nicht-Bestücken die Kanalanzahl
reduzieren kann.
Die meisten hier benutzen doch die Streifen aus der Sammelbestellung, oder?
Lassen sich die eigentlich aufteilen und damit weiterverwenden? Falls nein,
kann ich nur den Aufruf von Samael wiederholen:
Wir sollten uns passende RGB-Leds suchen.

Gruß,
Daniel

Display More

Hallo Daniel,

ja die LED's sind Superflux. Jeder Streifen hat 27 LED's wobei
jeweils 3 LED's in Reihe für 12V geschaltet sind.
Diese sind dann parallel zu 3x9 verschaltet. Die
Parallelschaltung würde ich aufheben indem einfach ein paar
Leiterbahnen aufgetrennt würden.
Stromaufnahme müsste dann deutlich unter 100mA pro
Kanal liegen.

Für den Controller würde ich meine bestehende Firmware
adaptieren. Die hatte ich schon im vorhergehenden Thread
"Ambilight war gestern" kurz beschrieben.
Nach Adaption hätten wir dann folgende Eckdaten:
Interne Auflösung 1151 Schritte also ca. 10 Bit
100Hz Refresh
30 oder 33 PWM Kanäle = 10 - 11 RGB
14Mhz CPU-Clock
Gammatabelle und Weißabgleich mit interner Auflösung downloadable
RS232 mit 56 KBaud, Protokoll DMX ähnlich und alternative ASCII Klartext

Für die notwendige Übertragungsrate rechne ich:
44 Kanäle * 8Bit * 3 + 3 (Syncbyte + Kanaloffset + Anzahl-Kanäle) * 25 (Vollbilder) ~ 33Kbit

Edited:
Wenn's denn 50Hz sein sollen könnte man ja mit 115KBaud arbeiten.

Für die Programmierung würde ich die Sockellösung vorziehen. Man
könnte dann für nur einen Sockel einen ISP vorsehen/bestücken.

Gruss
durchflieger

Also ich würde gerne meine LED-Streifen weiterverwenden. (Die hatte ich damals in der
Bucht erstanden bei jemanden aus Singapur. Die URL war damals mal im Rahmen der
Sammelbestellung erwähnt wurden.)
Meine Streifen lassen sich beim meinem 37" LCD recht einfach in jeweils 6 Kanäle
links/rechts und 9 Kanäle oben unterteilen. Das würde mir erstmal reichen.

Ein erster grober Blockschaltplan als Vorschlag zu einem Controller mit 132 PWM-Kanälen
gibts hier: http://www.halstenbach.de/public/atmo/schaltplan132.tar.gz

Mein Vorschlag sieht eine "grosse" Platine für den Controller vor die man aber beliebig
bestücken könnte um 11 / 22 / 33 / 44 RGB Kanäle zu bekommen.
Jeder Atmega Sockel hat eine eindeutige Adresse die über die Ports PD1-PD3 kodiert
ist. Damit lässt sich der "Sockel" auf der Platine per Software bestimmen. Den Rest
werden wir dann volldynamisch in der Firmware konfigurieren.

Als Treiber kämen Source- oder Sink-Driver z.B. vom Type ULN2803 oder UDN2981 bzw. UDN2982
zum Einsatz. Da es hier eine grosse Auswahl an Pin-kompatiblen IC's gibt könnten die
unterschiedlichsten LED-Stripes betrieben werden mit Strömen bis ~500mA und
Spannungen bis ~80V. Das alles mit einem Platinenlayout!
Die IC's sind alle im DIP-Gehäuse zu bekommen und z.b. bei Reichelt recht preiswert.

Gruss
durchflieger

Adama

unter http://www.halstenbach.de/public/atmo/atmoctrl.tar.gz der Schaltplan meines aktuellen Controllers sowie der Sourcecode der Firmware. Der Schaltplan war leider nur eine Beistiftskizze - die hab ich mal in
den Scanner gelegt
In der derzeitigen Schaltung ist der Programmer für den Atmega überigens gleich integriert.

Ich mach mir mal ein paar Gedanken zur zukünftigen Hardware und zum Protokoll VDR <-> Controller.

Gruss
durchflieger

Hallo,

erstmal vorab vielen Dank an die Entwickler die das Atmolight möglich gemacht haben!

Ich selber setze das Atmolight mit einem "abgewandelten" Controller auf Basis
der Atmega8 und einer selbst entwickelten in "C" kodierten Firmware ein.
Motivation dazu war hauptsächlich mal wieder ein Projekt mit einem Microkontroller
als Freizeitbeschäftigung durchzuführen.

Nun zur Sache - Die Firmware wäre in der Lage auf einem Atmega162 oder ggf.
Atmega32 alle vorhandenen Port-Pin's als PWM zu betreiben. Somit könnten
30 - 33 PWM-Kanäle also 10-11 RGB-Kanäle mit einer CPU realisiert werden.

Die Firmware für den Atmega 8 hat zur Zeit folgende Merkmale:
Interne Auflösung 1151 Schritte also ca. 10 Bit
100Hz Refresh
12 PWM Kanäle = 4 RGB
14Mhz CPU-Clock
Gammatabelle und Weißabgleich mit interner Auflösung downloadable
RS232 mit 38400 Baud, Protokoll DMX ähnlich und alternative ASCII Klartext
Lichtsensor über analogen Eingang mit dem das Atmolight bei Tag automatisch abgeschaltet wird
(funktioniert allerdings nocht nicht sonderlich gut, liegt aber an der zu einfachen Hardwarelösung)

Die Migration auf den Atmega162 bzw. 32 und Erweiterung auf die 30 -33 PWM Kanäle wäre
nicht aufwending. Beim Timing gibts genug Luft wenn die Lichtsensorfunktion entfallen würde.

Folgende Erweiterungen könnte man machen:
Zuordnung RGB-Kanal zu PWM-Pin frei konfigurierbar (gesteuert im VDR-Plugin)

Meiner Vorstellung zur Hardware:
Je nach Ausbau 3-4 dieser Einheiten die am RS232-Bus einfach parallel angeschlossen würden.
RS232 würde nur TX benötigt. Pegelumsetzung mit einfachen Transistor.
Für die LED's einfache Darlington-Treiber z.B. ULN2803.
Spannungsversorgung könnte auch einfacher werden da nur 1 ggf. 2 LED's in Reihe liegen würden
Eigene Quarze pro CPU.
Die Bauteile sind preiswert und alles im DIP-Gehäuse.
Da der Verdrahtungsaufwand zwischen Controller und LED's doch aufwendig wird wären
passende Platinen für Controller und LED's wichtig.

Ich könnte bei der Realisierung der Software (Firmware, Plugin) und dem Hardwareentwurf mitwirken.
Platinen routen und herstellen ist nicht so mein Ding.

Gruss
durchflieger

Quote

Original von Funzt
> Die Bildqualität von SD-Bildmaterial (nicht HD!) über RGB/Analog ist deutlich besser als digital über die Grafikkarte.

Genau das ist auch meine Erkenntnis beim Einsatz vom VDR und einem Plasma (42s5h).
Bin jetzt bei der PS3 gelandet und habe ein super SD Bild über HDMI (1080i).
Habe mich auch gewundert, da so viel gewandelt wird, aber das Bild ist wirklich top.

Hast du mal ausprobiert, wie die Bildqualität bei 576i ist? (falls das die PS3 kann). Und ist dein verwendetes SD-Material wirklich interlaced?

Gruss
durchflieger

Hallo,

ich verfolge die Threads über das Thema HDTV schon eine Zeit lang. Ich betreibe zur Zeit meine 2 LCD-TVs direkt an den TT-FF's mittels Scart per RGB. Ich habe diverse Tests mit Ausgabe über Grafikkarte (ATI 9600, fglrx-Treiber) mit xineliboutput und softdevice über XV und Anbindung über DVI/HDMI durchgeführt. Die Auslösung war native 1366x768@60. Die Bildqualität von SD-Bildmaterial (nicht HD!) über RGB/Analog ist deutlich besser als digital über
die Grafikkarte. Mir geht es darum, die Ausgabe über digital zu verbessern was letztendlich auch den HD-Auflösungen zugute kommen sollte. Meiner Meinung nach sollte die Ausgabe des SD bzw. HD-Material in dem Format passieren, in dem es gesendet wird also bei Sat-TV meistens 768x576i, 1280x720p bzw. 1920x1080i. Bei diesen Auslösungen würde der LCD seine interne Verarbeitung für TV-Signale zuschalten (deinterlacing, scaling, pulldown etc.) das dann mindestens zu gleicher Qualität wie über RGB führen sollte.
Nun meine Frage: Aus welchen technischen Gründen scheitert die Ausgabe dieser Formate zur Zeit bei meinem gewählten Weg über die Grafikkarte? Ich habe es z.B. nicht hinbekommen, eine 768x576i Auslösung einzustellen. Nach einen Blick in die xine-Sourcen (wobei ich hier nur Oberflächlich einblicke) habe ich weiterhin den Eindruck, das eine Interlaced-Ausgabe über XV ggf. gar nicht richtig unterstützt wird (auch wenn ich mal eine passende Modline for 576i finden würde)?

Gruss
durchflieger