[Projekt] Arduatmo - Ambilight auf Arduino-Basis

Hallo,

auch wenn die letzte Nachricht in diesem Thread schon etwas her ist hoffe ich, dass das der richtige Ort ist für meine Frage.
Ich habe nun einen WS2812B Stripe, den ich an einem Arduino UNO (hat einen CH340G Konverter) zusammen mit dem Seduatmo Plugin meines VDR betreiben möchte. Meinen Sketch kann man hier einsehen: https://pastebin.com/Gn7m1VgZ
Also "program" habe ich "10" (police_lightsALL) ausgewählt. Wenn ich den LED Stripe an den Arduino anschließe beginnt ein Grün/Blaues Lauflicht zu laufen.
Im Linux des VDR taucht das Gerät als /dev/ttyUSB0 auf. Ich habe einen symlink von /dev/ttySEDU darauf gelegt und die Rechte so gesetzt, dass der VDR auf das Device zugreifen darf. Wird das Plugin gestartet, kann es sich erfolgreich mit dem Device verbinden:

Mar 29 20:34:46 vdr vdr: SEDUATMO: Opening '/dev/ttySEDU' succeeded!

Solange im Plugin der Modus "Detached" ausgewählt ist läuft das default-Programm, also das Lauflicht. Sobald ich einen beliebigen anderen Modus auswähle werden ALLE LEDs dauerhaft rot. Schalte ich wieder auf "Detached" läuft wieder das Lauflicht los.

Hat jemand eine Idee was da falsch läuft? Die Kommunikation scheint ja grundsätzlich zu funktionieren, die Frage ist nur: Warum werden alle LEDs rot anstatt anzuzeigen, was man im jeweiligen Modus erwarten würde?

Viele Dank im Voraus für Eure Tips!

Viele Grüße,
Stephan

Hi
als Alternative zu dem seduatmo-plugin kannst du ja mal hyperion testen
Hier mal der Link zum Forum
https://hyperion-project.org/

Als Plugin dann vdr-boblight falls du softhdevice mit nvidia benützt sonst einfach nur hyperion-X11.
Grüße
Wolle

Zitat von TheChief

Eventuell wegen der Zeile

Code

oneColorAll(255,0,0);

oder

Code

default: oneColorAll(0,0,255);        break;

Kann sein, dass was bei der Kommunikation schief läuft und dann default eintritt. Mit Arduinos ohne FTDI hatte ich damals auch kein Glück so richtig.

Alles anzeigen

Ja, es scheinen tatsächlich die oneColorAll Zeilen zu sein, wegen denen der Strip rot leuchet. Wenn ich den ändere, ändert sich auch die Farbe.

Ich habe mal /dev/ttySEDU als normale Datei angelegt und somit mitgeschnitten was das Plugin so an den Arduino sendet. Dann habe ich die Baudrate auf 115200 gesetzt und debugging aktivert, den Arduino neu bespielt und direkt an meinen Rechner angeschlossen. Dann eine Serielle Konsole aufgemacht und die zuvor mitgeschnittenen ttySEDU
Daten dort hingesendet (cat ttySEDU > /tmp/ttyUSB0). Interessanterweise werden vom Arduino (sichtbar in der seriellen Konsole) nicht alle Daten _so_ empfangen, wie sie in der ttySEDU Datei stehen! Der Anfang stimmt, aber dann werden z.T. andere Werte empfangen als gesendet! Vor allem nicht nur andere, sondern MEHR Daten. Dadurch tritt dann ein Fehler auf, weil vor dem erwarteten End-Byte zu viele Daten kommen. Es kommen auch nicht immer die gleichen Daten an....Alles sehr merkwürdig. Evtl. ist das tatsächlich ein Problem, weil es kein FTDI konverter ist. Allerdings hatte ja jemand hier im Forum geschrieben, dass es mit seinem CH240G (den ich auch habe) funktioniert, daher hatte ich Hoffnung... Ein anderer Arduino UNO von mir hat einen atmel atmega16u2 als Konverter, mit dem es allerdings leider auch nicht klappt.

