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.
:
Bearbeitet durch User
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?
Die Mikrocontroller auf den Arduino-Boards haben doch alle min. 8 Analogeingänge - die aber nur mit 10bit Auflösung.
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.
Aber der Poti ist kein Stellwertgeber? Steht doch schon oben 8bit einlesen und auf 12 oder 16bit interpolieren.
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.
Tobias N. schrieb: > Kennt einer eine ARDUINO-ähnliche Plattform mit mehr als 4 ADC > Eingängen? https://www.ti.com/tool/EK-TM4C1294XL https://www.ti.com/lit/ug/spmu365c/spmu365c.pdf und dann entweder mit dem CCS und TIVAWARE oder mit Energia. fchk
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.