433 Mhz Receiver + Tchibo Wetterstation + Logic Analyzer

Hallo Marc,

ich kann Dich beruhigen, mir ist es auch noch nicht gelungen, die Außenstationen von den
Aldi Wetterstationen zu empfangen. Habe schon einiges probiert, Fernsteuerungen von Funksteckdosen
gehen problemlos, Wetter nicht.

Mal sehen, ob wir jemanden finden, der uns weiterhelfen kann.

Gruss Kalli

Da müsste man mal mit einem DSO/ Logicanalyzer ran. Die Datenpakete aufzeichnen, ggf. entschlüssen und dann sortieren/ zuweisen.
Das ganze mache ich gerade mit einem Reifendrucksystem (Tiremoni). Ganz so einfach ist das alles leider nicht, selbst wenn es nicht verschlüsselt ist :frowning:

Hi ihr,
also mit den Aussensensoren ist das so eine Sache, es funktionieren nicht alle mit den gängigen Bibliotheken. Das Problem ist, dass der Receiver Daten empfängt, diese kommen in einer bestimmten Form an, wenn diese nicht der Bibliothek entsprechen, passiert einfach mal gar nichts. Das liegt daran, dass die Aussensensoren unterschiedliche Protokolle zum Verschlüsseln/Übersenden ihrer Daten verwenden. http://www.hemitheconyx-caudicinctus.de/index.php/terrariensteuerung/sensoren Im ersten Programm auf der Seite findet diese Überprüfung in Zeile 28 statt. Hier müsstet ihr also die Veränderungen am Quellcode vornehmen und dementsprechend auch die decodier-Funktion anpassen. Das ist im allgemeinen aber nicht einfach getan mit einer Funktion alla "spuck mir alle eingehenden Daten aus". Ihr müsstet also erstmal mit Hilfe eines Oszilloskops eure eingehenden Daten auswerten und in die Form "1010101" bringen. Dazu haben sich 2005 Daniel Schüller und Ralf Töppner gedanken gemachthttp://www.uni-koblenz.de/~physik/informatik/studienarbeiten/toeppi.pdf Wenn ihr die Form "101010" habt könnt ihr versuchen die Daten zu entschlüsseln und überprüfen, wo genau die Temperatur, Luftfeuchtigkeit etc. abgelegt ist. Am besten eine Tabelle mit Referenzwerten anlegen (sprich verschiedene Temperaturen und Feuchtigkeiten) und dann überprüfen welche 0 und 1 sich ändern.
mfg
Balli
p.s. am besten Sensoren kaufen die nachweislich mit einer Bibliothek funktionieren, ansonsten kann es passieren das es irgendwann einmal kein Spaß mehr macht. Die eigentliche Wetterstation wird dann eh nicht mehr verwendetG.

Hi,

ich bin auch gerade dabei, eine Wetterstation zu dekodieren.
@Ballibum, leider klappts mit "Deiner" lib auch bei mir nicht - der Callback wird nichtmal aufgerufen, d.h. das Encoding ist anders.

Für eine Tchibo-Wetterstation habe ich das da gefunden: Garagentoröffner mit dem Arduino (unten im Artikel). Das produziert bei mir zumindest Daten. Leider scheint bei mir die Sequenzlänge anders zu sein. Daher habe ich mal überlegt, wie man die Sequenz mit Bordmitteln ohne Oszi ermitteln kann und eine einfache Lösung gefunden:

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

void loop() {
unsigned long LowVal=pulseIn(2,LOW);
Serial.println(LowVal);
}

Das gibt die Flanken als Mikrosekunden-Sequenz aus. Wenn nichts gesendet wird, habe ich da nur Müll. Wird gesendet, sehe ich ein klares Signal, welches sich 3x wiederholt. Es hat ein wenig gedauert sie zu isolieren: Sketch starten, Serielle Konsole auf 115200 Baud. TX am Sender drücken (mach sieht dass dann regelmäßigere Zahlen vorbeirauschen). Stecker zum Arduino ziehen, um den Output anzuhalten. Scrollen und suchen. Hier die Sequenz:
9012
1858
3761
1831
3753
3766
1804
1826
1828
3784
3740
1821
1843
3770
3754
3765
1828
1730
1856
1801
3791
1852
1842
1820
3784
1847
1813
1845
1835
1803
1841
1826
3798
3771
1834
1863
1856

Das erste ist eine Art Startsequenz. Danach kommen kurze und lange Flanken. Das findet sich auch passend im oben genannten Code wieder, nur dass meine Sequenz 36 Zeichen lang ist.

Nun geht die Decodierarbeit los:
010110001100110000010000111000011000 -> 27.0, Kanal 1
010110001100110100010000111000011000 -> 27.0, Kanal 2
010110001100111000010000111000011000 -> 27.0, Kanal 3

Das war einfach :wink:

010110001100111000001111110000011001 -> 25.2
010110001100111000001111110100011000 -> 25.3
010110001100111000001111111100011000 -> 25.5
010110001100111000010000111000011000 -> 27.0
010110001100111000010001000000011000 -> 27.2

Hier brauche ich wohl etwas Hilfe...

111111011000111011001111010000001100 -> Wow, ganz anders. Ist wohl das vom Nachbarn ^^

@Zickendoktor: Leider bin ich nun etwas vom Thread abgekommen aber ich denke, mit diesem Vorgehen bekommst Du auch schnell Deine Daten decodiert.

Hallo alle,

herzlich willkommen an alle "Schlaufüchse" (ist in diesem Fall ein Lob, weil ich ja von genau Euch Hilfe will :smiley: )!

Ich bin nicht weitergekommen, habe aber (ist so meine Art, wenn ich nicht weiterkomme) aufgerüstet. Seit heute nenne ich einen Bus Pirate 3.5 mein Eigen und habe damit jetzt rumprobiert. Da ich aber ein absoluter Beginner bin und keine Ahnung mit Logikanalyse habe, brauche ich JETZT eure Hilfe. Danke vorab!

Also:

Ich verstehe da ein paar Dinge nicht. Aber der Reihe nach.

Ich habe mit dieser Software http://www.lxtreme.nl/ols/ und dem BusPirate (BP) mir einen sehr einfachen Logicanalyzer für das 433Mhz Empfangsmodul aufgebaut.
Ich habe den MISO-Pin des BP an den Data-Pin des Receivers gehängt und mit einem Netzteil GND und 5V auf die anderen Pins gegeben. Da ich keine mir sinnvollen Werte erhalten habe habe ich nach den ersten Versuchen auch noch den GND-Pin des BP an GND vom Receiver (und damit auch vom Netzteil) gehängt. Den Aufbau seht ihr im angehängten Bild.
Sonst war kein Pin vom BP mehr verbunden. Hingen alle in der Luft.

  1. Frage: Warum bekomme ich auf den anderen Leitungen Signale? Hängt ja nix dran. Sonnenstürme? :slight_smile: Muss ich die in Alu-Folie wickeln?

Auf MISO (= Channel 1) hing der Data-Ausgang vom Receiver. Wenn ich dann mitgeschnitten habe, habe ich den Tx-Button des Aussensenders gedrückt und ich glaube, ich habe da irgendwas aufgezeichnet, was uns in diesem Fall weiterbringen kann. Ich schreibe uns, weil ich mit dem ganzen gar nix anfangen kann. Ich bin aber sehr lernwillig.

  1. Frage: Wie interpretiere ich diese Daten auf Channel 1 (die anderen ignorieren wir einfach)?

Ich habe mal das ganze Sniffer Projekt und alle möglichen Exports hier angehängt.

Über Hilfe zur Selbsthilfe würde ich mich sehr freuen.

Ich danke recht herzlich.

Servus!
Marc

Nachtrag: In der Beschreibung des Conrad Receivers steht noch sowas:
Empfangsfrequenz: 433,92 MHz +- 75 Khz
Ausgangssignal: Hi: 0,8V; Lo 0V

