mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Checksumme im Funkprotokoll von Thermo_Hygro-Sensor


Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich versuche seit Tagen die Funkübertagung von meinen 
Thermo-Hygro-Sensoren (TFA Dostmann TS33F) zu verstehen um es selber 
generieren zu können. Ich habe viel gefunden zu anderen Sensoren, aber 
meiner ist leider anders.
Einige Infos waren hilfreich um das Protokoll bis hier zu verstehen, 
aber ich komme einfach nicht mit der Checksumme weiter! Hab schon so 
viel gerechnet und probiert.. Ich vermute XOR-Verknüpfungen, aber wenn 
ich glaube, es geschafft zu haben, klappt es bei dem nächsten Datensatz 
nicht mehr :-(

Hier mein aktueller Wissensstand:

Codierung: Biphase-Mark-Code, lässt sich gut und einfach ablesen.
Gesamtumfang:11Byte (LSB-first)
in den ersten 4 Byte ist ID, Typ und Kanal codiert. Ändert sich nach 
Reset!(siehe Protokolle). Letzes Bit enthält Vorzeichen der Temperatur.
Danach folgt die Temperatur in 3 Nibbles mit noch unbekannter Codierung, 
aber das wäre nicht so schlimm. Ich vermute Faktor + Offset [muß ja auch 
für Fahrenheit gehen].

Die nächsten beiden Nibbles waren bisher immer fix (evtl. Bat.low und 
"Messbereich verlassen").
Danach 2 Nibbles mit Luftfeuchtigkeit, einfach BCD, zuerst 1%, dann 10%.
Das nächste Nibble habe ich noch nicht verstanden und wird fast immer 
von '1111' gefolgt. den Zusammenhang vesteh ich nicht.
Ich vermute, dass hiernach die Checksumme kommt (siehe . Aber evtl. ist 
auch der Taupunkt noch irgendwo enthalten - ich denke aber eher, dass 
den die Wetterstation ausrechnen wird. Es soll aber wohl Sensoren geben, 
die das auch übertragen.

Ich würde mich sehr freuen wenn jemand einen Verdacht hat! Ich komme wie 
gesagt nicht weiter und hab wirklich schon viel ausprobiert.

Hier mal ein paar Datensätze:, wie gesagt, ich gehe davon aus, dass die 
letzten 5 Nibbles zur Fehlererkennung vorgesehen sind. Teilweise 
funktioniert XOR auf die Nutzdaten, dann aber wieder nicht. Es soll auch 
Checksummen geben, bei denen von den Nutzdaten die Summe gebildet wird 
und nur das untere Byte dann geschrieben wird, oder manche addieren 
etwas zur Summe hinzu.. Ich komme momentan hier leider nicht weiter, 
vielleicht übersehe ich auch nur irgendwas? Das darf doch nicht so 
schwer sein, oder??

Der Grund für das ganze ist, dass ich eben an meine Wetterstation eigene 
Sensoren anschließen möchte. Dafür muss ich natürlich die Checksumme 
bilden können! Da bin ich natürlich nicht der erste, aber ich habe 
keinen Hinweis für dieses Protokoll finden können! Hier sind viel mehr 
Bits zur Fehlererkennung enthalten!
Vielen Dank schon einmal falls Euch etwas einfällt!



22.9°C;61%
                                          |Vorzeichen
1110 0100 1011 1011     0111 0011 1011 1100     1110 0101 0010     1000 0111     1000 0110     1001     1111 1000 1110 0101 0100 0000
---------ID-------          Kanal und Typ       --Temperatur--     ---fix---    Feuchtigkeit    -?-           ----checksumme??------  

----------
23.8°C;60%
1110 0100 1000 1011     0111 0011 1011 1100     1100 0111 0010     1000 0111     0000 0110     0001     1111 1000 1010 0111 1111 0100
----------
23.8°C;59%
1110 0100 1101 1011     0111 0011 1011 1100     1100 0111 0010     1000 0111     1001 1010     0001     1111 1010 0111 0110 1011 0100
----------
23.2°C;61%
1110 0101 1100 1011     0111 0011 1011 1100     1101 0011 0010     1000 0111     1000 0110     1001     1111 1001 0110 0101 0001 1010     
----------
23.3°C;61%
1110 0101 0100 1010     0111 0011 1011 1100     1111 0011 0000     1000 0111     1000 0110     1001     1111 1010 0110 0101 0001 0000
----------
23.2°C;62%
1110 0101 0110 1011     0111 0011 1011 1100     1101 0011 0010     1000 0111     0100 0110     1001     1111 1011 0010 0100 0010 0100
----------
23.2°C;63%
1110 0101 0001 1010     0111 0011 1011 1100     1101 0011 0010     1000 0111     1100 0110     0001     1111 1001 1100 0101 1111 0010
----------
23.3°C;62%
1110 0101 1110 1010     0111 0011 1011 1100     1111 0011 0000     1000 0111     0100 0110     1001     1111 1000 0010 0100 0010 1110
----------
23.5°C;61%
1110 0100 1011 1011     0111 0011 1011 1100     1110 1011 0000     1000 0111     1000 0110     1001     1111 1000 0000 0110 1000 1110                                               
----------
25,7 52%
1110 0101 1011 1010     0111 0011 1011 1100     1111 1010 1010     1000 0111     0100 1010     1000     0111 1000 1110 1110 1010 0110
1110 0100 0111 1011     0111 0011 1011 1100     1111 1010 1010     1000 0111     0100 1010     1000     0111 1011 0110 1101 1110 0000
1110 0101 0011 1011     0111 0011 1011 1100     1111 1010 1010     1000 0111     0100 1010     1000     0111 1001 1110 1100 1001 0000
1110 0100 0100 1011     0111 0011 1011 1100     1111 1010 1010     1000 0111     0100 1010     1000     0111 1011 0000 1100 0010 1110
                                                                                                        ????


Jetzt noch gleiche ID und gleicher Kanal: Nur wenig Bits unterschiedlich (Temperatur)!

1110 0100 0101 1010     0111 0011 1011 1100     1110 1010 0010     1000 0111     1110 1010     1111     1111 1011 0110 0111 0011 0010
1110 0100 0101 1010     0111 0011 1011 1100     1101 1010 0010     1000 0111     1110 1010     1111     1111 1000 0110 0111 0001 0000
1110 0100 0101 1010     0111 0011 1011 1100     1111 1010 0000     1000 0111     1110 1010     1111     1111 1010 0110 0101 0010 1100
                                                  !!   !    !                                                  !!        !    !! !!!



Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ganz kann ich Deiner Tabelle nicht folgen:

Ich würde vermuten, dass die Sensor ID nicht wechselt, das tut sie in 
Deinem Auszug oben aber.

Oder hast Du mehrere Sensoren dran und deswegen unterschiedliche IDs?

Für die Entschlüsseluung würde ich mir außerdem noch ein paar mehr 
wirklich unterschiedliche Temperaturwerte wünschen.

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Temperaturwert sollte wie folgt verschlüsselt sein, immer LSBit 
first:
23.8°C;60%  0     1100 0111 0010  -> 11 0001 1100 10 
                                     ??   8    3  ?? 
23.3°C;61%  0     1111 0011 0000  -> 11 1100 1100 00
                                     ??   3    3  ??
23.2°C;61%  0     1101 0011 0010  -> 11 0100 1100 10
                                     ??   2    3  ??
23.5°C;61%  0     1110 1011 0000  -> 11 1010 1100 00
                                     ??   5    3  ??
25,7 52%  0       1111 1010 1010  -> 11 1110 1010 10
                                     ??   7    5  ??
Zugegeben, damit habe ich immer noch nicht die 10er Grad gefunden, aber 
immerhin zeigt es auf, dass die vermuteten Nibble nicht unbedingt solche 
sein müssen.
Es zeigt außerdem, dass es schwer ist, die Position einer Information zu 
finden, wenn die Information nur wenig differiert. Mach doch noch mal so 
einen Log und sorge dafür, dass der Temperaturbereich auch mal von 
-4...+20 Grad abgedeckt wird, sonst wird das nix.

Gruß, Ulrich

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Also es ist das selbe Gerät. Die ID steht in den ersten 4 Nibbles. Im 
oberen Log-Bereich habe ich immer Reset gemacht weil ich sonst zu lange 
auf den nächsten Wert warten muss.
Da ich andere Messwerte in dieses Protokoll bringen muss, könnte ich die 
genaue Aufschlüsselung der Temperatur auch experimentell danach 
ermitteln.
Das größte Problem ist die Checksumme. Wenn ich die Umrechnung hierfür 
nicht habe, dann klappt das leider nicht.
Ich leg das Ding aber gleich mal ins Eisfach. Der eigentliche Sensor ist 
via I²C im Gerät angebunden - an den eigentlichen MEsswiderstand komme 
ich nicht heran. Hatte schon überlegt den eigentlichen Sensor zu 
simulieren, aber ich denke, dass der I²C-Code sicher auch etwas 
kryptisch sein wird. Dann hätte man die Messwerte ja einfacher abändern 
können, oder sogar erstmal die Messwerte meines zukünftigen Sensors 
damit vererbeiten können, aber ich wollte eher einen ATmega an ein 
433MHz-Modul setzen um die Werte zu übertragen - wesentlich billiger!

Also, ich lass den Sensor eben abkühlen.. Die Logs muss ich ja momentan 
noch alle per Hand ablesen... das dauert dann etwas..

Ich denke aber,dass die Aufschlüsselung der Temperatur nicht so dringend 
ist wie die Checksumme am Ende!
gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich widerspreche Dir ja garnicht, aber es ist einfacher etwas heraus zu 
finden, wenn man möglichst viel kennt.

Am besten wäre es natürlich, wenn man automatisch die Daten von I2C und 
Funkprotokoll loggen würde. Hilfreich wäre es auch gewesen, wenn Du das 
mit dem Reset kenntlich gemacht hättest. Ein automatisches Loggen würde 
natürlich auch über Nacht einfach durchlaufen.

Außerdem verwenden einige Funkprotokolle an verschiedenen Stellen ein 
Toggle-Bit. Dieses schaltet bei jeder neuen Sendung einfach nur um. 
Durch den Reset wird dieser Mechanismus vermutlich ausgehebelt.

Gruß, Ulrich

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ja, da geb ich Dir auf jeden Fall Recht! Ich habe auch eine ganze Weile 
versucht das Ganze automatisch auszulesen, aber ich bekam immer irgendwo 
einen Fehler hinterher und dann hab ich das erstmal alles per Hand 
gemacht...

Ich hab noch einmal ein paar Werte.. Übrigens echt gut, dass ich 
wirklich mal tiefe und hohe Werte genommen habe! Es ändert sich doch 
schon einiges, von dem ich vorher angenommen habe, dass es fix wäre!

Zu dem Toggle-Bit: Oben im ersten Log habe ich immer ein Reset gemacht, 
außer ab da wo ich geschrieben habe, daß die ID gleich bleibt, also die 
letzten 3 sind aufeinander folgende Protokolle ohne Reset!

Bei den Werten ist mir aufgefallen, dass das vermutliche 
"Vorzeichen"-Bits doch keins ist!

Und ganz wichtig!!! Wahrscheinlich sind vor allen Bits noch 2 Einsen!!!
Das wäre für die Checksumme natürlich extrem wichtig! aber 2 einzelne 
Bit? Ich habe es eher dafür vermutet, dass der Sender einschwingen muss, 
die sind nämlich nicht immer so sauber.

Ich habe die Aufteilung etwas angepasst, so wie ich es vermute.

So, hier noch ein log:
63.3°; 10%
1110 0101 1110 1010    0111 0011 1011 1100    1111 0010 0100 1100 0110    0000 1000    1000    1111 1101 0000 1001 1000 1100
-----ID------------    ----Typ & Kanal----    -------Temperatur-------    -Feuchte-                 
-----
1.3°; 83%
1110 0100 1110 1011    0111 0011 1011 1100    1111 0010 0010 0000 0110    1100 0001    1001    0111 1101 0110 1000 1001 0000

-----
-3.5°; 73%
1110 0100 0000 1010    0111 0011 1011 1100    1110 1011 0000 0000 0101    1100 1110    1001    0111 1101 0000 0011 1111 0010

-----
-2.5°; 76%
1110 0100 1110 1011    0111 0011 1011 1100    1111 0001 0010 0000 0101    0110 1110    1001    0111 1111 1110 0011 0100 0000


Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da fällt mir gerade auf, dass das mit den zwei ersten Bit doch gut 
hinkommen könnte, wenn man sich oben Deine Aufschlüsselung der 
Temperatur anguckt! Dann würde sich alles etwas veschieben. Zwischen 
Temperatur und Luftfeuchtigkeit müssten dann aber wieder zwei Bit 
einzeln stehen, sonst kommt das mit der Luftfeuchtigkeit nicht mehr hin!

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich denke, dass es wirklich so ist mit der Temperatur wie Du oben 
schon geschrieben hast! Ich kann die Logs leider nicht mehr ändern, da 
habe ich scheinbar Zahlendreher drin! sehr schlecht! Ich mache es ja per 
Hand.

Also es kommt sonst ja gut hin außer bei den 10ern. Im letzen Log mit 
-2.5° Ist hoffentlich ein Fehler drin! Da käme es nämlich nicht hin.

Also wäre das hier dann mein aktueller Stand mit den beiden zusätzlichen 
bits am Anfang.. Aber noch nichts weiter zur Checksumme :-(
63.3°; 10%
1111 1001 0111 1010     1001 1100 1110 1111 0011    1100 1001 0011   0001   10   0000 1000    1000 1111 1101 0000 1001 1000 1100
-----ID------------    ----Typ & Kanal----------     3    9    12                 0     1          

1.3°; 83%
1111 1001 0011 1010     1101 1100 1110 1111 0011    1100 1000 1000   0001   10   1100 0001    1001 0111 1101 0110 1000 1001 0000
                                                     3    1    1                  3    8

-3.5°; 73%
1111 1001 0000 0010     1001 1100 1110 1111 0011    1010 1100 0000   0001   01   1100 1110    1001 0111 1101 0000 0011 1111 0010
                                                     5    3    0                  3    7


Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Also das ganze scheint doch noch komplizierter zu sein!
Ich bin eigentlich davon ausgegangen, dass die Daten 3x direkt 
hintereinander gesendet werden, also einfach 2x wiederholt werden, aber 
ich habe gerade bemerkt, dass die Daten nicht genau gleich sind! Ich 
gehe mal davon aus, daß da noch codiert ist, welche Nachricht das ist.

Hier noch ein Log von einer Sendung:
1111 1001 0000 0010    1001 1100 1110 1111 0101      1010 1100 0000    0001    01    1100 1110    1001 0111 1101    1000 1100 0000 1010
1111 1001 0000 0010    1001 1100 1110 1111 0011      1010 1100 0000    0001    01    1100 1110    1001 0111 1101    0000 0011 1111 0010
1111 1001 0000 0010    1001 1100 1110 1111 0110      1010 1100 0000    0001    01    1100 1110    1001 0111 1101    0000 1001 0100 1010
--------ID---------    --Typ, Kanal & Nummer?--      --Temperatur--                   Feuchte                       -------Check-------

Da ja im Prinzip die Nutzdaten gleich sein werden, bis auf 
"Sendungsnummer", würde ich sagen, dass "nur" die letzen 4 Nibbles zur 
Kontrolle dienen!
Eine einfache XOR-Verknüpfung der einzelnen Nibbles kan ich mir nicht 
vorstellen weil die Änderung der vorherigen Daten nur auf die letzten 3 
Bit des einen Nibbles beschränkt ist und sich dabei auch nur die letzten 
3 Bit bei XOR ja nur ändern dürften. Demnach müsste das Ergebnis-Nibble 
am ersten Bit bei allen gleich sein. Solch ein Nibble taucht da aber 
nicht auf.
Da kommt dann vielleicht noch das angesprochene Toggle-Bit dazu???
Hat da jemand eine Vermutung?
Also wie gesagt, ich muss unbedingt den Check-Bereich entschlüsseln 
können!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, immerhin hat die 60°C+ und das durchlaufen ein paar andere Rätsel 
gelöst:
63.3°;10%   1110 0101 1110 1010   0111 0011 1011 1100  11   1100 1001  0 0110 0 0110    0000 1000    1000    1111 1101 0000 1001 1000 1100
                                                              3    9   T  6
23.3°C;61%  1110 0101 0100 1010   0111 0011 1011 1100  11   1100 1100  0 0100 0 0111    1000 0110    1001    1111 1010 0110 0101 0001 0000
                                                              3    3   T  2
1.3°;83%    1110 0100 1110 1011   0111 0011 1011 1100  11   1100 1000  1 0000 0 0110    1100 0001    1001    0111 1101 0110 1000 1001 0000
                                                              3    1   T  0
-3.5°;73%   1110 0100 0000 1010   0111 0011 1011 1100  11   1010 1100  0 0000 0 0101    1100 1110    1001    0111 1101 0000 0011 1111 0010
                                                              5    3   T  0
-2.5°;76%   1110 0100 1110 1011   0111 0011 1011 1100  11   1100 0100  1 0000 0 0101    0110 1110    1001    0111 1111 1110 0011 0100 0000
                                                              3    2   T  0

Die Bits sind nicht unbedingt in feste nibble zusammen gepackt, sondern 
kommen, wenn man sie in einen seriell-parallel Wandler schickt nachher 
an einer Position aus, an der man einfach den Protokoll-Overhead 
ausmaskiert und sinnvolle Ziffern erhält, am einfachsten BCD codiert.
So verwundert es mich nicht, dass sich das gesuchte Toggle-Bit mitten 
zwischen den Celsius Einern und Zehnern versteckt. Aber ich glaube, Du 
hast einen Tippfehler, es muss 69.3°C und -2.3°C heißen, oder?

Um einen weiteren Kandidaten zu finden, solltest Du den Sensor mal mit 
einem Labornetzteil versorgen und sehen, ob du das so runter regeln 
kannst, dass der Sensor in Low-Battery geht. Manche Sensoren gegen die 
Batterispannung auch in mehreren Stufen an. Damit wäre dann ein weiteres 
Bit oder sogar mehrere definiert.

Du hast auch recht, wenn Du sagst, dass einige Blöcke in dem Prokoll 
vorhanden sind, die sich nie ändern. Die Kodierung erfordert, dass sich 
der Empfänger synchronisiert.

Für ein Muster hinter der Prüfsumme müsste man nun noch zwei oder drei 
Pakete haben, die identische Werte für Temperatur und Feuchte 
übertragen...
Sportliche Aufgabe so ohne maschinelle Aufzeichnung...

Wie machst Du das überhaupt von Hand? Sitzt du am Scope auf 
Single-Trigger und wartest auf ein Telegramm?

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Das einzige Bit, dass sich bei Vorzeichen unterscheidet ist 
das hier:
1.3°;83%   1110 0100 1110 1011   0111 0011 1011 1100  11   1100 1000  1 0000 0 0110    1100 0001    1001    0111 1101 0110 1000 1001 0000
                                                             3    1   T  0       ^Vorzeichen 0=-/1=+
-3.5°;73%  1110 0100 0000 1010   0111 0011 1011 1100  11   1010 1100  0 0000 0 0101    1100 1110    1001    0111 1101 0000 0011 1111 0010
Hier nur als Ausschnitt, aber es ist bei allen vorigen Telegrammen mit 
positiven Werten eine 1.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch einer :)
 0100 1100  1 0100 001 1 1  1100 0110 0  001  1111 1001 1100 0101 1111 0010
   2    3   T  2       V P    3    6  P
 1100 1000  1 0000 001 1 0  1100 0001 1  001  0111 1101 0110 1000 1001 0000
   3    1   T  0       V P    3    8  P
 1100 1001  0 0110 001 1 0  0000 1000 1  000  1111 1101 0000 1001 1000 1100
   3    9   T  6       V P    0    1  P
 1010 1100  0 0000 001 0 1  1100 1110 1  001  0111 1101 0000 0011 1111 0010
   5    3   T  0       V P    3    7  P
 1100 0100  1 0000 001 0 1  0110 1110 1  001  0111 1111 1110 0011 0100 0000
   3    2   T  0       V P    6    7  P
Hier nur der Ausschnitt um die Temperatur herum. Das mit V 
gekennzeichnete Bit ist das Vorzeichen von eben. Das neu mit P 
gekennzeichnete Bit scheint die Anzahl der im davor stehenden T-Zehner 
+Vorzeichen auf eine gerade Anzahl Bits aufzurunden, also even Parity. 
Das zuerst vermutete Toggle Bit T macht vielleicht das selbe für T-Einer 
und T-10tel.
Die drei noch nicht dekodierten Bits zwischen T-10er und Vorzeichen 
könnten für die Batterie stehen.
Ach noch einer :) Auch das Bit hinter der Feuchte scheint Even-Parity 
für eben Feuchte zu sein. Hab noch einmal ein paar Deiner Telegramme 
zusammen kopiert und die Sachen entsprechend markiert.

Gruß und gute Nacht
Ulrich

Autor: ARC H. (gznw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Mensch!! Da hast Du ja echt noch einiges herausgefunden!! Cool!

Also ich komme huete leider erst spät nach Hause, ahbe aber gerade eben 
noch schnell ein paar Logs gemacht.

Ich habe leider nur ein analoges Oszilloskop, daher muss ich es mit der 
"Soundkarten"-Variante machen.. Etwas unschön, aber erstaunlich gut 
geeignet dafür :-)
Vor allem weil man über so langen Zeitraum aufzeichnen kann. Ich werde 
mir aber evtl. doch noch einen Controller programmieren dafür.. Den 
Fehler in meinem Programm hab ich gefunden.. Aber eigentlich geht es ja 
auch so...

Also ich habe nur mal auf die Schnelle per Poti die Spannung stark 
abgesenkt, da müsste auf jeden Fall jetzt ein Low-Bat drin sein. Die 
Spannung war dann wohl auch so gering, dass der I²C-Sensor nicht mehr 
richtig ging.. [na, ob das jetzt wirklich gut ist?] Auf jeden Fall 
konnte ich so bei der Temperatur ein HH.H erreichen und auch die 
Luftfeuchtigkeit hatte ihr Maximum von 99% erreicht. Also wäre das ganze 
schon interessant. Ich nehm die Logs mal mit udn guck mir das unterwegs 
an. Muß leider gleich wieder los.
ZU den Logs. Jedes Mal ein Reset - ich wollte gleiche Werte bekommen.
Dann 2x 2gleiche Werte.
low-Bat?;Temp HH.H;99%
11 1110 0101 1001 1011    0111 0000 1011 1100    11   1101 1101   0  1101   0   0010   1001 1001    0001    0111 1101 1111 1001 1100 1110
----------------
21.9°C;54%
11 1110 0100 1010 1010    0111 0011 1011 1100    11   0001 1000   0  0100   0   0111   0010 1010    1001    1111 1000 0100 0100 1010 0110
11 1110 0101 1110 1010    0111 0011 1011 1100    11   0001 1000   0  0100   0   0111   0010 1010    1001    1111 1010 1100 0101 1101 0110
----------------
21.8°C;54%
11 1110 0100 1001 1010    0111 0011 1011 1100    11   1001 1000   1  0100   0   0111   0010 1010    1001    1111 1010 0010 0111 0101 0100
11 1110 0100 1010 1010    0111 0011 1011 1100    11   1001 1000   1  0100   0   0111   0010 1010    1001    1111 1010 0100 0110 1001 1010


//Edit: Ach ja, das sind wieder nur die Daten aus dem mittleren Block, 
so wie am Anfang ;-) und die Reihnfolge der Logs ist auch etwas anders 
als aufgezeichnet.

Bis später...

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh! Ich seh gerade,21.8 und 21.9 sind vertauscht!!! Unten ist 
21.9,darüber 21.8 ...leider kann ich das oben nicht mehr ändern..

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich schon gesehen :)
Das Batterie-Bit scheint das letzte in dem 3er-Pack zu sein, das hinter 
den T-10er und vor dem Positiv Bit liegt. Habe es mal mit B 
gekennzeichnet:
     11 1110 0101 1001 1011   0111 0000 1011 1100  11   1101 1101 0 1101 000 1 0  1001 1001 0  001    0111 1101 1111 1001 1100 1110
                                                         11   11  P  11   !B V P    9    9  P
     11 1110 0100 1010 1010   0111 0011 1011 1100  11   0001 1000 0 0100 001 1 1  0010 1010 1  001    1111 1000 0100 0100 1010 0110
                                                          8    1  P   2    B V P    4    5  P

Mal ne Frage. Der Sensor, der da per I2C angebunden ist, ist das ein 
SHT11 oder SHT21? Die kenn ich ganz gut.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja,hab das da auch irgendwie so vermutet.. Zu dem Sensor kann ich gerade 
von unterwegs nur das sagen was ich mal mit dem handy fotografiert habe.
HIDEKI
TS04-HUMIDITY
E-PC-TS04-2F0V0
050720 REV.0.1

Ich müsste mal gucken was der genau kann..das mit dem I2C hab ich mal 
von den Anschlüssen abgeleitet: SCL & SDA, gnd und VCC

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Also ich habe leider über den Sensor nicht wirklich viel herausfinden 
können!
Ich mache morgen Vormittag noch ein paar Logs und dann werde ich noch 
einmal versuchen, etwas über die letzten 6 Nibble herausfinden zu 
können.. Ich weiß leider nicht, welche Daten da noch drin enthalten sein 
könnten... Taupunkt bestimmt nicht mehr.. Da bleiben ja auch nicht mehr 
viele Bits übrig für Daten.

Ich habe mal alles bisher zusammengefasst, man kommt ja schnell 
durcheinander..

11 1110 0100 0000 1010    0111 0011 1011 11   0101    1010 1100  0   0000  001 0  1    1100 1110    1  001   0111 1101  1000 1100 0000 1010
11 1110 0100 0000 1010    0111 0011 1011 11   0011    1010 1100  0   0000  001 0  1    1100 1110    1  001   0111 1101  0000 0011 1111 0010
11 1110 0100 0000 1010    0111 0011 1011 11   0110    1010 1100  0   0000  001 0  1    1100 1110    1  001   0111 1101  0000 1001 0100 1010
S   ------ID---------     Typ, Kanal          Nr.?    0.1°  1°   T   10°     B V  P     1%  10%     P                   -------Check-------


Jetzt frag ich mich, wie es zu der Änderung na der ID kommt. Das werde 
ich mal morgen mit ein paar Logs von den 3Paketen testen. Ich hoffe, 
dass da immer diese Reihenfolge auftritt, dann wäre das gelöst!
Aber die restlichen Bits, können doch unmöglich alle nur zum Check sein, 
oder? Zumal es ja schon Parity-Bits gibt. Also noch einmal Parity oder 
ein XOR könnte ich mir vorstellen, wobei XOR auf unterschiedliche 
Blöcke? - das wird ja auch nix.
Ich habe mal eine Version gehört mit Summe über alle Daten und dann die 
unteren 2 Nibble weg oder nur die unteren 2 hinschreiben... Aber was 
macht man mit den einzelnen? Das geht ja genauso wenig. Dann bleibt ja 
nur Parity, oder was gibt es noch? Meinst Du, es gibt sowas wie "Kennung 
der letzten oder nächsten Sendung"?  - würde bei Temperatursensoren aber 
auch wenig Sinn machen, oder?
Vielleciht sollte ich mal jetzt versuchen so einen 3er Block selber zu 
erstellen und gucken was die Wetterstation dazu sagt, also ob die das 
akzeptiert. Vielleicht wertet sie auch gar nicht alle Bits aus??
Ein Versuch wird es wert sein, denke ich.
So, bis später...
gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Also es gibt durchaus Funkprotokolle bei diesen Baumarktsensoren, die 
ein Paket drei mal hintereinander raus husten. Dabei sind natürlich alle 
Sensor/ID/Messwert bezogenen Daten identisch, aber der Footer 
unterschiedet sich, damit der Empfänger weiß, um welche der drei 
Sendungen es sich handelt.
Es gibt auch Sensoren, die die Daten einmal normal und einmal invertiert 
senden und auch sonst noch verschiedene bunte Dinge mit den Daten 
veranstalten.

Um dem Geheimnis auf die Spur zu kommen, müsste man nun mal ein paar 
Blöcke komplett haben, also 3 (Mehrfach-) Aussendungen mit identischem 
Inhalt (gleiche Kennung, also ohne Reset und gleiche Messwerte) und das 
dann noch 3x mit jeweils neuen Messwerten. Wichtig ist dabei, dass man 
es wirklich ohne Reset durchzieht.

Es scheint in dem Protokoll aber deutliche Recovery-Segmente zu geben, 
also Abfolgen von mehreren 1 und 0, die nur dazu dienen, den Empfänger 
für das Biphase-Decoding zu synchronisieren. Diese Blöcke werden aus den 
0111 oder 1110 Sequenzen zusammen gesetzt. Sie haben sich nämlich in 
keinem der Telegramme jemals verändert.

Ach, nebenbei, was Du mit T kennzeichnest ist ein P, es ist das 
Even-Parity über den ersten Teil der °C Daten.

