DMX Signalgeber & Tester

  • Hallo zusammen!


    hat von euch schonmal jemand versucht sowas in der Art selbst zu bauen?


    http://www.swisson.com/new/Ger…ts/x-mt-120/xmt_index.htm


    Der Preis ist nämlich meines erachtens für den "Kleinkram" deutlich überteuert (Belehrt mich gerne eines besseren :D ). Ich habe einen Bekannten der die alte Version davon hat. Und die ist schon vollkommen ok.


    ich bin auf der Suche nach ner Vorlage auf diese Site gestoßen:


    http://hoelscher-hi.de/hendrik/wahl.htm


    ich denke mal mit dem Analyzer könnte man auf jeden Fall schonmal was anfangen. Mein Problem ist halt das löten und Fehlersuche kein Problem sind ich aber bei der weiteren Programmierung (Signalgebung, aber ich glaub die groben Voraussetzungen existieren in dem System von Henne schon, gibt ja nen Testlauf-Modus) aufgeben müsste.


    Gibts vielleicht schon ein Projekt dieser Art? Bei der Suche bin ich leider weder im Netz noch hier auf vergleichbares gestoßen.

  • warum, was soll das den kosten? sieht mir nach einem grafischen LCD aus, das ist schonmal teurer und aufwändiger, als ein alphanumerisches. Ich habe sowas mal gebaut, damit konnte man Einleuchten, DMX-Signale checken, splitten, mergen und ein paar Szenen abfahren. Bis man sowas aber in ein hübsches Gehäuse gebastelt hat mit allem drum und dran, ist man an Material auch ~100EUR los.
    HTH
    Carsten

  • Also ein Grafisches Display ist ja gar nicht nötig. Alpha-Num. würde vollkommen ausreichen. Das was du gebaut hast hört sich durchaus brauchbar an. Du hast nicht zufällig davon noch die Pläne? Splitten und Mergen wäre nicht unbedingt notwendig aber wenn es das kann auch nicht zu verachten.


    Das Gerät soll 400 Euronen kosten und für 300 EUR Unterschied begebe ich mich gerne ans löten.


    Also wie gesagt, wäre super wenn du nen Ätz- und Bestückungsplan hättest. Ich schau mir auch immer gerne Bilder des Geräts an!


    Gruß
    André

  • das war damals meine Technikerarbeit. Ist dementsprechend dilletantisch programmiert und layoutet. Müsste man also schon nochmal drübergucken. Wenn ich nun einfach in etwa wissen würde, was man denn "im Feld" wirklich braucht, könnte man mit einem quasi-Pflichtenheft sicherlich ein Forums-Projekt draus machen. Schließlich wirds ja schon wieder kälter und man sucht wieder Beschäftigung indoor.
    Carsten

  • Also prinzipiell ist das:


    http://hoelscher-hi.de/hendrik/light/dmxanalyzer.htm


    schon eine super Sache, das einzige was es dann noch können muss ist per Tastenwahl einen DMX-Kanal auswählen und den dann auch nochmal per Taste auf 100 oder x Prozent zu setzen.


    Also es dürften auch 2 seperate Geräte sein.
    ich würd mir den von henne als Analyzer so bauen.
    Als weiteres Gerät bräuchte man dann einen Sender.


    Im selbst programmieren bin ich aber sehr untalentiert. basic und visual basic in den "basics".


    Sender müsste normalen Num-Block besitzen der ungefähr so aussieht:


    ______________________________
    < + -
    zurück and thru except
    ______________________________


    7 8 9 FULL
    ______________________________


    4 5 6 50%
    ______________________________


    1 2 3 @
    ______________________________


    0 ENTER
    ______________________________



    Irgendwelche Ideen?


    edit: meine leerzeichen wurden gestohlen.

  • Im Prinzip ist das alles kein großes Ding, es gibt sowohl für DMX-Empfang als auch fürs Senden fertigen udn frei zugänglichen Code und Beschaltung für gängige µCs (AVR/PIC), das einzige was dann noch bleibt wäre die Ausgabe und Bedienung des Teils und das bißchen Hühnerfutter drumherum 8)


    Was ich interessant finden würde wäre das Teil sehr klein und trotzdem "full-featured" zu bauen...das Swisson-Teil ist ja nach den Totschlägern von früher (die die Abmaße einer mittleren Bibel hatten... :shock: ) schonmal ein Schritt in die richtige Richtung, ich persönlich würd es aber noch weiter treiben...das schwierigste daran wird vermutlich ein schlüssiges Bedienkonzept und eben den doch recht sperrigen DMX-Stecker/Buchse unterzubringen...


    Grüße
    phlo


    EDIT: Noch ne bessere Idee, wie wärs mit nem DMX-Seriell-Interface für Handies und passender J2ME-Software dazu? :D DAS wäre mal schick...

  • Zitat von &quot;phlo&quot;


    EDIT: Noch ne bessere Idee, wie wärs mit nem DMX-Seriell-Interface für Handies und passender J2ME-Software dazu? :D DAS wäre mal schick...


    Leider untersützen die meisten Handys heute nur noch Divice Anwendungen, mir wäre keines bekannt, dass eine Host funktion hat.

  • Verstehe nich ganz worauf du hinaus willst, Host/Device ist denke ich eher ein USB-Thema oder? Die klassische serielle Schnittstelle ist bei vielen Mobiltelefonen auch nach aussen geführt, das ist halt in J2ME nicht ganz so einfach, da wär C++ eher gut, aber dann is Essig mit der Cross-Plattform-Kompatibilität...


    Ich dachte aber der Einfachheit halber (um auch nicht 1000 verschiedene Stecker für die Handytypen zu brauchen) sowieso eher an das hier:


    http://www.it-wns.de/data/datenblatt_0000012_1.pdf


    Konvertiert quasi transparent zwischen Bluetooth und seriell. Da noch einen AVR dran der entsprechend der über BT reinkommenden Befehle DMX erzeugt oder ausliest, und eine schöne J2ME-Software, und schon sollte das mit einem Großteil der Handies laufen. Kosten <=50€!!


    Grüße
    phlo

  • Jo, die die eine serielle Schnittstelle in Hardware haben und auch nach außen führen sind in der Tat recht selten, aber ich hatte wie gesagt dabei auch eher eine "virtuelle" RFCOMM-Bluetooth-Schnittstelle im Hinterkopf. Seriell aber dennoch trotzdem weil es beidseitig transparent nach einer seriellen Schnittstelle aussieht wenn man das BT-222-Modul benutzt (auf Handyseite die J2ME-RFCOMM-API, auf Interfaceseite UART).


    Wenn man das dann mit nem ordentlichen Handy kombiniert und ein brauchbares Protokoll für die Bluetoothverbindung benutzt, kann man z.B. das Interface irgendwo in die Dimmercity in die DMX-Schleife packen und in 50m Umkreis drahtlos im Rigg rumklettern zum Einleuchten ;) Und das auch ganz ohne GMA mit WLAN/Artnet...


    Grüße,
    phlo

  • Zitat von &quot;LC2412&quot;

    ich bezweifel, dass man mit den Bluetooth/Serial Bausteinen 250kBits hinbekommt. Schon mal probiert?


    Musst du ja auch gar nicht, wenn du das Handy nur als Bedienoberfläche für einen einfachen "DMX-Generator" verwendest. Klingt irgendwie nach einem netten Selbstbauprojekt – weil relativ unkompliziert, aber ziemlich nützlich.


    Wobei wohl viele Handy-Tastaturen zu kleine Tasten haben, um während des Einleuchtens angenehm bedienbar zu sein...

    Einmal editiert, zuletzt von klickverbot ()

  • Zitat von &quot;klickverbot&quot;


    Musst du ja auch gar nicht, wenn du das Handy nur als Bedienoberfläche für einen einfachen "DMX-Generator" verwendest. Klingt irgendwie nach einem netten Selbstbauprojekt – weil relativ unkompliziert, aber ziemlich nützlich.


    Das ist der Punkt - du musst erstens niemals sämtliche DMX-Werte auf einmal ändern vom Handy aus (macht ja auch keinen Sinn). Das 1. Stichwort ist also der erwähnte Generator. Vom Handy dorthin werden nur Änderungen übertragen, den Rest macht der µC. Du hast ja auf dem Handy sicherlich nicht vor hochkomplizierte Chases und Sequenzen zu fahren die die Verbindung da auslasten...
    Zweitens hast du durch relativ leistungsstarke Hardware auf beiden Seiten die Möglichkeit, die vollständigen DMX-Daten runterzukomprimieren auf sicherlich weniger als 25% der ursprünglichen Datenmenge, was auch die nötige Datenrate viertelt. Diese Anwendung kommt dir insbesondere bei der Analyzer-Funktion entgegen, da es hier sicherlich auch ganz interessant wäre, mal einige mehr Kanäle simultan im Auge zu behalten. Da aber das menschliche Auge eh träge ist, würde es auch hier vermutlich ausreichen, nur jeden 10ten DMX-Refresh überhaupt aufs Handy zu schicken, was die Datenrate auch nochmal auf ein Zehntel schrumpfen lässt. Kombiniert mit der Lauflängenkodierung könnte man denke ich auf eine Datenrate von gut unter 10kbit im Analyzermodus, unter 1kbit im Steuermodus und entsprechend immer noch ordentlich unter 15kbit im Dual/Kombimodus machen...sind natürlich alles theoretisch und fast overheadfreie Rechnungen, aber die Dimensionen passen!


    Zitat von &quot;klickverbot&quot;


    Wobei wohl viele Handy-Tastaturen zu kleine Tasten haben, um während des Einleuchtens angenehm bedienbar zu sein...


    Nunja, kommt aufs Handy an - die mittlerweile weit verbreiteten Smartphones (insbesondere mit Touch-Funktionen) dürften da schon einen ganz guten Komfort bieten. Für reine Tastenfeld-Phones wäre zumindest eine minimalistische Bedienung auch ganz brauchbar (so in die Richtung 4 und 6 ändern den Kanal, 2 und 8 die Helligkeit, 1 FullOn, 7 Blackout, 3 fürs Umschalten zwischen Fein- und Grobeinstellung usw.) - das dürfte auch mit ner Minitastatur immer noch besser kommen als immer wieder runter von der Leiter :wink:


    Was das Projekt allgemein angeht, wird das jetzt doch zunehmend interessant, mal schauen ob sich da noch mehr Leute dafür begeistern können. Müsste eigentlich echt schnell und einfach umsetzbar sein!


    Grüße,
    phlo

  • Interesand ist Projekt auf jeden Fall!


    Allerdings kann ich leider nicht wirklich helfen, da ich vom Programmieren null Ahnung habe.


    Bei elektrischen Messung kann ich allerdings helfen, da fehlt es mir an fest nichts...

  • Zitat

    Müsste eigentlich echt schnell und einfach umsetzbar sein!


    Na dann mal los :D


    Ich brauchte schon über einen Monat für meinen Analyzer - allerdings waren da auch noch LCD-Lib und Menüführung dabei...
    Das könnte auf Handy-Seite einfacher ausfallen.


    Datenreduktion:
    Es werden nur die angezeigten Kanäle an das Handy übertragen mit einer sinnvollen Frequenz (ca. 15Hz).
    Weitere Kompressionen bei binären Daten halte ich nicht für sinnvoll.


    In Gegenrichtung werden nur zu ändernde Kanäle übertragen.


    Was noch sinnvoll wäre:
    RDM-Controller (Paketdekodierung auf Handy, Discovery und Message-Buffer auf AVR)


    Geräte-Libraries (zum Testen von Movinglights)



    Offengestanden habe ich aber momentan eher das Gefühl, dass hier alle nur reden und hoffen, dass andere loslegen :wink:


    Bis die Hardware und die Grundfunktionalität steht, bleibe ich daher bei meinem Analyzer und schau Euch interessiert zu.


    Viel Erfolg,
    Hendrik

  • Hab ich das jetzt richtig verstanden dass über das interne Bluetooth-Modul eines Handy Daten ausgegeben werden die dann von diesem selbstgebauten Gerät empfangen, in DMX umgewandelt und dann in den DMX Bus eingeschliffen werden? Es zaubert irgendwie ein riesiges grinsen auf mein Gesicht wenn ich mir vorstelle das ich mit meinem iPhone im Rigg sitze und darüber die Lampen umschalten kann um einzuleuchten. Da besteht doch großes Interesse an diesem Projekt, auch wenn ich selber leider ncihts dazu beitragen kann, da ich von programieren keine Ahnung habe.

    Gebt mir Steine! Ich besitze kein Behringer-Gerät mehr :D

  • Zitat von &quot;Michael Quatmann&quot;

    Hab ich das jetzt richtig verstanden dass über das interne Bluetooth-Modul eines Handy Daten ausgegeben werden die dann von diesem selbstgebauten Gerät empfangen, in DMX umgewandelt und dann in den DMX Bus eingeschliffen werden? Es zaubert irgendwie ein riesiges grinsen auf mein Gesicht wenn ich mir vorstelle das ich mit meinem iPhone im Rigg sitze und darüber die Lampen umschalten kann um einzuleuchten. Da besteht doch großes Interesse an diesem Projekt, auch wenn ich selber leider ncihts dazu beitragen kann, da ich von programieren keine Ahnung habe.


    Jup - exakt erfasst. Man könnte es sogar noch allgemeiner fassen und sagen, wir wollen ein DMX-Interface mit DMX-In und DMX-Out und Bluetooth-Anbindung bauen. Ob das nun nachher an deinem IPhone zum Einleuchten hängt oder am Laptop mit ner Lichtsteuersoftware ist eigentlich egal. Das einzige Problem ist dass es evtl. mit der Performance beim Betrieb an einer Lichtsteuersoftware eng wird. Aber für einfache Geschichten geht das auch...


    @ Henne: Jo, das mit dem "einfach" ist natürlich relativ. Aber fürn µC-Projekt ist es im Prinzip schon einfach, weil a) sämtliche Entwurfsprobleme bereits irgendwo gelöst existieren (DMX und BT-Modulansteuerung) - die bei Standalonegeräten nervigen Sachen wie die Menüführung und LCD-Ansteuerung kann hier komplett in einer Hochsprache erledigt werden (Java/J2ME oder aufm Laptop/Rechner auch was anderes was Zugriff auf das SPP des BT-Anschlusses erlaubt, bzw. mit einem virtuellen COM klarkommt).
    RDM ist zumindest für mich aber fast komplettes Neuland, also hierzu mal kein Kommentar. Vielleicht später dann :wink: ...


    Dein Gefühl trügt dich in dem Fall auch nicht ganz, ich find das ganze zwar extrem interessant und bin auch gewillt das mal anzugehen, aber im Moment fehlt mir a) die Kohle für all die benötigten Bauteile, b) überhaupt irgendwelche DMX-fähigen Geräte die ich in Beschlag nehmen könnte für die Entwicklung (brauche ja dann min. 1 Controller & 1 steuerbares Gerät) und c) die Zeit. Bin leider nach wie vor Teilzeit-VTler mit Hauptberuf Student (noch dazu mit Prüfungen im Moment, hat aber immerhin auch mit µCs etc. zu tun), und hab da keinen eigenen Materialpark, und meine Stammverleiher werden mir auch nicht wochenlang ihr Zeug für Basteleien überlassen :( Aber falls sich jemand angesprochen fühlt und noch altes Material am Lager vergammeln hat :wink: ...

  • Zitat von &quot;Henne&quot;

    Offengestanden habe ich aber momentan eher das Gefühl, dass hier alle nur reden und hoffen, dass andere loslegen :wink:


    Das hast du zielsicher erkannt ;)


    Wenn sowas wirklich "mal schnell nebenbei" entwickelt wäre, dann würden wohl schon viele Leute damit herumlaufen. Mein Kommentar von oben bezog sich eher darauf, dass bei einem Projekt, dass auf etablierten Standards wie DMX (und verfügbaren Lösungen) meist leichter überschaubar sind als zum Beispiel Experimente mit Billig-Funkmodulen. Was aber nicht heißen soll, dass es nicht auch unerwartete Probleme bezüglich Kompatibilität geben könnte/wird.


    Zum Thema Einschleifen in den DMX-Bus: Dazu müsste das Gerät möglichst in Echtzeit ein DMX-Universum dekodieren und wieder auf die Reise schicken. Wie viel Rechenleistung ist nötig, um das mit einer vertretbaren Refresh-Rate bewältigen?


    Wobei ich mir nicht sicher bin, ob ein DMX-In überhaupt nötig wäre, nach dem Einleuchten muss das Ding sowieso wieder weg...

  • Zitat von &quot;klickverbot&quot;

    Zum Thema Einschleifen in den DMX-Bus: Dazu müsste das Gerät möglichst in Echtzeit ein DMX-Universum dekodieren und wieder auf die Reise schicken. Wie viel Rechenleistung ist nötig, um das mit einer vertretbaren Refresh-Rate bewältigen?


    Wobei ich mir nicht sicher bin, ob ein DMX-In überhaupt nötig wäre, nach dem Einleuchten muss das Ding sowieso wieder weg...


    Das sollte mit einem, im schlimmsten Fall zwei halbwegs kraftvollen aktuellen µC locker zu schaffen sein, ist ja im Prinzip nix anderes als simples Merging. Die Jungs von DMX4All haben das offenbar auch auf einem µC geschafft. Und der DMX-In ist an sich schon sinnvoll wenns auch ein Analyser sein soll :wink:. Aber man könnte ja falls es je doch zu aufwendig werden würde über eine Beschränkung der Modi nachdenken, so dass entweder Analyzer- oder Controllerbetrieb möglich ist, aber nicht beides gleichzeitig. Das haut dann auf jeden Fall hin.