LogicSnifferData.zip (72.9 KB)

Wenn du Signaleingänge nicht beschaltest, koppeln die Netzleitungen kapazitiv ein. Daher sollte man Eingänge von CMOS.ICs auch nicht frei hängen lassen sondern auf definierte Pegel ziehen.
Die Periodendauer ist übrigens 20ms, was exakt 50 Hz (Netzfrequenz) entspricht.

sth77:
Wenn du Signaleingänge nicht beschaltest, koppeln die Netzleitungen kapazitiv ein. Daher sollte man Eingänge von CMOS.ICs auch nicht frei hängen lassen sondern auf definierte Pegel ziehen.
Die Periodendauer ist übrigens 20ms, was exakt 50 Hz (Netzfrequenz) entspricht.

Heißt das, dass ich die unbenutzten Eingänge dann immer an GND sammeln soll?

Hast Du mal den Mini-Sketch von mir probiert, um die Signallängen zu messen (oder den aus dem Link für die Tschibo-Station)? Ich hab inzwischen die komplette Kodierung meiner Station damit raus.

Werde ich morgen mal probieren. Obwohl ich ja jetzt einen Logic analyzer habe :slight_smile:
Ich suche jetzt schon seit Stunden nach brauchbaren Anleitungen zum thema Logic analyzer.
Ich finde da nichts für Einsteiger verständliches auf deutsch (es ginge auch englisch)
Wenn jemand was zum Thema Auswertung von solchen Infos hat, gerne her damit.

Probier auch mal den leicht modifizierten Tchibo-Sketch:

/*
Liest dieses komische Tchibo-Wetterdingens per 433MhZ aus.
*/

boolean cnt=false;
int reader=0;
int cnter=0;
const int msgLeng=36;
char reading[msgLeng];
void setup() {
Serial.begin(115200);
Serial.println("go!");
pinMode(2, INPUT);
pinMode(13,OUTPUT);
}

void loop() {
int LowVal=pulseIn(2,LOW);
if (LowVal < 11000) { // Kuezer als 1100ms Low ? Koennte unserer Sensor sein
if (decodeTime(LowVal) == 'S') { // Startsequenz ?
cnt=true; // Dann go fuer die Sammlung
cnter=0; // BitCounter auf 0
}
if ( (cnter<msgLeng) && cnt && ((decodeTime(LowVal) == '0') || (decodeTime(LowVal)=='1'))) { // Stream noch nicht voll und ein Bit erkannt ?
Serial.print(decodeTime(LowVal));
reading[cnter]=decodeTime(LowVal); // Ab ins Array damit
cnter=cnter+1; // Arraycounter fuers naechste Bit inkrementieren
}
} else {
cnt=false; // Zurueck auf Anfang - nix fuer uns.
}

if ((cnter==msgLeng)) { // Arrray Voll ?
Serial.print('/');
Serial.print(reading);
Serial.print('/');
Serial.println(decodeTemp(reading));
cnter=0;
cnt=false;
}

}

