Wer LED-Steuerung über Netzwerk hört, denkt an Art-Net oder sACN. Beide kommen aus der Veranstaltungstechnik, beide sind standardisiert, beide laufen auf großen Bühnen. DDP und WARLS spielen in einer anderen Ecke. Sie sind aus der WLED- und Bastler-Community groß geworden, tauchen in Lichtpult-Dokumentationen kaum auf und haben trotzdem gute Gründe zu existieren.
Dieser Beitrag erklärt, was hinter den beiden Protokollen steckt, wie sie technisch aufgebaut sind und wann sich der Blick über den Art-Net-Tellerrand lohnt.
Warum diese beiden Außenseiter sind
Art-Net und sACN denken in DMX-Universen: 512 Kanäle pro Universum, ein festes Raster, das aus der Bühnentechnik stammt. Für ein paar hundert Pixel bedeutet das schon Rechnerei mit Universen, Start-Kanälen und Mapping.
DDP und WARLS lassen dieses Raster weg. Beide sprechen direkt über Pixel und ihre Position im Strip. Kein Universum, keine 512er-Grenze im Kopf. Genau das macht sie in der WLED-Welt beliebt, wo oft ein ESP32 mit ein paar hundert Pixeln an einem WS2812B-Strip hängt und niemand ein DMX-Universum aufteilen möchte.
DDP: schlank und pixelorientiert
DDP steht für Distributed Display Protocol und stammt von 3waylabs. Es läuft über UDP auf Port 4048 und ist darauf ausgelegt, Pixeldaten mit möglichst wenig Overhead zu übertragen.
Der Header ist nur 10 Bytes lang. Darin stecken ein Flags-Byte mit Versionsbits und dem sogenannten Push-Bit, eine Sequenznummer, ein Byte für den Datentyp, eine Ziel-ID (Standard ist 1 für den Standard-Ausgang), ein 4 Byte langer Offset und eine 2 Byte lange Längenangabe. Danach folgen direkt die Farbdaten.
Der Offset ist der Kern der Sache. Statt jeden Pixel einzeln mit Index und Farbe zu übertragen, sagt DDP nur: „Ab Pixel X kommen jetzt N Bytes Farbdaten.“ Der Strip füllt sich dadurch fortlaufend. Pro Paket passen bis zu 480 RGB-Pixel, also 1440 Bytes Nutzdaten, was sauber in einen Standard-Ethernet-Frame mit 1500 Byte MTU passt. Wer mehr Pixel hat, verteilt sie auf mehrere Pakete.
Damit sich das Bild erst dann aktualisiert, wenn alle Pakete angekommen sind, gibt es das Push-Bit im Flags-Byte. Software wie LedFx setzt es nur im letzten Paket eines Frames. Die vorherigen Pakete füllen still den Puffer, das letzte löst die Ausgabe aus. So flackert nichts, auch wenn ein Frame über vier oder fünf Pakete kommt.
DDP kann auch RGBW, also einen zusätzlichen Weißkanal, und beherrscht theoretisch Timecodes im Header. WLED liest diese optionalen Timecodes allerdings nicht aus. Wer also auf frameweise Synchronität hofft, sollte sich nicht auf DDP-Timecodes verlassen.
WARLS: WLEDs eigenes Echtzeit-Format
WARLS gehört zur Familie der UDP-Realtime-Protokolle von WLED und ist auf Port 21324 zu Hause (in WLED konfigurierbar). Der Aufbau ist bewusst simpel.
Das erste Byte legt das Protokoll fest, für WARLS ist es der Wert 1. Das zweite Byte bestimmt, wie lange WLED im Echtzeitmodus bleibt, bevor es zur normalen Anzeige zurückkehrt. Üblich sind ein bis zwei Sekunden, der Wert 255 hält den Echtzeitmodus offen, bis kein Paket mehr kommt. Danach folgt für jeden Pixel ein Viererblock aus Index, Rot, Grün und Blau.
| Byte | Bedeutung |
|---|---|
| 0 | Protokoll (1 = WARLS) |
| 1 | Timeout in Sekunden (255 = unbegrenzt) |
| 2 + n×4 | LED-Index |
| 3 + n×4 | Rot |
| 4 + n×4 | Grün |
| 5 + n×4 | Blau |
Weil der Index nur ein Byte belegt, endet WARLS bei 255 Pixeln. Für eine Ambient-Beleuchtung hinterm Fernseher oder einen kleinen Strip reicht das, für eine Fassade nicht.
Der Vorteil des Index: WARLS muss nicht den ganzen Strip senden. Wenn sich nur drei Pixel ändern, gehen auch nur drei Viererblöcke über die Leitung. Bei einem Effekt, der wenige Pixel bewegt, spart das spürbar Daten.
Die Geschwister von WARLS
WARLS ist selten allein unterwegs. WLED bringt drei verwandte Formate mit, die dasselbe erste Timeout-Byte nutzen, danach aber anders aufgebaut sind.
DRGB (Protokollwert 2) lässt den Index weg und schickt einfach Rot, Grün, Blau für Pixel 0, 1, 2 und so weiter. Das ist der klassische Vollbild-Stream und schafft rund 490 Pixel pro Paket. DRGBW (Wert 3) macht dasselbe mit zusätzlichem Weißkanal und kommt dadurch auf etwa 367 Pixel. DNRGB (Wert 4) löst die 255er-Grenze: Die ersten beiden Datenbytes geben einen Start-Index an, sodass sich über mehrere Pakete auch Strips mit tausenden Pixeln adressieren lassen.
In der Praxis heißt das: WARLS für gezielte Einzelpixel, DRGB für den durchgehenden Stream kleiner Strips, DNRGB für alles Größere. Wer die Wahl hat und viele Pixel bewegt, landet meist bei DRGB oder DNRGB statt bei WARLS.
DDP oder WARLS, und wo bleiben Art-Net und sACN?
Für ein WLED-Setup mit einigen hundert Pixeln ist DDP oft die ruhigere Wahl. Es überträgt große Frames effizient, kennt keine 255er-Grenze und synchronisiert das Bild über das Push-Bit. WARLS und seine Geschwister sind dann interessant, wenn es um schnelle, kleine Änderungen geht oder wenn ein Tool ohnehin nur diese Formate spricht.
Sobald aber mehrere Controller synchron laufen sollen, viele Universen im Spiel sind oder professionelle Pulte und Media-Server dazukommen, führt kaum ein Weg an Art-Net oder sACN vorbei. Deren Verbreitung in der Branche ist der eigentliche Grund, sie überhaupt zu nutzen. DDP und WARLS bleiben die pragmatische Antwort für die WLED-Ecke: wenig Overhead, kein Universum-Denken, schnell eingerichtet.
In PixDrive Studio
PixDrive Studio spricht beide Protokolle direkt, neben Art-Net, sACN und TPM2.NET. Damit lässt sich dieselbe Show ohne Umweg auf einen WLED-Controller ausgeben, egal ob das Ziel DDP erwartet oder auf den WARLS-Stream hört. Für kleine WLED-Projekte reicht damit oft ein Klick, ohne dass man sich vorher durch Universen-Mapping arbeiten muss.
Welches Protokoll für ein konkretes Setup am besten passt, hängt an der Pixelzahl, an der Hardware und daran, ob mehrere Geräte synchron laufen sollen. Für die Grundsatzfrage Art-Net gegen sACN gibt es dazu bereits einen eigenen Beitrag.
Die Dokumentationen zum Nachlesen
Die offizielle DDP-Spezifikation von 3waylabs steht unter http://www.3waylabs.com/ddp/. Wie WLED DDP umsetzt, inklusive Portangabe und dem Hinweis zu den Timecodes, beschreibt die WLED-Doku unter https://kno.wled.ge/interfaces/ddp/. Eine gut lesbare Darstellung aus Sicht der sendenden Software liefert die LedFx-Dokumentation unter https://docs.ledfx.app/en/latest/devices/ddp.html.
WARLS und die verwandten Formate DRGB, DRGBW und DNRGB sind samt Byte-Aufbau in der WLED-Doku zu den UDP-Realtime-Protokollen dokumentiert: https://kno.wled.ge/interfaces/udp-realtime/. Die zugehörige Wiki-Seite auf GitHub unter https://github.com/wled/WLED/wiki/UDP-Realtime-Control geht an einigen Stellen noch etwas tiefer.