Moin,
wie bekannt haben Jomelo und ich die Bitfolge von so einem China 433 MHz Thermometer entwirrt. Nun fehlt noch eine "Kleinigkeit" zum Glück - eine Bitfolge, die mir im Moment noch schleierhaft ist. Sie kommt nach den Temperatur- und Feuchte-Werten. Siehe
Ich meine den 8 Bit langen Wert mit der Spalte ???. Den in Zeile 2 mit dem Wert 01010000 etc.pp.
WAS ist das? An die Logiker unter Euch... Jomelo?
Hi super das du noch mehr Rohdaten geliefert hast. Da ich das Eingangssignal kenne und das Ausgangssignal müsste es mit Hilfe von Algorithmen möglich sein herauszufinden was sich dazwischen befindet. Eigentlich ist das nur Rätseln und höhere Mathematik 
Am Sonntag habe ich Zeit das im Detail durchzugehen.
Ich wäre Dir auf ewig dankbar 
Jomelo:
Hi super das du noch mehr Rohdaten geliefert hast. Da ich das Eingangssignal kenne und das Ausgangssignal müsste es mit Hilfe von Algorithmen möglich sein herauszufinden was sich dazwischen befindet. Eigentlich ist das nur Rätseln und höhere MathematikAm Sonntag habe ich Zeit das im Detail durchzugehen.
Das ist mal interessant:
110000011000 000100100000 01011100 18.3 48
001000011000 111000100000 01011100 18.4 47
101000011000 011000100000 01011100 18.5 46
011000011000 101000100000 01011100 18.6 45
111000011000 001000100000 01011100 18.7 44
Mystery-Bit-Folge immer gleich!
Anhand der Ergebnisse lässt sich bestimmt die Codierung decodieren.
Man sieht immer das in allen Werten wo zwei "11" Blöcke und drei "1" vorkommen, das gleiche Ergebnis raus kommt.
Ich muss aber noch bis morgen warten bis ich wieder in meiner Wohnung bin.
Da bei dieser Bitfolge, dass eine Ergebnis hoch läuft und das andere runter, ist das schon sehr merkwürdig und deutet vielleicht auf einen Fehler, bei der Bitfolgen Endschlüsslung hin.
Als nächstes schau ich mir mal an, ob es noch mehr solche Effekte gibt.
Edit:
Ist es realistisch, dass sich die Luftfeuchtigkeit um 5% verändert, wenn die Temperatur um 0,5 Grad schwank ? Irgendwo ist dort noch ein Wurm begraben.
Da darfst mich jetzt nicht fragen. Ich sehe, das das auch so am Gerät angezeigt wird. Also scheint die Bitaufdröselung zumindest bei Temp/Humi zu stimmen. Sonst gäbe es ja abweichende Anzeigen. Gerät und Log stimmen aber überein. Ich komme seit Stunden aber nicht auf diese Grützen Mystery Folge... Habe schon Dinge wie Addition, Subtraktion, XOR usw. durch. Es passt nie. Bin jetzt dabei die Log so zu bauen, dass die 8 Bit wieder als 4 Bit Nibble durchgerechnet werden. Also 4 +4 Bit. Wie bei Temp/Humi...
00000000001111;S;011011101000;100010100000;01101101;11110000;E;40;17.6;51;116
00000000001111;S;011011101000;100010100000;01101101;11110000;E;39;17.6;51;116
00000000001111;S;011011101000;010010100000;11101001;11110000;E;40;17.6;52;97
00000000001111;S;011011101000;010010100000;11101001;11110000;E;39;17.6;52;97
00000000001111;S;011011101000;010010100000;11101001;11110000;E;40;17.6;52;97
00000000001111;S;011011101000;010010100000;11101001;11110000;E;39;17.6;52;97
00000000001111;S;011011101000;100010100000;01101101;11110000;E;40;17.6;51;116
00000000001111;S;011011101000;100010100000;01101101;11110000;E;39;17.6;51;116
00000000001111;S;011011101000;100010100000;01101101;11110000;E;40;17.6;51;116
00000000001111;S;011011101000;100010100000;01101101;11110000;E;39;17.6;51;116
00000000001111;S;111011101000;100010100000;11101001;11110000;E;40;17.7;51;97
00000000001111;S;111011101000;100010100000;11101001;11110000;E;39;17.7;51;97
00000000001111;S;111011101000;100010100000;11101001;11110000;E;40;17.7;51;97
00000000001111;S;111011101000;100010100000;11101001;11110000;E;39;17.7;51;97
00000000001111;S;111011101000;000010100000;01101101;11110000;E;40;17.7;50;116
00000000001111;S;111011101000;000010100000;01101101;11110000;E;39;17.7;50;116
00000000001111;S;000111101000;000010100000;11101001;11110000;E;40;17.8;50;97
00000000001111;S;000111101000;000010100000;11101001;11110000;E;39;17.8;50;97
00000000001111;S;000111101000;000010100000;11101001;11110000;E;40;17.8;50;97
00000000001111;S;000111101000;000010100000;11101001;11110000;E;39;17.8;50;97
00000000001111;S;100111101000;100100100000;00001111;11110000;E;40;17.9;49;150
00000000001111;S;100111101000;100100100000;00001111;11110000;E;39;17.9;49;150
00000000001111;S;100111101000;100100100000;00001111;11110000;E;40;17.9;49;150
00000000001111;S;100111101000;100100100000;00001111;11110000;E;39;17.9;49;150
00000000001111;S;100111101000;000100100000;11111001;11110000;E;40;17.9;48;915
00000000001111;S;100111101000;000100100000;11111001;11110000;E;39;17.9;48;915
Ohne die 1111.... am Ende mitgerechnet, da ich davon ausgehe, dass es das Endesignal ist. Ähnlich wie vorne die 1111, die m.E. Start bedeutet. Die 40/39 bitte ignorieren. Es sind Counterwerte. Kommen nicht vom Thermo. Genau wie "S" und "E"
oT @DE8MSH
Es wäre wünschenswert zu erwähnen, das du dieselbe Frage auch woanders gestellt hast,
zB hier: An Bit Experten: "Alles CRC oder was?" - oder so. - Mikrocontroller.net
so ließen sich Überschneidungen bei der Lösungssuche vermeiden,
natürlich auch umgekehrt den Hinweis auf diese Seite geben...
Jetzt habe ich die 4+4 Bit des Byte mal nach dem Schema anzeigen lassen wie Temp/Humi. Ist auch nicht sehr aufschlussreich:
...2bc...
Schwarzfuss:
oT @DE8MSH
Es wäre wünschenswert zu erwähnen, das du dieselbe Frage auch woanders gestellt hast,
zB hier: An Bit Experten: "Alles CRC oder was?" - oder so. - Mikrocontroller.net
so ließen sich Überschneidungen bei der Lösungssuche vermeiden,
natürlich auch umgekehrt den Hinweis auf diese Seite geben...
Danke Dir für die Info. Das war micht nicht klar, dass ich das nicht machen darf. Da OT bitte per PN an mich, Peter.
Ein Hinweis darauf kann hilfreich sein da mehrere Leute am Lösungsversuch arbeiten und ein Geistesblitz des einen einen anderen zu Lösung bringt.
Grüße Uwe
Hi Uwe,
ok. Das verstehe ich. 
Wie kann ich das dann am Besten formulieren, dass Hi'un'da an dem Rätsel gearbeitet wird? Jetzt müsste ich ja noch die µC Seite informieren...
Hi Leutem
ich habe nochmal das angeregt...
"
Ich habe auch schon getestet ob eine andere Aufteilung etwas bring. Bisher nehmen wir ja
000000001111;S;100100011000;000011100000;11011000;11110000;E;18.9;70;111
an. D.h.:
000000001111 Intro/Startsignal
100100011000 Temp
000011100000 Feucht
11011000 Check???
1111 Ende
000000001111 Intro/Startsignal
100100011000 Temp
000011100000 Feucht
11011000 Check???
1111 Ende
Also Zweimal die Reihe gesendet. Vieleicht muss es aber auch
000000001111 Intro/Startsignal
10010001 >>> 10001001 >>> 0x89
10000000 >>> 00000001 >>> 0x01
11100000 >>> 00000111 >>> 0x07
11011000 >>> 00011011 >>> 0x1B Check???
1111 Ende
000000001111 Intro/Startsignal
10010001 >>> 10001001 >>> 0x89
10000000 >>> 00000001 >>> 0x01
11100000 >>> 00000111 >>> 0x07
11011000 >>> 00011011 >>> 0x1B Check???
1111 Ende
sein. Also die Werte nach dem Start in Byte-Format.
"
Moin Leute,
Läubi aus µC sprach m.E. ware Worte indem er schrieb:
8< 8< 8< 8< 8< 8< 8<
Die Frage ist halt wie oft es zu solchen Aussetzern kommt, du kannst die
Datensätze ja trotzdem speichern nur mit einem "Fehlerflag" versehen,
das wäre denke ich die Pragmatischtste Lösung, selbst wenn du hinter die
Prüfsumme kommst und da nur feststellst das der Datensatz fehlerhaft ist
ist man genau soweit wie vorher.
Theoretisch könnte es halt auch ein Fehlerkorrigierender Code sein, die
Redundanz ist ja recht hoch, eventuell könnte man versuchen eine
Wertetabelle eingangsbits zu ausgangsbits zu erstellen und dann schauen
welche Verknüpfungen zwischen den Bits gelten, das ist aber recht
aufwändig.
8< 8< 8< 8< 8< 8< 8<
Dieser Auszug ist aus dem Hintergrund heraus, dass ich ja die CRC/Checksumme/Whatever für eine Prüfung haben wollte, die mir sagt, dass Daten fehlerhaft sind. Da die Werte immer zweimal gesendet werden kann ich auch die Datenreihen vergleichen. Sind sie different sind Daten falsch. Nachteil: was wäre wenn der Fehler zufällig in beiden Datenreihen auftritt? Dann würde der Logger Zeug wie "00.9° bei 00%" als richtig ansehen...
Ach ja. Reversing ist nicht unanstrengend....
Das Problem kannst Du genauso auch mit fehlerkorrigierendem Code bekommen. Die Lösung ist normalerweise sowas eine Ebene höher zu beheben. D.h. Temperaturen und die Luftfeuchtigkeit ändern sich ja eher langsam --> Ausreiser einfach ignorieren.
Ich habe nochmal alles versucht, ich komm aber nicht dahinter. Es gibt Kombinationen die für einige Teile passen, (Digitale Schaltungen).
Aber andere Teile der Summe passen nicht dazu. Da keine Verfahren verwendet werden, die ich jemals schon mal irgendwo gesehen habe, ist es die genauso, als wenn man die wenzig kleine Nadel in einer Turnhalle aus Heu sucht.
Ich kann da leider keinen grünen Pfaden finden der zum Ziel verhilft.
Ok. Dann Danke ich Dir sehr für Deine Unterstützung. Ich habe bisher auch alles durch. Wie gesagt: Addition, Subtraktion, XOR etc. Keine Ahnung was das soll. Auch in µC ist es noch nebulös...
Aber nochmals VIELEN VIELEN Dank an Dich, dass Du damals so superschnell Temp und Humi herausbekommen hast, Jomelo!
Hi Udo,
irgendsowas werde ich machen. Im Moment läuft es erstaunlich stabil - auch ohne Check. Man könnte es so benutzen, Allerdings dachte ich an Nachbauer. Für die sollte das dann "bombenfest" sein
Moin,
wer sehen möchte wie das Thema weiterging / -geht schaut hier: An Bit Experten: "Alles CRC oder was?" - oder so. - Mikrocontroller.net