Henne-Dimmer-Problem

    DU SPEZIALIST :D

    Dann klatsch mal kurz den Dimmer drauf - der ist nämlich SP2 :D

    falls es nicht klappt - schreibe ich mal an der Startaddy für Dich weiter...

    Break-Length hat sich erledigt (aber vielleicht für bourd.hex nicht übel - nochmals Danke!)

    Henne:
    SB ist bisher noch nicht anders, manche Hersteller haben aber schon mal ins Auge gefasst, Statusgeschichten oder Adressierungsänderung per DMX über ein geändertes SB zu signalisieren, daher würde ich nicht unbedingt darauf vertrauen, dass SB immer 0 ist. Ich frage es, ehrlich gesagt, aber trotzdem ab, weil sich bisher noch keiner beschwert hat und wenn, bekommt der eine Sondersoft.
    Die dynamisch angepasste Kanalanzahl sollte nicht in jedem Packet anders sein, sobald zwei aufeinander folgende Packets gleich sind, wird der Fehlerzähler auf 5 oder höher gesetzt.

    Bisher mache ich das so, dass ich alleine beim Startbyte !=0 schon Dreher vermute. Aber meine geschilderte Version sollte idiotensicher sein und macht nicht soviel Aufwand, wenn man eh gerade was am ändern ist.
    Ich fasse meine Soft nur an, wenn sich an den Features was ändern soll und dann werden bessere Detektionsroutinen oder Statemachines mit reingepresst. Deshalb mich extra hinzuhocken und außen im Feld merkt eh keiner den Unterschied, tut mir leid, dafür ist mir meine Zeit zu schade und ich habe noch wichtigeres zu tun.
    Ich freue mich, dass der Fehler nun behoben ist, habe aber nicht wirklich kapiert, was denn nun eigentlich das Problem war. Klärt ihr mich auf?

    Grüße,
    Carsten (der jetzt noch ne Runde joggt) :lol:

    Da hast Recht, LC...

    woran lag's denn??

    und bevor es weiter geht:
    Die Lastteile bekommen alle +5V aus der Versorgung und - geht an den Transceiver (open collector)
    Flackern: Selektion des zc-OK könnte daneben gegangen sein. Die Firm für den eingeschränkten Regelbereich ist aber noch sb1.

    Der andere Fall ist nun auch vom Tisch - alles läuft.

    Gute Nacht - kann nicht mehr joggen :D

    Stefan: Wenn Du mal den ganzen Krempel mit Deiner Transmittersammlung durchtestest, würde ich Dir gerne gratis den Keller ersparen - nach der Aktion tut mir glaube ich etwas Überblick ganz gut...

    Wie macht MA eigentlich sowas? Haben die den ganzen Keller voll mit Botex zum testen? :roll:

    Michael:
    Bevor's ein anderer tut, da du dies gerne schreibst:
    Lies Dir bitte im mega8515 Datasheet die Seite 145 durch. Dann überlege was Du und ich machen. Dann überlege, wo der Unterschied ist :wink: (vielleicht bin ich ja auch auf dem falschen Dampfer...)
    ...ich halte einen Verlust von mehr als einem bit/Durchlauf für ziemlich heftig...

    Zitat von "Henne"

    Stefan: Wenn Du mal den ganzen Krempel mit Deiner Transmittersammlung durchtestest, würde ich Dir gerne gratis den Keller ersparen - nach der Aktion tut mir glaube ich etwas Überblick ganz gut...

    So einige DMX-Quellen hab ich ja mittlerweilen angesammelt :D
    * Billig-Botex-Pult (DC1216 oder so)
    * Digital Enlightenment
    * MiniDMX
    * OksiD
    * Cinetix
    * Manolator
    * "Dworkin DMX", wobei ich den noch nie getestet hab :oops:

    Vll. kann ich auch noch mal in meiner alten Schule vorbeifahren, da hätte ich noch einen Martin Freekie und ein Strand GSX zum Testen...

    Die kann ich gerne mal an die Platine hängen, hab allerdings für Testzwecke nur die alte Revision (mit Trafo und ZC onboard). In einigen Geräten hab ich auch ne 2.x, aber da kann ich kein LCD antüdeln...

    Was genau willst du eigentlich rausfinden?

    Stefan

    Stefan:
    Ich schick Dir 'ne 3.01 rüber wollte ich damit sagen. Was ich hören will: " A funzt nit, B geht, C hakelt, D ist auch nicht das wahre, E-H sind super, etc..." Da weiß ich dann, wo ich ugf. stehe.

    Michael:
    Na gut. Also explizit :wink:
    Der FE wird durch ein falsches erstes stop bit ausgelöst. Wenn ich also 8n2 wähle und habe einen FE, bedeutet dies, dass das 9.bit LO ist. (10.bit wird nicht beachtet)

    Du stellst nun 9n1 ein und bist von dem Pseudo 9.bit (= erstes stop bit) begeistert, was Du immer auf HI checkst, da sonst FE bzw. Break.
    Nichts anderes macht der FE in Hardware - ich halte beide Methoden für identisch, blos die im DS vorgeschlagene für etwas eleganter.

    möglicher Unterschied:
    Du wertest das 2. stop bit FE mäßig aus: Wenn dein Signal also gleich 2bits verschluckt, liegst Du richtig und ich falsch. In diesem Fall halte ich aber alles für zu spät, da dann wahrscheinlich auch sonst bits vertauscht und Frames gesprengt werden...

    @LC: ich versuche mal konkret einen Fehler zu entwickeln, der Deine state machine sabotiert. Wenn ich daran scheiter bzw. sie sich nicht verschluckt, wäre das ziemlich ultimativ 8)

    Stopp - alles falsch. Heute Nacht ist mir Folgendes aufgefallen:

    FE: Das Frame stimmt nicht mehr, da ein bit verschluckt oder doppelt gezählt wurde.
    Break: Ein LO-Pegel über >88µs

    Die 9n1 Variante muss in Wahrheit (vielleicht nur bislang falsch von mir verstanden) so aussehen:

    FE: 9.bit LO, 10.bit HI (-> ein bit daneben)
    BRK: 9.bit LO & 10.bit LO (FE) (-> beide bits müssen LO sein, da zwei Frames verschmolzen werden)

    Damit hat das Ding doch das Potential zusammen mit dem SB einen Irrtum nahezu unmöglich zu machen... Ich stells heute mal rein.

    Henne: Genau so mache ich das schon seit Jahren. Und es klappt. Du hast scheints wirklich was missverstanden. Die Errorflags müssen vor dem Daten Auslesen geholt werden, sonst sind sie weg - aber das weißt Du ja.

    Grüßle
    Carsten

    Ich selbst kannte diesen Trick erst von Michael - und der hat ihn nicht vollständig implementiert.

    So hier die finale (ultimative) state machine :D :
    1. stop bit = LO -> Break oder FE
    2. stop bit = HI -> FE
    data != 0 -> FE

    Der MAB erzeugt einen nach obigen Kriterien ungültigen zweiten FE. Deshalb darf ein gültiger Break nicht von einem folgenden FE gekillt werden.

    Hier der Code: http://www.hoelscher-hi.de/hendrik/share/9n1.zip

    Das war's von mir. Es wäre nett, wenn Ihr mal drüberschauen könntet, da bis auf den FC alles drin ist...

    Zitat von "Henne"

    Der MAB erzeugt einen nach obigen Kriterien ungültigen zweiten FE.

    Hä? Wie kommste denn darauf? Ein MAB (ich tippe auf "Mark after Break") ist idle. Warum soll dann da ein FE kommen?
    FEs werden eh ignoriert (was will ich auch damit?), bis wieder sicher ein Break erkannt wird. Das ist nur eine Hilfe für die Statemachine. Da Du dem Sender leider nichts zu kund und wissen geben kannst, musst Du die Information des FEs für Dich behalten.

    Interessant ist der FE bei anderen (entweder bidirektionalen) Kommunikationsformen oder wenn man versucht, über ein Trimmregister einen RC-Oszillator zu korrigieren, da (anders als beim LIN-Bus) leider kein Syncbyte als Startbyte kommt (da hätte man damals echt was gedacht, wenn man das so gelöst hätte).

    MAB ist 8µs HI. IDLE ist beliebig HI.
    Ich erhalte halt einen echten FE nach detektiertem Break (vielleicht ist ja auch der Break eine Ecke länger, weshalb es da knirscht - jedenfalls muss ein FE after Break ignoriert werden.)

    Andere FE jedoch eher nicht: Bis sich der USART wieder fängt und synct kann ich einen ch verloren haben. Also warte ich lieber auf einen Durchlauf ohne Störungen (wozu gibt's sonst eine möglichst hohe refresh rate, wenn nicht den Bruch zu verwerfen?)

    Henne: Was machst denn Du: USART und fertig. Wie lange soll denn ein Break gehen, das ist doch egal. Länger als längstes Byte isser. Schick mir endlich eine Mail, damit ich Dir mal an Deine Adresse eine Statemachine schreibe. Das ist doch nicht so schwer, wie Du es machst.

    MAB kann zwischen 8µS und 1 Sekunde sein (zumindest nach Soundlight).

    ..da will ich auch mal etwas mitspielen.

    Wir haben ein Register: DMX OK.
    Am Anfang ist es Null.
    Die Daten rauschen an der Schnittstelle vorbei, auf einmal gibt es ein Frame Error.
    Aha denke ich, das muss Break sein. Also ab jetzt empfangen, DMX OK =1.
    Der folgende Mark wird ja nur als "Idle" interpretiert, es gab ja vorher keine fallende Flanke (Start)
    Jetzt empfange ich das Startbyte was ich entweder prüfen kann ob es wirklich null ist oder einfach entsorgen kann.
    Ab jetzt werte ich die Kanäle die mich interessieren aus. Bis zum nächsten FE.
    Das ist die einfachste Art die auch an vielen Pulten zuverlässig funktioniert.
    NAtürlich habe ich dabei keinerlei Komfortmerkmale wie anzeige einer gedrehten Phase.

    Ich finde die Diskussion sehr interessant und lasse mich gerne belehren.
    Die Idee das ganze als 9n1 laufen zu lassen und das erste Stopbit zu Fuß auszuwerten finde ich gut. Werde mal drüber nachdenken.

    @LC: BTW, warum fünktionierte damals der blaue Kanal nicht?

    Was sagt der Raver auf der Techno-Party, wenn sein Extasy aufhört zu wirken?

    "Was ist denn das für eine sch... Mucke hier?"

    Falls der blaue der erste war: nach Erreichen der Startadresse nicht ausgewertet sondern nur state verändert? :D

    Grüße, Hendrik - der schon gespannt auf Carstens machine wartet (aber eigentlich noch ganz angetan von der 9n1 ist...)

    letzten Endes mache ich es genauso wie Sven M.

    interrupt [USART_RXC] void uart_rx_isr(void)
    {
    status=UCSRA;
    ctrl=UCSRB;
    data=UDR;

    if (((status&FRAMING_ERROR)==FRAMING_ERROR) && (((~ctrl)&STOPBIT)==STOPBIT) && (data==0))
    // Break erkannt
    {
    dmx_break=1; // Flag setzen
    dmx_ok=1; // Flag setzen
    dmx_start=1; // Flag für Neubeginn
    }
    if (((ctrl&STOPBIT)==STOPBIT) && (dmx_break==0) && dmx_start)
    // gültige Daten (Startbyte und Break schon erkannt)
    {
    if (dmxchannel<511) dmxchannel++; // Zähler hochzählen 0-511
    dmxvalue=data; // Datenwert sichern
    dmx_ok=1;
    }
    else
    if (((ctrl&STOPBIT)==STOPBIT) && dmx_break && dmx_start) // dmxstartbyte erkannt
    {
    dmxchannel=-1; // Zähler auf -1, damit Kanal bei 0 beginnt
    dmx_ok=1;
    dmx_break=0;// Flag zurücksetzen für Kanalempfang

    }

    }

    Warum das blau nicht geklappt hat?
    Weil ich doof war. Wenn man die ins EEPROM gespeicherten Werte nie mehr richtig einliest, kommt es halt drauf an, was drinsteht. Da hatte ich Mist gebaut.
    HTH
    Grüße,
    Carsten

    PS: Phasendreher erkennst Du dann auch, wenn Du das Startbyte auswertest. Das könnte man sogar noch in ein Array packen, damit man 5 Werte auswertet. Wenn dann noch der letzte Kanal jeden Frame anders ist, war das wohl nix.