Firmware dev-r332_cc1101 #65
Comments
|
Abstürze habe ich gestern behoben... glaube ich :) => 86537af Nach einigen Analysen habe ich noch festgestellt, dass ein BufferMove auf den kompletten Puffer nicht durchgeführt wird (macht auch keinen Sinn). => 98a2ed3 Fehlererkennung MC Nachrichten habe ich bereits bearbeitet => 86537af Die Variabe MuCut würde ich vermutlich nicht wählen. Wieso soll das ein Anwender konfigurieren? Den teil aus getSync könnte man fast 1:1 beibehalten. Was nicht aufgeht ist der teil in dem c berechnet wird: c wäre nach Ende der Schleife identisch mit Meine Ideen gehen wie folgt weiter:
Wenn der Puls nur 1x vorkommt, naja dann geben wir halt alles aus, was vor diesem Puls ist und machen ein move. Den Puls selber würde ich im Puffer behalten. |
|
bitte nich zu früh freuen! Soeben habe ich deine neue FW getestet DataOverflow IST NICHT behoben!
An der Erkennung der Protokolle wurd auch etwas verändert, so das die bisherige Erkennung der Entwicklerprotokolle FS20/FHT/FHT80b nicht mehr empfangen werden nach diesem Umstieg. EDIT: HIER ist was anderes noch faul. Ich erhalte keine RSSI Werte aber Empfangspakete grübel Muss erstmal genauer analysieren. |
|
@sidey79 zu meinem vorherigen Post,
|
|
Schade, wäre zu schön gewesen. :( RSSI Werte werden nur noch übergeben, wenn ein CC1101 angebunden ist. |
Ich VERWENDE einen CC1101! |
|
evtl habe ich hier einen Denkfehler gemacht? muß dazu das |
|
Die ganzen Konfig Parameter, müsste man in eine eigene Header Datei packen und dann in jeder bib einbinden. Die Bibliothek wird ja unabhängig vom Hauptprogramm compilieren und dann nur gelinkt. Gleiches Problem gibt es ja auch mit Output.h |
|
Ich habe verstanden, Du hast zwei SIGNALduinos... Wenn möglich, wäre es top wenn Du beide auf die gleiche Frequenz einstellst und dann einen mit MC Decoder aktiv und einen MC Devoder inaktiv laufen lässt. Mit Verbose 4 und aktiviertem mseclog würde mir das helfen. |
|
@sidey79 , |
Heisst das, daß Du davon ausgehst, daß dies so problemlos bei allen Protokollen funktionieren wird.
und dann ggf runtergehen bis ca 9-10 mal clock und dann ein paar Werte davor abschneiden. Zu den sync bei MS-Nachrichten, |
Funktioniert es noch wenn MC deaktiviert ist? |
|
@HomeAutoUser |
|
Ich antworte mal stellvertretend. Ich habe mir heute noch einen Signalduino mit einem Arduino mini pro und einem CC1100 zusammen gesteckt. Firmware ist die aktuelle vom Do 26.10.2017. Wenn ich MC eingeschaltet habe, bekomme ich immer Ausgaben in der Art: 2017.10.28 20:50:13 4: sduino868/msg READ: �MC;P0=-864;P1=393;P2=-395;P3=590;P4=-598;D=51212121212121212121212123412341234121234123412121234341212343412121212121212121234123412341234121212121212121212121210;O;� 2017.10.28 20:52:08 4: sduino868/msg READ: �MC;P0=-13472;P1=386;P2=-405;P3=602;P4=-588;D=51212121212121212121212123412341234121234123412121234341212343412121212121212121234123412341234121212121212121212121210;O;� Bei abgeschalteter MC-Erkennung sehen die Ausgaben folgendermaßen aus: 2017-10-28_20:21:20 FHT_5219 actuator: 0% 2017-10-28_20:23:16 FHT_5219 actuator: 0% 2017-10-28_20:25:11 FHT_5219 actuator: 0% 2017-10-28_20:27:07 FHT_5219 actuator: 0% 2017-10-28_20:29:02 FHT_5219 actuator: 0% 2017-10-28_20:38:40 FHT_5219 actuator: 0% Die Zeilen mit "FHT_5219 actuator" habe ich von einem parallel laufenden System mit einem CUL. Die Nachrichten stammen von einem FHT8 Raumtemperaturregler. Die Protokollbeschreibung ist zu finden unter: Ansonsten funktioniert diese Firmware-Version auf einem Radino-CC1101 auch mit eingeschalteten MC bei mir tadellos. Ich hatte nur Probleme alle Debug-Ausgaben auszuschalten, damit das Programm in den Speicher passt. Ich empfange damit aktuell folgende Protokolle: WS2000, CUL_TCM97001 W174, CUL_TX WS7035 WS7053, SD_WS07 und SD_WS37. |
|
Ich habe mir mal Angesehen. Aktuell weiss ich nicht, wieso man das nicht als MC erkennen sollte. |
|
Das Verhältnis von S (400) zu L (600) ist 1.5, dies müsste doch bei MC 2 sein? |
|
Naja, genau 2 ist es meist nie.. 1,5 bis 2,5 ist so im Bereich... |
|
Kann es bei MC Nachrichten einen sehr langen Puls (hier P5=-9304) ungefähr in der Mitte der Nachricht geben? MU;P0=-29008;P1=397;P2=-387;P3=604;P4=-587;P5=-9304;D=0121212121212121212121212341234123412123412341212123434121234341212121212121212123412341234123412121212121212121212121212341212121234121512121212121212121212121234123412341212341234121212343412123434121212121212121212341234123412341212121212121212121212;CP=1;R=41;O; |
|
Klar, das kann schon sein. |
|
Hallo @sidey79
Das sehe ich anders. Es passt schon mal nicht, das der Signalduino eine Nachricht in 3 verschiedenen Varianten ausgibt: 2017.10.28 20:50:13 4: sduino868/msg READ: �MC;P0=-864;P1=393;P2=-395;P3=590;P4=-598;D=51212121212121212121212123412341234121234123412121234341212343412121212121212121234123412341234121212121212121212121210;O;� Die übergebene Anzahl Bits ist auch unschlüssig. |
|
Ich habe eine Debug MC Ausgabe aktiviert, damit ich Mal genauer sehe, was im Nachrichten Puffer ist, wenn es als MC erkannt wird. Davon nicht beirren lassen. Das was da drin steht, ist valides Manchester. Wenn Du da anderer Meinung bist, dann gibt mit doch bitte genauere Hinweise. |
|
Habe mir das mit MU ausgegebene noch mal genauer angesehen, wieso das nicht als MC erkannt wird. Ist halt die Grundsatzfrage, ist es MC, weil es zufällig passt oder eben nicht? |
|
Ich denke nicht, das das Manchester ist. Zitat: "Manchester Code wird durch Anwenden der XOR Operation auf das Taktsignal und den Datenstrom (NRZ-Signal) erzeugt." Das bedeutet für mich, das ein Flankenwechsel immer im gleichen Takt erfolgen muss und nicht mal nach 400 µS und mal nach 600 µS. Vielleicht hast du ja die Toleranz für Manchester-Erkennung zu großzügig eingestellt. |
|
Ja, die Toleranz für einen Takt ist 0,5 und für zwei Taktlängen 0,8 . Das ist leider notwendig, damit die Messungenauigkeiten sowohl beim Senden als auch beim Empfangen kompensiert werden können. Ich könnte die Toleranz für eine Taktlänge auf 0,4 reduzieren. Irgendwo wird das halt vermutlich wieder ein neues Problem aufwerfen. |
|
Wenn ich jetzt die richtige Stelle gefunden habe: würde ich doch eher dazu tendieren, für plong die Toleranz zu verringern. Wenn ich richtig rechne, passt bei dieser Toleranz bei einem clockpulse von 400 ein aktpulse von 600 natürlich auch. Erst wenn ich einen Multiplikator von 0.4 verwende, wird 600 nicht mehr gültig sein. Ich habe jetzt probehalber beide Multiplikatoren auf 0.4 gesetzt. Dann werden die FHT und FS20 nicht mehr als MC erkannt. Mangels Sensoren mit MC-Kodierung kann ich allerdings keine Gegenprobe machen. Was mir bei den Tests noch aufgefallen ist: |
|
Wenn Du die Toleranz änderst, müsstest Du prüfen ob dann die anderen MC Protocol Ids (10 11 12 12.1 18 43 47 52 57 58) noch funktionieren. Ich würde es wichtiger finden, daß der MC-Decoder wieder so gut funktioniert wie vor diesen Anpassungen:
|
|
Das Problem mit den fälschlich als MC deklarierten Protokollen hat ja nichts mit dem benutzten Frequenzband zu tun. Wir hatten das auch schon beim WS7000/WS2000 (RFD-FHEM/RFFHEM#136). Dort hat sich der Fehler mit dem Einbau der Änderungen aus dem dev-r33_fixmc erledigt. Nun taucht er wieder auf. Es wäre doch besser, eine richtige Lösung zu finden, als nur erst mal etwas abzuschalten. Kann es sein, das sich der MC-Dekoder alles krallt, was mit einer Präambel mit mehreren Nullen beginnt? Worauf könnte man prüfen? Was ist das charakteristische an Manchester? Für mich eigentlich auch erst mal, was du schon schriebst:
Wenn ich da aber bei der Prüfung eine Toleranz von 80% zulasse, passt das eigentlich fast immer. |
|
Mir ist ehrlich gesagt nicht klar, wieso wir die Probleme aus #62 nun hier mit vermischen. Nun noch mal was generelles zum Thema Manchester: Charakteristisch für Manchester:
An dieser habe ich mich orientiert. Aufgrund diverser Hersteller hat der MC Decoder aber leider viele "Ergänzungen" erfahren. Die machen das ganze leider auch etwas komplexer. In der Beschreibung wird eine Toleranz von bis zu +-50% empfohlen und im Beispiel auch umgesetzt: Für long: Der MC Decoder schnappt sich nicht, was mit mehreren Nullen beginnt. Er schnappt sich alles, wo die Prüfroutinen ein valides Manchester Signal erkennen. Bei dieser Übertragung passt das leider (manchmal). Anpassungen der Toleranzen:
Ich könnte mir vorstellen, dass wir das Signal noch Zusätzlich auf die Signalfolgen prüfen und gegen die Anzahl der unterschiedlichen Sequenzen prüfen. Also immer zwei Pulse ergeben dann eine Sequenz. |
|
Keines Update, bei einer Toleranz von nur 0,40 gibt es Probleme mit der Oregon V2 Dekodierung :( |
|
Guten Morgen,
Diesbezüglich würde ich einschätzen, das wir vermutlich an einem Punkt sind, wo wir dem Problem von #62 auf die Schlichte kamen, da es erstmal nicht mehr auftrat aber dafür der Empfang von manchen Sensoren nicht mehr gegeben war. Das ist verschuldet vermutlich Aufgrund des ineinander greifen.
Das Thema ist auch sehr ausschlaggebend für das weitere Projekt finde ich. Natürlich ist es schwierig da eine klare Definition zu finden um alle 3 Protokolle MU - MC - MS zu unterscheiden. Dennoch sollte es Ziel sein, das man ohne Abschaltung von etwas zum Erfolg kommt. @Ralf9 - Meinung
Ich würde das vorgehen vom Abschalten nicht als Ursache wählen wollen. Das Thema der Erkennung wie o. angesprochen wird somit nur "vertagt" und zu einem späteren Zeitpunkt kommen wir wieder dort an den Punkt. Dennoch wissen wir nicht was auf dem 868 MHz Band noch an Sensoren kommen wird, denn dann wäre es verkehrt sich diese Option zu verbauen.
Ja dem stimme ich auch zu, ABER under dem o.g. Aspekt, das man nicht einfach etwas abschaltet. Das Projekt kann auf verschiedenen Frequenzen benutzt werden und so sollten wir auch weiter denken. Es kann immer stets ertwas neues kommen was wir entdecken aber nicht immer wieder an den Punkt kommen sollten, das das Thema vertagt wird und bei neuen Sensoren aufgekaut wird. Zumal wenn man eine zuverlässige Definition findet OHNE das man willkürlich MC abschalten müsste, so verhindert wir auch USER Anfragen die vielleicht das selbige Problem haben. Lasst uns bitte so denken, Fehler finden, korrigieren aber nicht vertagen.
Ich bin da ganz @elektron-bbs seiner Meinung.
Das sind Dinge welchen wir nachgehen müssen aber dazu muss ein "klarer Grund" existieren" Wir können ungern etwas Universelles zum Teil spezifizieren. Um nun auf die Punktliste aus dem ersten Faden zu kommen, @sidey79 wie weit kannst du einschätzen, das das Problem
behoben ist? Meine Einschätzung habe ich ja schon geschrieben. Auftreten war bisher nicht vorhanden (nicht mehr erhaltene Sensoren, erstmal ausgeklammert) Wenn du sagst, "fertig", dann bitte den code als Basis nehmen um den nächsten Punkt widmen. Da würde ich die "allgemeine Erkennung" der Sensoren erstmal anstreben. Danach dann die MC Erkennung auf allen Bändern (486/868) ... Wir, derzeit aktiven 4 Mitglieder @Ralf9 @sidey79 @elektron-bbs sind im Besitz zusammen an einer Vielzahl an Sensoren wo man doch erstmal einen "klaren" Schnitt hinbekommen sollte. |
Ich habe jetzt mal folgende Varianten durchprobiert, dein Vorschlag bringt auch keine Verbesserung. //pshort *0.4, plong *0.8 MU Erkennung geht nicht Ist eigentlich auch logisch: |
|
Tia, das ist durchaus etwas herausfordernd finde ich. Die Prüfung isManchester kennt da nur schwarz oder weiß. Wenn ein Kriterium nicht passt, dann wird abgebrochen. Wie gut die passen oder nicht, das wird derzeit nicht berücksichtigt. Wenn ich mir das Signal optisch ansehe, dann fällt mir ja auf, dass es genau zwei Signalfolgen gibt und das ist für Manchester eher untypisch. |
|
Ich habe jetzt das mit den Sequenzen in die Firmware eingebaut. Bitte mal testen. Wenn das hilft gehen wir das mit den manchmal invertierten Signalen an :) Ich habe noch Debug Ausgaben in der Firmware in etwa so:
Wenn wieder was falsch als MC erkannt wird, dann benötige ich diese Ausgaben :) |
|
Guten Morgen,
Desweiteren ist mir ebenso aufgefallen, die Hideki Erkennung ist schlechter. |
|
Bei mir sieht es ähnlich aus :-( |
|
Habe noch nicht alle daten verifiziert, aber es gibt schon mal ein kleines Update.. |
|
@elektron-bbs |
|
Guten Morgen,
|
|
Ja, mit dem FHT sieht das jetzt schon sehr gut aus. In ca. 1 h wurde nur eine Nachricht als MC definiert. Anbei die Logs vom SIGNALduino und CUL zum Vergleich. Ich habe den Regler zwischendurch verstellt, um verschiedene Werte in die Ausgabe zu bekommen. Bei dem Test wurde bei mir ein FHTTK fälschlicherweise angelegt. Da passte wohl zufällig die Prüfsumme. Die Sub für den FHTTK habe ich deshalb noch um eine Längenprüfung vervollständigt ( @HomeAutoUser müsste das dann mal testen). Bei FS20 funktioniert das noch nicht. Anbei auch nochmal einige Logausgaben: Was mir beim anschließenden Test mit abgeschaltetem MC auffiel: Die Nachrichten von FS20 werden neuerdings gesplittet. Hast du diesbezüglich auch schon etwas eingebaut, oder hat sich das zufällig ergeben? |
Hier soll es um Ideen, Vorschläge und todos für die Firmware dev-r332_cc1101 gehen.
@sidey79 kannst Du bitte von der dev-r33_cc1101 einen neuen Branch dev-r332_cc1101 erstellen.
Ich denke es macht Sinn damit zu warten bis die Probleme in der dev-r33_cc1101 die die Abstürze verursachen behoben sind.
Ich sehe momentan nur die Trennung der Wiederholungen als wichtig an.
Der "addData overflow" und "MU-Nachrichten werden z.T. als MC erkannt" dürfte nicht so dringend sein.
Da gibt es z.Zt, noch einge todos mit höherer Priorität.
Evtl ist ein Ansatz, wenn wir eine Variable MuCut einführen, in der die mindestlänge einer Pause als Vielfaches der Clock gespeichert wird. z.B. bedeutet 10: Pause = 10 x clock.
Mit z.B. dem command GSMUCUT kann man es konfigurierbar machen und im EEPROM speichern.
Bei 10 wird dann nach einer Pause von mindestens 10 * clock gesucht
The text was updated successfully, but these errors were encountered: