Posts by robernd

    Hallo zusammen,
    inzwischen habe ich einige Videos von meinem Musikbrunnen fertig. Außerdem habe ich mich schlau gemacht, wie ich sie in YouTube unterbringe. Einige meiner Musiktitel werden von dessen Musikrichtlinien akzeptiert (unter dem Vorbehalt, Werbung einzublenden).

    Queen: I want to break free

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Abba: Fernando

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Whitney Houston: I always love you

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Leider bin ich noch nicht dahinter gekommen, wie man das Angebot weiterer Videos nach Abspielen verhindert.

    Die weißen Lampen um die Düsen herum funktionieren zwar schon, erhalten bislang aber nur die gleichen Kommandos wie die Fontänen.
    Bunte Strahler rundherum und ein vernünftiges Becken gibt es erst im nächsten Jahr.


    Gruß robernd

    Hi Stefan,
    schönen Dank für den Hinweis auf die PROGMEM Library. Um die habe ich mich bislang nicht gekümmert. Allerdings müssen damit im Programmspeicher gehaltene Daten vor der Verwendung zunächst ins RAM kopiert werden. Das ist sicher sinnvoll, wenn nur eine von mehreren Tabellen benötigt wird.

    In meinem Fall war es etwas anders. Ich habe mehrere Tabellen gleichzeitig im direkten Zugriff gebraucht, und damit wurde es im 2k-RAM schnell eng.
    Auf meine alten Tage möchte ich mich mit der Atmel-Hardware nicht näher beschäftigen, um zu sehen, wie auf Daten im Programmspeicher zugegriffen werden könnte. Mir fiel nur auf, dass einzelne als Konstant definierte Variablen im Programmspeicher bleiben, während es bei Arrays nicht funktioniert.

    Ich habe früher viel für Z80- und MC68000-Prozessoren programmiert und bin etwas verwöhnt. Da lässt sich überall indiziert zugreifen, weil es logisch gesehen nur eine Art Speicher gibt, die dann je nach Adressbereich RAM oder EPROM sein kann. Auch mit den PIC-Prozessoren mit unterschiedlichen Programm- und Variablenspeichern geht es nicht so einfach. Dort gibt es ein Workaround um quasi indiziert in den Programmspeicher zu greifen. Sicher gibt es Ähnliches auch bei Atmel.

    Ich habe übrigens völlig übersehen, dass die Arduinos auch mit SD-Karten umgehen können. Dort lässt sich (fast) beliebig viel unterbringen.

    Gruß RoBernd

    Hi Martin und alle anderen,
    an einem ähnlichen Projekt habe ich auch schon für eine Weihnachtsbeleuchtung getüftelt. Die Vorgehensweise ist für mich abgehakt. Für eine aktuelle Realisierung fehlt allerdings die Zeit. Im Vordergrund steht bei mir die 1:1 Umsetzung von DMX auf den 2811-Bus. Ohne diese 1:1 Umsetzung und mit nur 170 Pixel vereinfacht sich der Programmaufwand drastisch. Allerdings musst du natürlich die auswählbaren Muster zunächst erfinden und einprogrammieren.

    Als Controller habe ich einen Arduino Uno vorgesehen. Bei einer größeren Anzahl hinterlegter Muster ist die Mega-Version nötig. Die hat 8 KBytes Arbeitsspeicher. Jedes Muster nimmt 510 Bytes ein. Damit gehen ungefähr 12 Muster in den Speicher. Normalerweise würde man die Muster im wesentlich größeren Programmspeicher ablegen. Das funktioniert bei den einfachen Arduinos aber nicht, weil sie beim Programmstart derartige Tabellen in den Arbeitsspeicher übernehmen. Es gibt einen wesentlich leistungsfähigeren Arduino Due, der mit den anderen Arduinos nicht kompatibel ist. Für den habe ich aber bislang keine DMX-Library gefunden. Die Veränderung eines vordefinierten Musters in der Helligkeit oder Farbe benötigt nur wenig Speicher. Mit dem Raspberry kann ich mich nicht anfreunden, weil ich für derartige Anwendungen ein Betriebssystem für hinderlich halte.

    Der Empfang von DMX-Kommandos durch den Arduino läuft bei mir seit einiger Zeit für einen anderen Zweck (Musikbrunnen). Mit der Bibliothek von http://www.mathertel.de ist das recht einfach zu haben. Wie ich es gemacht habe findet ihr auf http://www.radonmaster.de/dancingwater/slave/ und http://www.radonmaster.de/dancingwater/dmx-extension/
    Es gibt auch Libraries für die 2811-Ausgabe. Ich hoffe, mit denen lebt es sich ebenso einfach wie mit der DMX-Library. Um Details einer 2811 Library habe ich mich noch nicht bemüht.

    Gruß RoBernd

    Hi,
    schönen Dank für eure Hinweise. Speziell bei dem Dubai Spektakel bekomme ich Minderwertigkeitskomplexe ;) Das war mir natürlich von Anfang an klar.
    Es wird aber auch ein Unterschied zu meinen kleinen Fontänen (160 cm) deutlich: Bei mir dauert es weniger als 1 sec, bis sie oben sind. Damit bin ich wesentlich näher am Musiktakt als die Mega-Fontänen. Deshalb ist die bisher ausgewählte Musik auch weniger getragen. Ein typisches Beispiel ist "I want to break free" von Queen. Das ist auch bei meinem Vorbild, dem Barcelona Brunnen, gelaufen. Speziell davon gibt es eine ganze Reihe von Amateurvideos auf Youtube. Allerdings ist von der Musik kaum etwas zu hören, weil das Wasserrauschen zu laut ist. Bei mir soll die Musik deutlicher werden, weil ich einen Anteil Originalton unterlegen kann. Eine andere Musik ist Beethovens "Ode an die Freude" in einer Art Pop-Version. Hier ließe sich eventuell ein MIDI-File anpassen. Beethoven selbst ist ja wohl nirgendwo mehr unter Vertrag. Ich suche Musik, die ich als "farbig" bezeichne. Nicht im Gegensatz zu schwarzweiß sondern zu farblos. Damit meine ich wechselnde Instrumente und Lautstärken.

    Auch ich habe inzwischen mitbekommen, dass Youtube jetzt anders tickt. Interessant ist, dass Vimeo umfangreichere Verträge hat oder hatte. Wegen des größeren Abstands zu Google wäre mir das lieber. Erst einmal muss ich meine Videos schneiden, und dann werde ich weiter sehen. Schneiden, weil ich das Ganze unter mehreren Kameraperspektiven aufgenommen habe.

    Ich nehme an, dass ihr zumindest vor dem Frühling von mir noch etwas zu sehen bekommt.
    Gruß RoBernd

    Hallo zusammen,
    seit ich mich das letzte Mal gemeldet habe, sind einige Monate vergangen, in denen sich auch bei mir einiges getan hat. Ihr könnt euch vielleicht noch daran erinnern, dass ich ein Springbrunnenprojekt mit Musiksteuerung in Angriff genommen habe.
    Inzwischen läuft mein Brunnen im Testbetrieb in einem Plastikbecken. Gerade habe ich wieder alles abgebaut, bevor der Winter kommt. Deshalb gab es etwas Zeit, meine Internetseite zu aktualisieren und auch euch zu berichten.

    Das erste Bild zeigt meine 25 Düsen. Jede hat einen Ring aus weißen LEDs, so wie ich sie vom Hersteller Oase bekommen habe. Alle Pumpen mit den aufgesetzten Düsen sind auf eine Kunststoffplatte geschraubt, und am Rande gibt es schon die Befestigungslöcher für 12 wesentlich hellere RGB-Strahler.


    Meine Steuerung ist in erster Ausbaustufe fertig, und die Fontänen laufen auch synchron zur Musik. Die beiden Bilder sind Videos entnommen, die ich mit recht großem Aufwand aufgenommen aber noch nicht geschnitten habe. Zugegeben, die Bilder sind recht mickrig, im Video sieht es mindestens eine Klasse besser aus. Obwohl im Video die Musik nur leise im Hintergrund zu hören ist, traue ich mich wg. Ge ma nicht, die Videos zu veröffentlichen. Geeignete freie Musik habe ich bislang nicht gefunden. Aber ich habe ja den ganzen Winter über Zeit zum Suchen.


    Wie ursprünglich vorgesehen, besteht die Steuerung inzwischen aus 9 Arduino Controllern auf drei selbst gebauten Boards. Jeder von denen steuert 3 Pumpen/Düsen mit den zugehörigen 3 LEDs. Es sind genau 3+3, weil jeder Controller-Chip sechs PWM-Einheiten besitzt. Außer den Controller-Schaltreisen gibt es darauf noch einen Leistungstransistor für jeden Kanal und Störschutz-Komponenten.


    Bislang sitzen 3 Boards in einem Gestell, das in eine wassergeschützte Alu-Box passt. Später sollen noch einige Boards hinzu kommen. Oben seht ihr viele Steckanschlüsse mit insgesamt 50 Leitungen für die Pumpen und Lampen. Außerdem gibt es noch jede Menge Buchsen für die vorgesehenen Erweiterungen. Die Leitungen sind an den Oase-Teilen „angewachsen“ und wasserdicht vergossen. Es ist eine Eigenart von Oase, zum Anschluss alte deutsche Lautsprecherstecker zu verwenden. Wahrscheinlich sind es die billigsten Stecker, die 1 A und mehr vertragen.

    Die drei Metallkassetten rechts sind Netzgeräte mit 12V für die Lampen und 2x16V für die Pumpen. Damit erreichen sie Fontänenhöhen von 160 cm. Jedes Netzgerät liefert mehr als 20A.

    Weil alle DMX-Eingänge der Controller direkt miteinander verbunden sind und in unmittelbarer Nähe von Steuer-PC und DMX-Interface angeordnet sind, habe ich mich auf einfache 5V-Logiksignale beschränkt. Als Interface dient ein einfacher USB-Seriell Wandler, dessen Funktion dem OpenDMX Interface entspricht. Das funktioniert mit dem alten Notebook-PC mit WinXP sehr zuverlässig. Mit meinem größeren Win7 Rechner bricht es immer mal wieder zusammen. Und mit Win10 soll es nach euren Angaben im Forum überhaupt nicht funktionieren.

    Was die Editor-Software betrifft, bin ich fremd gegangen. Ich verwende also nicht DMXControl sondern den Show-Control-Editor von ID-AL, der in der Funktionsweise einem Video-Editor ähnlich ist. Der funktioniert wiederum nur mit dem OpenDMX Interface. Ursprünglich ist er dafür vorgesehen, eine Lichtgestaltung zu arrangieren, die später in ID-Al‘s eigenständigen Eventplayer geladen wird. Der spielt dann MP3- oder Wave-Musik ab und gibt dazu den DMX-Strom aus. Ob ich mir den Eventplayer tatsächlich kaufe, steht noch in den Sternen. Inzwischen bin ich auch etwas anspruchsvoller geworden und denke darüber nach, zu DMXControl zurückzukehren.

    Bislang habe ich Wasserspiele für mehrere Musikstücke arrangiert, die zusammen um die 30 min dauern. Das hat schon ein paar Tage gedauert. Es hat mir wirklich Spaß gemacht, die Emotionen, die die Musik in mir weckt, in Fontänenbewegungen umzusetzen.

    Bei meinen gesamten Aktionen habe ich jede Menge Erfahrungen gesammelt und auch Lehrgeld überwiegend in Form vertaner Zeit bezahlt. Viele „schlaue“ Gedanken der Vergangenheit, die großteils auch hier im Forum auf Unverständnis gestoßen sind, haben sich als unpraktikabel erwiesen. Dazu gehört z.B. die ursprünglich realisierte dynamische DMX-Adressenzuordnung mit dem Hintergedanken, auf elegante Weise Fontänenkonfigurationen rotieren zu lassen.

    Andere Gedanken habe ich weiter verfolgt. Dazu gehört der Einbau von Kalibrierkurven in jeden Pumpen-/Lampencontroller, die ihr als Dimmerkennlinien bezeichnet. Für die Lampen ist das recht einfach zu haben. Den entsprechenden Aufwand für die Fontänenhöhen habe ich völlig unterschätzt. Die übertragenen DMX-Informationen sollen ja nicht Pumpenspannungen sondern Fontänenhöhen vorgeben. Dabei ist der Zusammenhang zwischen Austrittsgeschwindigkeit aus der Düse und Spritzhöhe bereits quadratisch. Für eine doppelte Höhe brauchen wir also die vierfache Geschwindigkeit. Außerdem ist der Zusammenhang zwischen Pumpenspannung und Austrittsgeschwindigkeit auch krumm. Das in eine Kennlinie/Kalibrierkurve einzubauen, ging gerade noch. Es ist aber nur die Spitze des Eisbergs.

    Bei gleichen Motorspannungen spritzen die verschiedenen Pumpen nämlich unterschiedlich hoch. Das stört schon sehr, wenn bestimmte Gruppen die gleiche Höhe haben sollen. Außerdem ändert sich diese Eigenschaft im Laufe der Zeit und sogar mit der Wassertemperatur. Nun, ich habe zusätzliche Korrekturkurven (Polynome) eingebaut, die sich im laufenden Brunnenbetrieb durch Kommandofolgen in unbenutzten DMX-Kanälen für beliebige Düsen gleichzeitig einstellen und (nichtflüchtig im EEPROM) speichern lassen.

    Eine weitere Erfahrung zeigt, dass es allenfalls bei ganz einfachen Fontänenmustern möglich ist, eine grobe Brunnenprogrammierung vorzunehmen, ohne den Brunnen vor Augen zu haben. Das ist speziell im Winter gar nicht so einfach ;) Also bastele ich an einem Simulationsprogramm für die Fontänen. So etwas für einen PC zu machen, übersteigt meine Fähigkeiten. Ich habe mich deshalb auch hier für ein Arduino-Sytem entschieden. Allerdings nicht für die 16 MHz / 8-Bit Version der Pumpen-Controller sondern für eine 84 MHz / 32 Bit Version mit einem senkrecht gestellten 800x420 Pixel Farbdisplay (siehe Bild).


    Eigentlich ist es nicht so schwierig, eine Fontäne zu simulieren, wenn wir auf Feinheiten verzichten. Es gelten die Gesetze für den Freien Fall (vertikale Fontäne) oder eine Wurfparabel (schräge Fontäne). Die theoretische Zeitdauer für den Aufstieg einer Fontäne mit 160 cm Höhe beträgt 0,57 sec. Das stimmt mit meinen praktischen Erfahrungen überein. Eine Verzögerung der Musik zwischen 0,4 und 0,7 sec gegenüber den DMX-Kommandos hat sich recht gut bewährt.

    Ich habe mir die Mühe gemacht, einiges aufzuschreiben, weil es für euch im Forum unbefriedigend ist, wenn ein Mitglied kommentarlos in der Versenkung verschwindet. Auch zukünftig will ich einigermaßen regelmäßig über den Stand berichten. Mehr Gedanken und ausführlichere Einzelheiten findet ihr auf meiner Internetseite. http://www.radonmaster.de/dancingwater

    Gruß
    RoBernd

    Hi,
    auch wenn es schon eine Weile her ist:
    Ähnlich wie ein Videoschnittprogramm funktioniert auch der Show Control Editor von ID-AL.
    http://www.id-al.com/home2/en/produ…rs/event-player
    Eigentlich ist es ein Entwurfsprogramm für den stand-alone Eventplayer. Der Editor funktioniert im PC aber auch ohne den. Die Ausgabe erfolgt durch ein Open DMX Interface.

    Und übrigens: Jedes Abspielgerät, das WAVE Stereo wiedergeben kann, gibt auch DTS-Surround wieder. Also auch alle CD-Player und DAT-Recorder mit Digitalausgang, die es schon vor DMX gab. Die zugehörige Beschreibung findet man unter DTS-CD.

    Gruß RoBernd

    Hi,
    schönen Dank für deine Hinweise. Eigentlich bastelt man so eine Show, damit auch andere Leute sie sehen. Auf jeden Fall werde ich mal nachfragen, möglichst ohne schlafende Hunde zu wecken. Wahrscheinlich haben die ein Problem, überhaupt einen (aufgeschriebenen) Tarif zu finden. Nach halbwegs vergleichbaren Angaben sollte der Preis um die 7 EUR im Monat liegen.

    Gruß RoBernd

    Hallo,
    es gibt für mich immer wieder neue Wow-Effekte. Dazu gehören diese Mega-Trees, also die Weihnachtsbäume nur aus Lichterketten aber ohne Baum. Siehe Link von Helmuth. Ursprünglich wollte ich ja nur einen Springbrunnen steuern. Die Einrichtung dafür steht ja im Winter ziemlich nutzlos herum. Warum also nicht für eine Weihnachts-Illumination verwenden? Natürlich ebenfalls mit Musik.

    In der Musik sehe ich ein Problem. Mein Springbrunnen wäre sehr privat mitten im eigenen Garten, das geht niemanden etwas an. So ein Weihnachtsbaum sollte jedoch in Straßennähe sein. Und dort dürfen wir wohl nicht so einfach beliebige Musik spielen, obwohl es auf dem eigenen Grundstück wäre. Die übliche freie Musik baut mich nur wenig auf. Wie handhabt ihr so etwas?

    Wie alt muss eine Komposition sein, damit man sie ohne schlechtes Gewissen spielen kann? Es gibt ja jede Menge anonyme Midi-Files, darf man die öffentlich verwenden?
    Oder geht so etwas zum Discount-Tarif. Eine offizielle Gebühr für 20 Stunden Musikuntermalung (je Abend eine Stunde) mit jeweils 10 Zuhörern (auf dem Dorf) sollte nicht sehr teuer sein.

    Gruß RoBernd

    Hi,
    die zugrunde liegende Idee hat etwas. Wenn wir sie konsequent für unsere Zwecke abspecken, kann so ein Ding zeitnah in Produktion gehen. :) Das soll kein Witz sein!
    Ich baue mal auf die Informationen auf, von denen ich meine, sie verstanden zu haben. Es wäre allerdings nicht das erste Mal, dass ich etwas falsch verstehe.

    Wesentlich ist, dass allein die Brille oder wie immer das Ding heißt, weiß wo es ist. Damit ein Spot weiß, wohin er leuchten soll, muss die Brille ihre Position melden. Wir brauchen also einen Übertragungskanal vom Akteur zur Beleuchtung.

    Wenn wir das System anders konzipieren, können wir auf gefühlte 90% des Aufwandes verzichten. Allerdings benötigen wir weiterhin einen Übertragungskanal. Offenbar gibt es in einer Raumecke einen Laserscanner mit x-y-Ablenkung. Den bauen wir auf den Spot. Jetzt interessiert uns nicht mehr die Position sondern nur noch die Richtung des Akteurs.
    Das HTC Vive weiß nur, dass es den Laserscanner gibt und mit welchen Geschwindigkeiten der Scanvorgang läuft. Wenn der Scanner in unserer Regie ist, wissen wir, wann er wohin strahlt. Der Akteur bekommt nur noch einen Fotosensor. Immer wenn dieser getroffen wird, schickt er ein Signal an die Steuerung. Damit ist bekannt, in welcher Richtung sich der Akteur befindet. Falls der Scanner gemeinsam mit dem Spot nachgeführt wird, wissen wir sogar, wie weit der Akteur von der Sollposition bzw. -richtung entfernt ist. Das Nachführen sollte jetzt ein kleineres Problem sein.

    Können wir den Vive Scanner verwenden? Wenn ich es richtig verstanden habe, handelt es sich um zwei rotierende Laser, die abwechselnd horizontale und vertikale Linien aussenden. (weiß nicht, wie ich ein Youtube Video verlinke)
    https://www.youtube.com/watch?annotati…0&v=91gAf0hEews

    Wahrscheinlich können uns zwei eigene Fotosensoren am Rande des gescannten Feldes (nicht allzu weit vom Scanner entfernt) die nötigen Bezugssignale verschaffen. Wir müssen die ermittelten Zeitdifferenzen zwischen Bezugs- und Akteur-Impuls in die Bewegungen des Spot umrechnen. Nehmen wir einmal an, der Scanner braucht 10 ms für 10 m, dann sind es 0,1 ms für 10 cm. 10 kHz Bandbreite sollte dann zum Übertragen der Treffer-Impulse ausreichen. Im Zweifelsfall müssten wir doch einen eigenen Scanner bauen, der langsamer läuft.
    Vielleicht habt ihr Bühnen-Spezialisten sogar Laserscanner im Schrank, die dafür geeignet sind.

    Gruß RoBernd

    Hi,
    JPK's und Hoc's geniale und oft ebenso einfache Gedanken beeindrucken mich immer wieder :) Einfach cool so ein Coolpack.

    Ich vermutete Lichtfuzzi hätte die Körperwärme ins Spiel gebracht. Weshalb ich nachfragte.
    Keine Sorge, sie wird keinen IR-Empfang stören, der für IR-LEDs konzipiert ist. Zwischen dieser Wärmestrahlung und der Strahlung von LEDs liegen Welten, ähnlich wie zwischen infraroten und blauen LEDs.

    In meinem Leben habe schon verdammt viel gebastelt. Tatsächlich habe ich oft Dinge ausprobiert, die eigentlich nicht gehen konnten. Leider musste ich fast ausnahmslos feststellen, dass es wirklich nicht ging. Inzwischen habe ich mir angewöhnt, von so etwas meine Finger zu lassen. Das mag der Grund sein, weshalb meine Ausführungen oft pessimistisch klingen. Und dann kommt Hoc mit seinem Coolpack, und schon sieht die Welt ganz anders aus.

    Ich habe mir oft genug an plausible Methoden die Zähne ausgebissen. Meistens aber ließen sich plausible Sachen auch realisieren.

    Nein, ich will euch nicht den Mut nehmen, nur manchmal vielleicht etwas Arbeit ersparen. Allerdings kommen auch auf (vermeintlichen) Irrwegen oft neue Gedanken, die man sonst nicht hätte.
    So geht es mir mit dem Laser zur Entfernungsmessung. Prompt fällt mir ein, dass die älteren Entfernungsmesser mit Ultraschall funktionierten. Und schon können wir über ein neues Projekt nachdenken ;)
    Spinnen wir es weiter: Der Akteur trägt einen gepulsten Ultraschallsender. An drei Stellen auf der Bühne befinden sich Empfänger, die die Empfangszeitpunkte gut erfassen können. Wäre der Aussende-Zeitpunkt bekannt, würden zwei Empfänger ausreichen, um aus den Laufzeiten die Position zu berechnen. Ins Unreine gedacht, müsste sich mit drei Empfängern auch ohne Startsignal die Position bestimmen lassen. Darüber werde ich mal nachdenken. Ultraschallsignale werden speziell durch Reflexionen gestört. Allerdings laufen die später ein als das direkte Signal. Reflexionen dürften also nicht stören, wenn wir stets das erste eintreffende Signal auswerten.

    Was mit Ultraschall geht, sollte auch mit Mikrowellen (Radar) funktionieren. Nur tun wir uns sehr schwer, die extrem kurzen Laufzeiten zu erfassen. Allerdings wäre es ideal, um bewegte Objekte zu registrieren. Nur wenn die Frau oder der Mann stehen bleibt, haben wir Pech. Dann müssten wir aber auch keinen Spot nachführen. Aber wenn sich die Frau und der Mann bewegen, gibt es ein neues Problem.

    Und doch Vermessungslaser? Nur kleines Problem, wenn der Akteur einen rotierenden Laser auf dem Kopf hat. Scheint mir aber irgendwie über das Ziel hinauszuschießen.

    Zu jeder Idee müssten wir eigentlich ein paar Experimente machen. Und das ist der Knackpunkt. Jeder von uns hat so seine eigenen Ziele, und damit fehlt die Zeit dafür.

    Gruß RoBernd

    Hi,
    die Zeiten, zu denen ich über DMX die Nase gerümpft habe, sind längst vorbei. :) Zu der Zeit habe ich noch nicht einmal gewusst, dass es DMX-Editoren gibt.
    Längst habe ich gelernt, dass wir an DMX nicht vorbei gehen können. Zumal es keine Alternative gibt.

    Wie robust diese Technik ist, haben uns schon die alten Fernschreibsysteme gezeigt, welche letztlich das Vorbild für DMX waren (allerdings mit Stromschleife und nicht RS485).
    Ich habe Spaß am Tüfteln und versuche das eine oder andere etwas intelligentere an das System anzuhängen. Inzwischen kommen mir aber immer mehr Zweifel, ob das sinnvoll ist. Richtig schlimm wird es in der Tat, wenn sich Intelligenz verselbstständigt und gar ungefragt zu senden beginnt.

    Gruß RoBernd

    Hi,
    ein Hinweis zu der Übertragungsgeschwindigkeit von 44 Hz:
    Die Bitfrequenz (Baudrate) ist 250000 kHz.
    Jedes übertragene Byte benötigt 11 Bit (1 Startbit, 8 Datenbit, 2 Stopbit).
    Macht 22727,27 Bytes/sec
    Ein DMX-Zyklus umfasst 512 Kanäle.
    22727,27 / 512 = 44,389 Hz
    Und jetzt kommen noch ein Break hinzu (etwas mehr als 11 Bit) und vielleicht eine winzige Reserve.
    Und dann haben wir 44 Hz. Das ist also die "Schallmauer", wenn ohne Pause ein Byte nach dem anderen übertragen wird.
    Asynchrone Übertragung lässt Pausen zu. Auch unterschiedlich lange zwischen den einzelnen Bytes. Wenn also ein PC nicht mit dem Senden nachkommt, geht es eben etwas langsamer. Es dürfte aber nichts verloren gehen.

    Das DMX-Konzept stammt aus der Zeit, zu der Elektronik noch dumm war. Nichts wird gespeichert, nichts wird irgendwo automatisch erledigt. Deshalb wird bis zum Umfallen gesendet. Ja, Computer gab es damals schon, das waren aber teure, große Kästen.
    Ich habe mich mal über das historischen Verfahren ausgelassen: http://www.radonmaster.de/dancingwater/dmx-extension/

    Ist es tatsächlich üblich, dass DMX-Empfänger prüfen, ob Daten ankommen? Was passiert, wenn die Übertragung abreißt? In einem Beispielprogramm für einen Arduino-Empfänger hat der Autor eine Reaktionszeit vom 5 sec eingebaut. Dann geht der farbige Strahler als "Fehlermeldung" auf konstantes Rot. Das ist auf einer Bühne sicher keine gute Lösung. Während der Installationsphase kann es natürlich hilfreich sein.

    Gruß RoBernd

    Hi,
    was meint ihr mit IR-Abstrahlung? Die Wärmestrahlung eines Menschen, wie sie Bewegungsmelder registrieren oder die Strahlung umgebundener IR-LEDs?
    Wärmestrahlung lässt sich nicht analysieren, wenn es in der Umgebung warm ist. Außerdem sind entsprechende Empfänger sehr langsam.

    Ich dachte, wir hätten alle Hochfrequenz-Systeme (also auch Bluetooth) ausgeschlossen.

    Was bedeutet vlt Laser? Soll es das System sein, mit dem die Astronomen die Unruhe in der Erdatmosphäre messen?

    Gruß RoBernd

    Sorry,
    was das Programm Show Control Editor betrifft, muss ich mich korrigieren. Der ID-AL Support hat mir auf Nachfrage beigebracht, dass es sehr wohl weiches Dimmen gibt. Bei entsprechender Markierung, werden die Bereiche zwischen zwei zeitlich voneinander entfernten Einstellungen mit einem linearen Helligkeitsverlauf aufgefüllt. Die Symbole dafür hatte ich ignoriert, weil sie (grafisch) so ähnlich aussehen wie Relaiskontakte. Und die hatten mich nicht interessiert.

    Gruß RoBernd

    Hi,
    schönen Dank für die zusätzlichen Angaben.
    Allerdings frage ich mich, wo wir überhaupt leben. DMX setzt sich praktische über alle üblichen Standards hinweg. Das mag für den speziellen Zweck OK sein.
    Das Servoprotokoll stellt diese auch noch auf den Kopf.
    Seit -zig Jahren bin ich gewöhnt: XON, ...Daten.., Checksum, XOFF
    Warum beginnen die mit XOFF (Transmission off)? Natürlich weiß das nur deren Erfinder. Vielleicht ist es auch ein Druckfehler. Vielleicht soll damit automatisch die Datenrate ermittelt werden.

    Hallo Ralf
    schön, dass du dein Spielzeug inzwischen montiert hast. Ich drücke die Daumen, dass es auch bald alles tut, was du erträumst.

    Ich habe auch einmal die Daten der Dynamixel Servos überflogen. Sie machen schon einen professionelleren Eindruck als Modellbau-Servos. Auch die Datenübertragen scheint professioneller als DMX zu sein. Im Handbuch sind zwar einige Schlagwörter enthalten, über das verwendete Protokoll lässt es sich nicht aus. Nach meinem Verständnis müssen Adressen und Daten übertragen werden, und wie diese in den Seriellen Datentransfer eingebaut werden müssen, steht dort nicht. Schlagwörter wie RS485, TTL oder 8N1 (8 Bit, No parity, 1 Stopbit) sind Banalitäten, die einem nicht weiter helfen. Damit ist auch nicht abschätzbar, wie groß der Aufwand wäre, sie an DMX zu hängen. Wahrscheinlich ist es weit einfacher sie direkt an einem Computer zu betreiben. RS485 sagt übrigens gar nichts über das verwendete Protokoll, es beschreibt allein die Signalspannungen und Wellenwiderstände.

    Umwandlung PWM (Servoimpulse) nach DMX.
    Das ist zwar möglich, aber eine undankbare Aufgabe. Von allen denkbaren Signalen sind die Servoimpulse (1 MS bis 2 MS ; wer macht hier eigentlich immer MS aus ms ???) das Schlechteste. Wir müssen uns darüber im Klaren sein, dass es reine Analogsignale sind. Nicht die Signalhöhe, sondern deren Länge. Im klassischen Fall werden sie mit primitiven Multivibratoren erzeugt, deren Einschaltzeit (Impulslänge) sich mit einem Potentiometer verstellen lässt.

    Zur Umwandlung nehme man: Oszillator mindestens 200 kHz, Zähler-IC, Und-Verknüpfung, Mikrocontroller
    Die Impulse des Oszillators werden mit dem Servo-Impuls UND-verknüpft und gezählt. Wenn der Zählvorgang beendet ist (Ende Servo-Impuls) muss ein Mikrocontroller das Zählergebnis übernehmen und anschließend den Zähler auf Null setzen. Der Mikrocontroller muss das Zählergebnis in einen Pufferspeicher schreiben und als DMX-Zeichenfolge ausgeben. Die meisten Mikrocontroller enthalten Zähler, die dafür geeignet sind.

    Und was dann? Keine Ahnung. Ich wüsste nicht, was ich mit einem DMX-Datenstrom anfangen sollte, wenn er lediglich die Information von einem Servosignal enthält. Eigentlich bräuchte man einen Servo-Server, der die Signale vieler Servos zu einem DMX-Strom zusammenfasst und nötigenfalls in Steuersignale für angeschlossene DMX-Geräte umsetzt.

    Es ist übrigens auch nicht so einfach, Servo-Steuerimpulse aus DMX-Daten zu erzeugen. Servos werden mit Impulsen versorgt, die zwischen 1 ms und 2 ms lang sind. Wiederholt werden sie mit 50 Hz. Standard PWM-Zähler zählen 256 Schritte. Die innerhalb von 20 ms (50 Hz) bedeutet, dass um die 12 Schritte eine Millisekunde bilden. Es ist so nicht möglich, mit dem Servo mehr als 12 Positionen anzufahren. Deshalb enthalten die typischen PWM-Schaltungen für Servos 16 Bit-Zähler.

    Gruß RoBernd