Dann scheint es bestimmte Header zu geben, die die Datenblöcke 
einleiten. So ist es egal, wie oft Du den Sensor resettest und neu 
anmeldest, die ID wird immer mit 1110 010 eingeleitet. Dann folgen 8 bit 
ID, dann ein Parity.
Einzelsequenzen aus alten Logs
111110010 01101101 1   0111 0011 1011 11  001 1  0001 1100  1 0100 001 1 1  1001 1010 0  0011 1111 010 0111 0110 1011 01 0 0
111110010 11110101 0   0111 0011 1011 11  001 1  1100 1100  0 0100 001 1 1  0100 0110 1  0011 1111 000 0010 0100 0010 11 1 0
111110010 00101101 0   0111 0011 1011 11  001 1  0110 1000  1 0100 001 1 1  1110 1010 1  1111 1111 000 0110 0111 0001 00 0 0
111110010 01110101 1   0111 0011 1011 11  001 1  1100 0100  1 0000 001 0 1  0110 1110 1  0010 1111 111 1110 0011 0100 00 0 0
Dreier-Sequenz aus letztem Log
111110010 00000101 0   0111 0011 1011 11  010 1  1010 1100  0 0000 001 0 1  1100 1110 1  0010 1111 101 1000 1100 0000 10 1 0
111110010 00000101 0   0111 0011 1011 11  001 1  1010 1100  0 0000 001 0 1  1100 1110 1  0010 1111 101 0000 0011 1111 00 1 0
111110010 00000101 0   0111 0011 1011 11  011 0  1010 1100  0 0000 001 0 1  1100 1110 1  0010 1111 101 0000 1001 0100 10 1 0
SYNC+HEAD --ID-----P    Typ, Kanal        Nr.?P  0.1°  1°   P 10°    B V P   1%  10%  P  ???? SYNC    -------Check-------P 0
Hier habe ich noch mal alte und neue Telegramme zusammen kopiert und man 
sieht deutlich die gleich bleibenden Teile trotz Reset und Neuanmeldung.
Beachtet man die Dichte mit der das Protokoll an den verschiedenen 
Stellen Parities eingebaut hat, so kann man vermuten, dass auch hinter 
der von dir als Nr? bezeichneten Stelle ein Parity sitzt. Ich vermute 
noch ein weiteres im Typ/Kanal Block. Aber gehen wir davon aus, dass das 
letzte Bit in Nr ein Parity ist, dann würde der Sensor immer die Abfolge 
2,1,3 als Nummer schicken. Leider habe ich dazu nicht genug vollständige 
Sequenzen.
(Löte doch an der Reset Taste mal einen Pin hoch, damit Du nicht in 
Versuchung kommst:) )

Der noch unbekannte letzte Teil ist mir noch ein Rätsel. Normalerweise 
hätte ich hier auch einen mehr oder weniger konstanten Header erwartet, 
aber wie die ersten drei Telegramme zeigen, kann da auch in den ersten 
Bits hinter den 10% schon alles Mögliche drin stehen kann. Es ist mit 
Sicherheit irgend eine Checksumme, die da verborgen ist, eventuell sogar 
drei oder vier, jeweils eine für einen der Datenblöcke im Telegramm.
Ich hatte mein ein Protokoll gesehen, da wurden auch die Telegramme 
mehrfach gesendet und in einem der Telegramme wurde die Checksumme 
invertiert.

Ach so, das letzte Bit scheint immer 0 zu sein.

Nachtrag:
Ich habe im Footer noch eine Sequenz als SYNC markiert, die an allen 
bisher gezeigten Telegrammen 1111 war.

Noch ein Nachtrag:
das vorletzte Bit schein ein Parity über den kompletten Footer zu sein, 
also die mit ????+SYNC+Unbekannt.

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute mal, Du hast Dich beim abtippen der der Telegramme vertan 
und die Nummer ist 001,010,011, also 1. und 2. Zeile vertauscht. Denn 
alle anderen Telegramme hast Du ja per Reset provoziert und in diesen 
ist immer 001 an der Position 'Nr.'.

Gruß und gute Nacht
Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mensch, also wie Du das so siehst!! Klingt auf jeden Fall echt gut!
Ich habe gerade noch eine Dreiersendung geloggt.. Bzw. ich logge immer 
noch und das hier ist das erste Dreierpaket:


111110010 11010101 1  0111 0011 1011 11   010 1   0010 0100  0   0100  001 1  1   1001 1010  0  0011  1111  000  0011 1011 1010 11  1 0
111110010 11010101 1  0111 0011 1011 11   001 1   0010 0100  0   0100  001 1  1   1001 1010  0  0011  1111  000  0111 0101 1100 01  0 0
111110010 11010101 1  0111 0011 1011 11   011 0   0010 0100  0   0100  001 1  1   1001 1010  0  0011  1111  000  0111 1111 0111 11  0 0                    

Demnach sind die drei Bits für die Paketnummer wohl entschlüsselt :-)

//Edit: Hier das nächste. Gleiche ID! Paketnummern passen echt immer :-)
111110010 11010101 1  0111 0011 1011 11   010 1   0110 0100  1   0100  001 1  1   1010 1010  0  0011  1111  001  1011 1011 1101 11  0 0
111110010 11010101 1  0111 0011 1011 11   001 1   0110 0100  1   0100  001 1  1   1010 1010  0  0011  1111  001  1011 0111 0011 10  0 0
111110010 11010101 1  0111 0011 1011 11   011 0   0110 0100  1   0100  001 1  1   1010 1010  0  0011  1111  001  1011 1101 1000 00  0 0

P.S.: Nee, hab jetzt jedes Mal die 010,001,011... :-)

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hier noch ein 3er-Paket:
111110010 11010101 1  0111 0011 1011 11   010 1   0110 0100  1   0100  001 1  1   1100 1010  0  0011  1111  000  0011 1010 0001 10  0 0
111110010 11010101 1  0111 0011 1011 11   001 1   0110 0100  1   0100  001 1  1   1100 1010  0  0011  1111  000  0011 0110 1111 11  0 0
111110010 11010101 1  0111 0011 1011 11   011 0   0110 0100  1   0100  001 1  1   1100 1010  0  0011  1111  000  0011 1100 0100 01  0 0

Wenn man über so langen Zeitraum loggt, seh ich gerade mal einen 
extremen Vorteil der primitiven "Soundkarten-Methode" gegenüber dem 
Scope ;-)
Wieviele Pakete meinst Du, müsste man noch machen? Ich würde sonst noch 
einmal alle 5 Kanäle durchschalten was mit einem RESET verbunden wäre 
:-)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich wollte ich ins Bett... Eigentlich :)
Einzelsequenzen aus alten Logs
    Präambel |  ID       |   Type Code     |1|                Data Block                  |     Footer                        |0|
    111110010 01101101 1   0111 0011 1 0111 1  001 1  0001 1100 1 0100 001 1 1  1001 1010 0  0011 1111 0 1001 1101 1010 1101 0 0
                6   B        E    C      E     9        8    3      2    C        9    5       C    F      9    B    5    B
    111110010 11110101 0   0111 0011 1 0111 1  001 1  1100 1100 0 0100 001 1 1  0100 0110 1  0011 1111 0 0000 1001 0000 1011 1 0
    111110010 00101101 0   0111 0011 1 0111 1  001 1  0110 1000 1 0100 001 1 1  1110 1010 1  1111 1111 0 0001 1001 1100 0100 0 0
    111110010 01110101 1   0111 0011 1 0111 1  001 1  1100 0100 1 0000 001 0 1  0110 1110 1  0010 1111 1 1111 1000 1101 0000 0 0
Dreier-Sequenz aus letztem Log
    111110010 00000101 0   0111 0011 1 0111 1  010 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0110 0011 0000 0010 1 0
                0   A        E    C      E     5        5    3      0    4        3    7       4    F      6    C    0    4
    111110010 00000101 0   0111 0011 1 0111 1  001 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0000 1111 1100 1 0
                0   A        E    C      E     9        5    3      0    4        3    7       4    F      2    0    F    3
    111110010 00000101 0   0111 0011 1 0111 1  011 0  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0010 0101 0010 1 0
                0   A        E    C      E     D        5    3      0    4        3    7       4    F      2    4    A    4
    SYNC+HEAD --ID-----P   Typ,Kanal P      1  TNR P  0.1°  1°  P 10°    B V P   1%  10%  P  ???? SYNC P -------Check------- P 0
So wird schon eher ein Schuh drauß. Es werden augenscheinlich immer zwei 
Nibbels von einem Parity beendet, also 8-Bit + Even Parity. Nur bei der 
Prüfsumme nicht. Was mich wundert ist, dass die Prüfsumme 16-Bit lang 
ist und vor der Prüfsumme noch etwas steht, dass im high Nibble immer F 
hat aber trotzdem ein Parity-Bit.
Trotzdem erhält das ganze so langsam ein Muster.

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also zuerst noch mal die Frage, ob der Sensor immer n Pakete (3?) 
hintereinander sendet, wenn er einen neuen Messwert schickt?

Dann lass bitte mal ein paar Minuten durchlaufen, um heraus zu finden, 
ob der Sensor einen Messwert-Zähler hat, z.B. da hinten, wo noch ???? 
steht.
Dann wäre dieses Nibble, das immer auf F endet auch einer mehr oder 
weniger sinnvollen Funktion zugeordnet.

Wenn die Pakete wirklich eine 16-Bit Prüfsumme haben, dann müsste man 
sie mal gegen die verschiedenen CRC16 Verfahren laufen lassen und sehen, 
welches da möglicherweise passt. Denn einfaches Aufaddieren scheint 
nicht zu funktionieren. Dafür ist die Prüfsumme zu hoch.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das mit dem Bett kenn ich ;-)

Und ich wollte eigentlich morgen erst wieder tippen :-) Aber wo ich 
gesehen hab, dass Du schon so viel weiter bist...!
111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1110 1111 0111 0 0
111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1101 1100 1110 0 0
111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1111 0110 0000 0 0

Ich muss mir die Pakete auch mal angucken.. momentan tipp ich nur rum 
hier..
Was meinst Du zum Kanalwechsel? Meinst Du, die Pakete reichen so schon?

//Edit:
Also das hier sind alles aufeinander folgende Dreier-Pakete! Es kommen 
grundsätzlich IMMER bei allen Sensoren hier auf dem Grundstück 
3Sendungen in Folge. Und wie gesagt, das sind alles aufeinander folgende 
Sendungen!

So und hier hab ich noch ein Paket:
111110010 11010101 1   0111 0011 1 0111 1  010 1  1010 0100 1 0100 001 1 1  0000 1010 0  0011 1111 0 0000 1110 1110 1111 0 0
111110010 11010101 1   0111 0011 1 0111 1  001 1  1010 0100 1 0100 001 1 1  0000 1010 0  0011 1111 0 0000 1101 1101 0110 0 0
111110010 11010101 1   0111 0011 1 0111 1  011 0  1010 0100 1 0100 001 1 1  0000 1010 0  0011 1111 0 0000 1111 0111 1000 0 0

Mal ne Frage zu den CRC-Methoden.. Wie addiert man denn die einzelnen 
Bits zusammen wenn es keine wirklichen Nibbles sind?? oder einfach mit 
Nullen auffüllen???

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also du hast mehrere dieser Sensoren.
Hast Du auch unterschiedliche Typen, oder haben die alle im 2. Block die 
gleichen Kennung und unterscheiden sich nur in der ID?

Aber um das Prokoll zu finden:
Immer alle Dreier-Pakete zusammen loggen und natürlich auch mal ein paar 
verschiedene Temperaturen loggen. Aber das hast Du ja schon getan.

Es ist jetzt schon klar, dass das einfach Ändern des Paketzählers (TNR) 
bereits eine sehr große Änderung der Prüfsumme zur Folge hat. Wenn es 
eine einfache Summe wäre, dann müsste diese sich proportional verändern, 
je nachdem wie viele Bits die TNR ggf. verschoben einkalkuliert wird.
Aber die Differenz ist ungleichmäßig hoch. Das deutet auf einen CRC16 
Algorithmus hin.

Weitere Resets brauchen wir nicht mehr, denn meine geratenen Parity-Bits 
vorne im Telegramm stimmen augenscheinlich. Wenn Du aber noch 
andersartige Sensoren hast, dann kannst Du ja mal schauen, ob auch 
Typ/Kennung in Bezug auf Parity richtig sind. Die Wahrscheinlichkeit ist 
aber sehr hoch.

Oh, das letzte Trippel hat es in sich. Die Messwerte sind identisch zum 
Vorgänger Trippel und auch das Nibble an ???? stimmt überein. Aber die 
Prüfsumme hat sich ordentlich verändert... eine CRC kann es damit schon 
fast nicht mehr sein. Jedenfalls keine CRC16, denn die hätte auf das 
gleiche Ergebnis kommen müssen. Es macht keinen Sinn bei einem 
Funkprotokoll eine fortlaufende CRC zu verwenden, denn es besteht immer 
die Gefahr, dass ein Telegramm verloren geht. Damit wären Sender und 
Empfänger bei der CRC auseinander.
111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1110 1000 0110 0 0
            B   A        E    C      E     5        5    2      2    4        3    5       C    F      0    7    A    4
111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1101 1011 1111 0 0
            B   A        E    C      E     9        5    2      2    4        3    5       C    F      0    B    D    F
111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1111 0001 0001 0 0
            B   A        E    C      E     D        5    2      2    4        3    5       C    F      0    F    8    8

111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1110 1111 0111 0 0
            B   A        E    C      E     5        5    2      2    4        3    5       C    F      6    7    F    E
111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1101 1100 1110 0 0
            B   A        E    C      E     9        5    2      2    4        3    5       C    F      6    B    3    7
111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1111 0110 0000 0 0
            B   A        E    C      E     D        5    2      2    4        3    5       C    F      6    F    6    0
SYNC+HEAD --ID-----P   Typ,Kanal P      1  TNR P  0.1°  1°  P 10°    B V P   1%  10%  P  ???? SYNC P -------Check------- P 0
Sieht eher so aus, als würde der Sensor in die Sequenz vor der Prüfsumme 
mit Absicht irgendwas eintragen.

Also mal über Nacht laufen lassen, wenn Du das Logging automatisiert 
hast. Und immer schön der Reihe nach nur von einem Sensor loggen oder 
eben keinen Reset machen, dann müsste man ja die unterschiedlichen 
Sensoren anhand ihrer ID filtern können.

So, jetzt wirklich gute Nacht :)
Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0110 1111 1100 1 0
111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0101 1100 0101 1 0
111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0111 0110 1011 1 0

und hier noch ein Block:
111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0110 0011 1101 1 0
111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0101 0000 0100 1 0
111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0111 1010 1010 1 0

Ich speicher mal die restliche Aufzeichnung ab, falls wir noch welche 
brauchen aus dieser Serie hier. Jetzt werd ich mal die Kanäle durchgehen 
um zu gucken wo das Codiert ist.

//Edit: Nee, Du hast Dich bei der Feuchtigkeit vertan!! Oben 53%, 
darunter aber 55%! Also doch nciht gleiche Werte!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARC H. schrieb:
> Mal ne Frage zu den CRC-Methoden.. Wie addiert man denn die einzelnen
> Bits zusammen wenn es keine wirklichen Nibbles sind?? oder einfach mit
> Nullen auffüllen???

Ist schon spät, wa?
Es sind immer Nibbels, also immer vier Bit. Zwei davon stehen immer 
zusammen bevor ein Parity kommt, also steht da immer ein Byte.

Jetzt ist etwas Rätseln angesagt, da wir noch nicht wissen, was mit ???? 
ist und außerdem gibt es noch einige Varianten, wie man die einzelnen 
Nibbles zusammen addieren könnte, wenn es doch nur eine Prüfsumme ist.

Also, gute Nacht für heute.
Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, dass die "Edit"-Funktion hier zeitlich begrenzt ist...
Ich habe es immer noch ncith automatisiert :-( Bin bisher noch nicht 
dazu gekommen.. aber stimmt, dann könnte man das über Nacht laufen 
lassen..
Ich habe noch einen Regenmesser hier und einen Wind-Sensor mit 
zusätzlicher Temperaturerfassung (Windchill).
en müsste ich über Funk auslesen, ich kann aber nicht genau sagen was 
nun dann der Windmesser ist... Da fällt mir doch gerade was ein!!!
Wenn alle Sensortypen ihre Daten in das gleiche Protokoll setzen.. also 
dann bleiben ja bei einigen Sensoren zwangsläufig Bits unbenutzt!!
Ich muss echt mal gucken, ob der Windmesser das gleiche Protokoll 
verwendet.. gar nicht so einfach, weil ich hier insgesamt Neben Regen 
und Wind noch 5 weitere Funkthermometer verwende... - ja, 433MHz ist 
voll :-)
Nebenbei... 433,925 MHz - genau die selbe Frequenz wie die meisten 
Funkfernsteuerungen der Zentralverriegelung und Funksteckdosen und und 
und.. Ist echt interessant was da alles so los ist. Das wird auch der 
Grund sein für die starke Kontrolle am Ende des Protokolls und sie viel 
Parity mittendrin, oder? Also Störungen sind ja vorprogramiert.
Ich geh dann aber auch bald mal. Ich versuch mal den Windsensor zu 
finden :-)
Bis dann,

gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, falls Du noch weiter machen willst, ich hatte noch einen Bug in der 
Bin-Hex Konvertierung, oder auch einfach im Kopf, weil ich das V Bit 
vergessen habe, das gehört ja noch zum T-10 Nibble.
    111110010 00000101 0   0111 0011 1 0111 1  010 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0110 0011 0000 0010 1 0
                0   A        E    C      E     5        5    3      0    4        3    7       4    F      6    C    0    4
    111110010 00000101 0   0111 0011 1 0111 1  001 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0000 1111 1100 1 0
                0   A        E    C      E     9        5    3      0    4        3    7       4    F      2    0    F    3
    111110010 00000101 0   0111 0011 1 0111 1  011 0  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0010 0101 0010 1 0
      F    4    0   A        E    C      E     D        5    3      0    4        3    7       4    F      2    4    A    4

    111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1110 1000 0110 0 0
                B   A        E    C      E     5        5    2      2    C        3    5       C    F      0    7    A    4
    111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1101 1011 1111 0 0
                B   A        E    C      E     9        5    2      2    C        3    5       C    F      0    B    D    F
    111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1111 0001 0001 0 0
                B   A        E    C      E     D        5    2      2    C        3    5       C    F      0    F    8    8

    111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1110 1111 0111 0 0
                B   A        E    C      E     5        5    2      2    C        5    5       C    F      6    7    F    E
    111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1101 1100 1110 0 0
                B   A        E    C      E     9        5    2      2    C        5    5       C    F      6    B    3    7
    111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1010 1010 0  0011 1111 0 0110 1111 0110 0000 0 0
                B   A        E    C      E     D        5    2      2    C        5    5       C    F      6    F    6    0

    111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0110 1111 1100 1 0
                B   A        E    C      E     5        4    2      2    C        9    4       C    F      8    6    F    3
    111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0101 1100 0101 1 0
                B   A        E    C      E     9        4    2      2    C        9    4       C    F      8    A    3    A
    111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0111 0110 1011 1 0
                B   A        E    C      E     D        4    2      2    C        9    4       C    F      8    E    6    D

    111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0110 0011 1101 1 0
                B   A        E    C      E     5        4    2      2    C        8    4       C    F      9    6    C    B
    111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0101 0000 0100 1 0
                B   A        E    C      E     9        4    2      2    C        8    4       C    F      9    A    0    2
    111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0111 1010 1010 1 0
                B   A        E    C      E     D        4    2      2    C        8    4       C    F      9    E    5    5
    SYNC+HEAD --ID-----P   Typ,Kanal P      1  TNR P  0.1°  1°  P 10°    B V P   1%  10%  P  ???? SYNC P -------Check------- P 0

Also Addier mal alles irgendwie aufeinander und schau wann die 
Prüfsumme, vermutlich die letzten 3 Nibble, passt.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist schon spät, wa?
> Es sind immer Nibbels, also immer vier Bit. Zwei davon stehen immer
> zusammen bevor ein Parity kommt, also steht da immer ein Byte.
peinlich.... Ja.

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... Also ich hab mal ein paar Sachen ausprobiert...

guck mal diese beiden hier:
BA EC ED 42 2C 94  -> CF 8E 6D
BA EC ED 42 2C 84  -> CF 9E 55
Was sich da alles ändert nur wegen des einen Bit!

Oder mal so eine Gegenüberstellung:


BA EC ED 42 2C 84  -> CF 9E 55
BA EC ED 42 2C 94  -> CF 8E 6D
Differenzen
             0x10  -> - 0xFE8

BA EC E9 42 2C 84  -> CF 9A 02
BA EC E9 42 2C 94  -> CF 8A 3A
Differenzen
            0x10   -> - 0xFC8

BA EC E5 42 2C 84  -> CF 96 CB
BA EC E5 42 2C 94  -> CF 86 F3
Differenzen
            0x10   -> - 0xFD8

Aber bei dem hier:

BA EC E5 52 2C 35  -> CF 07 A4
BA EC E5 52 2C 55  -> CF 67 FE
Differenzen
            0x20   -> - 0x605A

BA EC E9 52 2C 35  -> CF 0B DF
BA EC E9 52 2C 55  -> CF 6B 37
Differenzen
            0x20   -> - 0x5F58

BA EC ED 52 2C 35  -> CF 0F 88
BA EC ED 52 2C 55  -> CF 6F 60
Differenzen
            0x20   -> - 0x5FD8

Da muss auf jeden Fall eine etwas komopliziertere Rechnung hinter 
stecken fürchte ich... Gibt es irgendwie Programme, die sowas 
herausknobeln können? Also müsste ja machbar sein mit einigen Blöcken, 
oder?
So.. schon vieeel zu spät!!
Bis denn..

gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Also wenn man sich mal diesen Block ansieht:

111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0110 1111 1100 1 0
            B   A        E    C      E     5        4    2      2    C        9    4       C    F      8    6    F    3
111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0101 1100 0101 1 0
            B   A        E    C      E     9        4    2      2    C        9    4       C    F      8    A    3    A
111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  1001 0010 1  0011 1111 0 0001 0111 0110 1011 1 0
            B   A        E    C      E     D        4    2      2    C        9    4       C    F      8    E    6    D

... dann fällt auf, dass sich das 2. Nibble der Prüfsumme um den 
gleichen Wert ändert, wie sich die TNR ändert.
TNR 5->(+4)->9 ... SUM 6->(+4)->A
TNR 9->(+4)->D ... SUM A->(+4)->E

Vergleicht man die Summen über verschiedene Resets hinweg, dann sieht 
man, dass sich der Erste Teil der Prüfsumme ändert, aber dann über alle 
Telegramme dieses Senders hinweg gleich bleibt:
111110010 00000101 0   0111 0011 1 0111 1  010 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0110 0011 0000 0010 1 0
            0   A        E    C      E     5        5    3      0    4        3    7       4    F      6    C    0    4
111110010 00000101 0   0111 0011 1 0111 1  001 1  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0000 1111 1100 1 0
            0   A        E    C      E     9        5    3      0    4        3    7       4    F      2    0    F    3
111110010 00000101 0   0111 0011 1 0111 1  011 0  1010 1100 0 0000 001 0 1  1100 1110 1  0010 1111 1 0100 0010 0101 0010 1 0
  F    4    0   A        E    C      E     D        5    3      0    4        3    7       4    F      2    4    A    4

111110010 11010101 1   0111 0011 1 0111 1  010 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1110 1000 0110 0 0
            B   A        E    C      E     5        5    2      2    C        3    5       C    F      0    7    A    4
111110010 11010101 1   0111 0011 1 0111 1  001 1  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1101 1011 1111 0 0
            B   A        E    C      E     9        5    2      2    C        3    5       C    F      0    B    D    F
111110010 11010101 1   0111 0011 1 0111 1  011 0  0110 0100 1 0100 001 1 1  1100 1010 0  0011 1111 0 0000 1111 0001 0001 0 0
            B   A        E    C      E     D        5    2      2    C        3    5       C    F      0    F    8    8
Zuerst hat der Sensor die ID 0x0A und der erste Teil der Summe ist 0x4F.
Nach reset hat der Sensor die ID 0xEC und die Summe ist 0xCF. Weiter 
oben sieht man in den Logs, dass sich dieser erste Teil der Summer nur 
dann ändert, wenn sich auch die ID ändert. Dann bleibt er immer gleich.
Allerdings gibt es in der ersten Zeile vermutlich einen Tipfehler oder 
einen Übertragungsfehler, denn dort ändert sich die Prüfsumme nach dem 
ersten der drei Telegramme. Das tut sie sonst nie. Aus 0x4F6 wird 
plötzlich 0x4f2.

Also male ich mir jetzt mal die verschiedenen Varianten übereinander und 
schaue was so raus kommt :)

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Also ich habe mal einen anderen Sensor abgehört.. Ich geh davon aus, daß 
es der Windmesser ist, aber ich bin mir nicht sicher! Ich wollte gucken 
welche Teile gleich sind. Ist ganz interessant, aber auch etwas 
frustrieren, da das Protokoll noch mal einige Bytes länger ist!
Der Start ist gleich und auch die "Paketnummern" sind in der gleichen 
Reihenfolge!

ACHTUNG!! ANDERER SENSORTYP!!!!!!!
1111 1001 0  0010 1001 1   0110 1011 1 0011 0  010 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0000 1010 0011 0011 0001 0100 0000
1111 1001 0  0010 1001 1   0110 1011 1 0011 0  001 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0000 1010 0011 0011 1100 0010 0010
1111 1001 0  0010 1001 1   0110 1011 1 0011 0  011 0  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0000 1010 0011 0011 0111 1001 1110
                                                       9     1     0 

ACHTUNG!! ANDERER SENSORTYP!!!!!!!

Hatte leider nicht die aktuellen Wind-Werte hier, aber kurz danach stand 
auf der Wetterstation Windchill: 1.9°C  Was nun die ganzen Nullen solen 
weiß ich nicht - ist ja aber gerade auch egal. Ich denke, daß der erste 
Teil auch so aufgeteilt werden kann.. Also da auch noch jeweils ein 
Parity, oder? Dann ergibt das oben nicht F4, sondern F9 und könnte für 
die Checksummer eben schon ausschlaggebend sein!

gznw

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo...
Hab mal noch ne Verständnisfrage wegen des LSB-first..
Also wenn ich das alles hier rechne, oder in Online-CRC-Rechner 
eingebe... also muss ich dann nicht die Nibbles auch umdrehen?...

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe das jetzt noch mal gerade gerückt:
111110010 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0110 0011 1101 1 0
111110010 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0101 0000 0100 1 0
111110010 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0111 1010 1010 1 0
SYNC+HEAD --ID-----P   Typ,Kanal P      1  TNR P  0.1°  1°  P 10°    B V P   1%  10%  P  ???? SYNC P -------Check------- P 0
111110010 00101001 1   0110 1011 1 0011 0  010 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1100 0101 0000 0 0
111110010 00101001 1   0110 1011 1 0011 0  001 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1111 0000 1000 1 0
111110010 00101001 1   0110 1011 1 0011 0  011 0  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1101 1110 0111 1 0
SYNC+HEAD --ID-----P   Typ,Kanal P      1  TNR P    9    1  P   0    B V P    9    1  P    0    C  p   5    1  p   0    0  p   0    0  p ???? SYNC P -------Check------- P 0
Temperatur und Windmesser im Vergleich.
Ich halte es für möglich, dass die Platine im Windmesser eventuell in 
unverändert in einem Combi-Sensor verwendet werden kann, also 
Windmesser, Windmesser mit Windrichtung und eventuell auch 
Windmesser+Windrichtung+Niederschlagsmenge oder noch mehr. Kann mich 
erinnern mal solche 'alles an einem Stecken' Konstruktionen gesehen zu 
haben. Oder hat der auch Windrichtung (510->15°)?
Merkwürdig, dass er die Windstärke zwei mal im Telegramm hat.

Das mit der 0xF4 in der Präambel kann schon sein. Ich hatte den Teil 
ganz platt als SYNC abgetan. Dafür kommt der aber sehr regelmäßig und 
man kann vielleicht davon ausgehen, dass der SYNC bereits gelaufen ist 
und hier tatsächlich irgend eine ID steht. Also morgen noch mal alles 
mit F9 statt F4 durchrechnen :)
Das 0xF9 könnte eine Art Hersteller ID sein. Danach kommt die Sensor ID.

Oh, der Windsensor zeigt, dass da, wo ich einem immer-1 vermutet habe, 
auch eine 0 stehen kann. Das Ding vor der TNR. Also alles mal nach den 
neuesten Erkenntnissen, eher Vermutungen, umgestellt:
1111 1001 0 11010101 1   0111 0011 1 0111 1  010 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0110 0011 1101 1 0
1111 1001 0 11010101 1   0111 0011 1 0111 1  001 1  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0101 0000 0100 1 0
1111 1001 0 11010101 1   0111 0011 1 0111 1  011 0  0010 0100 0 0100 001 1 1  0001 0010 0  0011 1111 0 1001 0111 1010 1010 1 0
VENDOR-ID P FUNK-ID  P   SENSORTYP P      1  TNR P  0.1°  1°  P 10°    B V P   1%  10%  P  ???? SYNC P -------Check------- P 0
1111 1001 0 00101001 1   0110 1011 1 0011 0  010 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1100 0101 0000 0 0
1111 1001 0 00101001 1   0110 1011 1 0011 0  001 1  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1111 0000 1000 1 0
1111 1001 0 00101001 1   0110 1011 1 0011 0  011 0  1001 1000 1 0000 001 1 0  1001 1000 1  0000 0011 0 1010 1000 1 0000 0000 0 0000 0000 0 0001 0100 0 1100 1101 1110 0111 1 0
VENDOR-ID P FUNK-ID  P   SENSORTYP P      ?  TNR P    9    1  P   0    B V P    9    1  P    0    C  p   5    1  p   0    0  p   0    0  p ???? SYNC P -------Check------- P 0

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JA, also der Windsensor hat Richtung, Windchill und Stärke, sowie Böen 
drin! Deshalb gehe ich echt davon aus, daß es der Windsensor sein wird, 
den ich da erwischt habe.
Zum Kanal habe ich nicht viel herausfinden könne bisher:
Ch.1
1111 1001 0   1011 0100   

