next topic »

[on:]

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

http://pastie.org/2361589

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?

[Reply #1 on:]

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.

[Reply #2 on:]

Ich wäre Dir auf ewig dankbar

[Reply #3 on:]

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.

Das ist mal interessant:

Code:

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!

[Reply #4 on:]

Und noch mehr. Ohne Doppelte:

http://pastie.org/2365002

[Reply #5 on:]

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.

[Reply #6 on:]

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...

Code:

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"

[Reply #7 on:]

oT @DE8MSH
Es wäre wünschenswert zu erwähnen, das du dieselbe Frage auch woanders gestellt hast,
zB hier: http://www.mikrocontroller.net/topic/228553
so ließen sich Überschneidungen bei der Lösungssuche vermeiden,
natürlich auch umgekehrt den Hinweis auf diese Seite geben...

[Reply #8 on:]

Jetzt habe ich die 4+4 Bit des Byte mal nach dem Schema anzeigen lassen wie Temp/Humi. Ist auch nicht sehr aufschlussreich:

http://pastie.org/2365715


...2bc...

[Reply #9 on:]

oT @DE8MSH
Es wäre wünschenswert zu erwähnen, das du dieselbe Frage auch woanders gestellt hast,
zB hier: http://www.mikrocontroller.net/topic/228553
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.

[Reply #10 on:]

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

[Reply #11 on:]

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...

[Reply #12 on:]

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.
"

[Reply #13 on:]

Moin Leute,

Läubi aus µC sprach m.E. ware Worte indem er schrieb:

8< 8< 8< 8< 8< 8< 8<

Code:

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....

[Reply #14 on:]

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.