moin,
Ich hatte in meiner Anfangszeit ein Bügeleisen und eine Membranpumpe aus dem Aquarienhandel genutzt.
Die Pumpe könnte ich evtl. heute noch empfehlen (für einen dickeren Hazer) - über das Bügeleisen sollten wir trotz 1.2kW Heizleistung lieber Stillschweigen bewahren...
VG,
Hendrik
(der demnächst seine DTS2003 auf RDM umbaut...)
tomy:
Damit wäre man wieder inkompatibel zur E1.20. (-> bitte nicht!!)
Ansonsten wäre das RS422, was dann auch Vollduplex erlauben würde.
Momentan fehlt mir eigentlich ein günstiger RDM-Controller am meisten.
Dann könnte man schon mal den Kreis, den ich oben beschrieb, durchbrechen.
VG,
Hendrik
Ich seh wie die anderen folgende Probleme:
Dein Standard müsste von der Industrie angenommen werden.
Wenn sich die großen Hersteller nicht für Dein Forschungsprojekt interessieren, ist es Zeitverschwendung. (Dieses Problem kann man ja derzeit an RDM beobachten: In immer mehr Empfängern werkeln AVRs. Ich habe eine passende Bibliothek für die Grundfunktionalität geschrieben und veröffentlicht. WYBRON hat inzwischen etwas Ähnliches mit erweiterter Funktionalität aber ineffizienter veröffentlicht. Allerdings wird es nicht implementiert, da es fast keine RDM-fähigen Pulte gibt. Und es gibt fast keine RDMfähigen Pulte, da es fast keine RDMfähigen Empfänger gibt...)
Ich selbst stand neulich bei einem Produkt vor der Frage, ob ich die RDM-Basisfunktionalität implementiere oder das Flash für ein paar weitere Lauflichter opfer. Der Produktmanager entschied für die Lauflichter...
Fazit:
Die Geschichte müsste auf Protokoll-Level vollständig rückwärtskompatibel zu DMX/RDM sein.
Auf diese Weise könnte man das Netzwerk um die WLAN-Schicht, Routing, usw. erweitern und dies mit zusätzlichen Wandlern umsetzen.
Am Ende dürfte das Ergebnis dann eine WirelessRDM-Lösung sein, die sich von anderen Produkten durch ein intelligentes Routing unterscheidet.
Du musst letztlich wissen, was Du mit Deiner Zeit machst. Ich denke nicht, dass "die Welt" darauf wartet. (In nächster Zeit dürften Investitionen und Ausgaben in R&D sowieso eher sinken...)
Viel Erfolg,
Hendrik
Wahrscheinlich habe ich Dich falsch verstanden - aber falls Du wirklich LED-Spots bei Filmproduktionen einsetzen willst: Hast Du auf Kameratauglichkeit geachtet? Bei der üblichen PWM ist sie nicht selbstverständlich...
Alles Gute,
Hendrik
Ich lese hier ja nur sporadisch mit, kann aber vielleicht noch etwas dazu schreiben:
5.2 und 5.4 hatte ich schon auf dem Tisch und erfolgreich umgestellt.
5.5 wurde im Schwesterforum von jmd. erfolgreich modifiziert.
Eine Skizze des Schaltplans habe ich vor kurzem dem Firmware-Archiv hinzugefügt. (Die sollte auch bei einer Reparatur helfen...)
Mittlerweile ärger ich mich, dass ich die FW nicht damals in C geschrieben habe...
Folgende Herangehensweise wäre bei Problemen angebracht:
1) grundsätzlicher Abgleich der Schaltung mit dem Schaltplan.
2) Funktion des manuellen Modes: Arbeiten DIPs "falsch herum"? Tut sich überhaupt etwas? (Falls sich nichts tut, könnten die fuse bits nicht passen.)
3) Blinken der LED / Nur Probleme mit DMX: Ich habe die FSM für den DMX-Empfang für das Strobe etwas pingelig ausgelegt. Wenn als Signal nur Müll ankommt, wird der Müll nicht akzeptiert. Durch gezieltes Triggern der LED an bestimmten Stellen der FSM kann man dann schauen, "wie weit" das Signal akzeptiert wird bzw. wo man anpacken müsste. (Ich kann solche Fehler nicht reproduzieren und hatte nie verwertbares Feedback dazu bekommen...)
BTW: An Feedbacks wie "geht net" bin ich nicht interessiert, da ich keine Zeit habe, Leuten Detailinformationen aus der Nase zu ziehen. Derzeit sind einige 100 Mods erfolgreich im Einsatz - ein paar mehr oder weniger sind mir zunächst einmal egal...
VG,
Hendrik
Das Firmwarearchiv auf der zugehörigen Seite von mir.
Hier der Direktlink: http://www.hoelscher-hi.de/hendrik/light/pimp/sp1500.zip
VG,
Hendrik
Ich habe eben die groben Schaltpläne vom SP1500 dem Archiv hinzugefügt. (Den Phasenschieber und Bauteilwerte habe ich weggelassen.)
Vielleicht hilft es ja wem bei Änderungen der Firmware oder bei der Reparatur...
VG,
Hendrik
Ich meinte die Libs in den Resources.
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!)
Erfahrungsgemäß geht das nur mit einer Timer-ISR in Assembler vernünftig und es bleibt keine Zeit mehr für ernsthaftere Berechnungen nebenbei.
Also ein AVR mit 2 USART. Somit gibt es auch ausreichend RAM. Mehrkosten sind bei >30EUR für das BT-Modul auch vernachlässigbar.
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.
Die Bridge kann an jede Stelle im Bus eingeschleift werden. Warum sollte man über BT große Strecken bewältigen wollen?
VG,
Hendrik
Das Universe kann auch bei Bedarf unterbrochen werden. Mit etwas Nachdenken kann man sich so das RAM für sinnvollere Dinge aufsparen :wink:
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...
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.
(Im Datenblatt der AVRs steht, welche Baudraten mit 8, 12 oder 16MHz möglich sind.)
Viele Grüße,
Hendrik
Müsste eigentlich echt schnell und einfach umsetzbar sein!
Na dann mal los 
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
Schaltplan?
Wenn es der typische nicht intelligente Booster ist (nur ein paar Optokoppler, RS485-Wandler und ein DC/DC-Wandler) und die Geräte mit dem Eingangssignal ohne Booster klarkommen, könnte das an einer fehlenden Terminierung, gealterten Elkos oder ähnlichem liegen. (Also mal mit einem Oszi die Pegel anschauen.)
Falls es ein intelligenter Booster ist - also eher eine Gateway oder Switch -kann das am DMX-Timing des Controllers liegen. (Dann hast Du wahrscheinlich Pech gehabt.)
Ich meine, dass MA für sein "gnadenloses" Timing ohne interbyte gaps und minimalem Break berüchtigt ist. (Das hat den Vorteil einer schönen hohen refresh rate - aber viele Billiggeräte haben ihre Probleme damit...)
Viele Glück,
Hendrik
EDIT: Die Terminierung scheidet natürlich aus - wer lesen kann...
@yamaha: Deine Punkte habe ich bereits erklärt und ImmerLauter hat sich eindeutig (für den deutschsprachigen Raum) ausgedrückt.
Lösungen: ABschnittsdimmer, PFC (power factor correction), konventionelle Trafos.
Schönes WE,
Hendrik *der sich ein ganz klein wenig mehr Niveau zurückwünscht...*
Ich komme ja VT-mäßig aus einer anderen Richtung, möchte aber noch einen Aspekt hinzufügen: Kundenbindung!!
dazu würde ich zählen:
Unvoreingenommenheit und pos. Auftreten
Verlässlichkeit (Materialzustand, Preise, Terminabsprachen)
sinnvolle und kompetente Beratung (muss nicht ewig dauern - aber kein Aufschwatzen von unnötigem Material)
ab und an Kontaktaufnahme (Weihnachtsgrüße, Einweihung neuer Geschäftsräume, Einführung in besonders interessantes neues Material,...)
Derartige Firmen habe ich in der Vergangenheit gern weiter empfohlen. Bei größeren Projekten ist der Preis nur ein Aspekt von etlichen anderen. Ich halte Verlässlichkeit für ausschlaggebend.
Ein Beispiel für eine solche Fa. wäre die AudioWerft aus Hildesheim mit Matthias Mehler. (Ich bekomme sogar immer noch Weihnachtsgrüße, obwohl ich schon seit ein paar Jahren an anderen Orten studiere )
VG,
Hendrik
@yamaha:
Unter einem elektronischenTrafo versteht man ein Schaltnetzteil - im Gegensatz zu dem von Dir beschriebenen konventionellen gewickelten Trafo. Hier kurz die Funktionsweise und der Grund für das Abrauchen.
Über einen Gleichrichter wird beim elektronischen Trafo (ich kürze ab jetzt mit SNT ab) ein Elko vom Netz geladen. Dies ist der sogenannte Zwischenkreis. Über einen Schwingkreis (entweder ein SNT-IC oder rückgekoppelter LC-Kreis) macht eine Halbbrücke aus der Zwischenkreisspannung ein hochfrequentes Rechtecksignal, das über einen kleinen Ferrittrafo in die gewünschte Sekundärspannung übersetzt wird. Über Schottky-Dioden und einer Drossel wird die transformierte Spannung dann wieder in die gewünschte Gleichspannung gewandelt. (Bei vielen Halogendimmern wird darauf verzichtet und direkt die HF-Spannung auf die Last gegeben. EMV-mäßig habe ich da aber meine Bedenken...)
Vorteil eines SNT: geringes Gewicht, wenig Kupfer, hoher Wirkungsgrad.
aber:
Durch den Zwischenkreiselko hast du eine kapazitive (komplexe) Last am Dimmer, was der Gleichrichter oder die Triacs im Dimmer nicht mögen.
Deshalb werden für SNTs Sinewave oder PhasenABschnittsdimmer anstatt der gewöhnlichen PhasenANschnittsdimmer empfohlen.
ABschnittdimmer sind derzeit eher wenig verbreitet, da diese nicht ohne weiteres mit den induktiven Lasten gewöhnlicher Trafos klarkommen.
Zu den Dimmerdetails hat sicher Wikipedia was parat und ich habe dazu auch schon mal etwas geschrieben:
http://www.hoelscher-hi.de/hendrik/light/ressources/AN016.pdf
Viele Grüße,
Hendrik
Eine remote-Verbindung im Internet wäre nicht unmöglich. Oder war nur ein eigenständiger RDM-Controller gefragt?
Bleibt die Frage nach verfügbaren RDM-Pulten/-Dongles.
Mal eine andere Frage:
Was für Pulte/Controller auf dem Markt sprechen denn bereits RDM?
Derzeit seh ich da nur das RDM-Dongle von Enttec, das ich mit 400EUR etwas unverschämt finde...
Ich würde gern meine Arbeit mal verifizieren.
Was soll denn sonst am Wichtigsten sein?
Statusmeldungen?
Wenn das Gerät in der truss hängt und den Geist aufgibt, kann man vielleicht schneller Ersatzteile bestellen - kaputt bleibt es trotzdem.
Und wenn es überhitzt: Was soll man machen? Laufen muss es trotzdem...
Firmware Update?
Die Firmen waren sich nicht einig - deshalb ist keine klaren Vorgaben erhältlich...
Dimmerkurven, Min. und Max.-Begrenzungen?
Auch hier nichts klares, so dass jede Fa. wohl spezifische PIDs einsetzen wird.
Ein Gespräch mit K. Ruling (Schreibweise?) hat mich ziemlich desillusioniert bzgl. RDM.
Wo Du schon schreibst, Mathias:
Wie empfindlich sind eigentlich Eure Geräte hinsichtlich der Time-Outs bei RDM-Paketen? Mit den üblichen FTDI-Wandlern hat man dank Windows Schwankungen von >1ms wodurch ich teilweise gegen die Spezifikation verstoße...
Viele Grüße,
Hendrik
Moin, zusammen!
Ich bekomme in der letzten Zeit ständig Mails mit der Bitte, vorhandene Firmwares für den Transceiver zu modifizieren oder neu zu schreiben.
Da ich in absehbarer Zeit mit meinem Studium fertig bin und dann weniger Freizeit habe, würde ich gern ein paar interessierten Leuten den Einstieg in die AVR-Programmierung und den Umgang mit meinen Libs vereinfachen.
Ich habe daher beschlossen, an einem Wochenende in vielleicht 2 Wochen (Termin noch offen) im Forum von http://www.dmxcontrol.de (da war die Nachfrage am größten) mit Euch in Echtzeit eine Firmware für den Transceiver zur Steuerung von DC-Motoren in C zu stricken.
Die Sache ist ansich nicht aufwendig und ich bin nicht der tollste Programmierer aller Zeiten - aber vielleicht erleichtert es ja dem einen oder anderen den Einstieg...
Schönes WE,
Hendrik
chws Lösung würde funktionieren.
Für die Zuornung bräuchte man die exakte Position und nicht eine grobe Annäherung. Es sei denn jeder Mac der Backtruss macht dasselbe.
Bei dem Einsatz von Chip-Karten etc. könnte man darauf auch die gesamte Parametrierung des Gerätes auslagern und RDM nur noch für status messages nutzen.
Die Auflösung von GPS dürfte zu gering sein. Die Ultraschall Triangulation (?) könnte funktionieren.
Letztlich wird man wohl nach einer vollständigen Discovery alle Geräte identifizieren (nacheinander aufblitzen, wackeln, hupen,...) müssen, um dann richtig patchen und einrichten (Achsen spiegeln, usw.) zu können.
(Die IDENTIFY_DEVICE PID fehlt bei mir sogar glaube ich noch.)
Viele Grüße,
Hendrik
