Professionelle Ethernet DMX Bridge als Alternative zur DMX Extension

**Gerrit** · 08.01.2019, 04:07

Kann es sein, dass der "Anstieg" bei RGB (also z.B. das Faden zu Beginn beim Anspringen einer bestimmten Farbe) tw. erst andere Farben anspringt, je nachdem wie die Anteile der Zielfarbe sind? Ich mein zuvor mit der Loxone DMX Extension war es die Zielfarbe, nur hochgedimmt. Das Verfahren von Loxone würde auch gerade beim Pulsieren deutlich besser passen.
Also es scheint so, dass alle Farben mit derselben Dimmkurve in der selben Geschwindigkeit gedimmt werden, aber nicht in der passenden Proportion, also wenn man 20, 20 und 60% bei RGB anfahren soll, ist bei der Hälfte 20, 20, 30%, statt 10, 10, 30% angefahren, also er ist mit manchen Farben zu früh fertig und dann stimmen die Zwischenfarben nicht.

**Robert L.** · 08.01.2019, 06:59

ja, das ist sicher so
Ich hatte angedacht dass in der "Version 2" mal zu verbessern, da mich RGB aber eigentlich nicht sonderlich interessiert (und wenn überhaupt, dann mit 16bit oder H801) hab ich es mal auf Eis gelegt.. (sehe das mehr als Marketing Gag..als praktischen nutzen..)

wie du richtig erkannt hast, bräuchte man pro Farbe unterschiedliche dimm-Geschwindigkeiten: in deinem Beispiel müsste R und G wesentlich langsamer dimmen, als B
wäre durchaus machbar, in überschaubarer Zeit, darf gerne jemand umsetzen und einen Pull-Request machen..

**Gerrit** · 08.01.2019, 12:39

Oh das RGB Licht nur für Marketing verwendet wird, sollte man dann potentiell als Hinweis geben pmayer , mit dem RGB Licht wird ja u.a. die Extension als Beispiel beworben

Soll auch kein Vorwurf an dich sein bzw. Kinderkrankheiten gibts ja immer.
Ich kann mal schaun, ob ich etwas helfen kann, verstehe das Verfahren aber noch nicht auf die Schnelle. Die Stelle sollte hier sein: https://github.com/LechnerRobert/UDP...worker.cpp#L47 Robert L. könntest du das aktuelle Vorgehen eventuell noch etwas erläutern oder mit Kommentaren versehen? Bzw. welche Idee du für ein proportionales Dimmen bereits grob hättest, das könnte mir auch helfen. Weil wahrscheinlich bräuchte man wieder möglichst ein Berechnung und Speicher optimiertes Verfahren, was den Code ja meistens komplexer macht

**Labmaster** · 08.01.2019, 13:37

Ein DMX Interface ist doch keine Number Crushing Unit, sondern nur eine Interface zu Umsetzen von einem Medium (Ethernet) in ein anderes (DMX).
Solche Dinge gehören eigentlich in den Ansteuerbaustein (Loxone Lichtsteuerung) zusammen mit einem zugehörigen Dimmer. EIn Interface dazwsichen wird sich hier recht schwer tun.
Um das sauber zu implementieren, bräuchte man Infos zum zeitlichen Verhalten als z.B. die Fadeingzeit aus Loxone, diese Info müsste bei jeder Ansteuerung mit übertragen werden und der Dimmer selbst müsste die dann auswerten und in eine entsprechendes Fading der einzelnen Kanäle umsetzen.
Ansonsten hauen einem da nur die Übetragungsrate (DMX) und Ethernet alle möglichen Stricke zwischen die Beine.
Im übrigen gibt es ein Ähnliches Problem auch bei Dual White Ansteuerung. Hat man da einen bestimmten Weiß Ton eingestell tund möchte zeitlich gesehen einen Dimmverlaub haben, dann stimmen ohne entsprechendes Vorgehen die Weiß Anteile während des Dimmens auch nicht. Aber auch hier hätte eine reines Interface ohne Infos zum zeitlich vorgegebenen Dimmverlauf kein große Chance das zu korrigieren.

Im übrigen löst das Problem Loxone mit Ihrer "Smart" Übertragung, wo eben neben den reinen Ziel Werten auch Zeit Infos übertragen werden.
Aus der Not raus hat Loxone bei DMX die Ansteuerung hierfür in das Interface verschoben, somit müssen keine DMX Kanäle für Zeitinfos geopfert werden und alle DMX Dimmer könnten damit arbeiten.
Würde man das Problem also ordentlich lösen wollen, dann müßte man mit dem Ethernet Interface irgendwie die Zeitinfos aus dem Smartaktor Ausgang auswerten.

**Labmaster** · 08.01.2019, 13:47

Ja das ist mit sicherheit auch so, der Tree Bus ist ja wegen der geforderten Übertragungs-Robustheit nicht gerade für große Datenmengen, sprich Wiederholraten ausgelegt.

**Robert L.** · 08.01.2019, 13:49

>Würde man das Problem also ordentlich lösen wollen, dann müßte man mit dem Ethernet Interface irgendwie die Zeitinfos aus dem Smartaktor Ausgang auswerten.

das weiß Loxone, deshalb ist sind diese Daten nicht zugänglich ..

**Gerrit** · 08.01.2019, 14:18

Was es ist und was es nicht ist, würd ich gern aus der Diskussion zur Lösung heraushalten