float decodeTemp(String bitstream) { // Versucht aus dem Bitstrom die Temp. zu berechnen
int x=0;
int chk=0;
for (int i=16;i<24;i++) { // Extrahiert das Byte zwischen Bit 16 und 24 und packt es als integer in "x"
if (bitstream == '1') {

  • bitSet(x,(23-i));*
  • }*
  • }*
  • for (int i=4;i<15;i++) { // Kenner aus den 3 Nibbles zwischen Bit 4 und 15 holen (koennte auch der Kanal sein ?)*
    _ if (bitstream == '1') {_
    * bitSet(chk,(14-i));*
    * }*
    * }*
    /* if (chk != 136) { // Kenner = 136 ? Dann ist es unserer Sensor !
    * return(-999); // Wenn nicht, dann -999 zurueck*
    _ } else*/ {_
    * return ((float)x/10);*
    * }*
    }
    char decodeTime(int time){ // Wandelt die Pulse in Bits um.
    * if (time > 1500 && time < 11000) { // passendes Signal (zwischen 150ms und 11000ms) ?*
    * if (time < 2500) { // kleiner 250ms ? Dann LOW*
    * return '0';*
    * } *
    * if (time < 5000 && time >3000) { // Zwischen 500ms und 1000ms dann HIGH*
    * return '1';*
    * }*
    * if (time >8000) { // Groesser 800ms dann Startsequenz !*
    * return 'S';*
    * }*
    * } else {*
    * return 'X';*
    * } *
    }
    [/quote]
    Setzte msgLeng dazu mal wieder auf 28. Bei mir sind es 36 Bits aber die letzten 8 ergeben keinen Sinn - macht also auch 26 Bit verwertbare Daten. Die decodeTime Methode funktioniert nicht für mein Thermometer aber immer wenn ich auf "TX" am Thermometer drücke kommt immer 3x die gleiche Bit-Sequenz. Die ersten 14 Bits sind bei mir konstant. Die nächsten 2 kodieren den Kanal. Danach folgen 12 Bit, die die Temperatur als signed integer kodieren (muss man durch 10 Teilen, dann hat man die Temperatur mit 1 Nachkommastelle).

Der Bus Pirate ist aber eigtl. kein Logicanalyzer. Dazu nimmt man den Open Bench Logic Sniffer aus gleichem Hause. Mit dem funktioniert das wunderbar.

Wie du richtig schreibst: eigentlich. Aber für diesen Zweck könnte er reichen und nützlich sein.
Keiner hier, der mir helfen kann, die Grafik zu interpretieren? Es gibt keine Anleitung im großen Internet, die einem das erklärt.
Ich weiß, dass es High und Low gibt und dass es 1 und 0 bedeutet. Aber ist der Abstand dazwischen auch wichtig? Wie erkennt man zwei gleiche Bits in Folge? Ist meine Messung überhaupt sinnvoll?
Das würde mir sehr weiterhelfen.

Womit hast Du denn die .olp-Datei erstellt? Mit einem entsprechendem Programm könnte man die ja vielleicht öffnen. Mit meiner OLS-Software für den OBLS geht das z.B. nicht.

Auf dem jpeg sieht man ja einen Ausschnitt der Daten, das reicht aber nicht zum Interpretieren. Da müsste ein ganzes Datenpaket zu erkennen sein. Auch die Samplefrequenz müsste u.U. deutlich schneller sein, da würde ich mal ein wenig herumprobieren.
Das Akquirieren und Interpretieren von solchen Daten ist meistens nicht ganz trivial. Daher ist es am einfachsten, wenn man weiß, wonach man suchen muss (bestimmte Temperatur- bzw. andere Messwerte) und das ganze noch in einem eng abgegrenzten Datenpaket sichtbar ist. Die 433-MHz-Funkdaten sind häufig Manchester-codiert, kommen in mehreren, gleichen Paketen hintereinander und zwischendruch gibt es dann auch immer mal wieder Datenbursts z.B. für ein Statuspaket o.ä. Also wirklich nicht ganz simpel. Wenn es dann noch codiert ist...

Eine Möglichkeit, um sich in das ganze einzuarbeiten wäre, sich erstmal andere, bekannte Signale (z.B. serielle Daten vom Arduino) sauber einzulesen, anzuschauen und zu deuten. Dann bekommt man auch ein Gefühl für die Triggereinstellungen und die Frequenz etc. Dann probiert man das gleiche mit dem I²C oder SPI-Bus.

Danke markbee, das ist schon mal ein netter Anfang.

Die Olp Datei habe ich damit erstellt:

http://www.lxtreme.nl/ols/

Damit sollte man die auch wieder einlesen können.

Die Temp. müsste zum Messzeitpunkt ca. 27 Grad gewesen sein.

Dann werde ich heute/morgen mal weiter testen.

Ich glaube mehr als diese Datenmenge kann ich nicht sampeln, das bringt der Bus pirate nicht :slight_smile:

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.

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!

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! :smiley:

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:

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

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

Keiner hier, der fließend Binär spricht... =( :slight_smile: