Umbau von LED Tube 144 LEDs

Hi LedBob,

ah, jetzt weiß ich endlich, was Ihr mit dieser Verzögerung meint!

Ja, das ist kein "Bus", sondern eher ne "Kette", das hat sich ja ein paar Beiträge weiter oben schon rausgestellt, mit dem Transceiver am "Anfang" und am "Ende"...

Nur: dazu müsste neben den RGB-Daten dann auch ne Zeit bei dem Paket mitgeschickt werden - da steht in dieser Beschreibung nix davon...

Und weitere Steuerdaten - die erste Röhre muss ja wissen, ist es jetzt ein Lauflicht? - soll ich also Verzögern und dann wieder ausgehen? - oder sollen alle Röhren das selbe anzeigen? - dann muss sie ja anbleiben und das Paket ohne Verzögerung weiterschicken usw. - Das ist doch nicht einfacher, als einfach das Paket "gekürzt" weiterzuschicken...?

Abgesehen davon habe ich auch schon Muster auf so Röhren gesehen (die stammen bestimmt vom selben China-Fließband), bei denen nicht jede Röhre das selbe anzeigt...

guckst Du hier

Und das kann nur funktionieren, wenn der Controller jedes Segment einzeln ansprechen kann - das geht jedoch nicht mit einem Paket, das verzögert weitergeschickt wird...

Und dass der Controller alle Segmente einzeln ansprechen kann, ohne dass die Röhre eine feste Adresse hat, kann m.M.n. nur so funktionieren, wie ich es beschrieben habe...

Wieso sträubt Ihr Euch denn so gegen meine Erklärung? - Ich meine, hardwaremäßig ist's das selbe wie mit der Verzögerung, softwaremäßig sogar noch einfacher: der Controller muss ja nur die ersten 24 Byte "abschneiden" und den Rest einfach weiterschicken...

Bei der "Verzögerungs-Methode" brauche ich noch zusätzliche Steuerdaten (was soll die Röhre jetzt machen? In welcher Zeit?), das muss der µC auswerten, dementsprechend ne Pause machen oder nicht und dann das Paket weiterschicken... das sind doch viel mehr Programmschritte als bei "meiner" Lösung....? - Und es könnte trotzdem nur jede Röhre das selbe Muster anzeigen...

Das wird ja immer mysteriöser... ;o)

Auch bei mir "neue Erkenntnisse": ich hab' mir nochmal den ersten Info-Link angesehen, den Du gepostet hast. Da ist bei der Röhre nicht die Rede davon, dass man diese dimmen kann...? Sowas hätte ich auf Deinen Videos auch nicht gesehen... kann es sein, dass man diese Röhren gar nicht dimmen kann? - Beim Controller steht zwar was von dimmen, aber evtl. ist das ja ein Versehen? - Hast Du das schon mal gemacht, die Röhren gedimmt?

Ausserdem habe ich mir auf Youtube massig Videos von so Röhren angesehen, dabei ist mir folgendes aufgefallen:

1. Ich hätte da auch nirgends gesehen, dass die Dinger mal gedimmt werden.

2. Ich habe auch nur die Farben Rot, Grün, Blau, Gelb, Pink, Türkis und Weiß gesehen - kann es sein, dass die Röhren nur diese 7 Farben können?

In dem Fall würden nämlich 3 Byte pro (8-Segment-)Röhre reichen, da ja pro Segment die Farben rot, grün, blau nur jeweils ein- oder ausgeschaltet werden müssen (1 Bit).

Darauf deutet m.M. nach auch der Controller in den Tubes hin (danke für das Foto). Ich glaube, die Tube ist intern eine einfache 3(rot, grün, blau)x8(Segmente)-Matrix nur mit an und aus. Ich glaube nicht, dass dieser kleine ATMega (man kann leider nicht genau erkennen, welcher) 24 Kanäle dimmen kann... die gesamte Röhre schon, dafür reicht ja ein PWM-Kanal...

Und dann würde auch das mit den 4.000 Röhren funktionieren - selbst bei gemütlichen 128 Kbit/s (das kann sogar ein PC-Com-Port) käme man dann auf einen Refresh von ca. 10 Hz, das reicht (zumindest bei den Programmen, die man da gesehen hat) auch leicht...

Und auch wenn man z.B. alle Röhren gemeinsam dimmen könnte, bräuchte man dafür ja auch nur ein Byte (pro Durchgang) mehr, das macht bei 12.000 Bytes insgesamt auch keinen Unterschied mehr...

