Lange Protokolle / MU Ausgabe #79
Comments
|
@Ralf9 was meinst Du? |
|
Ich sehe da kein Problem. Eine Nachricht besteht aus ca 225 Pulsen und danach kommt die Wiederholung. |
|
Der Empfänger bekommt die Übertragung nicht von Beginn an mit. Somit sind nicht zwei Startsequenzen im Puffer. Man hat das Ende von einer Übertragung und den Beginn einer weiteren. Aus den Daten kann man sich die Zeilen mit MU extrahieren. Daran ist es gut zu erkennen. |
|
Bei dieser Nachricht ist der Begin im Puffer |
|
Stimmt, aber die startsequenz fehlt am Anfang. Würde man danach suchen, findet man das signal nicht |
|
Seltsam, ich dachte ich hätte heute hier etwas gepostet.... Ich habe ein wenig experimentiert: Ich habe ein Flat: muDetected nach der gleichen Methode die mcDetected implementiert. Die Ausgabe der Pulse P1=x;P2=y; habe ich an das Ende der seriellen Übertragung geschoben. Ein anderer Ansatz wäre, wie bisher MU;P1=x;P2=y;D=121212 zu übergeben, wird overflow (puffer voll) erkannt, dann wird der Nächste Pufferinhalt auch ausgegeben. Das MU können wir uns schenken, die Pulse und die Signaldaten P1=x;P2=y;D=121212; brauchen wird. Das sähe dann in etwa so aus: Diese Daten könnte man in FHEM dann zusammensetzen. Geht mit ein bisschen Fleßarbeit. Eine dritte alternative wäre, dass unseren Puffer nicht komplett leeren. @Ralf9 |
|
Mit dem Mucut müsste es eigentlich passen. Dann wird ein buffermove bis P6 gemacht Ich habe den Mucut und die Ausgabe der Wiederholungen inzwischen in meiner Version eingebaut. |
|
Muss noch ergänzen. Variante drei hilft mir nicht bei meinem Lichterkerzen Protokoll. Habe mal eben Variante 2 ausprobiert (ohne reduction)
Vemutlich fehlen hier aber Daten, da der FIFO schneller volläuft, als die ganze Ausgabe dauert. Mit V3 kommen wir aber da nicht bei... :( |
|
Ich habe hier nun mal eine Aufnahme meiner Anpassung. Es geht auch genau um dieses Protokoll. Es sind aber nur zwei identische Wiederholungen enthalten (1 und 5), was mich ein wenig verwundert. @Ralf9 |
|
Ja bei P0 würde ein buffermove gemacht |
|
Ich habe gestern noch die Info bekommen, dass die Wiederholungen nicht identisch gesendet werden. Was das bedeutet weiss ich noch nicht :( |
|
Hallo, Es ist so, ich habe die Puls folgen damals alle mit dem Oszi aufgenommen und gespeichert. habe diese dann händisch ausgewertet und angefangen zu decodieren. `
` Gerne nehme ich das alles nochmal mit dem jetzt vorhandenen Logic Analyser auf um möglich Fehler auszuschließen. Gruß Sebastian |
|
Ich fasse meine Sicht zusammen: Die Nachricht hat 114 Bit In der experimentellen Firmware waren manche Wiederholungen kürzer, was auf Datenverlust hinweist. |
|
Ich probier noch mal, ob man die Nachrichten mit einer langen Pause nicht als MS ausgeben sollte. Ansonsten zum Thema sehr lange Nachrichten habe ich mir ein paar Grundlegende Dinge überlegt. Ist aber vielleicht eher was für Version 4 :) Sobald wir die minBitLength überschritten haben, könnten wir mit der Ausgabe (sofern es nicht Manchester ist) beginnen. Wir müssten die Ausgabe D= halt nur weiter nach Vorne ziehen. Be Manchester Signalen, könnte man auch schon was ausgeben, wenn der Puffer komplett demoduliert wurde wurde, wir aber am Ende nichts manchester untypisches gefunden haben |
|
So, hier das versprochene Update von der heute eingespielten experimentellen Version von dir Sidney. |
|
Meine Idee hat offenbar nicht so richtig funktioniert. Hmm |
|
Was ist den damit? Habe mich nochmal direkt vor dem Empfänger gestellt!! |
|
Das liegt nicht an dir. Meine Idee, wie man das Signal erkenne könnte hat nicht funktioniert. Bin halt noch unsicher, welcher Weg der insgesamt bessere ist. |
|
Achso, weil er ihn immer noch als MU nimmt und nicht wie angenommen als MS. Kann man nicht den Sync der am Anfang gesendet wird irgendwie als Start definieren? |
|
Naja, die Sequenz scheint irgendwie -11376, 5156, -1684; zu sein. Den 5156 zu erkennen, da er nur 1x im Puffer vorkommt ist etwas Risiko behaftet. Da besteht halt immer die Chance, dass man für andere Übertragung etwas ungünstiges einbaut. Vielleicht kann man aber auf die 11ms Sendepause gehen. Das scheint mir doch durchaus ein valider Anhaltspunkt |
|
Wenn ich den Handsender mit einem LA auslese ergibt sich ein SYNC von 5250 HIGH, 1750 LOW. Die Sendepause beträgt dann nach der ersten Aussendung 11500 LOW. Vielleicht kann man es ja so ähnlich machen. Gruß Sebastian |
Hier wird ein Protokoll beschrieben, welches aus ca. 244 Pulsen besteht:
https://forum.fhem.de/index.php?topic=80164.0
Es handelt sich um ein MU Protokoll, welches unter Umständen als MC erkannt werden könnte.
Das ist erst mal Nebensache.
Die Problematik besteht eher darin, dass es unwahrscheinlich ist, dass eine Übertragung komplett im Puffer liegt.
Es gäbe zwei Optionen:
The text was updated successfully, but these errors were encountered: