next topic »

[Reply #15 on:]

Ich habe mal ein bisschen in der Bildbearbeitung gespielt. Wie man sieht, kommen 2,5 Datenpakete an, die es zu dekodieren gilt. Da habe ich wenig zwar Erfahrung, aber es wäre günstig, wenn du uns die Randbedingungen nennen könntest und auch unterschiedliche Datensätze liefern könntest bei unterschiedlichen Temperaturen zum Beispiel. Erst dann kann man Rückschlüsse ziehen, welche Bereiche zur Adressierung des Sensors gehören und welche nutzbare Übertragungsdaten sind.

[Reply #16 on:]

Danke sth77, das ist schon mal wieder neue Info für mich.

Kann man jetzt davon ausgehen, dass jedes High eine 1 ist und jedes Low eine 0? Und kann ich die Abstände ignorieren oder gibt es doppelte Abstände für zwei gleiche Bits?
Offenbar sind die zwei ganzen Datensätze ja identisch, oder?
Muss man da jetzt noch diese Manchester Codierung beachten oder sind das schon thermometerdaten in reinform?

Ach sooo viele Fragen. Will lernen. Danke!

[Reply #17 on:]

Wie gesagt, das ist schon Reverse Engineering. Aus einem Datensatz bekommt man das nicht heraus.
Du brauchst mindestens 2, unterschiedliche Messungen mit dem gleichen Sensor bei unterschiedlichen Temperaturen, die du dann auch mit den auf dem Display dargestellten Werten abgleichen musst. Das "ca. 27°" hilft hier nicht viel.

Ich vermute eine Startsequenz durch diese einzelne Peek mit der darauffolgenden Pause, dann einen Adressierungsbereich und die Nutzdaten. Da das Signal so schön getaktet aussieht, könnte man das so interpretieren, dass jedes Peek für eine 1 steht, jedes nichtvorhandene für eine 0. Aber wie gesagt, alles Mutmaßungen, wie das so ist beim Reverse Engineering...

Also bitte mehr Daten!

[Reply #18 on:]

Also, hier jetzt mal ein paar Daten:

dahinter steht immer Temp / Luftfeuchte

000000110010101100111001100001001110010111 30,8 / 53
000000110010101001110101100010001110010011 29,6 / 50
000000110010100111110101100010001110010001 29,5 / 49
000000110010100101110101100001001100011010 29,4 / 49
000000110010100000110101100000001100100001 29,1 / 48
000000110001100110100001100001010010101001 25,0 / 65
000000110001101011100001100001010010100001 25,2 / 65
000000110001101100100001100010010010101111 25,3 / 65
000000110001101101100001100001010010100110 25,3 / 65 (25,4 / 65)
000000110001100000100101100000010010101001 25,6 / 64

Bei dem einen Ausreißer ist das Thermometer beim Ablesen umgesprungen. Ich kann nicht sagen, welcher der beiden Werte richtig ist. Da diese Reihe sich von der vorherigen unterscheidet, vermute ich den Klammerwert.

Wie bin ich an die Binärdaten gekommen? So:

Code:

boolean sbit=false;

void setup() {
  Serial.begin(115200);
  Serial.println("go!");
  pinMode(2, INPUT);
}

void loop() {
  unsigned long LowVal=pulseIn(2,LOW);
  unsigned long LowVal2=pulseIn(2,LOW);

  if (LowVal > 7000 && LowVal2 > 7000) {
    sbit=true;
  }
  if (sbit== true) {
    // Es geht los!
    // startbit zurücksetzen
    sbit=false;
    for(unsigned int j=0; j<42; j++) {
      LowVal=pulseIn(2,LOW);
      if (LowVal < 3200) {
        Serial.print(0);
      } else if(LowVal >= 3200 && LowVal < 7000) {
        Serial.print(1);
      }
    }
    Serial.println("");
  }
}

Wenn ich dann den Tx-Button gedrückt habe, kammen immer 5 oder 6x die gleichen Zahlenfolgen schnell hintereinander. Also scheine ich den Startcode gefunden zu haben.
Wie komme ich auf den Wert 42? Wenn ich mir die Zeiten ausgeben lasse, erscheinen 42 Zeiten zwischen zwei Startblöcken. Daher vermute ich 42 Bits.

Jetzt weiß ich nicht mehr weiter.

ich habe noch diese Seite entdeckt, aber was er da für Daten hat, deckt sich nicht mit meinen.

http://hobbyelektronik.org/w/index.php?title=Tchibo_Wetterstation

Ich habe ja 42 Bits, er hat 32.

Das Modell der Wetterstation von ihm ist wohl ein älteres, vom Aufbau vermute ich aber, sie sind sich sehr ähnlich. Das Design ist schon fast gleich.

Ach ja, ich habe noch eine Parallelmessung gemacht mit Arduino und Bus Pirate Logic Analyzer. Und wenn ich - analog zu der Webseite oben - die kurzen Abstände als 0 werte und die langen als 1, dann kommt mit Abzählen an der Logic-Grafik das gleiche raus, wie aus meinem Arduino Programm. Von daher scheint mein Programm zu funktionieren.

Nachtrag:

Jetzt habe ich den LogicAnalyzer mal direkt an den DataPin beim Sender und gleichzeitig am DataPin des Conrad Empfängers gehängt und eine Runde laufen lassen.
Man sieht, der Arduino empfängt genau das, was der Tchibo sendet (siehe Bildanhang, die Werte: 28,2°C und 53% Feuchte).

[Reply #19 on:]

Ist zwar leicht OT aber vielleicht trotzdem eine nützliche Info: In dem Datenblatt meines 433 MHz Receivers stand beim Antennenpin: ANT (about 13 cm). Daher habe ich einen 13cm langen Draht über einem Bleistift gerollt und an den Pin angeschlossen - mit dem Effekt, dass sich die Signalqualität enorm verbessert hat. Inzwischen bekomme ich mind. noch 4 Thermometer von irgendwelchen Nachbarn rein und meine eigenen empfange ich alle Problemlos (auch das aus dem Garten, wo die Batterie fast runter ist - ohne Antenne bekam ich da nie ein Signal).

[Reply #20 on:]

Keiner hier, der fließend Binär spricht...   

[Reply #21 on:]

* PUSH *

Sorry, Leute, ich hoffe bei dem schlechten Wetter sitzen ein paar mehr vor ihren Kisten!

Ich komme hier nicht weiter. Kann mir jemand bei der decodierung der Binärdaten helfen?

Danke vorab!

Marc

[Reply #22 on:]

Binär ist nicht das Problem, eher das dechiffrieren 

Deine Tabelle in # 18 scheint nicht so einfach zu sein, 42 Bit ist auch eine krumme Zahl, und für 2 Analoge Messwerte ziemlich viel.
Da sind bestimmt Adressinfo ( immer konstant ) und irgendwelche Prüfbits drin...

Hast du eigentlich mal überprüft, ob deine Anzeigewerte ( Temp / Feuchte ) und das Bitmuster immer 1:1 übereinstimmen ?
Oder hast du verschiedene Bitmuster mit den gleichen Anzeigewerten (Wandeln int -> float und Runden in der Anzeige-Einheit ? )
Wie oft wird eigentlich gesendet, hängt ein neuer Datensatz und Umspringen der Anzeige überhupt direkt zusammen?

Zum Mastermind Spielen sind es noch etwas wenig Daten, leider kannst du die Anzeige-Ergebnisse nicht direkt mitprotokollieren sondern musst das von Hand notieren.

 

[Reply #23 on:]

Ok, dann werde ich nochmal die Tage mehr Werte notieren und deine Fragen beobachten.
Ich Push den Thread dann wieder.

Danke dir.

Marc

[Reply #24 on:]

Ja es braucht entschieden mehr Daten wo einer der beiden Werte öfters vorkommt.
Grüße Uwe

[Reply #25 on:]

Ich habe da mal eine Theorie, ob die passt, müsste mit mehr Messdaten verifiziert werden
Ich teile die Daten aus den Messungen oben mal anders auf

000000 1100 1010     0111 1101     0110       0010 0011          1001 0001 29,5 / 49       
000000 1100 1010     0101 1101     0110       0001 0011          0001 1010 29,4 / 49
000000 1100 1010     0000 1101     0110       0000 0011          0010 0001 29,1 / 48  
000000 1100 0110     0110 1000     0110       0001 0100          1010 1001 25,0 / 65
000000 1100 0110     1011 1000     0110       0001 0100          1010 0001 25,2 / 65  
000000 1100 0110     1100 1000     0110       0010 0100          1010 1111 25,3 / 65
000000 1100 0110     0000 1001     0110       0000 0100          1010 1001 25,6 / 64  
000000 1100 0110     1100 1000     0110       0010 0100          1010 1111 25,3 / 65
000000 1100 0110     1101 1000     0110       0001 0100          1010 0110 25,3 / 65 (25,4 / 65)
000000 1100 0110     0000 1001     0110       0000 0100          1010 1001 25,6 / 64

Ich bin mir sicher, dass das 4. Datenpaket aus 8Bit für die Feuchte steht und zwar mit low Nibble zuerst. Allerdings müssten dann auch ein paar Ablesefehler dabei sein.
In der ersten Zeile wird also aus 0010 0011 -> 00110010 => dezimal 50, zweite Zeile wäre damit korrekt mit 49, die dritte korrekt mit 48.
In der 4. Zeile wird aus 0001 0100 -> 01000001 =>  dezimal 65, passt also auch. 5. Zeile wäre dann allerdings 66. 64 stimmt dann wieder in der nächsten Zeile.

Bei der Temperatur bin ich mir sicher, dass das 2. Paket für die beiden niederwertigen Nibbles steht, wobei 18Bit 1°C ausmachen würden. Hier auch wieder zuerst das niederwertige Nibble. Vermutlich steht das 3. Paket dann für das höchstwertige Nibble, zumindest passt das von der Differenz. Daraus ergäbe sich ein Offset von 67.77777 .
Also für die erste Zeile: aus  0111 1101 0110 ->   011011010111 -> dezimal 1751-> 1751 / 18 - 67.77777 = 29.5
4. Zeile:   aus 0110 1000 0110  ->  011010000110  ->  dezimal 1670 -> 1670 / 18 - 67.77777 = 25.0      passt !!
 
Ob diese Theorie passt, müsste man jetzt mit mehr Messwerten belegen. Interessant wären auch mal negative Temperaturen.