Und das mit dieser "Adressierung" macht auch Sinn: der Controller muss ja wissen, ob das 8- oder 16-Segment-Röhren sind (einer 8er muss er ja 3 Byte schicken, einer 16er 6 Byte), damit das mit dem Lauflicht etc. passt.

RS 485 ist ja bidirektional, ich könnte mir das so vorstellen, dass der Controller einen "Befehl" zur Identifikation durch die Röhren schickt (irgendwas, was im normalen Betrieb nicht vorkommt, z.B. Pause, 255, Pause, 255, Pause, 255), und die schicken dann nach ner ähnlichen Methode wie der Controller (jede Röhre hängt ihre Segment-Zahl an ein Datenpaket hinten dran) die Info zum Controller zurück.

Aber das ist alles nur graue Theorie, solange man nicht zumindest weiß, auf welcher Baudrate etc. diese Schnittstelle arbeitet - hast Du da schon was rausgefunden?

Unten mal (ohne Garantie, obwohl eigentlich nix passieren kann) eine Schaltung für nen RS232-auf-RS485-Konverter - mit einer Software, mit der man beliebige Daten auf nen Com-Port schicken kann (die gibt's, hab' ich jetzt nur auch nicht auf die Schnelle gefunden), könntest Du das mit maximaler Geschwindigkeit (evtl. reicht die) und versch. Einstellungen für Start- und Stopbits (Hardware-Handshake auf jeden Fall deaktivieren) mal probieren...

Wenn Du z.B. -Pause-,255,255,255,0,255,0,85,85,85,0,0,0,0,0..... auf die Röhren schickst, müsste dann nach meiner Theorie die erste Röhre weiß leuchten, die zweite grün und die dritte schwarz/weiß "gestreift"...

Nur mal so als Idee - schade, dass ich nicht in Berlin wohne, das würde mich echt interessieren, da mal rumzuprobieren...

schönen Abend noch, viele Grüße, Pesi

Zitat von "DSL-man"

welches tool empfehlt ihr mir zum senden/empfangen ?

Für Linux z.B.
http://sourceforge.net/projects/serialsniffer/

Für Win:
kostenlose Version:
http://www.serial-port-monitor.com/
Profi-Version kann man wohl 14 Tage ausprobieren:
http://www.hhdsoftware.com/Download/serial-monitor.exe

Ob die Tools auch senden können weiß ich nicht. Auf jeden Fall könntest du damit die Kommunikation mal mitschneiden und schauen ob die obigen Theorien zutreffen...

Gruß

LB

Schade, dass ich nicht in Berlin wohn' - ich würde das echt mal gerne "live" sehen, statt immer nur hier rumzutheoretisieren ;o) - und die Infos häppchenweise zu bekommen ;o)

Das mit den zwei Modi wusste ich z.B. noch nicht - aber so macht das Ganze Sinn: die schreiben ja nur, dass der Controller die Röhren dimmen kann, jedoch nicht, dass man die Programme auch dimmen könnte.

Auf die Methode funktioniert das Ganze auch mit den oben schon mal ausgerechneten Datenraten - da man ja, um die Röhre komplett in "Full RGB" (womit man dann auch dimmen kann) anzusteuern, auch wieder nur 3 Byte braucht... und die komplette Röhre so anzusteuern, schafft der kleine Atmel dann auch, sind ja nur 3 Kanäle PWM...

Umgeschaltet wird das am/über den Controller, richtig? - und man kann wohl auch nur alle Röhren gemeinsam umschalten, nicht "gemischt", oder?

Da denk' ich mir, dass dafür auch ein spezieller "Steuerbefehl" durchgeschickt wird - und im normalen Betrieb schickt der Controller einfach (wie in dieser kopierten Beschreibung) r,g,b,r,g,b,r,g,b,... raus - ob dann die Röhre komplett eine von 16,7 Millionen Farben anzeigt, oder 8-Segment-Muster mit 7 Farben, hängt einfach vom Betriebsmodus ab, ändert nix am Datenformat...

Mal was anderes, etwas o.T.: weiß jemand auch ein solches Programm, mit dem man unter Windoof über den Parallelport beliebige Daten ausgeben kann? - bräuchte sowas, um ein LC-Display zu testen...

Es tut mir leid, dass ich gleich als erste Aktivität hier einen uralten Thread ausgrabe, aber da er bei meinen Recherchen gleich ganz oben bei Google auftauchte, dachte ich es wäre gut, meine Ergebnisse hier zu posten.

