Signalduino Entwicklung

[Sidey]

hi Sidey,

habe mich ein wenig mit der Buffer-Verwaltung auseinander gesetzt .
Wenn ich versuche, die Manchester-Nachricht im Buffer (bufferMove auf ersten Puls) zu halten, dann wird diese von SignalDetectorClass::doDetect immer wieder rausgeworfen.
Damit ist natürlich die Pulse-Erkennung erheblich schwerer, weil keine Referenz verfügbar ist. Des weiteren scheint es so zu sein, dass SignalDetectorClass::doDetect nach einem Buffer-Move Daten nicht bis in die Manchester-Erkennung durchreicht, wenn mcDetected gesetzt ist und ManchesterpatternDecoder.doCode false liefert. Wenn hier mit einer FiFo gearbeitet wird, dann müsste man sich wenigstens darauf verlassen können müssen, dass auf eine Pulse-Grenze geshiftet wird. Alles mit mctest durchgeführt.

Hi,

bufferMove sollte  funktionieren, das habe ich intensiv getestet.

Die Logausgaben des angepassten Codes konnte ich jetzt leider nicht exakt verfolgen.

Da ich die Signaldaten nicht genau kenne, (schick mir die doch mal bitte zu), kann ich den exakten Fall nicht nachstellen.
Mit dem move und der darauf Folgenden Erkennung habe ich aber schon so meine Erfahrungen gemacht. Der Move wird wohl ausgeführt, da der Puffer voll ist, dann wird mcDetected = true.
Ich kenne die Anzahl der Pulse jetzt nicht, die noch kommen, aber vermutlich sind es nicht viele und dann kommt ein Puls mit -32001.. Damit wird dann processMessage() ausgelöst.

In processMessage() findet sich in Zeile 473 folgendes:

Code Auswählen Erweitern


// reinit clocks or reset if fails
if (mcDetected && !mcdecoder.isManchester()) {
mcdecoder.reset();
mcdecoder.setMinBitLen(17);
mcDetected = false;
}

In meiner Version wird immer mcdecoder.doDecode() aufgerufen, wenn mcDetected true ist. Der Grund ist, dass im Fall der MC Verarbeitung alle Pulse schon in den Manchester Speicher umgewandelt wurden. Dadurch wird der message Puffer geleert. isManchester() findet vermutlich kein MC Signal und liefert false zurück. Dann ist der Message Puffer zum einen schon gekürzt, aber der Manchester Puffer wird auch noch geleert.

Grüße Sidey

[habeIchVergessen]

so habe eine Version comitted, die MC-Nachrichten solange im Buffer hält, bis der  Buffer voll ist oder eine Nachricht decodiert wurde.

Speziell das reset() am Ende von SignalDetectorClass::processMessage habe ich ausgebremst. Dadurch kann es vorkommen, dass kurzzeitig die Verarbeitung stockt.

Das Ergebnis veranschaulich aber ganz gut die Probleme beim Decode von MC-Nachrichten.

SD SC:SR:SM:SR           sehr gut (5 von 6 richtig; 1x shr 1)
SD SC:SR:SM                  gut (4 von 6 richtig; 2x shr 1)
SD SM                               geht noch (1 von 6 richtig; viel wird als MU erkannt)
CUL                                   schlecht (Details habe ich noch nicht analysiert)

DEBUG_EHL sollte auskommentiert werden (Log-Ausgaben ergeben ein mieses Timing).

Code Auswählen Erweitern


SC:SR:SM:SR
MC;LL=-1290;LH=1264;SL=-685;SH=591;D=50D8D8D8150900;C=638;L=56;
MC;LL=-1323;LH=1231;SL=-681;SH=597;D=A1B1B1B02A1200;C=638;L=55;
MC;LL=-1293;LH=1260;SL=-659;SH=617;D=A1B1B1B02A1200;C=638;L=55;
MC;LL=-1294;LH=1262;SL=-655;SH=621;D=A1B1B1B02A1200;C=638;L=55;
MC;LL=-1293;LH=1264;SL=-653;SH=623;D=A1B1B1B02A1200;C=638;L=55;
MC;LL=-1293;LH=1264;SL=-653;SH=623;D=A1B1B1B02A1200;C=638;L=55;

