Beiträge von phlo

  • DMX-Nachfolger?

    So, dann will ich mich mal rückmelden...vielen Dank an alle bisher schon einmal, es waren schon einige wertvolle Anregungen dabei über die ich mir bisher noch keine Gedanken gemacht hatte. Ich will versuchen jedem von euch ne kurze Rückmeldung zu geben (es darf aber gerne auch noch mehr kommen, ich bin dankbar für alles!):

    @ Arno: Der Kostenfaktor ist natürlich unabsprechbar. Aber es geht auch nicht darum zusätzliche Hardware zu DMX zu haben, sondern einen vollwertigen Ersatz. Und ich denke durchaus, dass die Teilekosten nicht höher sein müssen als [Verkabelungskosten geteilt durch Anzahl der DMX-Einheiten] bzw. einfach ca. 2 gute Neutrikstecker und n Stück ordentliches DMX-Kabel pro Einheit. Das lässt der Stand der Technik durchaus zu. Was das Kanalmanagement angeht, das ist mir fast schon zu detailliert...es gibt mit Digitalmultiplexverfahren aber auch wirksame Möglichkeiten, da ein wenig Abhilfe zu schaffen. Frequenzvergabe wäre natürlich ein weiteres Thema. Eine Fallbacklösung allerdings wird schwierig...das Netz soll aber tendentiell so arbeiten dass es keine direkten Single Points of Failure gibt.
    Du bist auch mit dem Wikipedialink zu den MANETs schon recht nah dran an dem Forschungsgebiet in dem das Projekt ablaufen soll...allerdings wäre für den konkreten Fall wohl kein klassisches Multi-Hop-MANET Mittel der Wahl, das müsste man ein wenig anders lösen. Und es sollte auch für den Bediener transparent sein, d.h. funktionierend out-of-the-box. Ein wenig Computer-Grundwissen braucht in Zukunft eh jeder Techie...oder eben TomyN's Lösung. Sehe ich ähnlich...

    ljbigfish: Die verwendete Technik für automatisches Routing und Adressierung ist nicht festgelegt. Es wird aber auf jeden Fall so organisiert dass solche Fehler berücksichtigt sind. Denkbar wäre z.B. eine Lösung über verschiedene virtuelle "Kreise", denen man die gefundenen Geräte zuordnen kann, oder zusätzlich eben auch über die räumliche Anordnung. Das Positionierungsfeature ist nicht nur ein Gimmick, sondern ein Teil der Grundfunktionen und auch eine der großen Innovationen des Systems. So kannst du ja dann einfach aufm Notebook die Geräte deiner Stage markieren, Markierung umkehren, löschen, fertig...steht aber wie gesagt alles noch in den Sternen.

    nitrox: ACN hab ich mir jetzt mal angeschaut, aber da sind wir ähnlicher Meinung - ich sehe hier (ausnahmsweise!) keine wirkliche Zukunft für eine solche offene XML-basierte Lösung, vor allem wenn es auf reibungslose Interoperabilität ankommt.
    Was das Routing der Informationen angeht (wer bekommt welche Infos), das wäre im Prinzip auch schon eher ein Detail, wenn ich die Infos erstmal zentral vorliegen hab kriegt die wer will :D
    Was die Störsicherheit angeht und die verfügbaren Kanäle, so ist das wie oben erwähnt ja dann ein Gegenstand des Projekts, aber ich sehe da durchaus Möglichkeiten, zumal wir es ja mit extrem niedrigen Datenraten für heutige Verhältnisse zu tun haben.
    Auch die Paketorientierung etc. ist ebenfalls etwas, was dann erst einmal geplant und umgesetzt werden muss. Wobei das Problem mit dem defekten Gerät was Müll sendet auch in der DMX-Kette fatal wäre :wink:
    Auch die Selbstadressierung ist natürlich nicht sooo dynamisch gedacht wie das vielleicht rüberkam, es soll natürlich schon möglich sein ein gewisses Set von Pult und Geräten konsistent beieinander zu halten, aber eben abstrahiert. Wie wärs denn z.B. wenn du bei deinen 40 (identischen) Wacklern beim Hängen nicht mehr schauen musst welcher wohin soll und ob die Adresse passt, sondern die Adressen in der Steuerung einfach für eine Position im Rigg vergeben kannst, gleich welcher Wackler das jetzt genau ist.
    Was LED-Walls und Videoserver angeht, kann ich jetzt auch nicht wirklich mitreden, aber das ist auch ein anderes Thema denke ich.

    @ Leopold: Hm, das ist ein schwieriges Thema. Eigentlich geht es hier mehr um die Forschungsarbeit. Die ist aber natürlich auch müßig wenns nachher keiner benutzt und es keinen interessiert. Die Grundsatzfrage ist halt, wie die Zukunft weitergeht in punkto wired vs. wireless...ein Ethernet bringt dir eigentlich außer größerer Bandbreite und Sternverkabelung keine Vorteile. Aber wie du ja sagst, im Endeffekt werdens die Hersteller entscheiden wo der Zug hinfährt. Aber wir als Kunden haben da ja wiederum auch ein wenig Einfluss, und daher auch meine Frage hier im Board.

    Ich hoffe, dass ich jetzt euch allen gerecht geworden bin, bitte auch vorerst mal noch keine technischen Detailfragen, ich find den umgekehrten Ansatz viel schöner, ihr sagt mir einfach was ihr davon erwarten würdet damit ihr in Erwägung ziehen würdet es zu kaufen ;)

    Besten Dank und Grüße,
    phlo

  • DMX-Nachfolger?

    Hallo zusammen,

    ich hoffe der zugegebenermaßen provokative Titel lockt einige kompetente Leute hier in den Thread. :D

    Ich benötigt aus gegebenem Anlass (Entscheidung für oder gegen ein kleines "Forschungsprojekt") mal einige Anregungen und Meinungen aus der Praxis. Und zwar geht es darum, in Zeiten drahtloser Vernetzung und steigender Rechenleistung, eine mögliche würdige Nachfolge für das gesamte bus- und drahtbasierte DMX-Steuersystem zu kreieren, welches uns viele Jahre als Techniker treu begleitet hat.

    Konkret mache ich mir Gedanken über ein drahtloses System mit folgenden Kerneigenschaften:

    • Vernetzung der Einheiten geschieht komplett drahtlos bis zum "Gateway", welches wiederum mit der Steuerung verbunden ist. Die verwendete Drahtlostechnologie soll ein vielfaches der Bandbreite einer DMX-Linie bieten, dennoch aber extrem störungsfest sein - natürlich bei gewohnter Refreshrate
    • Bidirektionale Kommunikation für zukünftige Verwendung soll möglich sein (RDM-ähnlich)
    • Intelligentes Verhalten der Einheiten, so z.B. die Möglichkeit Nachrichten für andere Nodes weiterzuleiten, wenn diese nicht direkt über die Basis erreichbar sind (eine Art Routing)
    • Komplett selbstadressierend und -konfigurierend, es ist also nicht mehr nötig die Geräte explizit zu adressieren, einfach hochhängen, der Rest geht später am Pult/Rechner
    • Voriger Punkt bedingt sowohl eine automatische Adressierung und Lookup der Geräte, als auch eine robuste Möglichkeit mit der die Geräte ihre relative Position zueinander feststellen können.
    • Es gilt die Annahme, dass in Zukunft immer mehr Techies mit Laptop vor Ort sind, bzw. kommende Pulte die Konfiguration immer mehr über eine GUI erledigen und nur der Direktzugriff auf die Lampen noch über mechanische Bedienelemente läuft (Fader,Jogs etc.)
    • Das ganze soll natürlich so wirtschaftlich als möglich sein, d.h. niedrige Hardwarekosten und die Möglichkeit, vorhandene Geräte mit einer Art "DMX-to-Wireless-Dongles" umzurüsten, bzw. auch ältere Pulte durch eine Art Basisstation benutzbar zu machen

    Die Frage nun an alle, die mit sowas täglich arbeiten müssten: Haltet ihr das ganze für sinnvoll? Fällt euch spontan etwas ein was das ganze unsinnig oder unmöglich macht? Kennt ihr schon irgendwelche Ansätze in die Richtung oder vergleichbare Systeme?
    Ich habe mich z.B. die letzten Tage intensiv mit ArtNet und WLAN auseinander gesetzt, aber das ist ja im Prinzip auch nur eine bessere Möglichkeit für einzelne Strecken, und ändert am DMX-Grundprinzip mit Adressen etc. weiter nichts.

    Ich bitte jedoch darum dieses Thema etwas "philosophischer" zu behandeln als es in einem technischen Forum für gewöhnlich gemacht wird...Ich suche niemanden der mir sagt das ich gewisse Datenraten oder Störfestigkeiten nicht schaffe, das wären dann alles Dinge die in der Arbeit selbst zu klären wären. Es geht mir einzig um das zugrundeliegende Konzept. Oder anders ausgedrückt, würdet ihr im PP oder so eine Werbung sehen, die damit wirbt (ohne weitere technische Infos) - würde das eurer Interesse wecken?

    Herzlichen Dank für eure Antworten bereits im vorab,

    Beste Grüße,
    phlo

  • Suche leihweise: Video Kamera für Aufzeichnung

    Die Brennweite bezieht sich meistens auf Kleinbildäquivalent (35 mm) und ändert sich mit der Größe des Sensors. Ist eigentlich klar, wenn man sich vorstellt dass das gleiche Objektiv mit der gleichen Entfernung zum Sensor auch immer ein gleich großes Bild erzeugt. Wenn jetzt der Sensor aber kleiner ist wird ja nur ein Teil des erzeugten Bilds erfasst. Und je kleiner dieser Teil (ergo je kleiner der Sensor), desto größer die Vergrößerung (weil der Bildausschnitt kleiner wird).

    Das heißt für den Alltagsgebrauch: Je kleiner der Sensor, desto größer die äquivalente Brennweite. Siehe auch http://de.wikipedia.org/wiki/Formatfaktor

    In deinem Fall heißt das, dass du mit zunehmender Sensorgröße mit einer "normaleren" Brennweite auskommst. 1,8mm sind schon ein wenig arg kurz - die Rechnung war vermutlich eher für eine Taschenknipse gedacht :lol:

    Denke ansonsten auch dass es mit der EX-1 und dem WW zu schaffen sein sollte...

    Grüße,
    phlo

    EDITH sagt: falscher Wikipedialink! Ist jetzt korrigiert...

  • Suche leihweise: Video Kamera für Aufzeichnung

    Hab dir zwar selbst kein Material, würde dir aber anstatt Digital8 gerade wegen des Weitwinkels und der später im Schnitt vorhandenen Möglichkeiten (Ausschnittsvergrößerung, Fisheyeentzerrung) hier zu nem HD-Format raten...Da könnten z.B. folgende Kameras interessant sein:

    - Panasonic HVX-200 (entweder mit Firestore oder P2-Karten)
    - Sony PMW-EX1 (kann nur P2 Karten aber mit on-the-fly Wechsel)

    Mit beiden kommst du demnach auf die erforderliche Länge, die Qualität ist super, und je nach Anforderungen sollte auch der Bildwinkel von den fast 180 Grad machbar sein. Die 1,8mm kann ich mir aber noch nicht so richtig vorstellen, ist das auf den Sensor einer normalen 3Chip-Cam gerechnet oder ist das Kleinbildäquivalent? Also wenn ich die Szene fotografieren müsste würde ich mit APS-C-Sensor zu irgendwas in der Nähe von 8mm greifen denke ich...

    Wo man sowas geliehen kriegt weiß ich aber auch nicht, den Fall hatte ich noch nie. Vielleicht auch mal bei http://www.dv-kameraverleih.de in deiner Nähe anfragen, das is ür LoBudget ganz brauchbar. Da würde ich eh auch wegen der Cams schauen, vielleicht haben die ja auch so ein Fisheye/UWW-Objektiv dazu...

    Grüße,
    phlo

  • DMX Signalgeber & Tester

    Zitat von "Henne"

    SW-UART ist bei den Baudraten nicht empfehlenswert. Wir reden bei DMX von 250kBaud und die ANSI E1.11 erlaubt nur einen Jitter von <1us (Ich muss noch einmal nachgucken!)

    Jo, das stimmt schon, das bringt das Ding dann an seine Grenzen. Ich hatte auch wenn dann im Sinn den BT-UART in SW zu machen, die Funkmodule sollen da offenbar recht unkritisch sein (ist aber Hörensagen!). Aber im Prinzip wärs schon angebrachter einfach nen AVR mit 2 UART zu nehmen, da ist dann auch die entsprechende Power vorhanden, das stimmt. Vielleicht dann den neuen Mega644p, der wäre als PDIP40 auch noch für Raucher auf Entzug verarbeitbar :wink:. Hat dann auch entsprechend 2 UARTs etc. und 4K RAM für alle Fälle (da werden sogar kleine Standalone-Sequenzen etc. möglich...). Und mit 7-8€ wohl auch bezahlbar.

    Zitat von &quot;Henne&quot;


    Zu RDM:
    In diesem Fall sind die Sourcen auf SourceForge wohl interessanter, da es um einen Controller geht.

    Aus Gründen der Performance würde ich die Discovery im AVR durchführen und die gefundenen UIDs dem Handy übermitteln. Ansonsten werden die Pakete im Handy zusammengesetzt, im AVR noch einmal an Hand der Prüfsumme gecheckt und dann ausgegeben. Danach ein Port-Turnaround und Empfang und Puffern der Antwort.

    Diese geht wieder zur Dekodierung ans Handy.

    Wenn wir mal soweit sind, dann werde ich glaube ich einfach auf jeden Fall dich hinzuziehen :wink: und die Protokollspec erstmal ordentlich durchlesen...

    Zitat von &quot;Henne&quot;


    Die Bridge kann an jede Stelle im Bus eingeschleift werden. Warum sollte man über BT große Strecken bewältigen wollen?

    Stimmt auch wieder...wenn man das halbwegs zentral macht reicht das dann normalerweise auch aus von der Reichweite, selbst auf größeren Bühnen...

    Beste Grüße,
    phlo

  • DMX Signalgeber & Tester

    Zitat von &quot;Henne&quot;


    Bitte lasst die galv. Trennung weg. Sonst kann ich später für den RDM-Support nicht mehr aufspringen. Wir arbeiten doch schon mit BT...

    Okay, wenn man kein oder nur ein entsprechend ordentliches Netzteil vorsieht, kann man das aussparen. Wobei das natürlich immer noch kein 100%iger Schutz wäre wg. Überspannung von Seiten des Busses, aber der Fall ist denke ich schon vernachlässigbar...dann sind die Treiber halt hin, passiert ja im Regelfall nicht.
    Wie ist denn das generell sonst so gelöst bei RDM, ich denk die Hersteller werden da in amtlichem Gerät schon auch galvanische Trennung einbauen wollen oder?

    Zitat von &quot;Henne&quot;


    Ansich habe ich alles fertig und hochgeladen - nur was nützt dies ohne Anwendung auf dem Handy? Um diesen Low-Level Kram brauch sich also keiner den Kopf zerbrechen. Ach ja: Falls der BT-Wandler einen USART haben möchte, brauche ich noch einen zweiten für DMX und die Bausdraten müssten kompatibel sein.

    Sorry, komme grad net ganz mit, was hast du fertig und hochgeladen? Meinst du deine OpenRDM-Implementation auf deiner Seite?

    Was die UARTs angeht, ja, das BT-Modul wird auch einen brauchen. D.h. auch dass es bei kleineren AVRs eh nötig sein wird einen davon in Software umzusetzen. Ich schau mir das die Tage mal an...freut mich aber jedenfalls so kompententen Support wie dich hier zu haben :!:

    @ DJHeini: Wenn nur SingleSlot-Pakete übertragen werden, das BT-Modul Klasse 1 ist und eine ordentliche Antenne dranhängt, is da nix utopisches dran, da sollten gut 30m bei Sichtverbindung drin sein...Wenn beides Klasse 2 ist und Sichtverbindung herrscht, und die Antenne was taugt, ists immer noch knapp die Hälfte. Das reicht von Dimmercity bis Rigg schon auch meistens...

    Grüße,
    phlo

  • DMX Signalgeber & Tester

    Hey Michael,

    ja, ich hatte da auch wenig Zweifel dass das nicht gehen könnte. Ist halt alles eine Frage der Implementierung, ich glaube nicht mal dass der RAM ein Problem werden könnte wenn man einen der größeren AVRs nimmt (4KByte SRAM dürften locker hinkommen). Die größeren Probleme sind bei mir momentan wie erwähnt dass ich keine Geräte zum Entwickeln und auch keine Kohle und (noch...) keine Zeit habe...
    Würde dann sowieso wenn dann fürs Prototyping ein ArduinoBT-Board (aber dann natürlich nicht in Arduino programmiert...) oder so nehmen, da müssten im besten Fall nur noch 2 OK und 2 RS485-Transceiver dran und die Hardware wäre fertig...muss mal schauen was es da noch so an fertigen Prototyping-Lösungen gibt...

    Grüße,
    phlo

  • DMX Signalgeber & Tester

    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.

  • DMX Signalgeber & Tester

    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: ...

  • DMX Signalgeber & Tester

    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

  • DMX Signalgeber & Tester

    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

  • DMX Signalgeber & Tester

    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

  • DMX Signalgeber & Tester

    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...