SIGNALDuino
SIGNALDuino copied to clipboard
RFD-FHEM
MU Message obwohl MS ?
Hallo, ich habe folgendes Signal aufgezeichnet von einem Brandmelder direkt von der Platine. Beim Betrachten dachte ich, müsste das nicht ein MS Signal sein? Dennoch werden alle Nachrichten nur als reines MU erkannt. Sollte ich komplett falsch liegen, so bitte eine kurze Erläuterung. Ich verbinde MS Signal mit einem Sync.
Anbei mal das Signal zur Verdeutlichung.
Time Bit 0 low - avg (µS): 1404 Time Bit 0 high - avg (µS): 794 Time Bit 1 low - avg (µS): 2740 Time Bit 1 high - avg (µS): 794 Time Sync low - avg (µS): 915 Time Sync high - avg (µS): 8118
Pause between repeat - cur (µS): 19837 Pause between repeat - min (µS): 19288 Pause between repeat - max (µS): 19837
Legend:
0 or 1: bitvalue S: Syncpulse u: pulse / unknown bitvalue
Signal: S001101000000010100101101u
Ich hatte den Sync anhand von Bausteinen damals so spezifiziert dass zuerst ein high Pegel kommt und dann ein langer low Pegel.
Wenn ich deine Aufzeichnung korrekt deute, dann ist der lange Pegel hier ein high und danach kommt ein kurzer low Pegel?
Wenn ich deine Aufzeichnung korrekt deute, dann ist der lange Pegel hier ein high und danach kommt ein kurzer low Pegel?
Genau Richtig
Der Pegel der Aufzeichnung beginnt mit LOW. Als erstes kommt ein High Pegel LANG mit dazugehörigen LOW Pegel kurz was der Sync ist.
Da müsste man die MS Erkennung umbauen. Vielleicht den Zustand Low oder high ignorieren.
Das ist ja soeben nur ein "Musterbeispiel". Würde es "Sinn" machen dies anzugehen oder einfach ignorieren? Ich vermute, wir kommen hier wieder zu dem "alten" Thema MS Erkennung. hm...
Ich habe mir das nochmal durch den Kopf gehen lassen. Derzeit haben wir vermutlich eine "falsche" Auffassung von MS. Für mich ist ein MS Signal sobald ein SyncPlus vor dem Signal auftritt. Eine Pause ist aber kein Sync. Der Umbau der Routine ist sicherlich schwierig bzw, da wären Zuarbeiten von Signalen notwenidig, das du alle Fälle berücksichtigen könntest.
Derzeit wird es aber so sein, das wir nur MS zum teil richtig erkennen bzw sogar ein signal als MS deuten. Wie denkst du darüber? Die Erkennung antasten nochmal, so belassen "halb" oder die MS Erkennung herausnehmen was aber zum tragen hätte, manche Protokolle gehen vorerst nicht mehr.
Ich würde es gerne anpassen.
Allerdings möchte ich erst mal die Anpassung mit den Strings finalisieren.
Da muss ich noch ein bisschen was korrigieren. In der Hoffnung, dass der Microcontroller dann auch Mal wieder stabil läuft würde ich endlich die Version als stabil veröffentlichen. :)
Die ganzen Änderungen müsste ich dann auch noch auf den ESP portieren, bzw. Die Code Basis zusammen führen. (Hauptsächlich Fleißarbeit)
Wenn das gemacht ist haben wir einen neuen Absprung Punkt für solche Anpassungen.
Also ja, möchte ich angehen allerdings in einer etwas umfangreicheren Anpassung.
Dann lass uns die Fälle gern zusammen betrachten. Ich bzw wir können sehr gern Signale in Bildform beisteuern wo ein Sync vorhanden ist in form von Sync mit anschließendem Signal und wiederkehrenden Sync und Signal ..... bis hin zu einem Signal wo ein Sync kommt mit Signal gefolgt von einer Pause, dann ein Sync und Signal und so weiter.
Wir müssten die Erkennung generalisieren. Es ist doch meistens so, dass viele ähnlich Lange Pulse in den Puffer kommen und dann deutlich Längere, welche eine Übertragung voneinander abgrenzen. Das kann ein Sync oder eine Pause sein. Eigentlich ist das ja fast egal wie es genannt wird.
Vielleicht findet man so etwas leicht, wenn man einen gleitenden Mittelwert berechnet und feststellt, dass eine Pulslänge deutlich vom Mittelwert abweicht.
Ich habe hier einen neuen Fall
MU;P0=24188;P1=-16308;P2=993;P3=-402;P4=416;P5=-967;P6=-10162;D=0123234545454523234523234545454545454545232
623452345454545454523234523234545454523234523234545454545454545232
623452345454545454523234523234545454523234523234545454545454545232
623452345454545454523234523234545454523234523234545454545454545232;CP=4;R=25;
Ich dachte gleich, das müsste doch ein MS Signal sein, was geht da denn schief:
https://github.com/RFD-FHEM/SIGNALDuino/blob/fc0843c1bbfd71213ea4b53df815e86e085e281a/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L1006-L1018
Zuerst wird hier P2 ausgewertet und auch als validen Clock Pulse erkannt. Danach kommt P4 an die Reihe und ja das ist ein besserer Clockpulse. In der Tat würde ich auch behaupten die Clock Detection passt, P4 ist ja ~2x P2.
Der Sync wird dann wir folgt gesucht:
https://github.com/RFD-FHEM/SIGNALDuino/blob/fc0843c1bbfd71213ea4b53df815e86e085e281a/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L1060
Hier besteht der Sync also aus 2x Clock und 1x Sync. Hier stellt sich die Frage, ob man hier auch nach anderen Pulsen basierend auf Clock suchen sollte oder ob man es besser lässt.