Wer kennt sich mit dem DMX-Standard und der Technik aus?
Ich bin auf der Suche nach einem Steuergerät für RS-485 / RS-422 auf
diese Controller für Licht gestoßen und hatte das zunächst verworfen,
weil diese wohl nur 8 Bit senden können.
Jetzt bin ich in der Beschreibung des Protokolls jedoch auf über Hinweis
"double precision" gestolpert:
https://wiki.production-partner.de/licht/lichtsteuerung-mit-dmx-512/#Startbyte
Bedeutet das, dass man die auf 16 Bit umstellen kann? Oder können das
nur einige Marken?
Das wäre gut, weil die Geräte eine RS-485 / RS-422 Schnittstelle haben
und ich das Protokoll reinprogrammieren könnte. Sind ja "nur" 250 kHz.
Tobias N. schrieb:> Wer kennt sich mit dem DMX-Standard und der Technik aus?
Viele.
> Ich bin auf der Suche nach einem Steuergerät für RS-485 / RS-422 auf> diese Controller für Licht gestoßen und hatte das zunächst verworfen,> weil diese wohl nur 8 Bit senden können.
Das ist so.
>> Jetzt bin ich in der Beschreibung des Protokolls jedoch auf über Hinweis> "double precision" gestolpert:>> https://wiki.production-partner.de/licht/lichtsteuerung-mit-dmx-512/#Startbyte>> Bedeutet das, dass man die auf 16 Bit umstellen kann?
Nein.
> Oder können das> nur einige Marken?
Ja. Das ist ein selbstgetrickter Standard, der auf DMX512 aufbaut.
> Das wäre gut, weil die Geräte eine RS-485 / RS-422 Schnittstelle haben> und ich das Protokoll reinprogrammieren könnte. Sind ja "nur" 250 kHz.
Dann mach mal, es gibt dazu genügend Projekte. Ist auch nicht wirklich
schwer.
Das hängt allein vom verwendeten Gerät ab.
DMX-512 ist ja nichts anderes als 512 Kanäle zu je 8 Bit. Quasi ein
Datenpaket mit 512 Byte ohne jede Indexierung und jedes Gerät entnimmt
daraus für sich die Daten, die es möchte, beginnend mit seiner
Basis-Kanalnummer. Viele Geräte (z.B. Scanner) verwenden für ihre
X/Y-Achsen einfach zwei Kanäle, also 16 Bit. Also der Controller rechnet
das mit 16 Bit, der Scanner verarbeitet es mit 16 Bit, die Übertragung
erfolgt aber mit 2x 8 Bit.
Mehr Zauber ist nicht dahinter, DMX-512 ist halt schon recht alt.
Weis garnicht was an der Aussage stromkraft zu bemängeln ist. Genau so
ist das, das Startbyte markiert bloß das packet um welches Protokoll
verwendet wird. DMX 512 , RDM usw.
Das aufteilende in LSB und MSB Byte ist gängige Praxis aller seriellen
Schnittstellen.
Normale DMX Geräte ignorieren die Daten abseits vom Code 0, meist...
Marco H. schrieb:> Das aufteilende in LSB und MSB Byte ist gängige Praxis aller seriellen> Schnittstellen.
Das muss der Controller aber leisten und soweit ich mich da nun
eingelesen habe, tun die das anscheinend nur auf den Kanälen, die zur
Steuerung von 360° head-Systemen und anderen Präzisionselementen
vorgesehen sind. Das, was allgemein als "Lichtsteuerung" läuft, wird mit
nur einem Kanal gemacht. Das heisst, das DMX Protokoll sendet in der
Regel die Reglerposition mit 8 Bit.
Wenn, müsste der so programmierbar sein, dass alle Kanäle das tun, bei
eben der doppelten Protokolldauer. Frage wäre, welcher das kann. Ich
habe bisher keinen gefunden.
Eine andere Frage zur Protokoll-dauer: Sendet der eigentlich permament
die aktuellen Werte aller Potis oder nur die die sich ändern? Dann
müsste er nur bis zu dem Kanal senden, der sich geändert hat und kann
vorher abbrechen. Angeblich tun sie so etwas.
Tobias N. schrieb:> Sendet der eigentlich permament die aktuellen Werte aller Potis oder nur> die die sich ändern?
Der Standard gibt beides her.
> Dann müsste er nur bis zu dem Kanal senden, der sich geändert hat und kann> vorher abbrechen.
Ja, dann sollte man schlauerweise seine Adressen aber auch so verteilen,
dass nicht erst bei 450 die beiden Potis kommen, an denen dauernd
herumgeschraubt wird.
> bis zu dem Kanal senden, der sich geändert hat und kann vorher abbrechen.
Trotzdem wäre es sinnvoll, zwischendurch mal alle Adressen anzusprechen.
Sonst könnte der eine oder andere der "hinteren" Teilnehmer auf die Idee
kommen sich abzuschalten.
> Angeblich tun sie so etwas.
Wer behauptet das von wem?
Lothar M. schrieb:> Tobias N. schrieb:>> Sendet der eigentlich permament die aktuellen Werte aller Potis oder nur>> die die sich ändern?> Der Standard gibt beides her.>>> Dann müsste er nur bis zu dem Kanal senden, der sich geändert hat und kann>> vorher abbrechen.
Jein! Der Frame ist immer eigentlich 512byte lang. Alles andere würde
mit dem Timing Probleme machen unter 60 Channels wird dies zum Problem.
Es werden immer alle Channels übertragen, was du meinst ist Artnet aber
da werden auch immer alle übertragen. Nur wenn sich nichts ändert alle
4sec. Sobald sich was ändert werden Daten gesendet.
Die Aufteilung vom Fixture bestimmt das Fixture Profil. Daraus ergeben
sich die Startadressen ohne Überlappung. Wenn du 32bit übertragen willst
musst du das auf vier Channels aufteilen. Das einzige Problem was
auftritt ist das du dieses Profil nicht in den gängigen DMX Controller
anlegen kannst. 16bit sind auch für LEDs ausreichend was die Auflösung
angeht.
Das Protokoll kennt abseits von RDM keine Adressen. Diese fangen ab den
Startbyte an zu zählen oder speichern den ganzen Frame. Die Adresse
ergibt sich ab den Startcode und die Bytes die Übertragen werden. Jedes
Gerät holt sich das aus dem Frame was es braucht.
Marco H. schrieb:> Wenn du 32bit übertragen willst> musst du das auf vier Channels aufteilen. Das einzige Problem was> auftritt ist das du dieses Profil nicht in den gängigen DMX Controller> anlegen kannst. 16bit sind auch für LEDs ausreichend was die Auflösung> angeht.
Mir täten ja schon 16 reichen. Nur ist es eben so, dass die wenigsten
Controller über diese Kanalaufteilung machen und wenn, dann nur für
einzelne Kanäle, die z.B. vom Dreh-Regler gesteuert werden, weil man
offenbar vermutet, dass die auf die headlights gehen.
Eigentlich sollte es ja möglich sein, dass man die programmierbaren
Controller so einstellt, dass sie pauschal alle Potiwerte mit 16 Bit
senden und dann eben nur 256 Geräte-Kanäle besaften können.
Kann aber offenbar keiner.
Wofür brauchst du das? DMX ist ziemlich einfach, so dass man selber was
bauen kann.
Alternativ kannst du auch Daslight probieren. Das ist eine Software mit
USB-DMX-Peripherie. Über die passende Definition sollte es möglich sein,
Kanäle zusammenzufassen.
SW Geht leider nicht. Eine SW zum steuern haben wir. Ich möchte echte
Controller haben. Wir brauchen es physisch in den Händen.
Dussel schrieb:> Über die passende Definition sollte es möglich sein,> Kanäle zusammenzufassen.
Auch das ist nicht zielführend, weil ich dann 8 Regler bedienen muss, um
die 16 Bit zu steuern. Benötigt werden zwar nur 11-12 Bit, wie ich
inzwischen erfahren konnte und die ließen sich mit zwei Reglern noch
steuern, aber das ist total umständlich.
Das selber aufzubauen, würde es erforderlich machen, 10 ... 12 Potis mit
entsprechenden Wandlern zu versehen. Da wäre Kaufen eben symphatischer.
Die Industriesteuerungen mit Regler laufen meist über I2C und kosten um
die 100,- je Kanal.
Alternativ wäre auch eine andere Funktion, wie von einem Mischpult
denkbar, bei der ich die Regler auslesen kann. Digitale Mischpulte sind
aber zu teuer. Die einfachen, die MIDI senden, machen wiederum nur 7
Bit.
Ich habe einen Musikversand angeschrieben, welcher der DMX Geräte auf
allen Kanälen 16 Bit sendet und welcher davon der preiswerteste ist. Die
haben auch keine Ahnung, über die Details der Geräte. Die meisten sind
nicht einmal programmierbar.
Na oder halt die großen Pulte von MA-Lighting, ChamSys, Avolite, Zero88,
ETC...
Da legst du dein Fixture mit den gewünschten Kanälen alle in 16 bit an
und hast die dann auf den Schiebereglern.
Habe jetzt einfach mal einen Selbstbau abgeschätzt:
12x analoge Potis mit Beschaltung
2x 16-to-1 Analog Multiplexer
1x externer AD-Wandler
1x Microcontroller mit Beschaltung , gfs interner ADC
1x Stromversorgung
1x PCB
------------------
40,- Euro
30,- Zeit für Bestückung und Montage
1 MM Nettozeit Entwicklung = 10000,- / 50 Stück -> 200,- !
------------------
Gesamt an die 300,-
Im Gegensatz dazu:
2x 6-Kanal DMX vom Thomann zu 39,-
1/2 Woche Programmierung -> 50,- / Stück
1 RS485-RS232-Wandler 7,90
------------------
Gesamt unter 150,-
Es muss doch irgendein System mit ein paar Potis geben, dass man fertig
einsetzen kann.
Markus schrieb:> die großen Pulte von MA-Lighting, ChamSys, Avolite, Zero88,> ETC...
Ja,ja, die Viecher kosten zwischen 1.500,- und 15.000! Leicht an den
Erfordernissen vorbei. Die lassen sich das alle sehr gut bezahlen, wie
ich sehe.
Ich liebäugelte eigentlich mit dem Stairville DDC 6: Hat sogar eine
Anzeige für die Werte und liegt bei 39,- das Stück. Das ist angemessen,
für 7 Potis und einen mickrigen Controller.
Tobias N. schrieb:> Ja,ja, die Viecher kosten zwischen 1.500,- und 15.000! Leicht an den> Erfordernissen vorbei. Die lassen sich das alle sehr gut bezahlen, wie> ich sehe.
Du hast, ausser das du mit einem Regler die 16bit ausgeben willst, keine
weiteren Erfordernisse angegeben.
Wenn es unbedingt billigst werden muss kannst auch freie SW verwenden,
z.B. Freestyler und diese mit einem einfachen Midi-Controller steuern,
dann hast du auch was Physisches.
Die MIDI-Controller geben aber nicht die Präzision ab und die SW
erfordert wieder eine HW (PC oder Tablet) das nicht mit an die Anlage
verbaut werden kann. Deshalb mache ich das ja.
Momentan bin ich hier:
https://www.14core.com/wiring-multiple-sliding-potentiometer-on-microcontroller/
Kennt einer eine ARDUINO-ähnliche Plattform mit mehr als 4 ADC
Eingängen?
Wozu 16bit? Schon mal dir Gedanken gemacht das 16bit beim schiebe Poti
der an Vcc 3,3V oder 5V per ADC gewandelt wird für Steps heraus
bekommen? Das will ich sehen das du das halbwegs hinschiebst.
8bit reichen für einen Poti aus und der Rest wird interpolierter auf
16bit...
Brauchst Du wirklich 16Bit? Was für eine Anwendung ist das?
Ich brauche bei LEDs oft mehr als 8 bit PWM weil das Auge die Helligkeit
logarithmisch wahrnimmt. Aber wenn man das Potentiometer mit für das
Auge gefühlt gleichmäßig verteilten 256 Stufen belegt ist das mehr als
ein Mensch an so einem Potentiometer eigentlich einstellen kann.
Potentiometer -> 8 Bit DMX -> Empfänger -> Logarithmustabelle -> 16 Bit
PWM
das ergibt butterweiche Fades und auch in den unteren Reglerbereichen
schöne Farbübergänge.
Nochmal zum DMX-Protokoll:
Die Kanäle sind alle nicht indexiert, die angeschlossenen Geräte müssen
also alle Kanäle (=Bytes) mitzählen und sich die relevanten
herauspicken. Daher müssen immer alle Werte übertragen werden, egal ob
sie sich geändert haben oder nicht.
Es gibt aber inzwischen verschiedene hinzugekommene Features, so kann
z.B. die Übertragung eines Frames abgebrochen werden, also es brauchen
nicht alle 512 Kanäle gesendet zu werden. Dadurch erreicht man eine
höhere Framerate, aber langsame Geräte können Probleme haben wenn die
Frames zu schnell aufeinander folgen. Manche Geräte/Lichtpulte können
auch Daten über die DMX-Leitungen zum Pult zurücksenden, das war im
ursprünglichen alten DMX-512 nie vorgesehen.
DMX-512 wird auch nicht mehr so lange leben, da wird demnächst viel
durch Ethernet ersetzt.
Ben B. schrieb:> Manche Geräte/Lichtpulte können> auch Daten über die DMX-Leitungen zum Pult zurücksenden, das war im> ursprünglichen alten DMX-512 nie vorgesehen.
Wofür ist dann das zweite Signalpaar da? So wie ich das verstehe, kann
das beliebig benutzt werden, auch für einen Rückkanal? So war ein
Rückkanal zwar nicht vorgeschrieben, aber bedacht.
Ursprünglich war das zweite pair für den Rückkanal gedacht, wurde aber
nie umgesetzt. Es hielt kein Hersteller für notwendig. RDM war mit
damaligen CPUs die für die Geräte verwendet wurden undenkbar. Zumal
wurde das DMX Signal mit der SIO nur mit Tricks über externe Logik
erzeugt.
Das DMX Protokoll bleibt uns noch ewig erhalten, ARTNET transportiert ja
auch nur den Frame ;). Auch heute ist aus Kostengründen Ethernet viel zu
Aufwändig und die Verkabelung wäre über eine Switch er unpraktisch.
Corona Bedingt stirbt uns er der Anwenderkreis weg...
Ben B. schrieb:> DMX-512 wird auch nicht mehr so lange leben, da wird demnächst viel> durch Ethernet ersetzt.
Sehe ich eher nicht so
Marco H. schrieb:> Auch heute ist aus Kostengründen Ethernet viel zu> Aufwändig und die Verkabelung wäre über eine Switch er unpraktisch
Exakt. Wenn ich mir vorstelle, dass da 20 Geräte im Netzwerk
durchgeschliffen werden und man dann einen Farbwechsel machen möchte,
dann hat man allein schon durch die ganzen Switche in den Geräte einen
schönen Übergang. Aber niemals alles gleichzeitig...
Photonenschubser schrieb:> Exakt. Wenn ich mir vorstelle, dass da 20 Geräte im Netzwerk> durchgeschliffen werden und man dann einen Farbwechsel machen möchte,
Das ist eigentlich fast egal, wie viele Geräte eingeschleift (nicht
geschliffen :-) ) werden, weil wenn der Controller alle 512 Kanäle
sendet, ist die Datenrate immer unter 50Hz. Man kann ja die 250 kHz
nicht hochdrehen.
Das heisst man hat nur alle 20ms eine Übertragung. Damit scheidet das
Gerät leider aus.
So ein Quark... Ihr redet alle von PA-Technik anno 1980. Heute sieht das
alles deutlich anders aus, da wird sogar der Ton komplett digital über
Ethernet gemacht. Wenn alles ordentlich eingepegelt ist, schnappt sich
der Tontechniker heute ein Tablet, das per WiFi mit dem Mischpult
verbunden ist und macht den Mix vom Würstchenstand aus. Niemand rollt da
mehr ein x-Ader-Multicore aus - aus der Stagebox kommt ein Ethernetkabel
und das war's. Sogar die Endstufen sind oft schon per Ethernet
angebunden, sowas hat dann DSPs, update-able Firmware ... alles Dinge,
die die Welt nicht braucht, aber hat.
Die Lichttechnik entwickelt sich genau so weiter, bei mehr als 20..30
Geräten kommt man mit DMX-512 an die Grenzen. Ethernet ist dafür mehr
als schnell genug, erst recht wenn man über Switches geht und nicht von
Gerät zu Gerät durchschleift. Es gibt auch DMX über WiFi, wobei ich das
eher als Spielerei einschätze. Wer einmal damit Probleme mit Störungen
hatte, wird hinterher wieder ein Kabel benutzen.
Das zweite Daten-Adernpaar im DMX-Kabel würde ich als wilden Westen
beschreiben. Da haben alle verschiedene Dinge mit gemacht. Teilweise
wurde es als Rückkanal genutzt, teilweise als zweiter DMX-Port (so daß
man effektiv ein DMX-1024 hatte), viele Anwender haben auch einfach
drauf geschissen bzw. sich den teureren DMX-Stecker gespaart und DMX
über XLR geführt, so daß dieses Adernpaar bei diesen Anlagen gar nicht
verfügbar ist. Als besondere Sparmaßnahme wurde manchmal sogar das
DMX-Signal über's Audio-Multicore geschickt und der Tontechniker such
sich dann 'nen Wolf wo das Schnarren in den Mikros herkommt wenn das
nicht gut abgeschirmt war. Man munkelt, manchem Lichttechniker tut
deswegen heute noch der Arsch weh.
Das hast du ja jetzt ganz dolle beschrieben, was es so alles gibt, nur
leider hat das überhaupt gar nichts damit zu tun, mit welchem Controller
man regelmäßig und auf möglichst vielen Kanälen double prescision senden
kann.
Das war nämlich die Frage.
Tobias N. schrieb:> Das hast du ja jetzt ganz dolle beschrieben, was es so alles gibt, nur> leider hat das überhaupt gar nichts damit zu tun, mit welchem Controller> man regelmäßig und auf möglichst vielen Kanälen double prescision senden> kann.
Doch, hat er: Eben mit Geräten, die auf Ethernet aufsetzen statt auf
prähistischen Standards wie DMX.
> Das war nämlich die Frage.
Genau.
c-hater schrieb:> Doch, hat er: Eben mit Geräten, die auf Ethernet aufsetzen statt auf> prähistischen Standards wie DMX.
Das funktioniert aber nicht. Entweder braucht auch die Gegenstelle dann
Ethernet, und / oder das darin eingebackene DMX-Protokoll fährt trotzdem
seine 512 8-Bit Kanäle.
Das bringt mich keinen Schritt weiter. Ich möchte ja kein Licht steuern,
für das es sicher Geräte gibt, sondern mit RS485 auf technische
Einheiten gehen.
Es gibt genug RGB Controller für DMX, die 2 Kanäle für eine Farbe
verbraten (Highbyte, Lowbyte). So ein Scheinwerfer belegt dann eben 6
Kanäle.
Auch für die Positionierung von Scannern etc. werden oft 16-Bit Daten
gesendet.
Matthias S. schrieb:> Es gibt genug RGB Controller für DMX, die 2 Kanäle für eine Farbe> verbraten (Highbyte, Lowbyte). So ein Scheinwerfer belegt dann eben 6> Kanäle.
Natürlich. Aber wollte es ja nicht nur grundsätzlich haben (das ging ja
auch schon immer), sondern er wollte es auch noch mit hoher
Aktualisierungsrate haben. Und das geht halt nur, wenn man das
ursprüngliche physische Protokoll wegwirft, ansonsten ist man natürlich
an dessen Beschränkungen bezüglich des möglichen Durchsatzes gebunden.
Tobias N. schrieb:
Das funktioniert aber nicht. Entweder braucht auch die Gegenstelle dann
Ethernet
Natürlich, das ist ja klar.
> und / oder das darin eingebackene DMX-Protokoll fährt trotzdem> seine 512 8-Bit Kanäle.
Das ist Quatsch. Man konnte schon immer die grundlegenden DMX-Kanäle
logisch zu breiteren Kanälen kombinieren. Es gibt unzählige Anwendungen,
die das nutzen, sowohl über den klassischen PHY als auch über Ethernet.
DMX ist im Kern einfach der Austausch von Datenpaketen variabler Länge,
deren Breite "out of band" signalisiert wird.
Im Falle des klassischen PHY halt über den BREAK-Mechanismus, im Falle
von Ethernet steckt diese Information im IP-Protokoll. Auf der
DMX-Protokoll-Ebene wird das dann gleich. Die kriegt eine Datenpaket
bekannter Größe, ganz egal, über welchen physischen Weg das angeliefert
wurde.
> sondern mit RS485 auf technische> Einheiten gehen.
So lange du den klassischen DMX-PHY benutzen willst, bist du halt
bezüglich der Update-Rate daran gebunden, was das leisten kann. Die
logische Kombination von Kanälen ist eine reine Software-Sache, hat mit
RS485 vs. Ethernet überhaupt nichts zu schaffen.
Hallo Tobias,
bezüglich DMX wurde ja schon eine Menge geschrieben.
Offensichtlich benötigst du für deine Anwendung 6 Funktionskanäle mit je
wenigstens 12 Bit Auflösung.
Sendeseitig soll per Potis [1] eingestellt werden, wofür dann im
einfachsten Fall A/D-Wandlungen mit 12 Bit Auflösung für die
Poti-Stellung nötig wären.
Ist der DMX-Sender völlig eigenständig oder hat er noch eine
Schnittstelle zu einem anderen Gerät?
Wie es empfangsseitig ausschaut, hast du noch nicht beschrieben. Ist es
ein einziger Empfänger, der die 6 Funktionskanäle auswertet oder sind es
6 separate Empfänger, die am gemeinsamen DMX-Bus hängen?
Um welche Art von Signalen handelt es sich?
Offensichtlich muss immer volle 12-bit-Auflösung übertragen werden (und
nicht per nichtlinearer Kennlinie).
Unabhängig davon kann man per DMX-Protokoll beliebige Auflösungen
übertragen, indem man entsprechend viele 8-bit-DMX-Kanäle zu einem
Funktionskanal zusammenfasst.
Dann muss man eben empfangsseitig die einzelnen DMX-Bytes aus dem
DMX-Paket herausfischen und zu einem höher aufgelösten Funktionskanal
zusammenfassen.
Das DMX-Protokoll verlangt keinesfalls, dass immer alle 512 Kanäle zu
übertragen sind (wurde ja schon geschrieben).
Für nur sechs 12-bit-Daten reichen zusammen mit dem Startbyte wenigstens
13 DMX-Kanäle, zzgl. bei Bedarf noch ein paar weitere Kanäle für zu
übertragende Kommandos an die Empfänger. Entsprechend hoch ist die
Wiederholrate.
Allerdings sendet DMX normalerweise die Anzahl der festgelegten
DMX-Kanäle immer vollständig in aufsteigender Kanal-Reihenfolge bis zum
letzten festgelegten Kanal.
Natürlich müssen die DMX-Empfänger diese verkürzten DMX-Pakete für
optimalen Betrieb auch richtig auswerten können (und nicht immer 512
Bytes abwarten).
Fazit: Mir scheint das DMX-Protokoll durchaus für deine Anwendung
geeignet, falls die Wiederholrate ausreicht.
Allerdings gibt es für maximale Performanz m. W. nichts Bezahlbares von
der Stange. Deshalb würde ich wenigstens den DMX-Sender und vermutlich
auch die DMX-Empfänger selbst entwickeln.
Und dann könnte man sogar ein völlig eigenes optimal kurzes Protokoll
festlegen und nur geänderte Daten übertragen, wie z. B.:
Startbyte + ein Byte mit Anzahl der zu übertragenen Funktionskanäle +
Byte mit Nr. eines beliebigen Funktionskanals + 2 Bytes zugehörige Daten
+ Byte mit Nr. des nächsten Funktionskanals + 2 Bytes zugehörige Daten,
etc.
Allerdings benötigt man damit bei Übertragung aller 6 Funktionskanäle
(falls sich alle gleichzeitig geändert haben, was eher unwahrscheinlich
ist) bereits 20 Bytes statt sonst 13 Bytes, bei einem einzigen
Funktionskanal aber nur 5 Bytes.
Mit zwei Händen bedient man normalerweise nur zwei Potis. Dann wären es
maximal 8 zu übertragende Bytes pro DMX-Paket.
Und so schnell kann man 6 Potis gar nicht bedienen, dass die
Wiederholrate zu einem Problem werden würde. Noch wissen wir nicht, was
damit angesteuert werden soll ...
[1] Mit Drehgebern (die natürlich teurer sind) könnte man auf die
A/D-Wandlungen verzichten, benötigt dann aber geeignete Decoder
(Hardware oder Software). Vorteil wäre, dass man damit problemlos
höherere Auflösungen realisieren kann als mit Potentiometern (10 Bit
sind mit einem "normalen" Poti bereits grenzwertig, 12 Bit erst recht).
Nachtrag: Da eine variable DMX-Paketlänge bei wenig zu übertragenden
Bytes aber nur wenig Zeitvorteile bringt (wenn überhaupt), sollte man
bei sensiblen Daten bei der konstanten Paketlänge bleiben, bei der immer
alle Daten wiederholt werden.
Wenn bei der Wiederholrate aufgrund des verkürzten (aber konstanten)
DMX-Pakets noch Spielraum ist, könnte man sogar über ein abschließendes
Prüfbyte als letzten DMX-Kanal nachdenken.
Bei der Berechnung der Wiederholrate darf man natürlich das Break-Signal
(und ggf. Pausen) nicht vergessen.
In den Specs zu DMX steht ein Minimum von 26 Kanälen, wimre. Damit
müssen alle DMX Receiver klarkommen - soweit ich das ausprobiert habe,
tun die meisten das auch. Repräsentativ war dieser Test aber nicht.
Seine Anwendung ist ja zunächst kein Standard-DMX.
Wenn ein DMX-Empfänger von der Stange seine Anforderungen bezüglich
ausreichend Doppel-Bytes erfüllt, muss natürlich auch überprüft werden,
wie schnell die DMX-Pakete für diesen DMX-Empfänger nacheinander kommen
dürfen.
Es gibt nur eine DMX-Mindestanforderung für die Break-to-Break-Zeit von
ca. 1,2 msec, also etwa 27 Byte-Zeiten. Abzüglich 3 Byte-Zeiten für
Break und Start-Byte wären das dann mindestens 24 freie Daten-Bytes.
Oder anders ausgedrückt: ca. 1,2 msec entsprechen einer Wiederholrate
von mehr als 830 Hz.
Wenn das Tobias für seine Anwendung genügt, sind seine 12 Daten-Bytes
locker abgedeckt.
Wenn nicht, wird es auf einen selbstgestrickten DMX-Empfänger
hinauslaufen, der mit kürzeren Break-to-Break-Zeiten klar kommt. Und das
sollte eigentlich kein Problem sein.
Die relativ neue AVR-DB-Serie (als sehr kleines Kit: EV35L43A) z. B. hat
einen 12-bit-A/D-Wandler, der per Multiplexer je nach Gehäuse 10-22
Analogkanäle (und natürlich auch Poti-Stellungen) abtasten kann.
Ein DMX-Sender und viele andere Funktionen fallen nebenbei mit ab ...
Matthias S. schrieb:> Es gibt genug RGB Controller für DMX, die 2 Kanäle für eine Farbe> verbraten (Highbyte, Lowbyte). So ein Scheinwerfer belegt dann eben 6> Kanäle.
du hast den sinn und Zweck der Frage noch immer nicht verstanden. Ich
brauche keinen 2-Kanal DMX mit Bündelung zu 16 Bit sondern einen
mehrkanligen Datencontroller, z.B: 16 Kanäle mit jeweils 16 bit. Also
ALLE.
Eberhard H. schrieb:> wie schnell die DMX-Pakete für diesen DMX-Empfänger nacheinander kommen> dürfen.
Schneller, das DMX senden kann. Das wurde gecheckt. Die Übertragung
aller 512 Kanäle dauert 50ms. Ich kann die 250kbps mit mehreren Kanälen.
Benutzt wird z.B. ein RS485-Wandler auf single ended TTL mit 3,3V. Ich
könnte alle 16 Controller parallel anschließen und eintakten.
Eberhard H. schrieb:> Ein DMX-Sender und viele andere Funktionen fallen nebenbei mit ab ...
Inwiefern?
