Moin, wie vieleicht bekannt haben ein Kollege 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... Anyone?
> WAS ist das? An die Logiker unter Euch... Anyone?
Anyhow? Anytime? Annie Get Your Gun!
Für eine CRC wären mir das zu viele Kollisionen. Bspw. Zeile 111/112 oder 107/114. Gerade letztere unterscheiden sich nur in einem Bit im vordereren Teil, haben aber den gleichen Wert in der Fragezeichen- spalte. Eine 1-Bit-Änderung sollte bei einer CRC immer eine Änderung bringen, sonst hätte diese keinen Sinn.
Moin Jörg, diese "Besonderheit" ist mir auch schon aufgefallen. Immer dann wenn Temperatur und Feuchte im gleichen Abstand steigen/fallen, hier am Beispiel "20.2° 45%" zu "20.3° 44%", ist diese Bitfolge identisch. Ich habe auch schon über http://smbus.org/faq/crc8Applet.htm was schlaues herauszubekommen... Mir gelang es nicht. Welche Mechanismen gäbe es noch die Korrektheit der Bitreihen zu verifizieren?
SWL DE8MSH schrieb: > Moin Jörg, > > diese "Besonderheit" ist mir auch schon aufgefallen. Immer dann wenn > Temperatur und Feuchte im gleichen Abstand steigen/fallen, hier am > Beispiel "20.2° 45%" zu "20.3° 44%", ist diese Bitfolge identisch. Vielleicht irgendeine Art an einfacher Addition?
SWL DE8MSH schrieb: > Immer dann wenn > Temperatur und Feuchte im gleichen Abstand steigen/fallen, hier am > Beispiel "20.2° 45%" zu "20.3° 44%", ist diese Bitfolge identisch. Dabei gibt es aber noch eine Unterscheidung zwischen >=20°C oder kleiner: 00010011 20.0 41 (200+41= 241) 11011000 19.8 43 (198+43= 241) 01010000 200+43= 243 10111010 199+44= 243 01111101 199+45= 244 11010110 200+44= 244 11010110 201+43= 244 Allerdings bekommt man ja auch nicht viel Futter. Die Temperaturen bewegen sich zwischen 19.7 und 20.8°C, die Feuchte zw. 41 und 53% Was passiert bei 10°C? Was bei 30°C? Was bei 40%? Was bei 60%? Denn auch bei 50% findet eine Umschaltung statt: 00010011 200+50= 250 01001100 201+49= 250 01001100 202+48= 250 Gruß Jobst
Angehängte Dateien:
-
tempdata.png
360 KB
Hi Jobst, ich logge gerade wieder. Es wird ja nun kälter. D.h. Werte < 18° und > 40% werden erzeugt...
Machst du das selbst, oder das holde Weib auf der rechten Seite für dich? ;-)
Ja, das macht die Nette Dame für mich. Es ist "Melanie van de Shell" g
Bianca macht Werbung für Ubuntu ...!? Naja, <10°C und <40% wären interessant ... oder >60% An >30°C habe ich hier in D kein Interesse :-D Gruß Jobst
Jobst M. schrieb: > Naja, <10°C und <40% wären interessant ... oder >60% > An >30°C habe ich hier in D kein Interesse :-D <10° und >60%? Dann müsste sie, äääh ich nur lange genug loggen. Aber ich gebe Dir Recht: >30° bei uns ist echt "Schietwetter"... :)
Naja, auch 10-29.9°C und >60% sind interessant. Und 10-29.9°C und <40% ... Haben wir ja beides noch nicht. Alle Kombinationen eben. Edit: Nachdem Du eine Reihe von Daten gesammelt hast, schiebe die ganze Liste doch mal durch ein 'sort -u' um doppelte Werte herauszufischen. Gruß auch an Bianca Jobst
Viel is' noch nicht. Bereinigt und durch sort -u gehauen. Wieder das bekannte Schema: Temp hoch/Feucht runter aka Temp runter/Feucht hoch==gleiche Bit-Combi. Hier sortiert nach ??? Spalte:
1 | 100111101000 100100100000 00001111 17.9 49 |
2 | 010000011000 111000100000 00011111 18.2 47 |
3 | 000000011000 101000100000 00101110 18.0 45 |
4 | 001000011000 111000100000 01011100 18.4 47 |
5 | 011000011000 101000100000 01011100 18.6 45 |
6 | 101000011000 011000100000 01011100 18.5 46 |
7 | 110000011000 000100100000 01011100 18.3 48 |
8 | 110000011000 000100100000 01011100 18.3 48 |
9 | 111000011000 001000100000 01011100 18.7 44 |
10 | 000000011000 111000100000 01101101 18.0 47 |
11 | 011011101000 100010100000 01101101 17.6 51 |
12 | 100000011000 011000100000 01101101 18.1 46 |
13 | 100000011000 011000100000 01101101 18.1 46 |
14 | 111011101000 000010100000 01101101 17.7 50 |
15 | 111011101000 100100100000 01111101 17.7 49 |
16 | 110000011000 111000100000 10011011 18.3 47 |
17 | 110000011000 111000100000 10011011 18.3 47 |
18 | 000000011000 011000100000 10101010 18.0 46 |
19 | 001011101000 010010100000 10101010 17.4 52 |
20 | 101011101000 100010100000 10101010 17.5 51 |
21 | 101011101000 100010100000 10101010 17.5 51 |
22 | 000100011000 001000100000 11011000 18.8 44 |
23 | 001000011000 000100100000 11011000 18.4 48 |
24 | 101000011000 111000100000 11011000 18.5 47 |
25 | 010000011000 011000100000 11101001 18.2 46 |
26 | 000111101000 100100100000 11111001 17.8 49 |
Beispiele wie 011000011000 101000100000 01011100 18.6 45 101000011000 011000100000 01011100 18.5 46 001000011000 111000100000 01011100 18.4 47 oder 000100011000 001000100000 11011000 18.8 44 101000011000 111000100000 11011000 18.5 47 001000011000 000100100000 11011000 18.4 48 lassen auf was schließen. Aber was nur?
Nur zur Info: Ich addiere Temp*10+Feuchte und sortiere die Liste danach. Gruß Jobst
Du musst ja nicht warten bis es draußen Kalt wird. Zum Loggen gibt es Kühlschränke, Gefrierfächer und Backöfen (sofern er kleine Temperaturen kann) Luftfeuchte vllt den Fühler mal nachm Duschen ins Badezimmer legen Viel spaß
Ja, ich auch. Nehmen wir 188+44. Da ist 11101000/232, nicht 11011000/216. Wie Du oben auch schon richtig erkanntest. Noch ist der Hack noch nicht getan :)
sven schrieb: > Du musst ja nicht warten bis es draußen Kalt wird. Zum Loggen gibt es > Kühlschränke, Gefrierfächer und Backöfen (sofern er kleine Temperaturen > kann) > > Luftfeuchte vllt den Fühler mal nachm Duschen ins Badezimmer legen > > Viel spaß Oder einfach auf den Sensor hauchen, den Fön draufhalten, evtl. mit dem Lötkolben drangehen...
Du zeigst hier leider keine Rohdaten. Wie sieht die Übertragung als Bitfolge aus? Sind es erkennbare Byte oder die Unterteilung von dir? Ist deine Reihenfolge (also wo du Bits zeigst) orginal oder gedreht? Hast du schon an gewichtete Prüfsummen gedacht? avr
Moin, eine RAW Reihe sieht so aus
1 | 0000000000000001111000110011000100100100000010001001111 |
Und die wird 2x gesendet. Also so:
1 | 00000000000000011110001100110001001001000000100010011110000000000000001111000110011000100100100000010001001111 |
Ich habe es aber mit jemandem schon aufgedröselt: BSP
1 | 0000000000000001111 101011101000 100010100000 10101010 1111 17.5 51 ist |
2 | |
3 | ...1010 1110 1000 1000 1010 0000 10101010 1111 17.5 51 |
4 | == |
5 | ...0101 0111 0001 0001 0101 0000 ..... |
6 | == |
7 | 5 7 1 1 5 |
8 | == |
9 | 17,5 51 |
Jetzt fehlt nur noch der Sinn der Mystery 8 Bit...
Jobst M. schrieb: > Bianca macht Werbung für Ubuntu ...!? > > Naja, <10°C und <40% wären interessant ... oder >60% > An >30°C habe ich hier in D kein Interesse :-D > > > Gruß > > Jobst Moin Jobst, ich hätte noch 000000001111;S;000100011000;000011100000;01011100;11110000;E;18.8;70 000000001111;S;100100011000;000011100000;11011000;11110000;E;18.9;70 anzubieten. Ist >60% bei 18.8°/18.9°. Ich habe bisher Add, Sub, XOR auf die Werte getestet. Nie kam eigendwas sinnvolles heraus...
SWL DE8MSH schrieb: > Nie kam eigendwas > sinnvolles heraus... Eventuell ist das einfach für einen Sensor reserviert den deine Wetterstation nicht hat?
Das könnte sein. Es gibt aber so regelmäßigkeit bei den 8 Bits. Ich weiß ja, dass die Datenreihen immer doppelt gesendet werden. Jetzt frage ich mich natürlich: wie kann das Gerät erkennen ob sich ein Fehler in den Bitreichen eingeschlichen hat. Nur der Vergleich der beiden Aussendungen dürfte nicht reichen, da beide Reihen zufällig diesen Fehler haben könnten. Und das Gerät zeigt nie Dinge wie 00.0° / 99% an. Was ich bei meiner Software, die (noch) keinen Prüfmechnismus hat durchaus schon vorkam... 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.
Hab mal die Daten durchlaufen lassen mit allen Startwerten und diff/sum/xor kommt aber nur sehr wenige übereinstimmungen bei herraus... Eventuell wird auch einfach nur der Datensatz verworfen wenn nicht zweimal das selbe ankommt?
Moin, kannst Du die Übereinstimmungen zeigen? Auch an eine "schmeiße Weg, was nicht identisch ist"-Möglichkeit habe ich schon gedacht. Das wäre auch eine Art, die ich in die Software implementieren könnte. Nachteil: es könnten größere Sprünge in den Werten auftauchen. Die Werte werden nämlich jede Minute ausgesendet. Die Frage ist natürlich: fällt das wirklich auf? Hintergrund dieses ganzen Hacks: ein Temperaturlogger. D.z.I.
Angehängte Dateien:
-
logger.JPG
82 KB
So sieht der Prototyp im Moment aus. Oben rechts das 433 MHz RX Modul. Jetzt fehlt noch die SD-Card Anbindung.
Die Übereinstimmungen lagen im Bereich 4 oder 5 auf alle Datensätze, das würde ich mal als Zufall bezeichnen. 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.
Du hast Recht mit Deiner Aussage. Selbst mit CRC/Check wüsste ich: die Daten sind falsch. Ich denke, dass ich damit leben kann. Ich werde einen Vergleich beider Aussungen implementieren nach dem Motto: "wenn falsch, dann nicht auswerten" o.ä. Ich danke Euch für Euren Einsatz. Der Chinese ist noch einmal davongekommen :) EDIT: Einen Nachteil hätte der simple Vergleich: wenn beide Datenreihen <<zufällig>> ein falsches Bit hätten, welches genau an der gleichen Position wäre, dann wären beide Reihen identisch und richtig.....
Probiers aus, du solltest sowieso noch eine Konsistenzprüfung durchführen, Temp+Feuchte sollten sich ja nicht schlagartig ändern.
Dann noch fürs Protokoll: Eine einfache Quersumme über die sechs Ziffern ergibt zwar nicht die gesuchte Spalte. Aber die Quersumme korreliert 1:1 mit der Spalte. Soll heißen: Wenn die Quersumme z.B. 17 ist, wie bei "20.2/049, 20.5/046, 20.6/045, 20.7/044, 20.8/043", dann steht in der Spalte immer "11001000" und umgekehrt auch.
Hmmm.... Ok. Das ist ein Ansatz...
SWL DE8MSH schrieb: > EDIT: Einen Nachteil hätte der simple Vergleich: wenn beide Datenreihen > <<zufällig>> ein falsches Bit hätten, welches genau an der gleichen > Position wäre, dann wären beide Reihen identisch und richtig..... Man könnte noch eine Plausibiläts-Prüfung hinzufügen, z.B. ein maximal erlaubtes Delta zu den Werten des letzten gültigen Datenpakets. Temperatur und Feuchte ändern sich ja nicht so schnell. Im Log würde ich dafür ersatzweise die Werte zwischen zwei gültigen Messungen interpolieren und den Eintrag entsprechend markieren. Die Check-Bits sind ja auch nicht wirklich zuverlässig, denn sie sind für alle Fälle identisch, in denen die Summe über die Digits gleich ist, unabhängig davon, ob sich Temperatur und Feuchte jeweils um X in entgegengesetzte Richtung verschoben haben.
Auch das ist ein Ansatz. Gerade hatte ich es wieder, dass die Anzeige "142°342%" anzeigte :( Doof das.... EDIT: Kurz gesagt: es zeigt gerade nur noch Mist an. Jetzt sind wir bei 151.1°und 1010%
SWL DE8MSH schrieb: > EDIT: Kurz gesagt: es zeigt gerade nur noch Mist an. Jetzt sind wir bei > 151.1°und 1010% Interessant: Wie kann man mit 3 den BCD-Ziffern für die Temparatur und den 3 BCD-Ziffern für die Luftfeuchte, die das Protokoll bereitstellt ÜBERHAUPT zwei vierstellige Anzeigewerte errechnen? Alles was größer als 99.9° und 999% ist, wird wohl eher in deinem Code begraben sein, aber nicht im Protokoll.
Möglich ist das. Ist noch alles im Aufbau... Trotzdem hat es seit heute Morgen 8:00 Uhr immer korrekt angezeigt. Ich checke mal den Code, näch... Ich habe auch schon eine Vermutung: ich treffe nicht immer genau den Startpunkt der Bitreihe /4-Bit-Nibble) wo Temp/Feucht drin sind. Das muss ich dringend nochmal checken.
SWL DE8MSH schrieb: > Jetzt sind wir bei 151.1°und 1010% Du solltest in Deiner SW schon mal ausschliessen, daß ein Digit Werte >9 annehmen kann ... Edit: habe mich geirrt ... (Text gelöscht) Wie wäre es mit ein paar Messwerten bei 18°C, 21°C und 22°C? Aber bei 40 - 50% Gruß Jobst
Jobst, Du hast Recht. Eine Ziffer besteht aus einem 4-Bit Nibble. Dieser Wert darf dann nicht >9 sein. Korrekt. Zu den Werten: ja, ich bin dabei :)
SWL DE8MSH schrieb: > ich treffe nicht immer genau den > Startpunkt der Bitreihe Du solltest start und Endpunkt matchen und einfach in einem Puffer solange schieben bis es "passt" und erst dann als möglichen Datensatz akzeptieren.
Hi Läubi: genau das setze ich gerade um. Fülle ab Start, der immer erkannt wurd, ein Array. Habe es gerade im Debug... Sieht im Moment wieder gut aus mit den Werten.
Angehängte Dateien:
-
DSCF1435.JPG
83 KB -
DSCF1436.JPG
82 KB -
DSCF1437.JPG
82 KB
Mal sehen was passiert... Bis jetzt alles ok. Aber noch ohne Identisch-Check. Ich muss erstmal den 1552° 500% Bug rauskriegen.
Angehängte Dateien:
-
DSCF1439.JPG
21 KB
Verkehrte Welt... Nun macht China nichts mehr peng Aber mein Gerät misst noch ;)
Wie werden eigentlich negative Temperaturen kodiert? Gruß Jobst
Was ich bisher habe: Es kann maximal 46 Werte geben. (0.0°C 0% - 99.9°C 99% = 0 - 45) Das 6. Bit repräsentiert invertiert das Bit mit der Wertigkeit 1 Das 7. Bit repräsentiert das Bit mit der Wertigkeit 2 Das 8. Bit repräsentiert das Bit mit der Wertigkeit 4 Das 5. Bit repräsentiert das Bit mit der Wertigkeit 16 Das 4. Bit repräsentiert das Bit mit der Wertigkeit 8 - aber nicht immer ... Bit 2 ist invertiert zu Bit 7, solange Bit 1 nicht gesetzt ist. Gruß Jobst
Moin Jobst, das 43. Bit zeigt es an. Bit 43==1==Negativ 000000000000000000 1111 110011000000 010001001000 00110010 1111 000000000000000000 1111 110011000000 010001001000 00110010 1111 123456789012345678 9012 345678901234 567890123456 78901234 5678 IIIIIIIIIIIIIIIIII IIII TTTTTTTTTTTT FFFFFFFFFFFF CCCCCCCC EEEE I=M.E. Intro/Einschwinger o.Ä. Ich nehme (n==15) als Start an. T=Temperatur F=Feuchte C=CRC/Check/Sonstwas E=M.E. Outro I, T und E habe ich schon fest im Griff. O.g. Beispiel ist -03,3°/22%. Habe Außenfühler mal in den Freezer getan.
SWL DE8MSH schrieb: > Bit 43==1==Negativ Aha ... Negative Temperatur wird in der Checksumme also als 1 gezählt. Also keine besondere Behandlung ... gut ... Das Bit aber als Feuchtigkeit zu deklarieren, finde ich aber auch etwas ungewöhnlich ;-) Haben die anderen Bits (44-46) evtl. auch eine Funktion? Gruß Jobst
Jobst M. schrieb: > Es kann maximal 46 Werte geben. (0.0°C 0% - 99.9°C 99% = 0 - 45) Damit stimmt dies auch nicht mehr so ganz - obwohl ich mir -99.9°C bei 99% nicht so recht vorstellen kann ... Theoretisch gehen die nun bis 46 (also 47 Werte). Maximal bei Ausnutzung aller Bits bis 60 (also 61 Werte). Gruß Jobst
SWL DE8MSH schrieb: > Habe Außenfühler mal in den Freezer getan. Dann poste doch mal die daraus entstandenen Daten. Insbesondere der Weg von 20°/40% hinab in den Keller könnte aufschlußreich sein.
Jobst M. schrieb: > Negative Temperatur wird in der Checksumme also als 1 gezählt. In der Checksumme? Nein. Bit 43 von links aus. Also noch in der F-Reihe. D.h. in dem 3. 4-Bit_Nibble von links: 000000000000000000 1111 110011000000 010001001000 00110010 1111 123456789012345678 9012 345678901234 567890123456 78901234 5678 IIIIIIIIIIIIIIIIII IIII TTTTTTTTTTTT FFFFFFFFFFFF CCCCCCCC EEEE ^ ^ | | Hiäh
SWL DE8MSH schrieb: > Nein. Doch. :-) 1100 1100 0000 0100 0100 1000 ^ 3+ 3 +0 +2 +2 +1 = 11 ^ ^ Eins. Checksumme Gruß Jobst
Achso meinst Du das :) Stimmt. Dann wird 1 genommen :) Und was bedeutet das nun auf die C-Reihe? Blicke noch nicht ganz hinter....
Jobst M. schrieb: > Das 6. Bit repräsentiert invertiert das Bit mit der Wertigkeit 1 > Das 7. Bit repräsentiert das Bit mit der Wertigkeit 2 > Das 8. Bit repräsentiert das Bit mit der Wertigkeit 4 > Das 5. Bit repräsentiert das Bit mit der Wertigkeit 16 > Das 4. Bit repräsentiert das Bit mit der Wertigkeit 8 - aber nicht immer > ... > > Bit 2 ist invertiert zu Bit 7, solange Bit 1 nicht gesetzt ist. Ahso, verstehe langsam. Die Nibbke werden Addiert. Also 001000000100 001000100000 11110111 20.4 44 TTTTTTTTTTTT FFFFFFFFVVVV CCCCCCCC 0010 0000 0100 0010 0010 0000 20.4 44 TTTT TTTT TTTT FFFF FFFF VVVV 4 +0 +2 +4 +4 +0 =14 Und 14 steckt verwurschtelt in 11110111 CCCCCCCC drinnen. So meinst Du das, oder?
de8msh schrieb: > Und 14 steckt verwurschtelt in > > 11110111 > CCCCCCCC > > drinnen. So meinst Du das, oder? Präzise! Gruß Jobst
Das Problem ist: Entweder erstellt man eine vollständige Tabelle, in der jeder möglichen Quersumme ein "C" zugeordnet ist. Dazu reichen die bisherigen Daten nicht aus - es gibt bisher nur Codes für die Quersummen 7 bis 31. Oder man erkundet wie das "verwursteln" funktioniert. Auch hier komme ich ohne weitere Codes nicht weiter. Zum Gedankenaustausch meine bisherigen Ergebnisse: Angenommen man hat schon ein zwei Nibbles (oder BCD-Ziffern) verwurstelt und so eine Zwischensumme erhalten (1). Nun will ich die nächste Ziffer addieren, die "zufällig" eine Eins sei. Das klappt meistens mit diesem Code:
1 | val = base; // vorher berechnet |
2 | val += 97; |
3 | if( (val & 0x20) == 0 ){
|
4 | val -= 128; |
5 | } |
6 | val &= 0x00FF; |
Nur in 4 Fällen aus den Beispieldaten geht das nicht. Das betrifft die Fälle mit der Quersumme 15, 16, 30 und 31. Ideen? A.H. (1) Das kann man annehmen, denn die sowohl die Quersumme als auch die tatsächliche Berechnung müssen - den Beispieldaten nach - eine Eigenschaft gemeinsam haben: Die Reihenfolge und auch die Anzahl der verarbeiteten Ziffern spielen keine Rolle. D.h. hat man einen Code für eine irgendwie ermittelte Quersumme und den zugehörigen Code, so kann man den Code für die nächste Ziffer verwenden - also quereinsteigen.
A.H. schrieb: > Das betrifft die > Fälle mit der Quersumme 15, 16, 30 und 31. Welche jeweils genau 15 auseinander liegen ... grübel ... Gruß Jobst
So ein Aufwand fuer ein Thermometer ... Das baut man bald mal von Grund auf selbst
Hey! Andere Leute machen Sodoku! :-) Hmmm - mit 16 habe ich keine Probleme, dafür mit 7 und 23 ... Gruß Jobst
Jobst M. schrieb: > Hey! Andere Leute machen Sodoku! :-) Ich bin auch schon über das Stadium des "Es klappt doch auch so" hinaus :) Jetzt geht es nur noch darum dem "Chinamann" das letzte Geheimnis rauszukitzeln :) Und das ist sehr interessant... Keep it up, guys :)
> Oder man erkundet wie das "verwursteln" funktioniert. Auch hier komme > ich ohne weitere Codes nicht weiter. Habe ich schon diese Reihen dargeboten: http://pastie.org/2365002 und http://pastie.org/2365715 Bin mir jetzt nicht ganz sicher...
SWL DE8MSH schrieb: > Habe ich schon diese Reihen dargeboten Ich kannte sie noch nicht. bietet bis auf die 22 aber nichts neues ... Welche sich im übrigen genau so verhält, wie die 23 ... SWL DE8MSH schrieb: > Habe Außenfühler mal in den Freezer getan. Schmeiss ihn mal in den Kochtopf - ich brauche große Prüfsummen. Also so 59.9°C bei 59%, gerne auch 69% oder 69.9°C ... Hauptsache viele 9en hinten ... Gruß Jobst
Ich kann es ja mit einem Fön probieren. Oder vor dem Trockner halten... 18,1° / 69% ist nicht interessant, oder? Hätte ich derzeit...
Nein, die Checksummen sollen >38 sein. Am besten natürlich bis 45. Das wäre aber gerade verkochter Wasserdampf. Gruß Jobst
Schritt 0:
es wird exemplarisch von folgenden RAW-Daten (im BigEndian System!)
ausgegangen:
0000000000000000001111 110011000000 01000100 1000 00110010 1111
PPPPPPPPPPPPPPPPPPPPPP TTTTTTTTTTTT FFFFFFFF VVVV CCCCCCCC EEEE
P = Prologue
T = Temperatur
F = Feuchte
V = Vorzeichen (0=plus, 1=minus)
C = Checksum
E = Epilogue
Schritt 1:
Prologue und Epilogue sind uninteressant und werden verworfen.
Schritt 2:
Die Nutzdaten von Temperatur, Feuchte und Vorzeichen werden als sechs
4bit Zahlen dargestellt.
1100 1100 0000 0100 0100 1000
TTTT TTTT TTTT FFFF FFFF VVVV
3 3 0 2 2 - --> -03,3° / 22%
Schritt 3:
Es wird die Quersumme dieser sechs 4bit Zahlen gebildet
1100 1100 0000 0100 0100 1000
TTTT TTTT TTTT FFFF FFFF VVVV
3 +3 +0 +2 +2 +1 = 11
Schritt 4:
Bildet man nach oben beschrieben Prinzip die Quersummen für alle hier
geposteten Logs, so erkannt man, daß alle Daten mit gleicher Quersumme
auch die gleiche Checksum haben.
Die geposteten Logs enthalten Daten für die Quersummen 7 bis 31.
Es ergibt sich folgende Übersicht:
Quersumme Checksum
7 00010011
8 10010100
9 01010000
10 11010110
11 00110010
12 10110101
13 01110001
14 11110111
15 00000011
16 01001100
17 11001000
18 00101110
19 10101010
20 01101101
21 11101001
22 00011111
23 10011011
24 01011100
25 11011000
26 00111110
27 10111010
28 01111101
29 11111001
30 00001111
31 01000100
Schritt 5:
Theoretisch möglich sind Quersummen von 0 bis 46.
00,0°/00% bis -99,9°/99%
Hätte man Logs für alle 47 möglichen Quersummen so könnte man die
zugehörigen Checksums ganz einfach in einer Tablle - indiziert nach
Quersumme - ablegen/auslesen. Es dürfte aber unmöglich sein Logs für
beispielsweise -99,9°/99% zu erzeugen.
Schritt 6:
Es wird nun versucht Zusammnhänge zwischen Quersumme und zugehöriger
Checksum zu finden.
-> es existieren Logs für die Quersummen 7 bis 31
-> für die Darstellung dieser Quersummen genügen 5 bit
(00000 bis 11111 = 0 bis 31)
-> die 8bit Checksum wird in eine 5bit und 3bit Zahl aufgeteilt
Quersumme Checksum 5bit-Zahl 3bit-Zahl
7 00010 011 8 (00010) 6 (011)
8 10010 100 9 1
9 01010 000 10 0
10 11010 110 11 3
11 00110 010 12 2
12 10110 101 13 5
13 01110 001 14 4
14 11110 111 15 7
15 00000 011 0 6
16 01001 100 18 1
17 11001 000 19 0
18 00101 110 20 3
19 10101 010 21 2
20 01101 101 22 5
21 11101 001 23 4
22 00011 111 24 7
23 10011 011 25 6
24 01011 100 26 1
25 11011 000 27 0
26 00111 110 28 3
27 10111 010 29 2
28 01111 101 30 5
29 11111 001 31 4
30 00001 111 16 7
31 01000 100 2 0
Schritt 7:
In der Darstellung aus Schritt 6 erkennt man zunächst
-> das sich die 3bit Zahl mit der Sequenz 6,1,0,3,2,5,4,7 stetig
wiederholt
-> die 5bit Zahl 'nahe' and der Quersumme liegt
-> eine Ausnahme bildet die Quersumme 31 - dies macht aber Sinn denn die
nächste logische 5bit Zahl in der Reihe währe 32 und diese hat nunmal
6 bit
Schritt 8:
Geht man nun davon aus das sich die Reihe der 5bit Zahlen linear
fortsetzt und die Sequenz der 3bit Zahlen konstant bleibt so lässt sich
die Tabelle für die Quersummen 0 bis 6 logisch erweitern
Quersumme Checksum 5bit-Zahl 3bit-Zahl
0 10000 100 1 1
1 01000 000 2 0
2 11000 110 3 3
3 00100 010 4 2
4 10100 101 5 5
5 11000 001 6 4
6 11100 111 7 7
7 00010 011 8 6
8 10010 100 9 1
9 01010 000 10 0
10 11010 110 11 3
11 00110 010 12 2
12 10110 101 13 5
13 01110 001 14 4
14 11110 111 15 7
15 00000 011 0 6
16 01001 100 18 1
17 11001 000 19 0
18 00101 110 20 3
19 10101 010 21 2
20 01101 101 22 5
21 11101 001 23 4
22 00011 111 24 7
23 10011 011 25 6
24 01011 100 26 1
25 11011 000 27 0
26 00111 110 28 3
27 10111 010 29 2
28 01111 101 30 5
29 11111 001 31 4
30 00001 111 16 7
Schritt 9:
mögliche Kalkulation (hoch spekulativ):
0 1000 0 100 1 1 // wahrscheinlich als unmöglich
// auszuschließen!? -> keine Messwerte
1 0100 0 000 2 0
2 1100 0 110 3 3
3 0010 0 010 4 2
4 1010 0 101 5 5
5 1100 0 001 6 4
6 1110 0 111 7 7
7 0001 0 011 8 6
8 1001 0 100 9 1
9 0101 0 000 10 0
10 1101 0 110 11 3
11 0011 0 010 12 2
12 1011 0 101 13 5
13 0111 0 001 14 4
14 1111 0 111 15 7
15 0000 0 011 0 6
16 0100 1 100 18 1
17 1100 1 000 19 0
18 0010 1 110 20 3
19 1010 1 010 21 2
20 0110 1 101 22 5
21 1110 1 001 23 4
22 0001 1 111 24 7
23 1001 1 011 25 6
24 0101 1 100 26 1
25 1101 1 000 27 0
26 0011 1 110 28 3
27 1011 1 010 29 2
28 0111 1 101 30 5
29 1111 1 001 31 4
30 0000 1 111 16 7
31 01000 1 00 34 0
.
.
45
46 // zu verwerfen???
byte_quersumme = berechne_quersumme( RAW_DATA );
byte_checksum = 0;
if( byte_quersumme >= 1 && byte_quersumme <= 15 ) // 1-15
{
byte_checksum = ( (byte_quersumme + 1) and 11110000 ) \
and ( 11110111 ) \
or ( (byte_quersumme xor 1000000) shr 5 );
}
else if( byte_quersumme >= 16 && byte_quersumme <= 30 ) // 16-30
{
byte_checksum = ( (byte_quersumme + 2) and 11110000 ) \
or ( 00001000 ) \
or ( (byte_quersumme xor 1000000) shr 5 );
}
else
{
byte_checksum = ( (byte_quersumme + 3) and 11111000 ) \
or ( 00000100 ) \
????? ;
}
Ergo:
Für eine weitere Analyse fehlen Daten - insbesondere Checksum > 31
Das ablegen der Checksums in einer nach Quersumme indizierten Tabelle
scheint die sinnvollste Lösung.
Schon jetzt sollten mit den Daten für die Quersummen 1-31 nahezu alle in
unseren Breitengraden möglichen Konstelationen abgedeckt sein.
Have Fun
@Thomas: Danke für die gute Zusammenfassung. Ein paar Ergänzungen aufgrund meiner Beobachtungen: - Die Dreiergruppe funktioniert so: Ist das Low-Bit der Gruppe gesetzt, so wird Eins substrahiert, anderenfalls Drei addiert. Überläufe werden ignoriert. - Die Fünfergruppe halte ich für eine Vierergruppe und ein Spezial-Bit. - In der Vierergruppe läuft ein einfacher Zähler mit Schrittweite Eins durch, Überläufe werden ebenfalls ignoriert. - Ist die Vierergruppe vor dem Inkrementieren 0000, so wird die Vierergruppe ZUSÄTZLICH zum normalen Inkrementieren NOCHMAL Inkrementiert. und ZUSÄTZLICH das Spezialbit invertiert. (Beides zusammen kann man auch als XOR 0x11 auf das gesamte Byte betrachten.) Das funktioniert bis auf eine Ausnahme auf allen bisher ermittelten Daten. Die Ausnahme ist der schon von Thomas erwähnte Schritt von Quersumme 30 zu Quersumme 31. Das alles kann man im angehängten Code finden. Weitere Gedanken: - Vielleicht ist der Code für die Quersumme 31 aber auch einfach falsch, da er in den Daten nur einmal vorkommt, alle anderen Codes aber mehrfach gesichert sind. Man müsste nun genau wissen, wie zuverlässig die Mitschnitte sind. - Ich glaube, dass es sich ursprünglich um eine 4-Bit basierte CPU und einer entsprechenden Rechnung handelt. Vielleicht hilft das, wenn man z.B. versucht die Überträge in den Schritt 30->31 einzubauen. Aber wie jetzt eigentlich alle Vorredner bemerkt haben: Ohne weitere Daten halte ich es für sinnlos, das Thema weiter zu beackern. Und da auch gesicherte Daten für die Quersummen 0 bis 6 fehlen, ist man selbst im Herbst nicht sicher. Außerdem wäre zum Abschluss noch möglichst genaue Angaben und Photos über erkennbare Herstellerbezeichnungen, Platinen etc. wünschenswert, damit ggfs. auch Andere eine reele Chance haben, aus den Bemühungen Nutzen zu ziehen. CU A.H.
Angehängte Dateien:
-
DSCF1444.JPG
210 KB -
DSCF1445.JPG
250 KB -
DSCF1446.JPG
280 KB -
DSCF1447.JPG
320 KB -
DSCF1448.JPG
310 KB -
DSCF1449.JPG
310 KB -
DSCF1450.JPG
230 KB -
DSCF1451.JPG
230 KB
Moin, hier ein paar Bilder des Senders. Scheint einen kapazitiven (billig)Feuchte-Sensor zu haben. Darunter ist die Perle für die Temperatur Messung. Das scheint für 9,95 € ok.
> hier ein paar Bilder des Senders. Scheint einen kapazitiven > (billig)Feuchte-Sensor zu haben. Darunter ist die Perle für die > Temperatur Messung. Das scheint für 9,95 € ok. Ist wohl doch ein "Resistiver Feuchtigkeitssensor". Siehe Folie 10 von http://www.scribd.com/doc/27536011/Feuchtesensoren Ich tippe auf sowas hier: https://www.distrelec.ch/feuchtesensor/sencera-co-ltd/h25k5a/647395;jsessionid=A2E7EB773AA52DCA1B52C13EB12DA603.chdist144 Auch der "Reference circuit" aus dem Datasheet kommt mir nun irgendwie bekannt vor. Der Feuchtesensor mit dem Thermistor. Das riecht nach dem Sender ;)
Angehängte Dateien:
So sieht der Spaß aus, wenn keinerlei Check auf korrekte Daten stattfindet... Die vier Peaks sind schon sehr bemerkenswert.
habe eben kurz angelesen: ich fand lustich, das alle sofort wussten, das die Dame nicht "Melanie van de Shell", sondern Bianca Beauchamp ist, hihi... da ich von CRC Berechnungen garkeine Ahnung habe, klinke ich mich mal wieder aus, viel Erfolg noch. Gruß Axelr.
Und schon wieder ein neues Datenformat.... seufz Gabs eigentlich schon zweimal dasselbe? Oder gab es jedesmal ein neues? Zum Inhalt: Es sind drei neue Codes drin: Quersumme=23, Code=01000100=34 Quersumme=32, Code=11000000=3 Quersumme=33, Code=00100110=100 Der Code mit der Quersumme 23 ist wahrscheinlich ein Messfehler, denn für Quersumme 23 existieren schon viele andere Beispiele mit dem Code 10011011=217. Die Quersummen 32 und 33 dagegen schließen sich nahtlos an die Quersumme 31 an. Damit sehe ich diesen Code als richtig an und nicht mehr als fehlerhaft. (s.o.) Bleibt die Frage nach den niederen Quersummen. Wie wäre es mit einer weiteren Runde im Eisfach, aber diesmal mit den Daten-Mitschnitten :-) Vor allem wäre der Code für 00.0°00% wichtig, um überhaupt eine sichere Ausgangsbasis zu haben.
Moin, das mit dem Formt tut mir leid. Ich habe von Terminal auf SD-Card logging umgeschaltet. Dadurch schreibe ich nur noch die Datem, die ich brauche. Habe also 000000001111 .... 1111 weggelassen, weil sie für den Hack keine Rolle (mehr) spielen. Sorry :)
> Wie wäre es mit einer weiteren Runde im Eisfach, aber diesmal mit den > Daten-Mitschnitten :-) Vor allem wäre der Code für 00.0°00% wichtig, um > überhaupt eine sichere Ausgangsbasis zu haben. Hier die Eisfachrunde. 00,0° 00% klappt nicht bei einer Auflösung von einer Minute. http://pastie.org/2397486
Die gute Nachricht: Es ist wenigstens ein neuer Code für die Quersumme 6 dabei. Deren Wert (231) fügt sich auch ins Raster ein. Die schlechte Nachricht: Es sind diesmal auffallend viele Fehler dabei: 100111100000 100110000000 10110101 7,9 19 Code deutet auf Quersumme 12 hin, nicht 26 000010011000 100001000000 00000011 19 21 Code deutet auf Quersumme 15 hin, nicht 13 001010011000 110001000000 10101000 19,4 23 Bit-Flip in Checksumme? 101011100000 100111100000 00101110 7,5 79 Code deutet auf Quersumme 18 hin, nicht 28 110011001000 011000010000 11101000 13,3 86 Bit-Flip in Checksumme? Unbekannter Code, QS aber schon bekannt: 21 Wenn wir so ein Datenpaket am Anfang bekommen hätten, dann wären wie nie soweit gekommen wie wir jetzt sind. Denn wir hätten zu Anfang keine Chance gehabt, die kaputten Daten von den guten Daten zu unterscheiden. @SWL: Wenn die Minutenauflösung für das Eisfach grob für mehrere Werte um 0°0% sind, dann probier doch mal Eiswasser mit Eiswürfeln. Das sollte in einer isolierten Kühlbox konstante 0° über einen langen Zeitraum liefern. Nur wie bekommt man dabei auch 0% Luftfeuche hin? Vielleicht reicht es, das Gerät zusammen mit ein paar Silica-Beutelchen luftdicht zu verpacken und im Warmen erstmal zu warten, bis die die Feuchte aufgesaugt haben. Ansonsten hilft vielleicht noch die chemische Luftentfeuchtung mit irgendwelchen Salzen. Keep Testing!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.