Vor einiger Zeit habe ich mir bei eBay auch einige dieser Tubes zugelegt, die ich eigentlich nach Anleitung in unserem DMXControl-Wiki umbauen wollte: http://www.dmxcontrol.de/wiki/LED-Tube-Umbau
Mir hat der original verbaute Controller aber keine rechte Ruhe gelassen, so dass ich mir den etwas genauer angesehen habe - und siehe da, aus irgendwelchen Gründen waren die Lockbits nicht gesetzt und ich konnte die Firmware auslesen.
Nachdem ich mich nun eine ganze Weile durch den disassemblierten Code gewühlt habe, hier meine Ergebnisse in Kurzform:

• Die Tubes benutzen RS485 als Schnittstelle, also genau wie DMX
• Die Baudrate beträgt im Unterschied zu DMX aber 750000 Baud
• Schnittstellenformat ist ebenfalls wie bei DMX 8N2
• Das Paketformat besteht immer aus 7 Bytes: 1 Byte Opcode und 6 Bytes Parameter
• Folgende Befehle werden von den Tubes verstanden:

0x22 - Color Fade step (--, --, --, Fade In Delay, --, --)
0x55 - Set colors for addresses up to (Blink rate (0-100, 100=Always on), Max address (Ones), Max addess (Hundreds), Segments Green, Segments Blue, Segments Red)
0x77 - All LEDs on, set PWM (--, --, --, Red, Blue, Green)
0x88 - Configure Tube addresses (--, ?? (Ones), ?? (Hundreds), (First Tube Addr. - 1) (Ones), (First Tube Addr. - 1) (Hundreds), --)
0x99 - All red on (--, --, --, --, --, --)
0xAA - Set colors for address (Blink rate (0-100, 100=Always on), Address (Ones), Addess (Hundreds), Segments Green, Segments Blue, Segments Red)

Der interne Befehlssatz ist also relativ beschränkt (besonders was das dimmen angeht), aber immerhin lassen sich die Tubes so schon mal ohne Umbau ansteuern.

Ich hoffe, diese Infos helfen irgendwann noch mal irgendwem. Ich kann jetzt jedenfalls keinen 8051-Assembler mehr sehen.

Viele Grüße,
Stefan

Zitat von StefanKrupop

Es tut mir leid, dass ich gleich als erste Aktivität hier einen uralten Thread ausgrabe

Das macht ja nix, ist ja ein sehr sinnvoller Beitrag! - Willkommen im Forum...

(Lustiger Weise ist das hier der Thread, in dem ich ebenfalls meinen ersten Beitrag gepostet habe... ;))

Respekt, das war bestimmt einiges an Arbeit, das herauszufinden!

So wie's aussieht, gibt es ja tatsächlich diese beiden Ansteuerarten, entweder alle Segmente die selbe Farbe, dafür 3x8 Bit PWM-Dimmung (Befehl 0x77) oder jedes Segment einzeln RGB, dafür dann aber nur ein/aus (Befehl 0x55 bzw. 0xAA)...

Nur das mit der Adressierung ist mir hier noch nicht ganz klar - ist das Ganze nun ein Bus, oder ne Eimerkette...? - weil in ersterem Fall könnte ich mir trotzdem nicht vorstellen, wie das da nun adressiert werden soll (da würden ja alle Tubes immer das selbe empfangen), in zweiterem Fall wäre ein extra Befehl zur Adressierung *eigentlich* gar nicht nötig, weil die ja "automatisch" erfolgt...

EDIT: OK, bei diesen Befehlen macht das natürlich Sinn, dass sich *nicht* (wie bei anderen Projekten dieser Art, Biertrinkers Schattenfuge oder meine DMX-Lichterkette, etc.) jede Tube die 7 Byte "vorne" dran "abknabbert", weil es ja auch Befehle gibt, die für mehrere Tubes gelten... - also wird nur einmal zum adressieren dieser Befehl durchgeschickt, bei dem jede Röhre die nächsthöhere Adresse an die folgende weitergibt, im Normalbetrieb hört dann jede Röhre auf den gesamten Datenstrom, aber reagiert nur auf Befehle mit ihrer Adresse...

Rein aus elektrischen Gründen müsste es eigentlich eine Eimerkette sein, da man ja 4.000 Tubes hintereinander schalten kann, es können ja wohl kaum 4.000 Empfänger an einem RS485-Bus hängen.. - irgendwo in diesem Thread steht ja auch schon, dass da zwei RS485-Treiber in der Röhre sind...