Ch.2
1111 1001 0   0011 1010   

Ch.3
1111 1001 0   0010 1110   

Ch.4
1111 1001 0   1101 0101    
1111 1001 0   1011 1101   

Ch.5
1111 1001 0   0100 1011   


Ich vermute den Kanal eigentlich im zweiten Nibble von der Funk-ID und 
dachte eigentlich, dass Kanal 4 immer 0101 wäre.. alle Logs vorher waren 
von Kanal 4.. Vielleicht hat jeder Kanal auch mehrere Möglichkeiten und 
keine ganz starre Kanal-ID.
Ich guck mir das nochmal an mit ein paar Logs..
Nach welchem Muster das erste Nibble abläuft weiß ich nicht - wird aber 
eigetnlich auch nicht so wichtig sein, denke ich.
Ich bekomme beim Rechnen keine sinnvollen Sachen raus.. Gibt es Tools 
für sowas? Also mehrere Eingangs- und Ausgangswerte eingeben und man 
bekommt dann mögliche Rechnungen ausgespuckt, die man dann testen kann?
Bis denn...
gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also überträgt der Windsensor eventuell ein paar Werte mehr wie aktuell, 
gemittelt und letzter Höchstwert...
Das mit der Kanal-Nummer ist auch eine gute Idee. Ich hoffe, Du kannst 
ausschließen, dass Dir da irgend ein Nachbar noch rein funkt.

Also ich habe bisher keine Tools dafür genutzt. Für CRC Berechnung nutze 
ich ggf. den Tiny Hexer, der über Datenblöcke eine CRC berechnen kann. 
Aber das Erkennen von den Mustern und Zusammenhängen mache ich einfach 
auf einem Blat Papier, bzw. direkt in einem simplen Text Editor. Ich 
sehe das mehr so als eine lustige und für Dich vielleicht hilfreiche 
Alternative zu Sudoku :)

Ich habe hier noch ein paar Betty Funkfernbedienungen liegen. Hatte 
schon mal daran gedacht eine davon zum Empfänger für solche Sensoren um 
zu programmieren. Aber die laufen auf 434MHz und ich habe nur einen 
Außensensor an einer einfachen Wetterstation und die läuft auf 868MHz... 
Da wäre dann erst mal Löten angesagt.

So, ich mach mich jetzt mal ab in die Horizontale.
Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!
Ja, irgendwie macht das echt auch Spaß mit dem Rätseln,allerdings ist 
das mit der CRC.Geschichte nun doch etwas kniffelig.. Ausschließen kann 
ich Störungen vom Nachbar nicht,außer bei dem Funkthermometer, bei dem 
ich bisher alle logs gemacht habe. Da greif ich das Signal direkt ab.
Ich hab auch schon überlegt,ob es vielleicht auch 2 unabhängige 
checksummen sind. Also einmal für den Header und einmal für die Daten..

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend!
So, endlich macht n ATmega meinen Job :-)
Ist doch ein kleines bisschen einfacher so :-)
Ich lass das mal ne Weile laufen, dann sollte man ja genügend Pakete 
bekommen...
Ich bin mir ziemlich sicher, dass bei Dir in der Nähe auch jemand solche 
Sensoren hat, oder? Wobei es ja scheinbar sehr viele verschieden 
Protokolle gibt. Dies hier scheint schon recht komplex zu sein.
Ach ja, bei Watterott gibt´s diese 433MHz- Sender und Empfänger richtig 
günstig (Sender ca.3€ und Empfänger ca. 4€).
Bei meinem Funkthermometer sind Sensor, Controller und Sender richtig 
deutlich voneinander getrennt. Daher kann man da einfach am 
Sender-Eingang die Daten abgreifen. Wenn Dein Protokoll zufällig so ist 
wie meins, dann kannst Du ja auch einen besseren Thermosensor verwenden 
und deinen eigenen Sensor verwenden. ;-)
Ach ja, mit den 433MHz-Sender kann man echt richtig viel machen. Die 
Funksteckdosen können auch perfekt gesteuert werden.  Man muss nur 
aufpassen, dass man das Band nicht zumüllt, sonst geht da nicht mehr 
viel..
Naja, ich bin ansonsten mit der Berechnung leider noch nicht 
weitergekommen. Aber ich habe trotzdem mal die Firma Ventus 
angeschrieben, ob man nicht vielleicht einen Tipp bekommen kann. Ich 
glaube da zwar nicht dran, aber ein Versuch ist es wert.
Guck mal.. das klappt echt gut so automatisiert. Nun sind die Werte viel 
näher zusammen! SO wird das viel besser klappen!!
Ich lass mal über Nacht laufen und speicher das in ner .txt-Datei.
Ich kann die ja dann morgen hier als Anhang einfügen.


Bis denn,

gznw
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1111 1100 0000 0110 0 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   1110 0010 0   0011 1111 0   1011 0100 0110 0100 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   1110 0010 0   0011 1111 0   1011 0100 0110 0100 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   1110 0010 0   0011 1111 0   0011 0100 1110 1011 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1100 0100 1011 0010 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1010 1000 1   0100 001 1 1   1110 0010 0   0011 1111 0   0011 0100 1110 1011 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1100 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1010 0100 1111 0111 0 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1100 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1010 0100 1111 0111 0 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1100 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1010 0100 1111 0111 0 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   0001 0010 0   0011 1111 0   0100 0100 0011 1101 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   0010 1000 0   0100 001 1 1   1110 0010 0   0011 1111 0   1011 0100 0110 0100 1 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1100 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1010 0100 1111 0111 0 0
1111 1001 0   0000 1011 1   0111 0011 1   0111 1 010 1   1100 1000 1   0100 001 1 1   0001 0010 0   0011 1111 0   1010 0100 1111 0111 0 0



Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Das sieht doch schon richtig gut aus. Jetzt fehlt nur noch das decoding 
der einzelnen nibbles hinter den Bit-Telegramm. Um zu sehen, ob die 
Telegramme wenigstens vom Parity her stimmen, könnte man ggf. ein p oder 
ein ! hinter ein HEX Nibble schreiben. Dieses Decoding kann man dann 
Stück für Stück ausbauen. Wenn es komplett ist und alle Daten auch noch 
mit der Prüfsumme übereinstimmen braucht man es nur rückwärts zu 
benutzen und schon kann man eigene Telegramme senden :)

Du kannst aber die Decoder Software auch einfach mal anhängen, dann kann 
ich da mit basteln.

Habe mir Watterot noch nicht angesehen. Aber ich hatte ja schon gesagt, 
dass meine Station auf 868MHz sendet. Ich dachte Deine liegt auf 434MHz. 
Das ist zwar unerheblich für das Protokoll, aber ich schau mal nach, was 
so geht. Eventuell gibt es ja ein paar dieser Sender in meiner 
Nachbarschaft. Das würde ja reichen :)

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Ja, meiner liegt auf 433MHz. Aber Du kannst doch eigentlich bei Deinen 
Funksteckdosen-Empfänger auch einfach das Signal abgreifen wenn Du hören 
möchtest was bei DIr in der Nähe los ist...
Mein Code muss ich noch weiter bearbeiten.. Der ist echt gerade nicht 
schön! Wenn man mit dem Programm noch mehr machen will, dann sollte ich 
das wohl mal etwas besser schreiben.
Ich verwende einen ATmega48, gerade mit 18.432MHz.

Als ISR verwende ich (TIMER1_CAPT_vect). Hier muss ich leider jedes Mal 
umschalten, ob fallende oder steigende Flanke erkannt werden soll. 
BEides geht auf dem Eingang leider nicht. Oder ich nehm ne andere ISR.

Dann erfasse ich die Zeiten zwischen 200 Flanken und im Anschluss werden 
daraus die Bits bestimmt und ausgegeben.
Ich werde es heute wohl nicht mehr schaffen, mal gucken...

bis später,
gznw

Autor: ARC H. (gznw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier mein Code im Anhang. Wie gesagt, der war eigentlich nur dafür 
da, dass es funktioniert. Es wird nur das erste Paket ausgewertet, somit 
hat man viele Pakete untereinander, die nur wenig Abweichung haben. Ich 
muss nun noch in die for-Schleife am Ende bei der Ausgabe eine 
Berechnung für Parity und Hex-Wert schreiben.
Da sind bestimmt noch einige Sachen, die man besser machen sollte.
Ganz ganz seltsam ist das Problem an der Stelle wo der Controller warten 
soll bis 200Flanken eingelesen wurden! Gefällt mir überhaupt nicht so:
while(flanken_index<200) uart_send_string("");
Kannst Du mir sagen warum es nur so klappt??? Anders hängt der 
Controller an dieser Stelle! Ich vermute ein Problem zwischen dem Warten 
an der Stelle und der ISR.

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So!
Ich habe es jetzt mal in diese Form hier gebracht ;-)
Eigentlich kann ich es aber auch nur auf die hex-Werte minimieren, oder?
also z.B. nur:
F9 2A EC E5 22 2C 74  -> CF 06 48

Momentan bekomme ich folgende Ausgabe:
1111 1001 0 1111 0101 0 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 1110 0110 1111 1010 1 0
 F    9   0  F    A   0  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  7    6    F    5
1111 1001 0 0100 1101 0 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 0100 0110 1010 0110 1 0
 F    9   0  2    B   0  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  2    6    5    6
1111 1001 0 0001 0101 1 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 0001 0110 1000 1000 1 0
 F    9   0  8    A   1  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  8    6    1    1
1111 1001 0 1010 1101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 0111 0110 1101 0110 0 0
 F    9   0  5    B   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  E    6    B    6
1111 1001 0 1011 0101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 0011 0110 0101 1011 1 0
 F    9   0  D    A   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  C    6    A    D
1111 1001 0 0100 1101 0 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 0100 0110 1010 0110 1 0
 F    9   0  2    B   0  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  2    6    5    6
1111 1001 0 0001 0101 1 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 0001 0110 1000 1000 1 0
 F    9   0  8    A   1  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  8    6    1    1
1111 1001 0 0001 1101 0 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 0001 0010 0 0011 1111 0 1000 0110 1000 1111 0 0
 F    9   0  8    B   0  E    C   1  E    5   1  1    2   0  2    C   1  8    4   0  C    F   0  1    6    1    F
1111 1001 0 0001 1101 0 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 0001 0010 0 0011 1111 0 1000 0110 1000 1111 0 0
 F    9   0  8    B   0  E    C   1  E    5   1  1    2   0  2    C   1  8    4   0  C    F   0  1    6    1    F
1111 1001 0 0000 0101 0 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 0001 0010 0 0011 1111 0 0000 0110 0000 0000 0 0
 F    9   0  0    A   0  E    C   1  E    5   1  0    2   1  2    C   1  8    4   0  C    F   0  0    6    0    0
1111 1001 0 0000 0101 0 0111 0011 1 0111 1010 1 0000 0100 1 0100 0011 1 1110 0010 0 0011 1111 0 1001 0110 0001 0011 1 0
 F    9   0  0    A   0  E    C   1  E    5   1  0    2   1  2    C   1  7    4   0  C    F   0  9    6    8    C
1111 1001 0 1011 0101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 0011 0110 0101 1011 1 0
 F    9   0  D    A   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  C    6    A    D
1111 1001 0 1011 0101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 1010 0110 0110 0011 0 0
 F    9   0  D    A   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  5    6    6    C
1111 1001 0 1011 0101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 1010 0110 0110 0011 0 0
 F    9   0  D    A   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  5    6    6    C
1111 1001 0 1011 0101 1 0111 0011 1 0111 1010 1 1000 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 1010 0110 0110 0011 0 0
 F    9   0  D    A   1  E    C   1  E    5   1  1    2   0  2    C   1  7    4   0  C    F   0  5    6    6    C
1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 0100 0100 0 0100 0011 1 1110 0010 0 0011 1111 0 0000 0110 0010 0001 0 0
 F    9   0  2    A   1  E    C   1  E    5   1  2    2   0  2    C   1  7    4   0  C    F   0  0    6    4    8

P.S.: Was machen wir eigentlich mit den letzten beiden Bits??? Ach.. das 
letzte Parity-Bit wird noch berechnet... kommt noch.
Ansonsten stimme alle von dir vermuteten Parities!

gznw

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi nochmal!
Also weil ich heute Abend nicht zu Hasue bin, lasse ich mir die Daten 
auf einen Serevr laden - immer aktuell ;-)

http://nslu2.homeip.net/myweb/sensor.log

Klappt echt gut so.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also da hast Du ja jetzt ganze Arbeit geleistet! Alle Achtung.

Da Du ja jetzt nur der erste der drei Pakete aufzeichnest, und das 
zeitnah, kann man schön erkennen, dass bei gleichem Inhalt auch die 
Prüfsumme immer identisch ausfällt.
Woher weißt Du eigentlich, dass ich Funksteckdosen habe? Hab ich das 
irgendwo geschrieben, oder wohnst Du direkt neben mir?
Das Protokoll selbiger ist aber offen gelegt, wenn ich das richtig in 
Erinnerung habe. Ist wohl HomeEasy.

Also die Prüfsumme ist nicht so durchsichtig, wie gedacht. Außerdem 
scheint es in dem Log auf dem Server auch ein paar Probleme zu geben. Ob 
das jetzt an der Software liegt, oder tatsächlich Empfangsprobleme sind, 
kann ich nicht sagen. In einigen Fällen stimmen Daten und Prüfsumme 
nicht überein, obwohl sie davor und danach korrekt sind. Natürlich meine 
ich korrekt im Sinne von sie folgen dem Muster.

Deine Software habe ich mir auch gerade mal angesehen. Also das kann man 
noch aufräumen, aber darum geht es nicht. Sie soll ja nur ein kleines 
Helferlein sein, damit man mal fortlaufende und nachvollziehbare 
Telegramme bekommt. Trotzdem ist es für den kleinen AVR natürlich eng, 
wenn Du die 200 Zeiten des Decoders als int ablegst. Wäre vermutlich 
besser, den Timer so zu drehen, dass er einen nachvollziehbaren Wert der 
Pulsbreite in einem Bereich von <255 schafft. Dann würde das auch in ein 
Byte passen. Oder aber DU dekodierst das Bit gleich im ISR und schreibst 
nur das Bit raus.
Ach ja, bau doch mal eine kleine globale Variable in das ISR mit rein, 
die nach dem 200ersten Flankenwechsel gesetzt wird und damit der 
Mainloop signalisiert, dass es was zu holen gibt. Dann kann diese die 
Daten auch in Ruhe entschlüsseln und darstellen. Dann setzt sie diese 
Variable wieder zurück auf 0.

Das kann man dann ausbauen. Hat man aus der ISR gleich nur noch Bits, 
dann passen auch mehrere Telegramme ins RAM und man kann eines 
entschlüsseln und darstellen, während ein weiteres parallel dazu vom ISR 
empfangen wird, in einen weiteren Puffer.

Gruß, Ulrich

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann es evtl. sein, daß Fehler im Datenstrom sind ?
Hab mal zufällig ein paar Werte incl. einem vom Windsensor?
herausgegriffen und interessanterweise passen einige zu einem
CRC Polynom, aber nicht alle ... das finde ich eher merkwürdig ...
(oder ich sollte anfangen Lotto zu spielen :-) )

Ohne Parity, in Bitreihenfolge

1111 1001 0 F9
1101 0101 1 D5
0111 0011 1 73
0111 1010 1 7A
1010 0110 0 A6
1000 0011 1 83
1010 0010 1 A2
1100 1111 0 CF
1001 0100 1011 1001  94B9

z.B also:

F9D5737AA683A2CF94B9
Parameters:

 polynom             :  0x8689
 order               :  16
 crcinit             :  0x28cd direct, 0xe30e nondirect
 crcxor              :  0xa766
 refin               :  1
 refout              :  1


Results:

 crc bit by bit      :  0xb994
 crc bit by bit fast :  0xb994


F9D5737A2683A2CF1436
Parameters:

 polynom             :  0x8689
 order               :  16
 crcinit             :  0x28cd direct, 0xe30e nondirect
 crcxor              :  0xa766
 refin               :  1
 refout              :  1


Results:

 crc bit by bit      :  0x3614
 crc bit by bit fast :  0x3614

F9296B3298039803A8000014CC50
Parameters:

 polynom             :  0x8689
 order               :  16
 crcinit             :  0x28cd direct, 0xe30e nondirect
 crcxor              :  0xa766
 refin               :  1
 refout              :  1


Results:
 crc bit by bit      :  0x50cc
 crc bit by bit fast :  0x50cc



CU Dirk

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI!
Also Fehler im Datenstrom kann ich fast ausschließen,da ich den Sensor 
direkt am ATmega, bzw. STK500 angeschlossen habe, ohne Empfänger, 
einfach die Datenleitung abgegriffen.
wo meinst Du denn, sind Fehler im Log? Ich seh das gerade nicht... komme 
allerdings auch gerade von der Arbeit...
Es kann evtl. sein, denn ab und zu wird wohl die allererste Flanke nicht 
korrekt erfasst. Dann  fehlt das erste Bit. Da habe ich extra eine 
Überwachung geschrieben, die guckt, ob das 5.Bit eine 1 oder eine 0 ist. 
Bei einer 0 werden alle einen nach rechts verschoben. Evtl. wäre da ein 
denkfehler im Verschieben. Oder meinst Du den Dreierblock, den ich zum 
Nibble geschoben habe?
Zu den Funksteckdosen... ich habe es so verstanden, als Du meintest, 
dass Du solche Fernsteuerungen hast.. Meintest Du was anderes?
Das Protokoll von den Dinger ist richtig easy :-)
Hab mal ein Programm geschrieben, das alle Möglichen Geräte durchgeht 
und alle einschaltet und danach wieder aus :-) Also so kann mna gucken 
wo die Dinger benutzt werden. Ich wollte die eigentlich benutzen um 
etwas von einem kleinen Server zu steuern. Bietet sich ja an.
das mit dem CRC muss ich mir anchher angucken.. aber ich kann mir nicht 
vorstellen, daß da Fehler im Datenstrom sind.. Die Signale 1 und 0 
unterscheiden sich deutlich voneinander. Oder meinst Du erst jetzt wo 
ichd as mit dem Controller auslese?
So, muss erstmal ins Bett...
Bis später.

Also wenn der Log doch richtig ist, dann hätte es sich gelohnt, dass ich 
das Fenster im Arbeitszimmer aufgelassen habe.. 15° sind es nun hier, 
also wurde mal ein Bereich ganz langsam durchlaufen..
Ach ja, die Verbesserungsvorschläge im Programm werd ich noch 
umsetzten.. Mit der Entschlüsselung der Bits in der ISR ist wirklich 
besser - hab mich da schrittweise durchgearbeitet und es dann so 
gelassen weil es ja ging... reine Faulheit.. aber sinnvoller ist Deins 
auf jeden Fall. Man kann ja auch alle drei Pakete nebeneinander 
schreiben, dann sind auch gleiche Pakete untereinander.
So, nu aber.. Bis denn...

gznw

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich meinte keine Fehler in der Auslesung oder im Programm sondern
vom Sensor selbst. Schließe ich jetzt aber mal aus ... (hab jetzt 
geschlafen ^_^)

Hab mal ein bisschen weiter getestet.
Wenn ich das Polynom fest lasse würde es auf alle Checksummen
passen, allerdings ändert sich der CRC-Initialwert...

Wenn ich Zeit hab, lasse es mal über alle bisherigen Ergebnisse
laufen; mal sehen ob sich was ergibt ...


CU Dirk

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit der CRC ist schon interessant!

Ich vermute jetzt einfach mal ganz dreist, dass der erste Schuss der 
Software zur Entschlüsselung nicht 100% läuft. Ist nicht böse gemeint, 
aber es gibt im Log auf dem Server einige Stellen, an denen die 
Prüfsumme offensichtlich nicht ins Muster passt. Das Log zeigt ganz 
klar, dass die Summe immer die gleiche ist, wenn sich in den Daten 
nichts ändert. Und trotzdem ändert sie sich manchmal ganz deutlich.
Allerdings finde ich die Stelle, die mir da gestern ins Auge sprang, 
jetzt nicht wieder, das Log ist schon recht lang geworden...

Ob das einfache Verschieben ausreicht um die Position zu korrigieren, 
wage ich zu bezweifeln. Wenn also das CRC Polynom in 80% der Fälle 
passt, haben wir schon einen guten Treffer gelandet.
Ich würde es einfach mal mit in die Software einbauen und nachsehen, ob 
es funktioniert. Man kann ja eine kleine HTML sequenz in das printf 
einfügen, dass die Zeilen, in denen es passt, farblich hervorhebt.

Man kann davon ausgehen, dass eine CRC nur dann Sinn macht, wenn es für 
jede Zeile einen festen Startwert hat. Sonst würde ein gestörter Empfang 
verhindern, dass weitere Telegramme decodiert werden können.

Die Daten werden aber, was im log noch nicht drin ist, als 
dreier-Telegramme gesendet. Es kann gut sein, dass der init Wert für die 
unterschiedlichen Telegramme eines Trippels unterschiedlich sind.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also dann muss ich mir das noch einmal angucken, ob das Problem mit der 
ersten nicht erkannten Flanke sich evtl. auch auf andere Bits auswirkt. 
Würde mal interessieren, welche Zeilen das waren.
Ich denke, ich sollte das Programm nun aber so ändern, dass jetzt nur 
die Hex-Werte ausgegeben werden, oder?
Da die Daten dann ja sowieso schon auf einem kleinen Server liegen 
(NSLU2), könnte der ja auch was rechnen.
Also ich müsste die Zeile mal suchen, die fehlerhaft ist. Ich denke, 
dass es eigentlich nur eine Verschiebung sein kann. Interessant ist 
aber, dass die Fehlerkennung des ersten Bits nicht verieinzet sonder 
gehäuft auftritt. Eine richtige Erklärung habe ich dafür noch nicht 
gfunden.
Ich muss dann mal gucken wie ich die CRC-Berechnung im µController 
umsetze.

//Edit: Also ich hab mal die Daten durchgescrollt und mir ist 
aufgefallen, dass
alle Daten wie folgt anfangen:
F9 BA EC E5
Somit kann man doch eigentlich ausschließen, dass es Fehler durch die 
Fehlerekennung / Veschiebung auftreten. Verschoben wird ja schon ab dem 
4.Bit! ;-)

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh, ja, ok.. hab da jetzt was falsches gefunden... ich guck mir das mal 
an..
P.S.: Dass man die Beiträge nach 15 Minuten nciht mehr verändern kann 
ist ja irgendwie doof :-(

Seltsam, seltsam!!
Guckt mal hier:
1111 1001 0 0101 1101 1 0111 0011 1 0111 1010 1 0100 1000 0 0100 0011 1 1000 0110 1 0011 1111 0 1101 1110 0010 1101 0 0
1111 1001 0 0101 1101 1 0111 0011 1 0111 1010 1 0100 1000 0 0100 0011 1 1000 0110 1 0011 1111 0 1110 0110 1001 1001 1 0
Die Parities stimmen aber... Für eine falsche Entschlüsselung wäre das 
aber ein seltsamer Zufall, oder?
Da fällt mir gerade ein.. sowas wäre ja gut geeignet um die 
Verschlüsselung vor dem "Entschlüsseln" zu sichern :-) Einfach falsche 
Prüfsummen zwischendurch rauswerfen, dann fällt die Messung halt unter 
den Tisch, aber das wird ja sicher nicht gemacht worden sein.. Aber wäre 
ne nette Idee..
Ich muss dann wohl mal wieder mit der Hand parallel gucken was da los 
ist.

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich denke, ich habe eine effektivere Idee... Man könnte sich ein 
eigenes Protokoll zusammenstricken anhand der vermuteten Verschlüsselung 
und gucken ob die Wetterstation das annimmt... wenn das der Fall ist, 
dann ist das Problem gelöst ;-)
ich mach mich mal an das Programm ran...

Gruß
gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundsätzlich würde man bei einem Biphase Code so vorgehen:

Man setzt einen TimerIRQ auf, der sich durch die 1111 auf den 
Flankenwechsel synchronisiert. Dieser IRQ füllt zudem einen Puffer mit 
den empfangenen Bits. Nach der Synchronisation schaut er eigentlich nur 
nach, ob innerhalb eines 2x 1-Timings ein Flankenwechsels stattgefunden 
hat, dann ist es eine 1 sonst ist es eine 0. Oder man mittelt die 
Bitzeit von 1111 aus und schaut nach, ob die später folgenden Flanken 
etwa so lang sind oder doppelt so lang.
Das ganz kann man auch noch verriegeln, also man setzt sich tot-Zeiten 
innerhalb der ein Flankenwechsel ignoriert wird um Störungen zu filtern.
Oder man macht das altbekannte Oversampling, man tastet eine 0-Zeit 
x-mal ab und kann dann sagen, dass ca x/2 Samples mit gleicher Polarität 
eine 1 sind, während ca x Samples gleicher Polarität eine 0 sind. Dabei 
gilt halt der gemittelte Wert der Samples, so dass kurze Spikes durch 
Störungen ignoriert werden.

Jedenfalls schiebt dieser IRQ die Daten in einen langen Bit-Speicher. 
Eine andere Routine (muss nicht IRQ sein) wertet diesen Speicher aus in 
dem sie nach einem bekannten Pattern sucht, also F9 BA EC E5 oder sie 
ignoriert das F, weil dieses durch die Synchronisation verstümmelt sein 
könnte.

Findet sie das Wort, so beginnt sie zu dekodieren. Da die Telegramme 
unterschiedliche lang sein können, dekodiert sie entweder anhand einer 
Tabelle die unterschiedlichen Längen aus, oder sie hat die Möglichkeit 
ein weiteres Pattern zu erkennen, das z.B. Anzeigt, wann nun die CRC 
erfolgt.

So wäre das ganze sehr dynamisch.

Natürlich ist Deine Analyse aber auch richtig. Wenn der Header F9 BA 
EC... stimmt, durch die Bit-Verschiebung und dann auch noch alle 
Parities in Ordnung sind, dann sollte alles Andere auch OK sein.
Allerdings kann ein Parity immer nur einen 1-Bit Fehler aufdecken. 
Sobald zwei Bits kippen, ist Parity machtlos.

Zur CRC: Es kann durchaus sein, dass im Dreierpack die CRCs 
unterschiedlich berechnet werden, oder die mittlere CRC z.B. invertiert 
ist. Das kann möglich sein. Aber ich denke nicht, dass das 
Hauptaugenmerk der Protokoll-Entwickler auf einer Verschlüsselung lag, 
sondern darauf, die Daten auch halbwegs zuverlässig am Empfänger 
ankommen zu lassen. Außerdem müssen sie darauf achten, dass nicht zu 
viele gleiche Bits im Telegramm sind, denn sonst wäre die 
Synchronisation problematisch.
Schließlich möchten die Hersteller solcher Billigwaren keine teuren 
Quarze einsetzen, sondern billige aber temperaturanfällige 
Keramik-Resonatoren.
Der Taktunterschied zwischen dem im Winter kalten Sensor draußen und dem 
warmen Empfänger drinnen kann dann schon immens sein.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Na, da werd ich ja demnächst noch einmal eine vernünftige Auswertung 
machen, die auch für mehrere Sensoren einsetzbar sein wird :-)

Ich habe jetzt einmal ein kurzes Programm geschrieben zum Senden. Mit 
den geloggten Daten geht es auch wunderbar!
Jetzt muss ich nur mal ein paar Datensätze haben, die ich da mal in mein 
Programm reinsetzen kann. Ich habe erst einmal nur drei Arrays gemacht, 
in die ich die Pakete einfach reinkopiert habe:
char paket_1[90]={1,1,1,1, 1,0,0,1, 0, 1,1,0,1, 0,1,0,1, 1, 0,1,1,1, 0,0,1,1, 1, 0,1,1,1, 1, 0,1,0, 1, 0,0,1,0, 0,1,0,0, 0, 0,1,0,0, 0,0,1, 1, 1, 0,0,0,1, 0,0,1,0, 0, 0,0,1,1, 1,1,1,1, 0, 1,0,0,1, 0,1,1,0, 0,0,1,1, 1,1,0,1, 1, 0};
char paket_2[90]={1,1,1,1, 1,0,0,1, 0, 1,1,0,1, 0,1,0,1, 1, 0,1,1,1, 0,0,1,1, 1, 0,1,1,1, 1, 0,0,1, 1, 0,0,1,0, 0,1,0,0, 0, 0,1,0,0, 0,0,1, 1, 1, 0,0,0,1, 0,0,1,0, 0, 0,0,1,1, 1,1,1,1, 0, 1,0,0,1, 0,1,0,1, 0,0,0,0, 0,1,0,0, 1, 0};
char paket_3[90]={1,1,1,1, 1,0,0,1, 0, 1,1,0,1, 0,1,0,1, 1, 0,1,1,1, 0,0,1,1, 1, 0,1,1,1, 1, 0,1,1, 0, 0,0,1,0, 0,1,0,0, 0, 0,1,0,0, 0,0,1, 1, 1, 0,0,0,1, 0,0,1,0, 0, 0,0,1,1, 1,1,1,1, 0, 1,0,0,1, 0,1,1,1, 1,0,1,0, 1,0,1,0, 1, 0};

