Entwicklung eines Universal-USB-/DMX-/Ambilight-Controllerboard Mega16

  • Also von mir zumindest nicht... die Helligkeit kann man ja z.B. im AtmoWin selber einstellen, die Optionen meiner SW (Farben tauschen, Pixel wiederholen) stellt man ja nur ein mal passend ein...


    *geplant* ist später noch, dass das Teil im Standalone-Modus (also wenn vom Rechner keine Daten kommen) dann per FB wie ein üblicher RGB-Controller zu bedienen ist...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hi,


    hab schon mal mit nem atmega16 2801 und dmx getestet. Leider bin ich bissl enttäuscht von den dimming steps. Ich dachte mit ws2801 kann ich jetzt mit dmx einfach smooth dimmen. Aber im moment sehe ich die steps beim dimmen. Woran liegt das? An dem DMX protokoll selbst?

  • Ok verstehe. Na ja, 8 bit reicht ja erstmal ;)


    Mir fällt da ein, dass bei manchen Movingheads z.b pro pan und tilt kanal, 2 kanäle benutzt werden um damit doppelte (16 bit) präzision zu erzeugen. Weiss aber nicht ob man das hier bei pixel leds auch so umsetzen kann...


    Mich wundert es halt, dass in youtube bei manchen videos auch bei langsamen farb-übergängen die pixels so smooth laufen. Was machen die denn anders?

  • Hi,


    wobei man selbst bei 10 bit noch genau die Abstufungen sieht. Die unterste Stufen wird man halt normal immer sehen, da dürften dan auch 16 bit nicht besonders weiterhelfen. Spätestens bei der letzten Stufe wird es eng, von Helligkeit 0 auf Stufe 1 der PWM sind nun mal unendlich Helligkeitsunterschied, Division durch 0 halt.


    Also ich finde man kann z.B. bei einer 10 Bit PWM die unteren 10 bis 15 Stufen gut erkennen, danach wirds schwierig.


    Gruß, Benny.

  • Mir fällt da ein, dass bei manchen Movingheads z.b pro pan und tilt kanal, 2 kanäle benutzt werden um damit doppelte (16 bit) präzision zu erzeugen.

    Das ginge hier natürlich auch, wäre aber nicht sinnvoll - bedingt durch die logarithmische Empfindlichkeit des Auges würdest Du da zwischen 63.000 und 65.535 kaum nen Unterschied sehen, genauso wenig wie bei 8 Bit zwischen 250 und 255


    Dafür bräuchtest Du aber pro Kanal zwei DMX-Kanäle, könntest also nur noch die Hälfte der Leuchten ansteuern, das wäre ja Quatsch... aus dem Grund kann auch keine (mir bekannte) Lichtsteuer-SW 16-Bit-Daten für sowas erzeugen...


    bei besseren Fixtures (GLP Impression, ETC Selador, iPix BB4/BB7, etc.) wird daher mit 12 oder 16 Bit gedimmt, die empfangenen Daten werden aber von 8 Bit mittels einer Tabelle auf die 16 Bit "umgerechnet", und zwar so, dass Dir der Helligkeitsunterschied zwischen 1 und 2 genauso groß vorkommt wie zwischen 254 und 255...


    und da (bei 16 Bit) sieht man dann wirklich überhaupt kein "Ruckeln" mehr - zwischen Stufe 1 und 2 eigentlich kein Unterschied feststellbar, erst wenn man ein paar Stufen raufdimmt, merkt man, dass es heller geworden ist...


    und, klar, der Unterschied zwischen kleinster Stufe und aus ist immer unendlich, auch bei ner "Glühbirne", da gibt's auch irgendwo nen Punkt, wo man sagt, "ah, jetzt leuchtet sie gaanz schwach", und drunter ist sie aus - im Extremfall ist's eben ganz aus oder es kommt *ein Photon* raus... das wäre die kleinstmögliche Stufe :D


    Mich wundert es halt, dass in youtube bei manchen videos auch bei langsamen farb-übergängen die pixels so smooth laufen. Was machen die denn anders?

    Hast Du mal ein Beispiel..? - evtl. ist's ja höhere Aufösung... hängt auch vom Fading-Programm ab, wenn z.B. eine Farbe hochfadet während ein andere noch an ist, fällt das auch nicht soo sehr auf - und das Video "schmiert" die Übergänge auch noch etwas zu, je nach Qualität der Kamera/Codec kann das auch so sein, dass Du die untersten Stufen gar nicht unterscheiden kannst... und in echt ruckelt das Teil da auch etwas

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ja, das mit "pro kanal 2 dmx kanäle" ist quatsch. Dann nehme ich doch lieber die "mehr pixel pro universe" version.
    Photonen von ner glühbirne hab ich bis jetzt noch nicht gesehen (vielleicht sollt ich noch n schluck bier trinken), und wenn ich sie sehen sollte, nehm ich den stecker raus. ;)


    Hab zwar minimal ahnung vom programmieren und so, aber ich sehe halt, dass in allen modulen die henne dmx routine benutzt wird. Deshalb frage ich mich, ob man vielleicht bei dieser routine noch was aendern könnte / sollte bzw. ob das überhaupt etwas damit zu tun hat usw. Wenn man nicht da drin steckt, kommen so manche gedanken ins köpfchen :)


    Mir ist aufgefallen, dass es bei manchen videos im netz auch ein bisschen ruckelt. Dennoch stelle ich fest, dass da viele faktoren zu beachten sind. Hab die 2801'er mal über artnet getestet und da dimmen sie schon viel besser. Kommt also auf die matrix-software (und die einstellungen) und den DMX adapter an - sogar, ob die pixel mit satiniertem plexi oder ohne laufen. Da mit dem plexi eine grössere flaeche wahrgenommen wird und es somit mehr ruckelt. Bla bla bla


    Für ein "flickerfreies" dimm-ergebnis nehme man also HQ pc software, artnet und nackte pixel - da merkt man dann am wenigsten, dass die kleinen ruckeln...;)

  • Photonen von ner glühbirne hab ich bis jetzt noch nicht gesehen (vielleicht sollt ich noch n schluck bier trinken), und wenn ich sie sehen sollte, nehm ich den stecker raus. ;)

    ?( - jede Glühbirne gibt Photonen ab, und die mit ner Wellenlänge von ca. 380 - 780 nm kannst Du auch sehen, das nennt man "Licht" :D

    aber ich sehe halt, dass in allen modulen die henne dmx routine benutzt wird

    ?( k.A., was Du meinst..? - ich glaube jetzt nicht, dass sich alle Hersteller von DMX-Equimpent ne simple Routine zum empfangen und abspeichern von Bytes von einem Typen programmieren lassen... :D

    Mir ist aufgefallen, dass es bei manchen videos im netz auch ein bisschen ruckelt. Dennoch stelle ich fest, dass da viele faktoren zu beachten sind. Hab die 2801'er mal über artnet getestet und da dimmen sie schon viel besser. Kommt also auf die matrix-software (und die einstellungen) und den DMX adapter an

    Ah, jetzt verstehe ich! - da hat's bei Dir wohl extrem geruckelt aufgrund von schrottigem DMX-Equipment, nicht primär wegen den 8 Bit... hatte ich früher auch mal, Freestyler mit DMX4All-RS232-Interface - war nett und billig, aber bei 8 Scannern schon merkliches rumzuppeln (da gehen die Daten einfach nicht schnell genug raus), und ca. alle Stunde mal musste man das Teil neu starten (bei Konzerten kein Problem, halt nach jeder Band mal, bei Partys eher nervig... :D) - seitdem nutze ich E:Cue, auch weil's komfortabler ist, da gibt's weder ruckeln noch sonstige Probleme...

    sogar, ob die pixel mit satiniertem plexi oder ohne laufen. Da mit dem plexi eine grössere flaeche wahrgenommen wird und es somit mehr ruckelt. Bla bla bla

    Ja, spielt alles mit rein - auch ob Du direkt drauf schaust oder aus dem Augenwinkel, den Kopf dabei bewegst oder nicht... bei diesen billigen LED-PARs z.b. sehe ich aus dem Augenwinkel bzw. bei Kopfdrehung auch das PWM-Flimmern, bei ruhigem Blick auf ne beleuchtete Fläche dann nicht...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Zitat

    jede Glühbirne gibt Photonen ab, und die mit ner Wellenlänge von ca. 380 - 780 nm kannst Du auch sehen, das nennt man "Licht"

    ich habs doch mit einer runtergedimmten glühbirne gemeint!!! :D

    Zitat

    ich glaube jetzt nicht, dass sich alle Hersteller von DMX-Equimpent ne simple Routine zum empfangen und abspeichern von Bytes von einem Typen programmieren lassen..

    Tja, dann liegt es wohl doch nicht an der dmx routine ;)


    Das thema mit dem schrottigen DMX-Equipment ist ajf ne wichtige sache. Ja, Freestyler benutze ich schon lange nicht mehr. Hatte es nur irgendwann mal getestet. Wie du schon sagst, man kann sich nicht drauf verlassen...
    Was lichttechnik betrifft, habe ich bis jetzt schon einige konsolen hinter mir zb. Grand MA, ETC Congo usw., und leider gehören sie nicht mir, um sie mit nach hause zu nehmen. Für die leds finde ich halt im moment die madrix software sehr gut, wobei bei manchen langsamen effekten die software selbst nicht smooth genug ist. Hat jemand vielleicht erfahrungen mit led/pixel-mapping software, die langsame effekte auch smooth genug rausschickt? Dann bräuchte ich vielleicht noch n tip welches artnet interface reibungslos und wirklich schnell funktioniert. Vielleicht hast du ja da auch schon einige erfahrungen.


    E:Cue sieht ganz gut aus. Nur die http://www.traxontechnologies.com/ seite geht nicht im moment wo sie angeblich "led-solutions" vorstellen. Welches E:Cue produkt hast du denn?

  • Ich hab nen Butler und nen nano, ab&zu leihe ich mir von nem Kollegen die Faderunit aus, die finde ich aber nicht so gelungen (bzw. es fehlen halt nur ein paar Anzeigen und das Ding sollte Motorfader haben, dann wäre es super)


    Ja, Madrix sollte eigentlich die Daten schon flüssig erzeugen - hab' ich in echt noch nicht ausprobiert... muss mal gucken, angeblich geht das mit dem Butler zusammen...


    wird aber langsam bisschen off-topic hier... ;)


    wenn ich das richtig verstehe, hast Du also einfach die DMX-Empfangsroutine und ne WS2801-Ausgaberoutine kombiniert und steuerst damit die Pixel an..? - mach' doch mal die Steuerung direkt vom AVR aus, also da einfach ne Schleife, die Farben hoch- und runterdimmt, und dann die Daten an die WS2801 ausgibt, dann siehst Du, was da maximal möglich ist an smoothness, ohne dass irgendwie Probleme mit DMX oder anderer SW da reinspielen...


    klar, im untersten Bereich wird es da auch etwas ruckeln, das ist bei 8 Bit halt so, auch bei den ganzen "billigen" gekauften LED-Produkten...


    Artnet-Interface habe ich selbst nicht, aber dieses Teil auf Basis des Pollin-Net-IO soll ganz gut funktionieren - siehe z.B. auch hier...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Zitat

    wenn ich das richtig verstehe, hast Du also einfach die DMX-Empfangsroutine und ne WS2801-Ausgaberoutine kombiniert und steuerst damit die Pixel an..?

    Genau! Ich nimm dafür den code von 2bl für den mega16.



    Hast du denn zufällig eine FW, den ich gleich draufflashen kann, um die AVR zu ws2801 ohne dmx und pc software zu testen? Ich glaube auch, dass sich da einiges ändert vom smoothness her. Das wär schon ne geile sache, um zu sehen was die 2801'er in verbindung mit einem AVR jetzt wirklich können oder nicht. Dann könnte ich nämlich gezielt an der sache arbeiten und herausfinden was bei mir nun das ruckeln erzeugt.


    Diesen artnet-io von pollin den du meinst, habe ich gebaut und funktioniert einwandfrei. Frage ist nur ob die FW die drauf ist, jetzt wirklich genauso gut ist wie die artnet interfaces von den grossen im markt. Müsste mal einen vergleich mit nem pro artnet interface machen.


    Gruss

  • Ja, ich mache heute abend an der Ambilight-SW weiter, da kommt auch ein Rainbowfader als Standalone-Programm rein, kann ich dann mal hier reinstellen, wenn es soweit ist, dass der läuft...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • mach' mal die 500 µs-Pause etwas länger... ich hatte das selbe Problem, wenn die ein bisschen zu kurz war - liegt wohl daran, dass die ersten Chips ja da schon mit den Daten "durch" sind und daher in ner Art "Wartestellung", während die weiter hinten weniger Zeit zwischen Datenempfang und Pause haben, die brauchen da wohl ein bisschen mehr...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Um noch mal auf die 8 Bit des PWM-Faders und Youtube-Videos zu kommen. Bei einem Videobild werden die einzelnen Farbkanäle auch nur mit 8 Bit diskretisiert. Das die Stufen nicht so auffallen liegt im Wesentlichen an nicht-optimalen Monitoren und dass man eher selten ein einfarbiges Monitorbild zur Beleuchtung verwendet.
    (Und dann war da noch was mit dem Gamma-Wert...)

  • habe endlich mit den 500us wert rumgespielt aber irgendwie flackert es immer noch heftig. Ausserdem bekomme ich beim kompilieren diese fehler meldung ?( weiss jemand warum?


    Code
    _WS2801.o.d  -c  ../PIXEL_WS2801.c
    ../PIXEL_WS2801.c: In function 'hsv_to_rgb':
    ../PIXEL_WS2801.c:84: warning: 'b' may be used uninitialized in this function
    ../PIXEL_WS2801.c:84: warning: 'g' may be used uninitialized in this function
    ../PIXEL_WS2801.c:84: warning: 'r' may be used uninitialized in this function