SC:SR:SM
MC;LL=-1302;LH=1255;SL=-662;SH=616;D=A1B1B1B02A1200;C=639;L=55;
MC;LL=-1302;LH=1253;SL=-663;SH=613;D=A1B1B1B02A1200;C=638;L=55;
MC;LL=-1302;LH=1253;SL=-663;SH=613;D=50D8D8D8150900;C=638;L=56;
MU;P0=-2879;P1=2370;P3=4512;P4=-1297;P5=1255;P6=-690;P7=586;D=01010101010101034545676767476547656767476547656767476547656767676767454545676767456745676767676767676701010101010;CP=7;
MC;LL=-1302;LH=1255;SL=-663;SH=615;D=A1B1B1B02A1200;C=639;L=55;
MC;LL=-1303;LH=1254;SL=-663;SH=615;D=A1B1B1B02A1200;C=639;L=55;
MC;LL=-1303;LH=1254;SL=-663;SH=615;D=50D8D8D8150900;C=639;L=56;

SM
MC;LL=-1273;LH=1270;SL=-653;SH=624;D=36360542400;C=636;L=42;
MS;P1=483;P2=-795;P3=-1474;P4=1030;P6=-3836;D=16434212121312431242121312431242121312431242121212121343434212121342134212121212121212;CP=1;SP=6;O;
MS;P0=-1341;P1=483;P2=-795;P4=1030;P6=-3836;D=16404212121012401242121012401242121012401242121212121040404212121042104212121212121212;CP=1;SP=6;
MS;P0=-1341;P1=483;P2=-795;P4=1030;P6=-3836;D=16404212121012401242121012401242121012401242121212121040404212121042104212121212121212;CP=1;SP=6;
MU;P0=-1360;P1=-714;P2=388;P3=562;P4=1192;P6=-3904;D=0121313131313136404131313031403141313031403141313031;CP=3;
MC;LL=-1312;LH=1243;SL=-674;SH=603;D=A1B1B14800;C=638;L=37;
MC;LL=-1312;LH=1243;SL=-674;SH=603;D=A1B1B1B02A1200;C=638;L=55;

CUL
MU;P0=1242;P2=-732;P3=538;P5=-1348;P7=240;D=02323235320532023235320532023235320532023232323235057;CP=3;
MU;P0=688;P2=-1273;P3=-673;P4=1298;D=44243030302034203430302034203430302034203430303030302424243030302430243030303030303030;CP=0;
MU;P0=688;P2=-1273;P3=-673;P4=1298;D=44243030302034203430302034203430302034203430303030302424243030302430243030303030303030;CP=0;
MC;LL=-1286;LH=1246;SL=-708;SH=629;D=50D8D8D8;C=644;L=31;
MU;P0=687;P2=-1276;P3=-675;P4=1297;D=44243030302034203430302034203430302034203430303030302424243030302430243030303030303030;CP=0;
MU;P0=687;P2=-1276;P3=-675;P4=1297;D=44243030302034203430302034203430302034203430303030302424243030302430243030303030303030;CP=0;
MC;LL=-1322;LH=1235;SL=-711;SH=628;D=50D8D8D8;C=649;L=30;
MU;P0=-1277;P2=-672;P3=688;P5=1217;P7=4852;D=3702022323230325032523230325032523230325032;CP=3;
MC;LL=-1275;LH=1295;SL=-671;SH=688;D=06C6C6C0A84800;C=654;L=53;


[Sidey]

so habe eine Version comitted, die MC-Nachrichten solange im Buffer hält, bis der  Buffer voll ist oder eine Nachricht decodiert wurde.

Speziell das reset() am Ende von SignalDetectorClass::processMessage habe ich ausgebremst. Dadurch kann es vorkommen, dass kurzzeitig die Verarbeitung stockt.

Hi, habe mir die Änderungen angesehen. Ganz schlau werde ich noch nicht daraus.
Vor allem ist mir unklar, welche Nachrichten werden in welchem Puffer gehalten?  Ich habe so den Eindruck, dass da ein reset zu viel vorkommt.
Insgesamt sollte dieses Verhalten doch auch heute schon zu sein, oder ging das durch deine Anpassungen verloren.

Mir stellt sich gerade die Frage, was ich mit deinen Änderungen nun genau mache
Die sind ja bestimmt in Teilen nicht verkehrt, die allgemingültige Funktionsfähigkeit hatte sich bei mir jetzt aber nicht eingestellt.

Da es eher ein kompletter rewrite von Funktionen ist, wird das schwierig das einzeln und Problembezogen zu integrieren.
Vielleicht kannst Du noch mal schildern, was das ursprüngliche Problem war, welches zu lösen wolltest?

Grüße Sidey

[habeIchVergessen]

hi,

mit Buffer meine ich SignalDetectorClass::message, der ja am Ende von SignalDetectorClass::processMessage per reset geleert wird (wenn keine truncated Nachricht gedektiert wurde). Wenn aber eine MC-Nachricht durch einen nicht-MC Pulse abgeschlossen wurde, dann ist truncated false und es werden alle weiteren Daten im Buffer gelöscht. Besser wäre hier, nach der MC-Nachricht das Parsen fortzusetzen.

Habe ich auch in mcfix so gesehen.

[Sidey]

Meiner Meinung Nacht besteht eine MC modulierte Nachricht immer aus zusammen hängenden Manchester konformen Pulsen.
Wenn ein nicht Manchester konformen Puls erkannt wird, dann könnten wir doch davon ausgehen, dass die Nachricht dort endet.

Der Teil bis da kann demoduliert und übergeben werden.
Den restlichen Nachrichtenpuffer sollte man wieder ganz normal behandeln. Wenn dann erneut Manchester modulierte Daten kommen werden diese wieder demoduliert. Es können an dieser Stelle aber auch ganz andere Daten empfangen werden.

Der Manchester Puffer kann geleert werden, nachdem die Daten an FHEM übergeben wurden. Der Message Puffer wird (hoffentlich) nur so weit geleert, wie Daten verarbeitet wurden.

Grüße Sidey

[habeIchVergessen]

habe den Branch mctest gelöscht.
in mcfix habe ich noch den Shift-Fehler beim MC-Empfang korrigiert.

Nachrichten vom CUL und SD SC:SR:SM + SC:SR:SM:SR funktionieren jetzt recht zuverlässig. reine SM sind nicht so gut.

[Sidey]

Kannst Du erklären, wodurch es zu dem Shift Fehler kommt.
Ich habe es leider noch nicht geschafft herauszufinden, woran das genau liegt.

[habeIchVergessen]

das erste LL ist in den Somfy-Nachrichten eigentlich ein SL aus dem ersten SR und ein SL vom ersten Manchester-Bit (immer 0xA also 1/in Manchester SL-SH). Außerdem kann in Manchester kein Long als erstes vorkommen, weil nach der 1. clock (halber Pulse) immer ein Flankenwechsel stattfinden muss.

Vielleicht sollten wird die Begrifflichkeiten sortieren, um Irretationen auszuräumen.

[Sidey]

Ja, bislang hatten ich folgende Begriffe verwendet:

MC = Manchester  Codiert
Pulse = Dauer eines Pegel Zustandes
LL = long low (Pege lowl)
LH = long high (pege highl)

SL = short low (Pegel low)
SH = short high (Pegel high)

Bit = Bit
Nachricht = Zusammenhängende Bits
Clock = Takt mit dem das Manchester Signal moduliert wurde.

Pegel = Zustand des Pins zu einem Zeitpunkt

Pattern = Kombination von Puls und Pegel

Sync = Synchronisation auf das Manchester Signal

Mehr fällt mir gerade nicht ein

Grüße Sidey

[habeIchVergessen]

Ein Bit = 2x clock mit entgegengesetzten Pegeln.
Ein Long = 2x clock mit gleichem Pegel => Teil 2 von eine Bit und Teil 1 vom nachfolgenden.
Ein Short = 1x clock.

@Sidey: wie denkst du über eine Testversion (Modul+Firmware)?

[Sidey]

Mit Testversion meinst Du: Übernahme der Anpassungen in dev32 und bereitstellen einer compilierten Firmware?

Könnte man wohl mal machen. Dass OSV3 jetzt nicht so wie vorher decodiert wird, muss kein Fehler sein.

Grüße Sidey

[RappaSan]

Welche Oregon-Sensoren sprechen denn OSV3?
Ich hab hier einen THGR228N.

[habeIchVergessen]

Mit Testversion meinst Du: Übernahme der Anpassungen in dev32 und bereitstellen einer compilierten Firmware?

mcspecial würde ja erst mal reichen. dev32 kann immer noch erfolgen, wenn ein Feldtest mit Somfy-Hardware erfolgt ist.

[Sidey]

Stimmt, da hast Du recht

[Sidey]

Das THGR228N verwendet soweit ich weiss das Protokoll 2.1. Wäre aber trotzdem gut, wenn Du es mal testen könntest.
Meine V2.1 Sensoren laufen zumindest.


Die Angepasste Firmware mit dem angepassten Modul gibt es hier:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32-mcspecial/controls_signalduino.txt


Für Somfy habe ich eine Winzigkeit angepasst. Könnte so funktionieren.
Einfach mal bissl testen.

@Burny: Testest Du noch mal OSV3?

Grüße Sidey