Henne-Dimmer-Problem

    hallo,


    ich habe 2 henne-dimmerpacks gebaut....


    zuerst habe ich die firmware von v2.0 drauf gehabt, ich habe trotz definitiv funtionierender hardware immer einen addressierungsfehler erhalten.


    dann habe ich v.3 draufgeladen, seitdem wird gar kein dmx signal mehr erkannt!!!!


    bitte gebt mir tips zum fehlersuchen!!!!


    ich habe sogar schon den prozessor getauscht und arbeite auch mit anti-statik matte....


    ich bin schon ganz verzweifelt...


    lg


    stagepower

    Code Ursache Behebung
    1 x Blinken kein DMX-Signal (oder verpolt) DMX richtig anschließen
    2 x Blinken falsche Startadresse sinnvolle Startadresse eingeben
    Dauerlicht Überhitzung abkühlen lassen / besser kühlen
    Blinken zero crossing -Error zc-Detection verbinden / reparieren
    wild DMX-Overflow (noch nicht erlebt) (mehr Kanäle ausgeben)


    sind die Fehler, die angeblich angezeigt werden. Welchen nennst Du nun Adressierungsfehler?


    Wenn die Hardware definitiv geht, liegt es wohl vor dem Dimmer. Denke mal, dass entweder die Dips nicht funktionieren (Nachmessen) oder was an der DMX-Empfangseinheit nicht tut. Oszilloskop dran und nachschauen.


    Wer genauer Fehler beschreiben kann, macht es dem Rest, der nicht die Brocken auf dem Tisch hat, einfacher, sich in einen Fehler reinzudenken. Wenn Dir also an Hilfe gelegen ist, lass as much as possible Infos rüber.
    Was meint Henne zu dem Problem?


    HTH
    Carsten

    hallo,


    1* Bilnken ist der jetzige Fehler
    2* Blinken war der Fehler mit der alten Firmware (siehe oben)


    DMX-Signal sollte in Ordnung sein, werde aber heute noch ein pult (habe bis jetz dmx-interface verwendet) probieren...


    welche ähnlichen Fehler habt ihr schon gehabt???? noch einem firmware-update kein sig mehr erkannt???


    bustreiber wird heute gemessen!
    Aber warum wird ausgerechnet


    lg


    michi

    Henne dreht langsam am Rad...


    Ich habe vor wenigen Tagen sämtliche Firmwares in der DMX state machine korrigiert, da es zu Problemen an einem ScanOperator gekommen sein soll (Signal nicht erkannt)


    Sowohl die alte Version als auch die neue läuft bei mir.


    Spiele bitte die aktuelle Version auf den Transceiver auf (muss Revision 3.X sein!!) und sage mir was passiert.


    Schlimmstenfalls stelle ich in diesen Thread eine abgespeckte Version der state machine mit source code und modifiziere sie so lange, bis es an allen Geräten läuft...


    Ich denke, das Problem liegt an mir und nicht an der Hardware :(
    Aber wir kriegen das hin!


    Noch was: Du sprichst von einem Adressierungsfehler und V2 - kann es sein, dass Du einen älteren Transceiver verwendest? Die sind von der Hardware inkompatibel... (ein Foto von der Platine wäre da ganz hilfreich...)


    Hendrik

    Zitat

    bitte maile mir mal eine funtionierende firmware an ...


    Glaubst Du, es läuft nicht, weil ich dich quälen will?
    In diesem thread wird es nun darum gehen, zu sehen wo der Fehler liegt, so dass ich


    a) erkenne, welche Firmware du brauchst
    b) Sie so repariert bekomme, dass ich wieder ruhig schlafen kann...


    @Rest:
    Falls Euch ein Fehler auffallen sollte, oder eine Idee habt: Ich wäre Euch wirklich dankbar. Wenn Ihr lieber schreiben möchtet, dass so etwas niemals hätte vorkommen dürfen oder Selbstbau eh sinnlos und gefährlich ist -> bitte neuer Thread (im ersten Punkt stimme ich übrigends zu...)


    NUN GEHT'S LOS:

    1.) Feststellen des Boards:
    Die aktuelle Revisionen (3.X) haben einen 10er DIP und einen Trimmer.
    Falls der Trimmer fehlt, solltest Du das auch erstmal überleben...


    Falls Du einen 8er DIP hast, liegt eine Rev2.X vor Dir. (Diese ließ sich nur auf ch1 -256 addressieren). Ein Upgrade wäre irgendwann ganz sinnvoll - hier sind aber erst einmal die alten Kompilate: http://www.hoelscher-hi.de/hendrik/share/Rev2_2.zip (Wegen unterschiedlichem Pinning der rev können die alten Firmwares evtl. den AVR schädigen - also nicht einfach drauflosprobieren!)



    ===============================


    2.) Du hast eine Rev.3.X vor Dir. Nun wollen wir wissen, ob überhaupt irgendwas an Daten ankommt und die taktfrequenz stimmt.


    Lade dazu bitte PinTest.hex in das Flash: Die grüne LED sollte mit 10Hz Ihren Status wechseln (Du zählst wahrscheinlich intuitiv eher 5Hz). Wenn dem so ist, stimmt dein Takt (8,0000MHz Quarz vorausgesetzt).
    Ohne DMX leuchtet die rote LED stetig. Mit DMX blinkt sie - deutlich langsamer als die grüne. Wenn dem so ist, wissen wir, dass irgendwas Datenartiges im Prozessor ankommt.


    Hier ist das Archiv: http://www.hoelscher-hi.de/hendrik/share/PinTest.zip

    Schade, dass bislang kein feedback kommt...


    Ich RATE jetzt mal, dass wir eine Rev3.X vor uns haben, der takt stimmt und irgendein Signal ankommt...


    3.) STOP BITS
    Offiziell hat DMX 2stop bits. Anfangs wollte es in meiner ersten state machine damit nicht funktionieren. Durch Zufall haben wir mal 1 stop bit eingestellt und seit dem funzte es.
    Vor einer Woche wollte ich mit der aktuellen state machine mal wieder DIN-konform sein :roll:


    Wer den Code näher verstehen will, sollte ab S.143 im ATmega8515-Datasheet nachsehen.


    Dieser Code ( http://www.hoelscher-hi.de/hendrik/share/stop1.zip ) macht Folgendes:
    250kBit/s
    8 data bits
    no parity
    1 stop bit (!!!)


    Grün sollte genauso flackern. Der Transceiver gehorcht (unabhängig von DIPs) auf Startadresse 1. Wenn ch1 >127 leuchtet die rote LED, wenn kleiner ist sie aus.


    Hier ist dasselbe mit 2 stop bits ( http://www.hoelscher-hi.de/hendrik/share/stop2.zip )


    Eines der beiden hex-Files muss passen.

    Für mich klingt das irgendwie schwer nach ner 2.X-Platine...


    Schade, dass die neuen nicht kompatibel sind, ich fand die mit dem Trafo drauf sooo schön. :cry: Ideal für Testzwecke, ich musste nicht immer noch mit dem Netzteil rumfuchteln. Werd mir wohl demnächst mal ne 3er ätzen oder bei dir bestellen...

    Ich weiß, Stefan - mir geht's ähnlich. Ich kann blos die Leistung nicht im Vorfeld wissen (Dimmer, LED,...) und außerdem war Kopfsteinpflaster so ne Sache (Mir hats mal nen dickeren Printtrafo halb abgeschüttelt.) Der Schritt musste leider also sein.
    Grund für die Inkompatibilität ist letztlich auch der 10er DIP: Ohne ihn kann man nur 256Adressen einstellen, was auf ziemliche Kritik gestoßen ist - nun ist er drin und man muss halt evtl. noch mal in den Keller... (bitte nicht mit Rumfräsen anfangen!!)


    lassen wir uns überraschen - vielleicht macht auch das Stopbit das Rennen...

    Zitat von "Henne"

    Schade, dass bislang kein feedback kommt...
    Offiziell hat DMX 2stop bits.


    das mit den 2 Stoppbits ist so ne Sache. Wenn der Mark oder Inderdigit knapp oder gar nicht vorhanden sind, gibt`s Ärger.


    Wegen welchem Sender hast Du Deine Statemachine geändert? Warum dann gleich bei allen Geräten?

    Mark ist im Standard vermerkt und in die DIN übernommen worden - es wäre also eigentlich theoretisch alles so einfach...


    Pult: ScanOperator (ich weiß...) eines Kunden, den ich nie in den Fingern hatte. Wieso ich schnell alles anpasse? Bei mir funzt beides, es entspräche dem Standard (...)


    Wenn jetzt rauskommt, dass ich mit diesem Schritt vom Regen (theoretisch ein Pult) in die Traufe (alles hakelt) gekommen bin, werde ich das am WE noch wieder umstellen :twisted:

    hallo,


    sorry das ich mich nicht schneller gemeldet habe bin schüler....


    ist v3 mit trimmer und 10er dip....


    ich werde jetzt mal signale mit oszi testen, firmwares draufladen und später alles berichten...


    mal keinen stress: dimmer muss erst in 2 wochen laufen...


    vielen dank erstmal


    lg


    michi


    ...und los gehts ;)

    Zitat von "Henne"

    - Immer auch mal schauen, ob du nicht das signal verdreht hast (BREAK sollte >88µs LO sein, IDLE ist HI) -


    ich dachte, das erkennt Deine Firm. Sie zeigts doch auch an, oder?

    Das Startbyte sollte dann aber als !=0 erkannt werden. Was noch nicht alleine reicht, um ein Phasendreher zu erkennen.
    Dann einfach mal 2-3 Werte des Startbytes speichern und vergleichen. Wenn bei jedem Packet ein anderes Startbyte rauskommt, kann das schon fast nicht mehr sein.
    Und wenn dann noch das zuletzt gesendete Byte dauernd wo anders liegt (zu deutsch, wenn die Anzahl der gesendeten Kanäle dauernd wechselt) dann kann das auch nicht sein.
    Mit diesen Kriterien brauche ich keinen Timer um sicher einen Phasendreher zu erkennen.
    Hübsches Exor vornedran und mit einem Portpin umgeschaltet und dann nochmal das gleiche getestet und voilá, es war wohl verkehrt, weil jetzt Startbyte stimmt oder mindestens 3x hintereinander gleich ist, Kanalanzahl auch stabil ist und mehr braucht es nicht.

    Phasendreher? (Was sagt das Oszi?)


    @LC:
    SB ist immer null. Etwas anderes halte ich nicht für ein Startbyte...
    FrameCounter hatte ich mal (mein Code ist ja auch eigentlich dafür noch ausgelegt :wink: ). Hat sich an dynamisch angepassten Transmittern nicht bewährt (Universeminimierung zur Optimierung der refresh rate -> FrameCounter sauer...)


    andererseits: hier ist die Idee mit der Breaklength-Messung ganz klasse... ich mach das mal kurz.