Hallo, beim letzten µC-net-DD-Stammtisch [1] kam die Idee auf, mit 802.15.4 Transceivern DMX Daten zu ubertragen und dann ggf. auch zu Sniffen und mit einem Tool wie Wireshark zwecks Debugging anzuzeigen. (Ich habe das Thema hier erstellt, da der Fokus auf DMX und nicht auf der Funkschnittstelle liegen soll.) Die Brutto-Datenrate von 15.4. mit 250kbit/s reicht nicht aus, um die Wired Daten, die mit 250kbit/s ueber die RS485 gesendet werden, zu uebertragen. Die Daten muessen irgendwie gepackt werden. Im uC-net-DD Thread wurden bereits LZW genannt, dass gut funktionieren duerfte, da die DMX-Daten wohl sehr redundant sind. Meine Idee waere, da die 15.4-Frames nur max. 127 Byte lang sind und davon noch > 11 Byte fuer Header + CRC16 abgehen, folgendes Format zu waehlen: "Kanaloffset, Kanalmaske, Wert, Wert, Wert ..." Wobei Kanaloffset den Startkanal angibt, und in der Kanalmaske die Bits gesetzt sind, fuer die nachfolgenden Werte gelten. Damit wuerde "0x2a,0x0000003,42,43" bedeuten, setze in Kanal 42 den Wert 42 und in Kanal 43 den Wert 43. Um die Effizienz der Packalgorithmen zu testen und zu vergleichen waere es schoen, wenn man irgendwoher DMX-Mitschnitte mit dem zugehoerigen Szenario bekommen koennte. [1] Beitrag "µC.net-Usertreffen Dresden"
Axel Wachtler schrieb: > Im uC-net-DD Thread wurden bereits LZW genannt, dass gut funktionieren > duerfte, da die DMX-Daten wohl sehr redundant sind. Warum sollte das gut Funktionieren? LZW ist für Streams nicht wirklich gut geeignet, da es die Tabellen erst aus dem Datenblock berechnet, dann komprimiert, und nun beides zum anderem Teilnehmer übertragen wird. Wenn man bei den DMX Daten wirklich eine Statistische Verteilung kennt könnte man Huffman (oder je nach Aufwand sogar adaptiver Huffman) fahren.
Hallo Axel, möchtest Du wirklich DMX mit Funk übertragen??? DMX wird ja üblicherweise für den Veranstaltungsbereich verwendet. Beim Aufbau/Einrichten wird das sicher prima funktionieren. Nur irgendwann kommen dann ganz viele Leute mit Handys in den Taschen, die ganz heftig über Bluetooth und WLAN senden. Du findest im Web viele Erfahrungsberichte aus diesem Bereich, wo dann bei Veranstaltungsbeginn die Funkreichweiten auf wenige Meter zusammengebrochen sind.
>möchtest Du wirklich DMX mit Funk übertragen???
Naja, man muss sich ja nicht gleich in die verseuchtesten
Funk-Gebiete vorwagen, bei Massenparties ala Mayday
verbietet sich sowas tatsaechlich. Aber vielleicht kann man
ja in dem einen oder anderen PartiyKeller ein wenig Kupfer
einsparen.
Für kleine Partykeller bietet sich auch optische kommunication an. Laser, IR. Ist ja nur eine Richtung, also sehr leicht aufzubauen.
ZZZ schrieb: > Hallo Axel, > > möchtest Du wirklich DMX mit Funk übertragen??? > > DMX wird ja üblicherweise für den Veranstaltungsbereich verwendet. Beim > Aufbau/Einrichten wird das sicher prima funktionieren. Nur irgendwann > kommen dann ganz viele Leute mit Handys in den Taschen, die ganz heftig > über Bluetooth und WLAN senden. Du findest im Web viele > Erfahrungsberichte aus diesem Bereich, wo dann bei Veranstaltungsbeginn > die Funkreichweiten auf wenige Meter zusammengebrochen sind. Du hast im Prinzip recht. Normaler Weise benutze ich WLAN zum Einstellen, wobei der Sequenzer dann im Betrieb in einem Schaltschrank haengt und alles fest verstrippt ist. Ausserdem gibt es Funkstrecken zu kaufen. Dem Axel gehts aber ums Basteln ;o)) Da es ja kein Kommerzielles Produkt sein soll wuerde ich folgendes zum Packen vorschlagen: - Nullen Weglassen, d.h. ein Wert nach der Null sagt wie oft die Null wiederholt wird. Das greift oft am Ende des Frames, da idR die Universen nicht vollgepackt werden. Wird es Eng, nimmt man gleich 2 Stueck, was im Privatbereich eh kaum vorkommt. (vielleicht auch das immer mehr als 3 Nullen codiert werden, ?-0-?; 0-0-? wird normal benutzt, erst die 3. folgenull ist die Zaehlbedingung ?-0-0-0-12-? heisst, 12 weitere nullen inkl der aktuellen) - sollten die Nullen mal nicht ausreichen, dann wird einfach Lag eingebaut, in dem Sinne, das so lange zwischengespeichert wird bis der Puffer mit einem Frame gefuellt ist, dann wird dieses Frame einfach verworfen. - das geraet muss zwindgend auch mit kuerzeren Universen klarkommen koennen und dann auch die ggf. hoehere Framerate benutzen. Damit hat man, sofern genug nullen da sind, ein geringeres Lag als wenn man erst ein komplettes Frame empfangen muss. Ab und an mal ein fehlendes Frame, wird nicht so oft stoeren. bye uwe
Axel Wachtler schrieb: > "Kanaloffset, Kanalmaske, Wert, Wert, Wert ..." > > Wobei Kanaloffset den Startkanal angibt, und in der Kanalmaske > die Bits gesetzt sind, fuer die nachfolgenden Werte gelten. Damit wuerde > "0x2a,0x0000003,42,43" bedeuten, setze in Kanal 42 den Wert 42 und > in Kanal 43 den Wert 43. > > Um die Effizienz der Packalgorithmen zu testen und zu vergleichen > waere es schoen, wenn man irgendwoher DMX-Mitschnitte mit dem > zugehoerigen Szenario bekommen koennte. Hmm, wenn der Lightcorder nicht geklaut waere, dann haette ich welche ;o))) Reicht denn eine tabellarische Auflistung der verwendeten Kanaele mit beispielhafter Information was sich so gemeinsam aendert? Wahrscheinlich ist es doch am besten von 432 sich vollkommen Konfus aendernden Werten auszugehen. Das waere eine 12x12 RGB-Matrix mit wolkigem, schmierigem Motiv. 13x13 Matrix ist sicher Untypisch und 14x14 reicht eh nicht. Ein Movinghead braucht so 12-40 Kanaele, je nach Typ. Das ist teurer als der Partykeller ansich, wenn das Universum voll werden soll ;o)) Ich denke, der am haeufigsten am Stueck vorkommende Wert ist die Null. bye uwe
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.