\documentclass[11pt,ngerman,a4paper,chapterprefix]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage[ngerman]{babel}
\usepackage{fancyhdr}
\usepackage{hyperref}

\usepackage{geometry}
\geometry{bottom=30mm}

\usepackage{nomencl}
\makenomenclature

\title{DMX512-RDM}
\author{Jens Ullmert}


\newcommand{\abbr}[2]{\textit{#2} (#1)\nomenclature{#1}{#2 \nomrefpage}}
\newcommand{\source}[1]{ {\scriptsize  Quelle: {#1} } } %command definition for sources in figures

\begin{document}
\pagestyle{fancy}
\setcounter{section}{7}


\section{DMX 512 - RDM}

Die in Abschnitt 4 vorgestellte Hardware kann durch den \textit{GPIO18} zwischen Lese- und Schreibfunktionalität umgeschaltet werden.
Diese Funktion ermöglicht es theoretisch, die \abbr{RDM}{Remote Device Management} Erweiterung des DMX Protokolls zu nutzen, womit sich der folgende Abschnitt näher befasst.\\

RDM wird im Live-Bereich der Veranstaltungstechnik sehr selten bis nicht verwendet und grundsätzlich während der Show deaktiviert.
Da dieses Feature nur von hochpreisigen Endgeräten angeboten wird, ist die Wahrscheinlichkeit groß, dass sich ebenfalls Geräte ohne RDM im Strang befinden.\\

Durch den Zugriff mehrerer Sender auf den gleichen Bus muss ein passendes Buszugriffsverfahren gewählt werden, bei dem die rückmeldenden Pakete den Datenfluss vom Mischpult an die Endgeräte nicht stört.
Der Reset zur Einleitung jeder Übertragungssequenz setzt mithilfe des \abbr{CSMA/CA}{Carrier Sense Multiple Access / Collision Avoidance} Zugriffsverfahrens eine Priorität, sodass alle Endgeräte ihre Übertragung im Sinne der Kollisionsvermeidung abbrechen und den Bus freigeben.\\

Dies setzt zusätzlich voraus, dass jedes Endgerät in der Lage ist, einen vom Lichtpult gesendeten Reset zu detektieren.
Alte oder nicht standardkonform programmierte Geräte können hier möglicherweise aufgrund falscher Interpretationen ein Fehlverhalten aufweisen.\\

\begin{figure}[h]
	\centering
	\includegraphics*[scale=0.3]{img/c2-1-1_dmx_timing.PNG}
	\caption{Timing bei DMX}
	\label{fig:timing}
	\source{https://wiki.production-partner.de/licht/lichtsteuerung-mit-dmx-512/}
\end{figure}






~\\
\subsection{Aufbau der RDM Pakete}
Die Kommunikation im RDM-Fall ist vergleichbar mit \(I^2C\).
Das Lichtpult fungiert als Master und fragt gezielt eine Information an einer Lampe an, welche daraufhin antwortet.
Zur Adressierung wird eine 48 Byte UID verwendet, welche stark an die MAC-Adresse bei Ethernet erinnert.
Die ersten 16 Byte geben Aufschluss über den Hersteller, die restlichen 32 Byte können individuell vergeben werden.\\
Die UID FF.FF.FF.FF.FF.FF wird als Broadcast verwendet.\\

Um eine eindeutige Unterscheidung zwischen DMX- und RDM-Paketen zu gewährleisten wird als abweichender Startcode 0xCC anstelle 0x00 verwendet.
Bei einer korrekten Implementierung des DMX Protokolls sollte das empfangene Paket verworfen werden, wenn keine RDM Funktionalität im Endgerät verfügbar ist.\\
An den Startcode wird der sogenannte Substartcode Byte 0x01 angehängt.
Dieses dient als Platzhalter für zukünftige Protokollerweiterungen.\\

Befehle und Antworten setzen sich aus drei Byte zusammen.
Das erste Byte ist die Befehlsklasse, siehe Tabelle \ref{tab:klassen} die anderen beiden die Befehls-ID, siehe ausschnittsweise Tabelle \ref{tab:id}. \\

\begin{table}[!h]
	\centering
	
	\begin{tabular}{|r|l|}
		\hline
		\textbf{Klasse} & \textbf{Funktion} \\
		\hline
		0x10 & Discovery Befehl \\
		0x11 & Discovery Antwort \\
		\hline
		0x20 & Leseanforderung \\
		0x21 & Antwort mit angefordertem Wert \\
		\hline
		0x30 & Schreibbefehl \\
		0x31 & Antwort auf Schreibbefehl \\
		\hline
	\end{tabular}
	
	\caption{Befehlsklassen bei RDM}
	\source{https://www.soundlight.de/techtips/dmx512/dmx\_rdm.htm}
	\label{tab:klassen}
\end{table}
~\\

\begin{table}[!h]
	\centering
	
	\begin{tabular}{|r|l|}
		\hline
		\textbf{Befehls-ID} & \textbf{Befehl} \\
		\hline
		0x0001 & Discovery \\
		0x0002 & Mute für Discovery \\
		0x0003 & Unmute für Discovery\\
		\hline
		0x0050 & Liste unterstützter Parameter \\
		0x0051 & Parameterbeschreibung \\
		0x0060 & Geräteinformationen \\
		0x0081 & Herstellername \\
		0x00C0 & Softwareversion \\
		0x0400 & Betriebsstunden \\
		0x0401 & Lampenstunden \\
		0x0402 & Lampenzündungen \\
		0x0403 & Lampenstatus \\
		\hline
	\end{tabular}
	
	\caption{BefehlsID bei RDM}
	\source{https://www.soundlight.de/techtips/dmx512/dmx\_rdm.htm}
	\label{tab:id}
\end{table}
~\\


Durch die Mute- bzw. Unmute Funktion wird der Buszugriff zusätzlich unterstützt.
Erhält man auf einen Discovery-Broadcast eine Antwort, kann aus dieser die UID des Endgerätes entnommen werden.
Wird im Anschluss gezielt an dieses Gerät ein Mute-Befehl gesendet, antwortet es nicht auf künftige Discovery-Broadcasts.\\

Da alle Hersteller unterschiedliche Befehle unterstützen oder teilweise umfunktionieren, ist es erschwert, einen einheitlichen Monitor oder Interpreter zu entwickeln. 
Der individuelle Funktionsumfang muss lampenspezifisch der Anleitung entnommen werden.
Der Lampenhersteller Robe beschreibt im Handbuch des BMFL Blade die BefehlsIDs \textit{ROBE\_DMX\_INPUT} oder \textit{ROBE\_WIRELESS\_UNLINK} und gibt ebenfalls in dieser Liste durch eine Fußnote an, andere Optionen für gewisse BefehlsIDs zu verwenden. \source{https://www.robelighting.de/res/downloads/user\_manuals/User\_manual\_Robin\_BMFL\_Blade.pdf} 










~\\
\subsection{Praxistest}

Die Veranstaltungssicherheit und -technik hat dankenswerterweise den Audimax der Technischen Universität Kaiserslautern zur Verfügung gestellt, um das RDM Protokoll in der Praxis testen zu können.
Hierzu wurde die bestehende Verkabelung aufgelöst, da sich zwischen Regiekabine und Beleuchterzug ein nicht-RDMfähiger DMX-Splitter befindet.\\

Im Beleuchterzug wurden zwei RDM kompatible Robe BMFL Spot und vier Eurolite ML56 LED Par ohne RDM Funktion verbunden.
Nach dem Aktiviern der RDM Funktion am grandMA 2 Steuerpult konnte hier direkt ein Fehlverhalten der ML56 beobachtet werden, welches sich ähnlich wie ein Busfehler zeigte.
Der Versuchsaufbau wurde daraufhin so verändert, dass lediglich die beiden BMFL an die grandMA angeschlossen worden sind.
Eine erste Spekulation ist die Missinterpretation des geänderten Startcodes von 0xCC für RDM anstelle des standardmäßigen 0x00.\\

Im veränderten Aufbau wurden beide BMFL nach einiger Zeit korrekt detektiert.
Auch wenn die grandMA einen limitierten Umfang der eigentlichen Möglichkeiten unterstützt konnten einige Sensorwerte gelesen und händisch interpretiert werden.
Alternativ wäre mit dem Robe RDM Communicator eine einfache herstellergebundene Möglichkeit gegeben, fertig interpretierte Werte zu erhalten.\\

Der Testaufbau hat gezeigt, dass es in diesem Fall nicht möglich ist, beliebige Lampen in einer einzigen DMX-RDM-Kette zu betreiben.
Würde man im Audimax die RDM-fähigkeit der BMFL nutzen wollen, müsste ein weiterer DMX-Strang in die Beleuchterzüge eingebracht werden.
Dieser Aufwand ist im Vergleich zu einer Ethernetverkabelung so verschwindend gering, dass es wirtschaftlich nicht zu vertreten wäre, DMX statt Ethernet zu verwenden.
Ethernet bietet im Vergleich zudem weitere Vorteile und Möglichkeiten wie beispielsweise eine Überwachung der Lampen über \abbr{SNMP}{Simple Network Monitoring Protocol} oder das Verbinden weiterer Geräte über trunk Ports.
Da eine Ansteuerung der Lampen aus der bestehenden Peripherie über sACN oder ArtNet problemlos möglich ist, entfällt die Notwendigkeit der klassischen DMX Verkabelung.







\newpage
\section{Hardware- und Softwareanpassung}
Der in der ursprünglichen Projektarbeit beschriebene DMX-Hat für den Raspberry Pi wurde modifiziert und ist verfügbar unter \url{https://git.agg-hosting.de/Erwin/DMX-Hat\_RasPi}\\

Einige Hardwareanpassungen wie eine zusätzliche galvanische Trennung des DMX Ausgangs, eine Erhöhung der Busspannung auf 5V und eine Montagemöglichkeit für einen 20mm Lüfter wurden einbezogen.\\
Die aktuelle Platine ist als Projekt für KiCad 6.0 verfügbar.\\

Softwareseitig wurde ein Lesen für eingehende Pakete implementiert, eine Auswertung wurde aufgrund der sehr Herstellerspezifischen Interpretationsweisen von RDM nicht durchgeführt. 




~\\\\
\section{Fazit}
Insbesondere der Praxistest hat gezeigt, dass das Remote Device Management zwar viele Funktionen bietet, welche das Leben erleichtern, bei inhomogen Systemen aber oft zu Fehlern führt. 
Gepaart mit einer Wünsch-Dir-Was Mentalität der Hersteller wurde hier jegliche Innovation bereits im Keim erstickt. \\

Der erste Versuchsaufbau im Praxistest konnte musste bei einer überschaubaren Menge an Endgeräten abgebrochen werden, was bei einer Skalierung in große Systeme nicht unbedingt Besserung vermuten lässt.
Auch wenn die Kommunikation im zweiten Versuch erfolgreich war, bleibt eine gewisse Skepsis gegenüber dem Protokoll.
Im Live-Betrieb wäre eine Lampenüberwachung zwar wünschenswert, unterliegt aber der Störungsresistenz des Gesamtsystems. \\

Im Ausblick auf die nächsten Jahre verschwinden hoffentlich immer mehr Endgeräte, die aktuell nicht in der Lage sind, RDM von DMX Paketen zu unterscheiden.
Mit ausbleibenden Störungen auf dem Bus könnte RDM allmählich Fuß fassen.
Ein vollständiger Ersatz durch Ethernet ist jedoch nicht zu vernachlässigen.








\end{document}