Das klappt. Wenn die Check-Nibbles nicht stimmen, dann nicht.
Kennt Ihr online-Rechner, in die man einfach mal seine Sachen 
reinkopieren kann und der rechnet das dann aus? Dann könnte ich das 
testen. Das wäre dann die direkte Methode.
Später würde ich dann gezielt einzelne Bits entsprechend meiner 
Messdaten abändern.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also einen online CRC Generator kenne ich jetzt auswendig nicht.
Du kannst aber den Prozess schon mal teil-automatisieren. Du gibst die 
Netto-Daten in hex vor und lässt die Software später die Parity-Bits 
dazu berechnen. Die Nettodaten selber brauchen ja die Checksumme.
Das wiederum kannst Du z.B. mit Tiny Hexer (www.mirkes.de) machen. Den 
verwende ich auch für sowas. Das Teil ist sehr gut.
Also pack Dir die Nettodaten in eine kleine Datei, importiere sie, lass 
die CRC berechnen und dann schaust Du mal was raus kommt.
Dann fügst Du das in deine Software ein.

Oder Du suchst mal nach CRC16 und schaust, welche verschiedenen Polynome 
da üblich sind. Dann lässt Du die auf die Netto-Daten los und schaust 
was da raus kommt.

Das Üble ist ja, dass man zuerst mal die Parities entfernen, dann CRC 
berechnen und anschließen die Parities wieder einfügen muss.
Ist was umständlich.

Aber oben hatte Dirk ja schon mit dem Polynom 0x8689 einen direkten 
Treffer.
Zieh das mal durch und schaue was raus kommt.
Wie man eine CRC ini C berechnet hatte ich wohl mal in Nut/OS 
(www.ethernut.de) hinzugefügt. Kannst Du Dir dort im Sourceforge 
Repository einfach ansehen. Sonst hänge ich Dir da morgen was an diesen 
Thread.

Gruß, Ulrich

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm.. Also ich hab mir jetzt den Tiny Hexer installiert und die Werte
F9D5737AA683A2CF in eine Datei geladen und dort importiert. Nun muss ich 
nur noch gucken wo ich die Parameter für die CRC-Berechnung eingeben 
kann.
Ich hab es auch mit mit dem hier versucht:
http://zorc.breitbandkatze.de/crc.html
Aber ich mach scheinbar irgendewtas falsch bei der Bedienung..?? ich 
bekomme nicht ansatzweise etwas heraus, das passen könnte..
gznw

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab mal nochmal viele CRC Sachen durchrechnen lassen.
Die 3 Werte die ich rausgegriffen hatte, waren wirklich Zufall..
hätte ich doch mal besser Lotto spielen sollen.

Sieht jetzt nicht mehr wie eine einfache CRC Checksumme aus.

Hab mir jetzt auch mal die Telegramme genauer angesehen ...
dabei sind mir 2 Werte mit gleicher Checksumme aufgefallen siehe unten:

1111 1001 0 1101 0101 1 0111 0011 1 0111 1010 1 0010 0000 1 0100 0011 1 
0000 1010 0 1111 1111 0 0100 1010 1111 1000 0 0
F9 0 BA 1 EC 1 E5 1 40 1 2C 1 05 0 FF 0 25 F1 0

1111 1001 0 1101 0101 1 0111 0011 1 0111 1010 1 1100 1000 1 0100 0011 1 
0110 0010 1 0111 1111 1 0100 1010 1111 1000 0 0
F9 0 BA 1 EC 1 E5 1 31 1 2C 1 64 1 EF 1 25 F1 0


Das würde entweder auf eine ganz andere, relativ schlechte, 
Checksummenberechnung deuten oder auf eine zusäztliche "Verschlüsselung" 
die aber zu Kollisionen führt.

Frage:
Kannst du den Sender eigene Werte senden lassen ?
Dann könnte man geziehlt Abhängigkeiten suchen ..
Oder hat der µC evtl. nützliche (Programmier-)Anschlüsse ?

CU Dirk

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Bei den zuletzt geloggten Daten scheint es ja ein Problem gegeben zu 
haben. Ich kann mir die Zeilen gerade nicht richtig angucken - bin 
unterwegs und hab nur das Handy dabei...
Ich müsste den Datenstrom zwischen Sensor und Controller erstmal 
untersuchen und eigene Werte übergeben zu können. Ansonsten hab ich da 
nicht viel gesehen damals..das wäre das einzige was mir einfällt.  Ich 
guck mal.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, ich hatte mal was gelesen, dass CRC Verfahren je sicherer werden, 
je länger der Text ist, den sie sichern. Kann also vielleicht sein, dass 
hier zwei unterschiedliche aber kurze Texte zur gleichen Summe führen?

Ulrich

Autor: gznw (Gast)
Datum:
Angehängte Dateien:
  • preview image for 1.png
    1.png
    90,7 KB, 272 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Also im Prinzip müsste ich jetzt wohl mal Schritt für Schritt beide 
Messbereiche komplett von unten bis oben unabhängig durchlaufen 
lassen... Nun fürchte ich aber, dass das zu heftig wird, nun noch das 
Protokoll zwischen Sensor und Controller zu entschlüsseln und einen 
Controller das beizubringen, sich so wie der Sensor zu verhalten...
Hab mal das die Daten angeguckt.. I²C ist es doch nicht :-(
Es ist nur ein Teil von dem Ganzen gesendeten...

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich habe noch einmal etwas probiert! Wenn ich die Datenleitungen 
kurzschließe, dann sind ja die gesendeten Messwerte immer gleich 
(Fehler).
Alles was sich nun noch ändern kann, ist die Sensor-ID. Also habe ich 
einige Resets gemacht und an 2.Stelle in der Checksumme steht immer die 
gleiche Zahl! Wie ich festgestellt habe, hängt sie scheinbar nur vom 
Kanal ab!
Außerdem ist das letzte Byte vor den Check-Bytes immer 00. Da dachte ich 
ja bisher, dass es nur von der Sensor-ID, Sensor-Typ & Kanal abhängt!
Damit müsste man doch nun einen Schritt weiter sein, oder? Ich müsste 
mir das mal ausdrucken, da sieht man ja so einiges besser.. Aber ein 
Konstanter Wert innerhalb einer Checksumme kann ja schon ein Zeichen 
sein...

Mir ist noch etwas aufgefallen,was allerdings wieder nicht so schön ist.
Also die Fälle, in denen die Checksumme trotz gleicher Daten 
unterschiedlich waren, da wird wohl doch kein Fehler im Programm sein! 
Ich habe das Programm etwas abgeändert und die Korrektur bei 
fehlerhafter Erkennung des ersten Bits ausgeschaltet. Es kommt hin und 
wieder vor, dass die Checksumme trotzdem verschieden ist! Und das Parity 
kommt trotzdem hin! Zufall kann das doch nicht sein.
Da sind nun viele doppelte drin, aber daran kann man sehen, dass nur 
eine geringe Anzahl an IDs verfügbar ist.
Kanal1
1111 1001 0 1011 1100 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0111 1111 1101 1100 0 0   F9 D3 E0E5AAA8AA00  -->  EFB3
1111 1001 0 1010 0100 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0011 1111 0101 0001 1 0   F9 52 E0E5AAA8AA00  -->  CFA8
1111 1001 0 0100 0100 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1100 1111 0010 0011 1 0   F9 22 E0E5AAA8AA00  -->  3F4C
1111 1001 0 1011 1100 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0111 1111 1101 1100 0 0   F9 D3 E0E5AAA8AA00  -->  EFB3
1111 1001 0 1010 0100 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0011 1111 0101 0001 1 0   F9 52 E0E5AAA8AA00  -->  CFA8
1111 1001 0 0100 0100 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1100 1111 0010 0011 1 0   F9 22 E0E5AAA8AA00  -->  3F4C
1111 1001 0 1011 1100 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0111 1111 1101 1100 0 0   F9 D3 E0E5AAA8AA00  -->  EFB3

Kanal2
1111 1001 0 1101 1010 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0011 1001 0110 1101 1 0   F9 B5 E0E5AAA8AA00  -->  C96B
1111 1001 0 0011 1010 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1100 1001 0001 1111 1 0   F9 C5 E0E5AAA8AA00  -->  398F
1111 1001 0 1100 0010 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0111 1001 1110 0000 0 0   F9 34 E0E5AAA8AA00  -->  E970
1111 1001 0 1100 0010 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1001 1001 0011 0001 1 0   F9 34 E0E5AAA8AA00  -->  99C8
1111 1001 0 1111 0010 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1111 1001 0111 1011 0 0   F9 F4 E0E5AAA8AA00  -->  F9ED

Kanal3
1111 1001 0 0000 0110 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0001 1101 0000 0010 1 0   F9 06 E0E5AAA8AA00  -->  8B04
1111 1001 0 0001 1110 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0101 1101 1000 1111 0 0   F9 87 E0E5AAA8AA00  -->  AB1F
1111 1001 0 1111 1110 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1010 1101 1111 1101 0 0   F9 F7 E0E5AAA8AA00  -->  5BFB
1111 1001 0 0000 0110 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0001 1101 0000 0010 1 0   F9 06 E0E5AAA8AA00  -->  8B04
1111 1001 0 0001 1110 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0101 1101 1000 1111 0 0   F9 87 E0E5AAA8AA00  -->  AB1F
1111 1001 0 1111 1110 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1010 1101 1111 1101 0 0   F9 F7 E0E5AAA8AA00  -->  5BFB
1111 1001 0 0000 0110 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0001 1101 0000 0010 1 0   F9 06 E0E5AAA8AA00  -->  8B04


Kanal4
1111 1001 0 1000 0101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1011 1110 0100 0000 1 0   F9 1A E0E5AAA8AA00  -->  D720
1111 1001 0 0010 0101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0101 1110 1001 0001 0 0   F9 4A E0E5AAA8AA00  -->  A798
1111 1001 0 1001 1101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1111 1110 1100 1101 0 0   F9 9B E0E5AAA8AA00  -->  F73B
1111 1001 0 1100 0101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1010 1110 1110 0011 0 0   F9 3A E0E5AAA8AA00  -->  577C
1111 1001 0 0110 0101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0100 1110 0011 0010 1 0   F9 6A E0E5AAA8AA00  -->  27C4
1111 1001 0 1101 1101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1110 1110 0110 1110 1 0   F9 BB E0E5AAA8AA00  -->  7767
1111 1001 0 0010 0101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0101 1110 1001 0001 0 0   F9 4A E0E5AAA8AA00  -->  A798
1111 1001 0 1001 1101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1111 1110 1100 1101 0 0   F9 9B E0E5AAA8AA00  -->  F73B
1111 1001 0 1100 0101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1010 1110 1110 0011 0 0   F9 3A E0E5AAA8AA00  -->  577C
1111 1001 0 0110 0101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0100 1110 0011 0010 1 0   F9 6A E0E5AAA8AA00  -->  27C4
1111 1001 0 1101 1101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1110 1110 0110 1110 1 0   F9 BB E0E5AAA8AA00  -->  7767
1111 1001 0 1000 0101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1011 1110 0100 0000 1 0   F9 1A E0E5AAA8AA00  -->  D720
1111 1001 0 0010 0101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0101 1110 1001 0001 0 0   F9 4A E0E5AAA8AA00  -->  A798
1111 1001 0 1001 1101 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1111 1110 1100 1101 0 0   F9 9B E0E5AAA8AA00  -->  F73B
1111 1001 0 1100 0101 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1010 1110 1110 0011 0 0   F9 3A E0E5AAA8AA00  -->  577C


Kanal 5
1111 1001 0 0110 1011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1101 1000 0011 0110 0 0   F9 6D E0E5AAA8AA00  -->  B1C6
1111 1001 0 1100 1011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0011 1000 1110 0111 1 0   F9 3D E0E5AAA8AA00  -->  C17E
1111 1001 0 0111 0011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1001 1000 1011 1011 1 0   F9 EC E0E5AAA8AA00  -->  91DD
1111 1001 0 0010 1011 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1100 1000 1001 0101 1 0   F9 4D E0E5AAA8AA00  -->  319A
1111 1001 0 1000 1011 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0010 1000 0100 0100 0 0   F9 1D E0E5AAA8AA00  -->  4122
1111 1001 0 0011 0011 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1000 1000 0001 1000 0 0   F9 CC E0E5AAA8AA00  -->  1181
1111 1001 0 0110 1011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1101 1000 0011 0110 0 0   F9 6D E0E5AAA8AA00  -->  B1C6
1111 1001 0 1100 1011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0011 1000 1110 0111 1 0   F9 3D E0E5AAA8AA00  -->  C17E
1111 1001 0 0111 0011 1 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1001 1000 1011 1011 1 0   F9 EC E0E5AAA8AA00  -->  91DD
1111 1001 0 0010 1011 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 1100 1000 1001 0101 1 0   F9 4D E0E5AAA8AA00  -->  319A
1111 1001 0 1000 1011 0 0111 0000 1 0111 1010 1 0101 0101 0 0101 0001 1 0101 0101 0 0000 0000 0 0010 1000 0100 0100 0 0   F9 1D E0E5AAA8AA00  -->  4122


Gruß,
gznw

Autor: ARC H. (gznw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!!
So, ich heb noch einmal über Nacht das ganze laufen lassen mit leicht 
geöffnetem Fenster -> langsames Durchlaufen der Temperaturen nach 
unten..
Bei der Ansicht so mit den hex-Werten rechts, kann man beim 
herunterscrollen schon etas mehr erkennen! Temperatur fällt und die 
erste Ziffer fällt auch. Die zweite nur etwas.
Leider wird das letzte Byte vor dem Check-Bytes auch beeinflusst... Ich 
bin ja wirklich davon ausgegangen, dass dies fix wäre für eine ID.. 
Naja, hat der Test gestern Abend ja eigentlich auch schon widerlegt..
Ich guck mal ob ich da etwas aus dem Log erkennen kann...Irgendwie sieht 
es ja schon sehr wild aus...
Ach ja, hab ja zwei Firmen angeschrieben... Wäre ja möglich gewesen,dass 
man wenigstens einen kleinen Tipp bekommt.. Aber leider nichts.. 
Freundlich waren sie beide, aber mir konnte leider keinerlei Information 
gegeben werden, "da das Datenprotokoll als empfindliche, vertrauliche 
Information des Unternehmens gesehen wird."
Na, irgendwo ja auch verständlich... Ein Versuch war es wert...
Zu dem Log... ich kann leider keine Fehler ausschließen,aber ich gehe 
schon davon aus, dass die Werte stimmen. Die Fehlerkorrektur habe ich 
ausgeschaltetund die Parities kommen auch schon hin...

//Edit: Ach ja, ich habe sonst noch einen anderen Snesor, der hat einen 
Anschluss für einen externen Sensor. Da könnte ich ja egentlich ein Poti 
anschließen.. Wolte ich bisher eigentlich nicht machen weil ich die 
Messwerte von dem Sensor an der Stelle haben wollte, aber das wäre nun 
eigentlich egal.
Sonst knöpf ich mir den noch einmal vor :-) Dummerweise dauert so ein 
Log dann sehr lange wenn man nicht resettet.. Da müsste man ja 
eigentlich einen Controller mit der Widerstandsänderung beauftragen und 
das dann mal laufen lassen..

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich habe heute noch etwas weiter loggen lassen...

Vielleicht kommt man dem Ganzen so auf die Schliche?

das '!!' steht an den Stellen, bei denen die Checksumme sich 
entgegengesetzt der vorheigen Daten ändert. Ist schon interessant! Ich 
habe die Daten so geordnet, dass der nächste Datensatz größer ist als 
das vorherige. Hin und wieder wird die Checksumme kleiner!

Das sieht noch ganz schön wild aus. Aber ich muss irgendwie an die 
Checksumme von einem anderen Funkthermometer-Protokoll denken, bei dem 
einfach nur die unteren Bytes von der eigentlichen Checksumme angegeben 
wurden und die vorherigen unter den Dich fallen.
Also z.B.:
D486 
C499 d= - 0FED

>>>>
z.B.
...0D486
...1C499  d= F013

.. bringt mir aber gerade auch keine neuen Erkenntnisse..

Hier habe ich mal ein paar ausgewählte Datensätze verglichen. Immer so 
angeordnet, dass sich immer nur eine Stelle ändert!
                       Check    Differenz zum Vorwert
-----------------------------------------------------
Änderung nur an 9.Stelle

         |
F92AECE5 002C24 FF      D486
F92AECE5 102C24 FF      C499  d= - 0FED !!


F92AECE5 091C73 9F      DAD3
F92AECE5 191C73 9F      CACC  d= - 1007 !!


F92AECE5 191C83 9F      3A65
F92AECE5 291C83 9F      0A64  d= - 3001 !!


F92AECE5 202C24 FF      F498   
F92AECE5 302C24 FF      E487  d= - 1011 !!


F92AECE5 491C24 3F      6DD0
F92AECE5 591C24 3F      7DCF  d= 0FFF


F92AECE5 402C34 FF      848A
F92AECE5 502C34 FF      9495  d= 100B


F92AECE5 481C83 BF      4BE9 
F92AECE5 581C83 BF      5BF6  d= 100D
F92AECE5 681C83 BF      6BF7  d= 1001


F92AECE5 691C24 3F      4DCE  
F92AECE5 791C24 3F      5DD1  d= 1003


F92AECE5 681C93 BF      7BCF  
F92AECE5 781C93 BF      6BD0  d= - 0FFF


F92AECE5 891C24 3F      ADBC  
F92AECE5 991C24 3F      BDA3  d= 0FE7


----------------------------------------------------------
Änderung nur an 13.Stelle

             |
F92AECE5 191C73 9F      CACC  
F92AECE5 191C83 9F      3A65  d= - 9067 !!


F92AECE5 302C24 FF      E487
F92AECE5 302C34 FF      F4BF  d= 1038


F92AECE5 902C74 CF      24E9   
F92AECE5 902C84 CF      D440  d= AF57 (warum so groß?)

Ein richtiges Muster kann ich da nicht so wirklich erkennen..

bis später....
gznw

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi noch einmal :-)
Sooo, ich hab was!!!!
Also ich habe mir noch einmal überlegt, ob es wirklich CRC sein wird... 
Wäre der Rechenaufwand für so einen mickrigen Controller wie er da in 
dem Ding ist nicht etwas hoch? bzw. mit Kanonen auf Spatzen??

