mini-DMX-Protokoll - Modifikation/Erweiterung

  • Hier mal eine Idee: i.M. geht es ja wieder verstärkt um Pixelmatritzen, Ansteuerung solcher über den PC u.ä.


    Dabei tauchen immer wieder ähnliche Fragen/Problemstellungen auf wie ich habe ne (evtl. selbstgeschriebene, so wie hier) SW am PC, die Daten erzeugt (Animationen etc.) und ne Matrix, die damit angesteuert wird - wie am Besten machen, und gerade bei den komplett selbst gestrickten Sachen kocht da jeder sein eigenes Süppchen... ;)


    DMX ist zwar weit verbreitet, hat hier aber die Beschränkung, dass man mit einem Universe nur 170 Pixel ansteuern kann - und evtl. zusätzliche HW braucht, also erst mal ein oder mehrere DMX-Interface(s), und dann wieder ne HW, die DMX empfängt und damit die Matrix steuert (so wie hier z.B.)


    für wirklich große Setups ist dann wiederum eher was über Ethernet zu empfehlen, das stellt dann aber schon größere Anforderungen an HW und SW, als die meisten hier bewältigen können...


    viele so selbst gebaute LED-Displays haben ja ne Größe zwischen 8x8 bis 16x16 oder 32x16 Pixel, diese Datenmenge ist noch gut über USB zu bewältigen, und von der HW her simpel, ein µC mit USB-Serial-Bridge dran (z.B. FT232) und VCP-Treiber am PC ist alles, was man braucht...


    dann geht's nur noch um das Protokoll, was da drüber soll - und hier wird von einigen hier im Forum schon mini-DMX benutzt, auch von Projekten wie AtmoWin (Ambilight), Steuer-SW wie DMXControl und Freestyler kann dieses Protokoll auch ausgeben...


    Ich würde es daher gut finden, wenn man diesen Standard im Forum "etablieren" könnte, *muss* ja keiner verwenden, aber wenn jemand gerade so was plant und sich selbst noch keine Gedanken über das Protokoll gemacht hat, warum dann nicht dieses, und dann ist möglichst viel hier im Forum vorgestellte HW und SW von Bastlern untereinander kompatibel...


    was haltet Ihr davon...?


    das Protokoll ist ja ganz simpel: der µC empfängt Bytes über die serielle Schnittstelle bzw. USB mit Bridgechip - das sid im wesentlichen dann hier eben die RGB-Daten, dazu ein Header zum synchronisieren...


    es kommt also zuerst 0x5A, dann als Angabe der Framegröße entweder 0xA0, 0xA1 oder 0xA2, dann die Nutzdaten, und danach 0xA5, wobei


    0xA0 = 96 Byte Nutzdaten
    0xA1 = 256 Byte Nutzdaten
    0xA2 = 512 Byte Nutzdaten


    also im Original maximal auch nur ein DMX-Universe...


    nun ist es aber kein Problem, mit ausreichender Framerate bei entsprechender Geschwindigkeit an der seriellen Schnittstelle auch größere Frames zu übertragen - von mir getestet wurde bis 3.072 Kanäle mit stabil 33 fps, bei 1 Mbit/s seriellem Input. Das reicht dann schon für ne Matrix mit 32x32 Pixeln...


    ich schlage also nun einfach eine simple Erweiterung des Protokolls um weitere Framegrößen vor, und zwar:


    0xB0 = 768 Byte Nutzdaten (= 256 RGB-Pixel, also z.B. Matrix 16x16)
    0xB1 = 1.536 Byte Nutzdaten (= 512 RGB-Pixel, also z.B. Matrix 32x16)
    0xB2 = 3.072 Byte Nutzdaten (= 1.024 RGB-Pixel, also z.B. Matrix 32x32)


    da sollte für jeden ein passender Kompromiß zwischen Overhead und Nutzdaten dabei sein, ich werde für meine 20x10-Matrix dann z.B. 0xB0 nehmen, auch wenn es nur 200 Pixel sind - man muss auf Empfängerseite ja auch nicht den kompletten Frame speichern, sondern nur die benötigten Bytes, um RAM zu sparen...


    32x32 ist dann schon ziemlich Ende der Fahnenstange bei der Methode, sollte aber für die meisten reichen...


    hier eine Übersicht, welche Frameraten dann bei welchem Modus und Datenrate erreichbar sind:


    Code
    .          250k     500k     1Mbit
    0xB0     32 fps   64 fps   128 fps
    0xB1     16 fps   32 fps    64 fps
    0xB2      8 fps   16 fps    32 fps


    (gerundet, wie gesagt, 3.072 Byte über 1 MBit haben in der Praxis 33 fps ergeben, das reicht...)


    im Original wird dann eine Bestätigung zurück gesendet, also 0x5A 0xC0 0xA5 für "ausgeführt" - das ignorieren die meisten Sender aber...


    da es sich auch nur um ein Byte Info handelt, finde ich die Bytes für Blockstart und Blockende hier überflüssig, würde also nur ein Byte zurück schicken, das reicht - bei mir ist das z.B. 0xAC für "ACknowledge" als Bestätigung - ist so in der SEDU-Ambilight-SW drin und wird auch benutzt...


    Dort gibt es auch noch eine Erweiterung - kommt nach dem Blockstart statt A0 - A2 etc. ein 0xFF, dann sind die folgenden Daten Steuerbefehle - wie diese wiederum aussehen, ist dann anwendungsspezifisch, ich benutze das z.B. für die Konfiguration des SEDU-Ambilight über Terminal bwz. Config-Tool...


    Bei den Nutzdaten würde ich das dann so machen, dass diese "generisch" gesendet werden, also immer je ein Byte R, G und B, von links oben nach rechts unten - wenn eine Matrix z.B. weniger Farbtiefe als 24 Bit hat, oder von der Pixelreihenfolge her anders verkabelt ist, dann kann man das Umrechnen/Umsortieren im Controller machen, weil *der* gehört ja zur Matrix dazu, der *weiß*, wie diese die Daten braucht - wenn schon in der PC-SW ne bestimmte Reihenfolge oder Farbtiefe etc. festegelegt wird, dann ist man nicht mehr flexibel... so (generische Daten) kann man dann im Prinzip jede Matrix mit jeder Steuer-SW ansprechen


    Also, wer alles mit der Thematik beschäftigt ist, schreibt doch mal hier, was Ihr davon haltet - also wie Ihr es generell finden würdet, wenn man sich hier im Forum auf so nen Standard einigen könnte, und ob dieser hier passen würde oder was man dran verbessern könnte...

    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!

    Einmal editiert, zuletzt von Pesi ()

  • Ja, das ist schon eine sehr gute Idee. Es gibt ja auch noch Wünsche, das Ambilight mit mehr Kanälen aufzubohren. Da würde man aber sicher mit den vorhandenen Codes noch auskommen.


    1024 Pixel machen ja auch die gängigen China-Controller wie der Ledwalker. Der bietet aber auch einige Protokolle mit 2048 an. Aber 1024 ist schon eine gute Größe. Beim Onumen sind es pro Port nur 512, aber dafür 8 Ports (die aber dann per Ethernet).


    Sind eigentlich die Bytes nach A2 schon reserviert? Wenn nicht würde ich es logischer finden, da mit A3 usw. anzusetzen. Was ich super finden würde, wenn das in den "offiziellen" Standard von miniDMX einfließen würde. Dann gäbe es eine Version 3.0 des Protokolls.

    Zitat

    Original wird dann eine Bestätigung zurück gesendet, also 0x5A 0xC0 0xA5 für "ausgeführt"

    kleine Korrektur: bei C1 ist der Befehl ausgeführt, C0 steht für einen Fehler. Ich denke, diese Bestätigung zu ändern wäre für das offizielle Protokoll nicht gut, denn einige Software wird sich darauf verlassen. Für das SEDU sollte es aber kein Problem sein, 3 Bytes zu senden, oder? Damit wird ja auch nichts gemacht.


    Die Erweiterungen müssten eben so sein, dass das originale Protokoll bestehen bleibt und es wirklich nur Erweiterungen sind. Dann funktioniert die bisher erhältliche Software einfach weiter. So könnte auch der FF-Befehl für custom-Erweiterungen problemlos implementiert werden. Hier weiß man dann, dass es vom Standard weggeht und nur noch kompatible Geräte das verwenden können. Aber die Byte-Folge bleibt unverändert.


    Ich hätte auch kein Problem, noch ein weiteres Byte mit 2048 Kanälen zu reservieren. Dann sind es eben nur noch 16 Frames. Aber es gibt bestimmt Anwendungen, wo das ausreicht.


    Ich bin gerade an der Vorbereitung einer Software für den RGBW-Controller. Da könnte ich mir gut vorstellen, das Protokoll zu nutzen, auch wenn die Datenmenge eher gering ist.


    Edit: blöde Frage: warum sendet das man an das SEDU eigentlich A5 5A A1? Es geht doch eigentlich mit dem 5A los.

  • Ja, "erwischt".. :D - das ist dort eine weitere kleine Modifikation, die sich aber nicht auf die Kompatibilität auswirkt...


    im Prinzip, man könnte ja - wenn Sender und Empfänger gleichzeitig starten, und garantiert kein Byte verloren geht - auch reine Nutzdaten schicken. Das geht aber in der Praxis natürlich nicht, deswegen gibt es ja hier die Blockstart-Bytes.


    die Empfangsroutine wartet praktisch drauf (nach dem Einschalten, oder wenn's nen Fehler gegeben hat), dass sie die Bytefolge 5A A1 bekommt, da fängt der neue Block an. Das funktioniert deswegen, weil es relativ unwahrscheinlich ist, dass ausgerechnet 5A A1 in den Nutzdaten vorkommt, und die Routine somit an der falschen Stelle "einrastet".


    Ich warte nun nicht auf "Blockstart", sondern auf "Blockende, Blockstart", einfach weil es dann eben noch mal 256x unwahrscheinlicher ist, dass diese Folge A5 5A A1 in den Nutzdaten vorkommt... ;)


    beim Daten empfangen ist's ja wurst, Du hast ja immer:


    5A A1 Nutzdaten A5 5A A1 Nutzdaten A5 5A A1 Nutzdaten A5 5A A1 Nutzdaten A5 5A A1 Nutzdaten A5 5A A1 ....


    also reine Definitionssache, wo das A5 nun "dazu gehört", "A5 5A A1" ist einfach immer der "Trenner" zwischen den Daten - und bei den Befehlen (A5 5A FF), das ist im Protokoll ja nicht vorgesehen, also sowieso nicht "Standardkompatibel"... würde ich hier dann aber schon so machen, dass ein Befehl eben mit 5A FF anfängt... da man die normal nicht kontinuierlich sendet, ist dort auch die Gefahr geringer, dass die Routine an ner falschen Stelle ansetzt...


    dieses Blockende-Byte ist ja nur wirklich sinnvoll, wenn man die Daten puffern kann - dann empfängt man nen Block, und schaut, ob A5 hinterher kommt - wenn ja, dann wird der Frame übernommen, wenn nicht, dann ist bei der Übertragung was schief gelaufen, und der Frame wird verworfen... aber da hat man ja meistens zu wenig RAM, um nen kompletten Frame noch mal zu puffern.

    Ich hätte auch kein Problem, noch ein weiteres Byte mit 2048 Kanälen zu reservieren. Dann sind es eben nur noch 16 Frames. Aber es gibt bestimmt Anwendungen, wo das ausreicht.

    klar, wäre kein Problem, dann halt B3 für 6.144 Kanäle - und wenn man den USART auf 2 MBit stellt (FT232 sollte das auch können), dann hätte man auch da 32 fps... auch da wäre eine Weitergabe an die WS2801 noch problemlos möglich, wenn man mit den Daten nix aufwändiges mehr machen muss (wie umsortieren o.ä.)


    ich habe ja auch deswegen mit B0 angefangen, weil man da noch "Luft" hat für weitere Sonder-Framegrößen - bei "A" wäre nur noch A3 und A4 frei, dann kommt ja Blockende A5, und dann könnte man bei A6 weiter machen - auch irgendwie doof... so hat man 16 mögliche Framegrößen, wäre durchaus denkbar, eine z.B. für RGBW-Controller mit eben nur 4 Byte Nutzdaten vorzusehen...


    Da wäre es aber eben sinnvoll, wenn möglichst viele mit geplanten Anwendungen Vorschläge machen würden, damit man sich dann auf 16 Framegrößen einigen kann, die die meisten Fälle abdecken - und die dann nach Größe sortieren, statt dass es da dann irgendwie durcheinander geht, also z.B. B4 ist wieder kleiner als B3 o.ä.

    Ich bin gerade an der Vorbereitung einer Software für den RGBW-Controller. Da könnte ich mir gut vorstellen, das Protokoll zu nutzen, auch wenn die Datenmenge eher gering ist.

    Klar, dann nimm' doch einfach das Original mit 96 Kanälen... oder eben (siehe oben) z.B. "BF" für 4 Byte Nutzdaten...


    wobei ich da an Deiner Stelle eher das Original mit A2 nehmen würde - weil, Du musst ja nicht alle Bytes abspeichern, die rein kommen, man kann das ja wie bei "normalem DMX" auch so machen, dass Du nur die 4 relevanten Bytes entnimmst - dann könnte man Deinen RGBW-Controller *direkt*, ohne weiteres Interface mit Freestyler und DMXcontrol ansteuern... ;)

    kleine Korrektur: bei C1 ist der Befehl ausgeführt, C0 steht für einen Fehler. Ich denke, diese Bestätigung zu ändern wäre für das offizielle Protokoll nicht gut, denn einige Software wird sich darauf verlassen.

    Ja, sorry, C1 natürlich - aber m.W. fragt da sowieso keiner nach, also Atmowin garantiert nicht, die Plugins für Freestyler und DMXcontrol m.W. auch nicht...


    aber man könnte das ja so machen, dass eben bei den "Sonderformaten" B0 - Bx dann eben einfach nur "AC" als Bestätigung zurück gesendet wird, bei A0-A2 die "alte Norm", ist ja reine Definitionssache... dann bleibt es auch zur alten Norm kompatibel.

    Für das SEDU sollte es aber kein Problem sein, 3 Bytes zu senden, oder? Damit wird ja auch nichts gemacht.

    Ja - i.M. ist's halt so, nach dem empfangen der Nutzdaten (also eigentlich auch an der falschen Stelle, schon vor dem Blockende-Byte) schiebe ich 0xAC in's UDR-Register, also wird dieses Byte gesendet. Direkt in der Empfangsroutine.


    Ich kann nicht in der Empfangsroutine in ner Schleife 3 Bytes senden, weil in der zeit könnten schon wieder 3 rein kommen - und ne völlig unabhängige Senderoutine, die dann die 3 Bytes raus schickt, ist halt wieder zusätzlicher Aufwand - es wäre halt wesentlich einfacher, wenn die Bestätigung nur aus einem Byte besteht, und für ein Byte ist ja nun kein "Blockstart" und Blockende nötig... ;)


    das braucht man meistens ja sowieso nicht - ich nutze das im Zusammenspiel mit dem Treiber von meinem Kumpel, damit die Ausgabe synchronisiert erfolgt: Der schickt mir ein Datenpaket, das wird komplett verarbeitet (umsortiert und an die WS2801 ausgegeben), dann schicke ich erst "AC", und so weiß der PC, dass er das nächste Paket schicken kann.


    Das geht hier bei meiner 200-Kugel-RGB-Matrix, bei größeren Datenmengen muss das dann "parallel" laufen, also da wird dann vom PC einfach nur - wie bei "normalem DMX" - stur geschickt, ohne auf ne Bestätigung zu warten...


    Und, klar, wäre super, wenn das in den "ofiziellen Standard" (der ja letztlich auch von einem Bastler festgelegt wurde) einfließen würde, da müsste man dem einfach mal schreiben, ob er es auf seiner Seite veröffentlicht - ansonsten ist's halt dann einfach der "Ledstyles-Pixelstream"-Standard oder wie auch immer genannt... ;)

    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!

  • Ok, Danke für die ausführliche Erklärung. So wird mir alles klar. Jetzt müsste "man" das mal als Spezifikation verfassen ;) .


    Dann gäbe es noch eine Idee: man könnte das Protokoll auf AVR-Seite ja schon in einer Software-Lib zusammenfassen. Dann kann es jeder sehr einfach einsetzen und damit wird es auch sicher weiter verbreitet...

  • EDIT Pesi: Die Antwort bezieht sich z.T. auf o.t. zur Datenübertragung im allgemeinen, der in diesen Thread ausgelagert wurde...


    Hallo,


    dann will ich mich auch mal zu Wort melden, nachdem ich einen Hinweis bekommen habe, dass in diesem Forum über eine Erweiterung des MiniDMX-Protokolls diskutiert wird.


    Ich habe im Jahr 2001 die erste Version vom MiniDMX-Protokoll ins WWW gestellt. Das genaue Datum ist der 18.2.2001. Jetzt habe ich doch glatt die 10 Jahresfeier verpasst. Damals habe ich nicht damit gerechnet, dass das Protokoll sich so weit verbreitet. Das lag wohl daran, dass der MiniDMX einfach und preiswert nachzubauen war. Zudem waren der Schaltplan und die Quelltexte der Firmware frei zugänglich. Schnell haben dann auch die ersten Lichtsteuerprogramme für den PC einen Treiber für das MiniDMX-Protokoll eingebunden. Und nun wird es auch für die Ansteuerung von hunderten von LEDs verwendet.


    Zur aktuellen Diskussion hier will ich auch etwas beitragen. Vorab möchte ich aber noch auf Folgendes hinweisen: Jedem ist es freigestellt das MiniDMX-Protokoll als Vorlage zu nehmen, mit eigenen Erweiterungen zu versehen und dann zu veröffentlichen. Er sollte dann aber deutlich darauf hinweisen.


    Jetzt zu den Diskussionspunkten hier im Forum:


    Warum hat das MiniDMX-Protokoll keine Fehlererkennung?


    Es wird davon ausgegangen, dass der Übertragungsweg hinreichend fehlerfrei ist. Warum nur "hinreichend"? Erstens werden keine sicherheitskritischen Anwendungen mit dem Protokoll realisiert. Zweitens treten in der Praxis Fehler so extrem selten (oder gar nicht) auf, dass der Aufwand einer Fehlererkennung in keinem Verhältnis dazu steht.


    Noch ein paar weitere Punkte dazu:


    Eine Prüfsumme (CRC) erkennt auch nicht alle Fehler. Ein nicht erkannter Fehler wird nur unwahrscheinlicher. Eine perfekte Fehlererkennung gibt es nicht. So ist leider die Realität.


    Bei einer Datenrate von 1 MBit/s wird eine Echtzeitberechnung einer CRC-16 auf einem Mikrocontroller schwierig.


    Häufig wird das MiniDMX-Protokoll über eine USB-Schnittstelle oder Ethernet-Verbindung verwendet. Diese Verbindungen besitzen bereits eine gute Fehlererkennung und sogar eine Fehlerkorrektur.


    Kann es denn beim Verbinden oder Trennen der Leitung zu fehlerhaften Übertragungen kommen?
    Kann es zu Fehlern kommen, wenn der Wert $5A (Blockstart) in den Kanaldaten vorkommt?


    Nein. Nicht wenn sich Sender und Empfänger an ein paar Regeln halten, die leider auf meiner MiniDMX-Seite nicht oder schlecht dokumentiert sind. In der MiniDMX-Firmware und der Ansteuerungs-DLL ist es aber so realisiert. Hier spielt auch das Antwort-Paket seine Stärken aus:


    1. Der Sender schickt ein Paket und wartet mindestens 100 ms (Millisekunden) auf eine Antwort. Ein neues Paket kann direkt nach der Antwort oder nach der Wartezeit verschickt werden.
    2. Der Empfänger überprüft Blockstart, Blocktyp und Blockende. Sobald ein Wert fehlerhaft ist, wird wieder auf Blockstart gewartet. Die bisher empfangenen Daten werden verworfen.
    3. Wenn der Empfänger 100 ms lang nichts vom Sender hört, auch z.B. mitten in einem angebrochenen Block, dann wartet der Empfänger auf den nächsten Blockstart. Die bisher empfangenen Daten werden verworfen.
    4. Der Empfänger muss natürlich Antwort-Pakete verschicken, damit die Aktualisierungsrate größer als 10 Hertz ist.


    Damit dürfte das "alte" Protokoll nun hinreichend sicher sein.


    Tatsächlich gibt es aber schon mehrere Anfragen bezüglich einer Protokollerweiterung. Insbesondere wird immer wieder nach einer größeren Kanalanzahl gefragt, wie auch hier.


    Ich werde mal eine MiniDMX-Protokoll Version 3 vorbereiten. Sie wird vollständig abwärtskompatibel sein und weitere Blockgrößen beinhalten. Die Blockgrößen werden aber ein Vielfaches von 512 Kanälen (einem DMX-Universe) sein. Die Obergrenze wird auf jeden Fall mindestens 3072 Kanäle sein.


    Gruß
    Mathias

  • Eine Version 3 des Protokoll klingt interessant. Vielleicht kann ja das eine oder andere hier noch einfließen. Pesi hat da immer gute Ideen. Klar, die Abwärts-Kompatibilität muss vorhanden sein. Wir haben ja im Protokoll für das SEDU-Board noch eine Erweiterung für Daten, die nicht angezeigt werden sollen. Wäre so eine Erweiterung auch denkbar? Sowas wird ja kaum standardisierbar sein, aber zumindest das Funktionsbyte 0xFF könnte dafür stehen.

    Dort gibt es auch noch eine Erweiterung - kommt nach dem Blockstart statt A0 - A2 etc. ein 0xFF, dann sind die folgenden Daten Steuerbefehle - wie diese wiederum aussehen, ist dann anwendungsspezifisch, ich benutze das z.B. für die Konfiguration des SEDU-Ambilight über Terminal bwz. Config-Tool...

    Andererseits müsste es ja eigentlich so sein, dass der Empfänger die Daten igrnoriert, wenn er sich an obige Regeln hält.

  • Hi Mathias,


    schön, dass Du Dich hier mal meldest! :)

    nachdem ich einen Hinweis bekommen habe, dass in diesem Forum über eine Erweiterung des MiniDMX-Protokolls diskutiert wird.

    Hm, naja, ausser dieser o.t.-Diskussion über die Sicherheit hat das leider niemanden so richtig interessiert - hier z.B. wurde das Mini-DMX-Protokoll mit den neuen Framegrößen eingebaut, das war's dann schon...


    Es wird davon ausgegangen, dass der Übertragungsweg hinreichend fehlerfrei ist. Warum nur "hinreichend"? Erstens werden keine sicherheitskritischen Anwendungen mit dem Protokoll realisiert. Zweitens treten in der Praxis Fehler so extrem selten (oder gar nicht) auf, dass der Aufwand einer Fehlererkennung in keinem Verhältnis dazu steht.

    Ganz genau so sehe ich das auch - und wie schon gesagt, es wird ja kein Kernkraftwerk damit gesteuert, wenn alle 2 Minuten mal in einem Frame ein Pixel Rot statt Orange ist, kann ich zumindest leicht damit leben... ;)


    Hatte mal aus Neugier ne kleine SW in Processing gemacht, die erzeugt ne Zufallszahl, schickt die raus, µC schickt sie wieder zurück, Processing vergleicht, und gibt Meldung, wenn das Byte fehlerhaft ist - dann laufen lassen, so nach ca. 5 Minuten kam das erste mal ne Fehlermeldung, dann über 10 Min. keine mehr, dann hatte ich keine Lust mehr zum zuschauen... :D


    2. Der Empfänger überprüft Blockstart, Blocktyp und Blockende. Sobald ein Wert fehlerhaft ist, wird wieder auf Blockstart gewartet. Die bisher empfangenen Daten werden verworfen.
    3. Wenn der Empfänger 100 ms lang nichts vom Sender hört, auch z.B. mitten in einem angebrochenen Block, dann wartet der Empfänger auf den nächsten Blockstart. Die bisher empfangenen Daten werden verworfen.

    Das geht wie gesagt nicht immer, z.B. bei mir, mit den 768 Byte in nem Mega16, da habe ich einfach nicht genug RAM, um nen empfangenen Frame und die Daten für die Ausgabe abzulegen, also werden die Daten immer gleich gespeichert, ich kann keine Frames verwerfen...


    4. Der Empfänger muss natürlich Antwort-Pakete verschicken, damit die Aktualisierungsrate größer als 10 Hertz ist.

    > 10 Hz ist bei mir noch zu wenig, mir geht's um möglichst viele Pixel mit möglichst hoher Framerate - bei dieser Pixelcontroller-SW wird angezeigt, ob/wann die Bestätigung zurück kommt, da sind's oft mehr als (müsste noch mal nachgucken) 40 ms (so lange wird dort gewartet) - die SW schickt unabhängig davon weiter raus, würde sie tatsächlich den neuen Frame erst nach Bestätigung schicken, dann wäre das dort schon ne recht ruckelige Angelegenheit...


    Das hat wohl auch mit dieser Puffer-im-FT232-Sache zu tun...


    Darum bin ich auch - für meine Zwecke - auch gar nicht so sehr an einer korrekten Implementierung (mit der Rückmeldung, Wartezeiten, doppelt puffern) interessiert - ich komme ja aus der "klassichen DMX"-Ecke, dort wird auch einfach gesendet ohne Rückmeldung... ich vertraue bei sowas schon darauf, dass 99,9999% der Daten richtig ankommen... ;)


    Bei dieser PixelController-SW wäre es mir sogar lieber, wenn die Rückmeldung ignoriert würde, da ich normale DMX-Leitung verwende, muss ich so immer 2 Leitungen vom Rechner zum Controller ziehen, damit die SW den Com-Port (Autodetect) erkennt - da wäre es mir lieber, wenn man den Com-Port einfach einstellen könnte, und das Teil dann da "fire & forget"-mäßig rausschickt...


    Bei der von Turi erwähnten Ambilight-Sache schicke ich z.B. auch gar keine Bestätigung zurück, AtmoWin macht das eben auch so, Daten rausschicken, werden schon ankommen.... :D


    und prüfe auch gar nicht auf Blockende - weil ich wie gesagt eh' nicht die Möglichkeit habe, einen Frame zu verwerfen...


    bei mir ist praktisch A5 5A A1 der Startcode - nach diesem wird "gescannt", wenn er erkannt wurde, werden die 256 Byte abgezählt, danach wieder auch A5 5A A1 gewartet... da beim Dauersenden (in AtmoWin ist das wie gesagt auch kein 100% "echtes" Mini-DMX, da wird nicht 100 ms oder auf Antwort gewartet) diese Kombination immer zwischen 2 Blöcken Nutzdaten vorkommt, erkennt meine Empfangsroutine die Daten auch korrekt...


    das führt dann eben auch dazu, dass diese Konfigurations-Befehle nicht mit 5A losgehen, sondern eben mit A5 5A... man hätte natürlich das Blockende-Byte auch einfach komplett ignorieren können, aber nach "A5 5A A1" zu prüfen, verringert die Wahrscheinlichkeit, dass der Empfänger "falsch einrastet" (was bei sich ändernden Daten ja eh' maximal für einen Frame passieren kann) eben nochmals im Gegensatz zu "5A A1"...


    Turi: so "richtig" abwärtskompatibel ist die "Erweiterung" im Ambilight auch nicht, wenn da ein echter mini-DMX-Sender (also streng nach Protokoll) dran ist, dann wartet der immer 100 ms vergeblich auf Antwort, also *max* 10 fps erreichbar...

    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!

  • Es gibt hier nun mal Neues - der User "T64" und ich haben eine Tabelle mit neuen Framegrößen erstellt, die weitere User auch praktikabel finden... diese ist praktisch in DMX-Universes abgestuft, also Schritte von 512 Bytes, mit der zusätzlichen Sondergröße 768 Bytes, weil diese genau für eine RGB-Matrix mit 16x16 reichen, was auch eine gängige Größe (Pixeltische etc.) ist.


    Nur noch mal zur Sicherheit/Verdeutlichung: Es geht hier in diesem Thread *nicht* darum, den offiziellen Mini-DMX-Standard zu erweitern oder zu modifizieren, das kann nur der Erfinder des Protokolls, der hier weiter oben auch schon als" MDZ" gepostet hat - nur er kann eine neue Version von Mini-DMX vorstellen, die ist wohl gerade in Arbeit.


    Der Thread ist dazu angelegt, ein Protokoll *auf Basis von* Mini-DMX zu schaffen, das für LED-Matritzen praktische Framegrößen enthält, und eben zu echtem Mini-DMX abwärtskompatibel ist, damit man nicht für kleinere Sachen wieder was anderes braucht...


    da es nun schon 3 Freeware-Lösungen zur Matrixsteuerung hier im Forum gibt, von denen bereits 2 modifiziertes Mini-DMX ausgeben können (bei der 3. gerade in Arbeit) wäre es durchaus sinnvoll, sich möglichst schnell auf einen gemeinsamen zumindest Forums-internen Standard zu einigen, damit nicht jede SW das anders ausgibt oder dann irgendwann noch mal umgebaut werden muss...


    hier mal noch aus dem anderen Thread, das gehört ja eher hier her:


    andere Idee noch: B0 bleibt für 768 Bytes, B1 ungenutzt, und dann könnte man praktisch ab B2 = 1.024 Bytes anfangen, das wäre leichter zu merken, also B2 = 2 Universes, B3 = 3 Universes, usw.


    wie im verlinkten Thread schon gesagt, "richtiges Mini-DMX" ist das nicht mehr, erstens eben wegen den Framegrößen, zweitens weil man bei den größeren Werten in nem üblichen AVR einfach nicht genug Speicher hat, um nen Frame zu puffern und bei Fehler zu verwerfen, ausserdem reichen die bei Mini-DMX festgelegten 115,2 k bei größeren Frames nicht mehr - da wäre dann auch eine "Norm" (bzw. Empfehlung, Boblight z.B. kann halt einfach keine 250 k) ganz cool, die zu jeder Framegröße die Datenrate so festlegt, dass mind. 25 fps erreicht werden...


    Tabelle würde dann so aussehen:


    Code
    B0 =   768 Kanäle - 250 k - 32 fps - Sondergröße RGB 16x16
    B1 - reserviert -
    B2 = 1.024 Kanäle - 500 k - 48 fps - 2 Universes
    B3 = 1.536 Kanäle - 500 k - 32 fps - 3 Universes bzw. RGB 32x16
    B4 = 2.048 Kanäle -   1 M - 48 fps - 4 Universes
    B5 = 2.560 Kanäle -   1 M - 39 fps - 5 Universes
    B6 = 3.072 Kanäle -   1 M - 32 fps - 6 Universes bzw. RGB 32x32


    mit der Option, das noch auf mehr Kanäle und 2 Mbit zu erweitern, wenn nötig und möglich


    Zu der Rückmeldung und verwerfen von falsch empfangenen Frames (Wie von MDZ oben genau erklärt) gibt es auch noch was in einem anderen Thread, m.M. ist das nicht nötig, ohne Rückmeldung und doppelt puffern wird das Ganze leichter, auch gerade bei großen Framegrößen kann diese Rückmeldung evtl. wieder Verzögerungen verursachen - dazu wurde hier im Forum auch schon mal was geschrieben zum Thema Buffer im FT232, der bis zu 16 ms warten kann, wenn man nur 3 Bytes sendet...


    darüber kann und soll man ja aber auch diskutieren, dazu ist dieser Thread hier da... ;)

    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!