Viele Grüße,
Stephan

TheChief: Der Originalcode ließ sich übrigens weder mit der aktuellen Arduino GUI noch mit Atom / PlatformIO kompilieren. Ich habe damit das funktioniert in meinem Sketch alle Funktionen ganz oben deklariert, erst damit klappte es mit Atom. Mit der aktuellen Arduino IDE klappt es nach wie vor nicht, da verstehe aber irgendwie die Fehler auch nicht. :-/ Evtl. wäre es schön, wenn Du den code im Repository mal aktualisierst, so dass auch Neueinsteiger eine Chance haben und Leute ohne große Programmierkenntnisse nicht gleich vor ner unüberwindbaren Hürde stehen Danke für das coole Projekt, ich hoffe ich bekomme das auch mal ans laufen :-/

Zitat von plautze

Hi
als Alternative zu dem seduatmo-plugin kannst du ja mal hyperion testen
Hier mal der Link zum Forum
https://hyperion-project.org/

Als Plugin dann vdr-boblight falls du softhdevice mit nvidia benützt sonst einfach nur hyperion-X11.
Grüße
Wolle

Alles anzeigen

Hi Wolle,

danke für den Tip, allerdings habe ich gelesen, dass das boblight Plugin die CPU _deutlich_ stärker belastet als seduatmo, deshalb versuche ich die boblight variante zu vermeiden...

Viele Grüße,
Stephan

Hi,
FTDIs funktionieren auch in anderen Bereichen wie Astro am Besten.

MfG,
Stefan

Na, dann werde ich mal nach nem FTDI Ausschau halten. Das Problem ist aber wohl wie ich las, das man da momentan mit ziemlich hoher Wahrscheinlichkeit nen gefälschten Chip bekommt, der bei hoher Taktung Probleme mach. Daher hatte ich gehofft das mit nem anderen Chip hinzubekommen, aber das scheint ja nicht zu funktionierren. Versuch ich mal mein Glück mit FTDIs

So, ich hab in meiner Grabbelkiste tatsächlich noch einen USB-RS323 Adapter gefunden mitnem FTDI Chip. Die Frage, die ich mir nun stelle ist: Kann ich überhaupt nen externen Adapter an den Arduino anschließen, während der einen onboard adapter drauf hat? Die RX und TX Pins die nach Außen geführt werden werden schon mit 5V vom onboard Adapter gespeist... Habt ihr da Erfahrungen mit?

Viele Grüße,
Stephan

Es läuft nun bei mir. Ein paar Hinweise dazu von mir für Leute die es nachbauen wollen:

• Den Sketch habe ich hier geladen: https://github.com/TheChief79/tpm2arduino
• Ich habe die aktuelle Arduino IDE (1.8.2) auf dem Mac verwendet, da ich mit der Atom IDE o.g. Fehlermeldungen erhalte.
• In das Arduino Library Verzeichnis ( ~/Documents/Arduino/Libraries ) habe ich die Version 1.4 von Adam Dunkels Protothreads Library (http://dunkels.com/adam/pt/download.html)in ein eigenes Unterverzeichnis entpackt
• Aus diesem Ordner habe ich alle example* Dateien gelöscht, da diese nicht mit der aktuellen Arduino IDE zusammenarbeiten wollen und dieser daher beim Kompilieren einen Fehler wirft.
• Ich habe einen Arduino Nano verwendet (http://www.ebay.de/itm/271513578559?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT ). Dieser hat einen FTDI FT232RL USB-Serial converter drauf.
• Es muss jedoch nicht zwingend ein Arduino mit FTDI Chip sein. Wie ich durch tests herausfand funktioniert ein Arduino UNO mit CH340G Konverter Chip ebenfalls sehr gut. Der atmega16u2 als USB-Seriell Konverter funktionierte zunächst auch gut machte aber - zumindest bei mir - nach einiger Zeit Probleme (Device ließ sich nicht mehr ansprechen).
• Damit der Zugriff auf den USB Konverter auch ohne Root Rechte funktioniert habe ich folgende udev-rule definiert:
  KERNEL=="ttyUSB?", OWNER="vdr", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", SYMLINK+="ttySEDU"
• Ich verwende 181 WS2812B LEDs. Zunächst bekamen die ihre 5V nur vom USB Port des Arduino. Dabei stellten sich jedoch komische Effekte ein. So z.B.: Kleine helle (nahezu weisse) Flächen am Bildschirmrand führen zu schönen ebenfalls nahezu weiß leuchtenden LEDs. Handelt es sich jedoch um eine größere fast weiße Fläche (z.B. eine Landschaftsaufnahme mit sehr hellem Himmel) so leuchten die entsprechenden LEDs nicht mehr weiß, sondern stets rötlich orange. Zudem stieg nach längerer Benutzung z.T. auch der Arduino aus und war nur durch einen reset wieder zum leben zu erwecken.
  Die Lösung war dann die LEDs über eine separate, leistungsfähigere Stromquelle anzusteuern (wobei Ground mit dem Arduino geteilt sein sollte). Nach TheChiefs Tip habe ich mir die 5V von einem freien DVD/HDD Molexstecker meines VDR-Mainboards geholt. Damit ist der orangestich bei großen weißen Flächen weg und auch insgesamt leuchten die LEDs gefühlt etwas heller.
  

Was ich noch nicht so ganz durchblicke sind die vielfältigen Einstellungsmöglichkeiten im Seduatmo Plugin des VDR. Kennt jemand für diese eine gute Beschreibung?

Viele Grüße,
Stephan

Bei mir lässt sich die RGB Reihenfolge nicht ändern, egal was ich anstelle.
Früher unter einer alten easyvdr hatte das mal funktioniert.
Nun kann ich nichts mehr ändern, im OSD steht immer RGB und das wird auch benutzt, egal was in der setup.conf eingestellt ist.

Auf der Seite des Plugins findet sich bei den letzten Revisionen:

Merge branch 'dev'


    dev:
    code review
    added individual RGB order to seduatmo.conf
    added individual RGB order to seduatmo.conf

Meine durch das perl-script erstellte .conf beinhaltet aber kein RGB Order.
Bin gerade etwas ratlos.

Danke für den tip, ich werde es mal im Sketch ändern.
Seltsam ist das trotzdem.

Hallo TheChief,

Zitat von TheChief

Hauptsache Du lässt nicht die gesamten Strom durch den Arduino wandern. Dann hält er sicher nicht lange. Würde dennoch so verkabeln, wie im PDF im ersten Thread, nimmst halt die 5V vom Netzteil des PC, hatte ich anfangs auch mal so und 5V an einem Molex Stecker abgezweigt.

Vielen Dank für den tollen Tip mit dem Molex Stecker. Mit diesem sind nun alle meine bisherigen Probleme (inkl. der rötlichen weißen Flächen) weg und ich spar mir ein separates Netzteil. Top-Tip!

Viele Grüße,
Stephan

Habe ich auch so gemacht.
Bei mir ist der Arduino im Gehäuse verbaut und hängt an einem internen USB-Header.
Die Versorgung für die LED Streifen und die Daten/Clock Leitung werden mit einer Klinkenbuchse und 2 Bananenbuchsen bereitgestellt.
diese habe ich in ein Slotblech verbaut.

TheChief:

funktioniert nach Änderung im Sketch.
Trotzdem kurios das es im OSD nicht mehr verstellbar ist.

Zitat von sboldt

Solange im Plugin der Modus "Detached" ausgewählt ist läuft das default-Programm, also das Lauflicht. Sobald ich einen beliebigen anderen Modus auswähle werden ALLE LEDs dauerhaft rot. Schalte ich wieder auf "Detached" läuft wieder das Lauflicht los.

Hat jemand eine Idee was da falsch läuft? Die Kommunikation scheint ja grundsätzlich zu funktionieren, die Frage ist nur: Warum werden alle LEDs rot anstatt anzuzeigen, was man im jeweiligen Modus erwarten würde?

sboldt
so weit bin ich jetzt auch, wie hast du dieses Problem lösen können?

@all
Frohe Ostern!