Daher hab ich das mal auf logische Verknüpfungen untersucht:
erstes Ergebnis:
1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0100 0 0100 0011 1 1010 0010 1 1111 1111 0 1011 0110 1010 0101 1 0 
1111        0100        0111        0111        1110        0100        1010            XOR->   1011

1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0100 0 0100 0011 1 1010 0010 1 1111 1111 0 1011 0110 1010 0101 1 0 
1111        0100        0111        0111        1110        0100        1010            XOR->   1011


1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0000 1 0100 0011 1 0010 0010 0 1111 1111 0 0011 0010 1010 1101 0 0 
1111        0100        0111        0111        1110        0100        0010            XOR->   0011

Ich habe drei weitere Stichproben gemacht und es kam da auch hin. Heißt 
zwar noch nicht, dass es so schon stimmt, aber es sieht bisher schon gut 
aus. Vielleicht iste s alles so nach dem Prinzip aufgebaut, vielleciht 
noch andere Operationen mit einer Konstanten... Ich guck mal weiter...

//Edit: Es gibt leider Fälle, in denen es nicht hinkommt. Aber ich 
vermute trotzdem soewtas in der Rcihtung. Vielleicht hat das letzte Byte 
noch was zu tun damit.. oben ist das Nibble 1111 und da kommt es hin. 
HIer nicht:
1111 1001   0100 0101   0111 0011   0111 1010   1100 1000   0100 0011   0000 1010   0011 1111    1111 0010 1100 1011
1111        0100        0111        0111        1100        0100        0000            XOR->    0011

die 0011 kommt allerdings in dem Nibble vorher vor! Also vielleicht noch 
eine Operation mit dem Nibble??

Autor: ARC H. (gznw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, dass ich so viel poste.. aber die Edit-Funktion geht leider nur 
15Minuten :-(
Ich habe noch etwas herausgefunden: Das zweite Nibbel hat auch etwas 
auffälliges! Allerdings nur wenn das Byte vor dem Check FF ist. so wie 
vorhin:
1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0100 0 0100 0011 1 1010 0010 1 1111 1111 0 1011 0110 1010 0101
1111        0100        0111        0111        1110        0100        1010            XOR->   1011
     1001        0101        0011        1010        0100        0011        0010             Summe: 011011
___________________________________________________________________________________________________________________                       
     


1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0100 0 0100 0011 1 1010 0010 1 1111 1111 0 1011 0110 1010 0101
1111        0100        0111        0111        1110        0100        1010            XOR->   1011
     1001        0101        0011        1010        0100        0011        0010             Summe: 011011
___________________________________________________________________________________________________________________



1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0000 1 0100 0011 1 0010 0010 0 1111 1111 0 0011 0010 1010 1101 
1111        0100        0111        0111        1110        0100        0010            XOR->   0011
     1001        0101        0011        1010        0000        0011        0010             Summe: 001011
___________________________________________________________________________________________________________________



1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1110 0100 0 0100 0011 1 0110 0010 1 1111 1111 0 0111 0110 1100 0100
1111        0100        0111        0111        1110        0100        0110            XOR->   0111
     1001        0101        0011        1010        0100        0011        0010             Summe: 011011
___________________________________________________________________________________________________________________




1111 1001 0 0100 0101 1 0111 0011 1 0111 1010 1 1010 1000 1 0100 0011 1 1010 0010 1 1111 1111 0 1111 1010 0111 1011
1111        0100        0111        0111        1010        0100        1010            XOR-->  1111
     1001        0101        0011        1010        1000        0011        0010             Summe: 101011
___________________________________________________________________________________________________________________


Das sind nicht nur die Datensätze, bei denen es hinkam, das sind alle, 
die ich probiert habe und die FF hinten haben!

Nun überleg ich einmal, wie das angesprochene Byte reingehen kann und da 
es insgesamt im Nutzdatenbereich 8Parity-Bits gibt, bietet sich da doch 
eigentlich acuh eine Operation an, oder? Ist allerdings bei dem langen 
Protokoll vom Windsensor ja nicht zutreffend, also da gab es ja mehr 
Parity-Bits, soweit ich weiß.. Auf jeden Fall bin ich sicher, dass dies 
der richtige Weg hier ist!


Gruß gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin etwas müde, was ich so tagsüber mache ist in den letzten Wochen auch 
nicht gerade ohne :)

Aber ich denke, jetzt sollte man das decodieren mal irgendwie 
automatisieren. Eventuell ein kleines einfaches Progrämmelchen auf dem 
Pc schreiben mit irgend einem einfachen Compiler.
Zeile einlesen, entschlüsseln und sehen was passiert. Das ist einfacher, 
als es jedes mal erst flashen zu müssen.

Ich schau mal, was ich da auf die Schnelle machen kann. Unter Linux hab 
ich schon mal was angefangen, ist aber noch nicht fertig und wird heute 
auch nix mehr. Wenn Du nur Windows hast, dann einfach MingW oder 
ähnliches installieren und den Quelltext durch jagen, sobald ich ihn Dir 
schicke.

Gruß, Ulrich

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi.. Also Linux wäre mir natürlich lieber... Ich hab hier 2 Nslu2,falls 
du die kleinen Dinger kennst. Dazu noch eine Etrayz. Alle laufen mit 
Linux und sind hier im Netzwerk verbunden. Ich könnte ja den Controller 
direkt an die nslu anschließen und die befasst sich dann mit den Daten. 
Ich könnte sonst noch einen alten Laptop nutzen,aber auf Dauer zieht der 
ja schon etwas viel Strom..

Autor: Daniel R. (motsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr Zwei, merke gerade, es ist schon fast zwei Jahre her... na 
egal. Habe selbst einen solchen Thermo-Hygro-Sensor am Start. Ich habe 
euren Thread interessiert gelesen. Gute Arbeit!
Meine bescheidene Frage an Euch, wo habe ich überlesen, warum Ihr den 
Biphase-Mark-Code invertiert betrachtet. Oder steh ich schon 
grundsätzlich im Verständnis des Codes auf der Leitung?

Viele Grüße und ein frohes Weihnachtsfest...

Daniel

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich weiß es jetzt auch gar nicht mehr so genau, aber das war eben der 
Ansatz, den wir an der Stelle hatten. Es ist bis jetzt ja leider auch 
nicht aufgelöst worden. Ich habe mich dann aber auch nicht mehr 
großartig damit befasst. Vielleicht kümmer ich mich darum nochmal, wenn 
ich demnächst etwas mehr Zeit habe, aber so einfach wird es ja leider 
nicht sein. Wenn Du neue Ansätze oder Ideen hast, sag unbedingt mal 
Bescheid!

gznw

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mich um die geschichte aus zeitlichen gründen nicht mehr 
kümmern können. Abgesehen davon, dass ich hier nur theoretisch mit 
gemacht habe, weil ich solch ein Gerät garnicht besitze, ich hätte es 
auch nicht geschafft, wenn ich eines hätte.

Aber wenn Ihr da weiter macht, dann schau ich einfach mal wieder vorbei.

Gruß
Ulrich

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich wäre auch wieder dabei. ;-)
Ich würde diesmal einen anderen Ansatz verfolgen wollen: die Sensorwerte 
vorgeben und gucken was hinten rauskommt. Dafür müsste man den internen 
Sensor wohl mal untersuchen. Bin leider diese Woche noch unterwegs, aber 
ich schau mal. ich hatte die Bezeichnung hier bestimmt schon erwähnt und 
tipp mal auf I2C-Schnittstelle.


gznw

Autor: Daniel R. (motsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hab ich ja die Threadväter wieder an den Tisch geholt :)
Also ich hab mal noch ein wenig mit der CRC-Geschichte getestet und bin 
auch nicht weiter gekommen. Wenn es das ist, dann ist es eh nur Lotto 
spielen. Ich glaub aber nicht mehr das es so kompliziert ist. Wir haben 
ja schon die Sicherheiten des 3-maligen Sendens und der Parity-Bits. Vom 
Prinzip her reichen mir auch die anderen Daten, da ich den Sensor für 
meine eigene Wetterstation nutzen  und nicht Daten zu einer bestehenden 
Station senden will. Aber interessieren tut's mich natürlich schon, was 
die letzten beiden Bytes nun genau sind. In Ulrich hatte ich da meine 
Hoffnung gesetzt, dass er da zwischen den 1sen und Nullen das 
CRC-Polynom entdeckt :)

Was mir aufgefallen war ist, dass der Bi-Phase-Mark-Code invertiert ist, 
also das was Signalmäßig ne Eins sein sollte ist ne Null und umgekehrt. 
Vielleicht hab ich aber auch bei grundlegenden Verständnis schon ein 
Dreher... aber auch nebensächlich.

Zum Innenleben: Also die Sensorik ist einfachste Elektronik -> 
Temperatur = temperaturabhängiger Widerstand und Luftfeuchte ein 
billiger Flächenkondensator mit Spule(Schwingkreis). Erfasst wird das 
ganze wohl vom allseits geliebten Klecks welcher dann auch die Signale 
zum Senden herstellt. Also nix i2c.
Mir ist auch nicht so richtig klar, was vorgegebene Sensorwerte bringen 
sollen, es geht ja immer noch um die ominöse Checksumme oder?

Grüße Daniel

Autor: gznw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe hier mehrere dieser Sensor-Module und es gibt scheinbar zwei 
verschiedene Varianten:
Eine verwendet die von Dir beschriebenen Sensoren und es gibt die 
Module, die einen Sensor verbaut haben, der scheinbar per 
I2C-Schnittstelle angebunden sind. Das habe ich vor ein paar Tagen 
festgestellt, nachdem ich mir nochmal diesen Sensor anschauen wollte.

Meine Überlegung war, dass man gezielt einzelne Bits verändert und 
darüber dann die Entschlüsselung herausbekommen kann, da man eben 
einzelne Bits veränden kann und sich die Checksumme dann anschauen kann. 
Im primitivsten Fall kann man dann ne Lookup-Tabelle machen, aber das 
ist irgendwie nicht so hübsch.
Apropos.. Eine Verschlüsselung, die per Lookup-Tabelle funktioniert, 
wäre eine, die wir hier nie entschlüsseln könnten, wenn man nicht alle 
möglichen Kombinationen austesten würde! Aber ich glaube eher nicht, 
dass das so implementiert wurde.

gznw

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.