Und wenn ich das richtig sehe, dieser "DMX-Controller", den es dazu gibt, da kann man dann halt wohl per DMX bestimmte Programme/Szenen auswählen - so wie es der TE gewünscht hätte, dass man jede Tube "direkt" über ne "DMX-Brücke" steuert, würde zwar theoretisch gehen, aber nicht für 4.000 Tubes - weil bei 7 Bytes pro Tube wäre das ne Refresh-Rate von ca. 2,4 Hz - bis zu 400 Tubes (entspr. ca. 24 Hz) sollte ja aber halbwegs vernünftig gehen...

Zitat von Pesi

So wie's aussieht, gibt es ja tatsächlich diese beiden Ansteuerarten, entweder alle Segmente die selbe Farbe, dafür 3x8 Bit PWM-Dimmung (Befehl 0x77) oder jedes Segment einzeln RGB, dafür dann aber nur ein/aus (Befehl 0x55 bzw. 0xAA)...

Na ja, der verwendete PWM-Controller (ist nicht softwareseitig) unterstützt nur 5 Bit, also 32 Stufen. Leider unterstützen die Befehle 0x22, 0x77 und 0x99 keine Adressierung, so dass immer der ganze Strang die gleiche Farbe hat.

Zitat von Pesi

Nur das mit der Adressierung ist mir hier noch nicht ganz klar - ist das Ganze nun ein Bus, oder ne Eimerkette...?

Eimerkette, wobei außer bei Befehl 0x88 die Daten unverändert weitergegeben werden.

Zitat von Pesi

in zweiterem Fall wäre ein extra Befehl zur Adressierung *eigentlich* gar nicht nötig, weil die ja "automatisch" erfolgt...

Der Befehl 0x88 veranlasst die Tubes, die Adressen neu einzustellen - beginnend bei der vorgegebenen Zahl. Als einziger Befehl verändern die Tubes hier die Werte, nämlich die Adresse um +1 für die nächste Tube, so dass hinterher alle fortlaufende Adressen haben. Diese werden (scheinbar) auch in einem EEPROM abgelegt, so dass der Befehl nur nach Änderungen am Strang nötig ist.

Stefan

Zitat von StefanKrupop

Na ja, der verwendete PWM-Controller (ist nicht softwareseitig) unterstützt nur 5 Bit, also 32 Stufen. Leider unterstützen die Befehle 0x22, 0x77 und 0x99 keine Adressierung, so dass immer der ganze Strang die gleiche Farbe hat.

Das auch noch - stimmt, da ist keine Adresse dabei, wieso eigentlich nicht.. - versteh' einer die Chinesen... - wäre ja reine SW-Sache gewesen, dass man zumindest jede Röhre komplett in einer Farbe individuell einstellen/dimmen kann...

Zitat von StefanKrupop

Eimerkette, wobei außer bei Befehl 0x88 die Daten unverändert weitergegeben werden.
Der Befehl 0x88 veranlasst die Tubes, die Adressen neu einzustellen - beginnend bei der vorgegebenen Zahl. Als einziger Befehl verändern die Tubes hier die Werte, nämlich die Adresse um +1 für die nächste Tube, so dass hinterher alle fortlaufende Adressen haben. Diese werden (scheinbar) auch in einem EEPROM abgelegt, so dass der Befehl nur nach Änderungen am Strang nötig ist.

Siehe mein EDIT, das habe ich schon kapiert...

Also bei *den* beschränkten Möglichkeiten rentiert es sich hier echt nicht, da noch ne DMX-Bridge oder eigene Ansteuerung zu bauen - da ist dann ein Komplettumbau doch wesentlich sinnvoller - gutes Tutorial dazu bei Euch übrigens!

(wobei es mittlerweile im Netz auch so Packungen mit 24 1-m-DMX-Tubes für 920 Dollar gibt... also eine für ca. 40 Euro ;))

Hallo, ich habe diesen Bericht eifrig gelesen und gehofft das es zu einer Lösung bei diesem Problem kommt aber leider erfährt man nicht mehr was nun am Ende passiert ist.
Ich habe das gleiche Problem. Ich habe Stairville LED RGB Multicolor Tubes mit einem SDL-109C-W Ver. 4.0. Ich finde leider zu diesem LED Tube Modell nichts im Internet.
Ich möchte auch gern mehr machen mit diesen LED Tube bin aber durch den Controller mit seinen Programmen ziemlich eingeschränkt,da ich hoffte über DMX mehr machen zu können...aber nada!
Welche möglichkeiten gibt es denn um mehr mit den LED machen zu können? Thx für eure Antworten