An erster Stelle ist es eine Alternative zur DMX Extension (siehe auch Thema des Threads). Wenn wir uns da einig sind, können wir ja schauen, wie man das am besten hinbekommt.
Und Zeitinfos werden ja bereits im Protokoll von Robert übertragen, also geht es ja "nur" darum die Proportionen im Bezug auf die Dimmstufen anzupassen. Da jeder RGB Kanal sowieso einzeln angesteuert wird, sollte es generell denke ich kein großes Problem sein. Zudem stehen die Werte schon als 0-100 Werte pro Kanal zur Verfügung. Nur verstehe ich die aktuelle Lösung zur Umsetzung der Fading-Time nicht direkt. Und bevor ich mir etwas falsches zusammenreime, dachte ich frage geschwind

**Gerrit** · 08.01.2019, 14:21

btw waren meine Versuche mit den Smart Aktoren bei DMX und der Loxone DMX Extension erschreckend. Da war die Performance beim Faden von mehreren Kanälen gleichzeitig nochmal deutlich schlechter. Habe aber nicht geschaut, wer der Verursacher sein könnte.

**Gerrit** · 08.01.2019, 15:32

Robert L. ist theoretisch der aktuelle Wert eines Dimm-Kanals in der intQueue.dimTo, mit dem man dann die Dimmzeit berechnen könnte? Zumindest wird dieser Wert als Anhaltspunkt für das Fast-Dimming > 10% Delta genommen oder?

**Robert L.** · 09.01.2019, 07:57

Gerrit
ja, max() von allen 3 ermitteln, usw.

habs mir kurz angeschaut, und auf github gestellt
sollte jetzt funktionieren (zumindest bei RGB und zumindest etwas besser als vorher)

"emulator" gäbe es auch, das wäre die x86 version

ich nehme aber eher einen UNO + Ethernet-shield und baue mir debug Ausgaben

**Gerrit** · 09.01.2019, 18:15

Robert L.
Ah dann haben wir uns überschnitten

Hatte gestern noch dran gearbeitet:
Hier schon mal PseudoCode bzw. der Ablauf

(1) Pro Kanal absoluten Differenzwert zwischen Zielwert und aktuellem Wert berechnen
(2) Größten Wert bzw. die beiden kleineren erkennen..
(3) ...und zu diesen neue Speed Werte berechnen falls Speedwert != 255
SPEED_IDX: Speedwert ohne Faktor
Faktor F1: Übergebener Speedwert Faktor 0xx (=8), 1xx (=2) oder 2xx (=1)
Faktor F2: Differenz zwischen größtem Wert und einem der kleineren
Ziel: Über höchste Genauigkeit annähern = neuen Wert in Achtel-Schritten ausdrücken, wenn zu groß in Viertel-Schritten, wenn zu groß in ganzen Schritten bzw. Max/Überlauf

float temp = SPEED_IDX * F1 * F2
if (temp > 54) {
temp = temp / 2;
if (temp > 99) {
return min((int)(temp / 4),99);
} else {
return 100 + (int) temp;
}
} else {
return 200 + (int) temp;
}

Der Unterschied müsste sein, dass ich versuche über potentiell kleinere Schritte näher an den Zielwert zu kommen. Jedoch ist mir dann als ich das soweit durchgespielt hatte eingefallen, dass man ja auch einfach einen berechneten zusätzlichen Faktor mitgeben könnte, statt der Werte, die nur aus der gegeben Werte Liste generiert werden können um dann es ganz korrekt zu haben. Oder sind die Werte für den Speedwert, und Viertel bzw. Achtel ganz spezielle abgestimmt auf die Verarbeitungsloop?

**Gast** · 21.01.2019, 11:46

Hallo,

wir von der cod.m GmbH würden euch gerne unterstützen. Wie ist der momentane Stand und wo können wir uns beteiligen?

Unsere Roadmap sieht so aus, dass wir auf lange Sicht planen die Version 2 auf unserer Hardware zu betreiben. Vorausgesetzt die Software hat den Beta-Status verlassen und läuft stabil. Zusätzlich würden wir gerne das Projekt mit einem Build-Automatismus für das Kompilieren der Binaries erweitern. Das sollte vorallem Endanwendern helfen, da sie automatisch die letzte stabile Version herunterladen und flashen können.

Habt ihr Anregungen oder Feedback dazu?

**pmayer** · 29.01.2019, 19:56

Robert L. und hismastersvoice: Sollte ich bei der 644p/RS485 Variante, also die Hardware die hinterher auch mehr als DMX nutzen solln, ~RE und DE auf zwei separate Pins des Atmega legen? Oder einfach beide auf einen Pin zum umschalten der Sende-/Empfangsrichtung?

**Robert L.** · 30.01.2019, 06:26

Correctly using RE and DE with RS485

https://electronics.stackexchange.com/questions/153500/correctly-using-re-and-de-with-rs485

I'm trying to build a RS-485 project using MAX485's. However, I'm having trouble finding out how to correctly use the RE and DE pins. Some PDF's and websites say that RE and DE should be tied toget...

ich denke separat ist unnötig..

**julianbmw** · 17.02.2019, 12:53

Hallo!

wird es dieses Jahr noch eine V2 geben? Bin gerade am planen aber brauchen werde ich es erst Anfang Sep. 2019...

lg