Protokoll von unbekanntem Gerät auf 433Mhz ASK/OOK alle 4 Minuten

[Peter G. (pit1989)]

Hallo zusammen, ich wollte mal in die Runde fragen ob das zufällig einer 
deuten kann: siehe Anhang.

Zu sehen sind 8 Telegramme, die ich über 433,x Mhz empfange. Sozusagen 
'vom Nachbarn'. Ich tippe auf ein Thermometer? Die Pakete kommen all 4-5 
Minuten, sind ASK moduliert. Die Timeings sind in µS.

Der HighPuls in Paket vier könnte ein Empfangsfehler sein.

Das Protokoll ist kein Manchester, sonst wären die die Puls/Pausen 
gleich groß. Scheint ein Return to Zero zu sein ? Aber mit min. drei 
verschiednen high Zeiten !?

Start 3900µS
kurzes High 480µS
mittle.High 860µS
langes High 2140µS
kurzes Low: 980µS
langes Low: 1950µS

Grüße, Pit

[chris (Gast)]

Dies sieht sehr nach Manchester Code aus.
Einfach mal im Netz nach Manchester Code suchen.

[Peter G. (pit1989)]

Nö - Einfach mal in meiner Frage nach Manchester Code suchen.

[Detlef K. (adenin)]

Nein, ist ganz sich nicht Manchester Code, weil, da gäbe es nur zwei 
mögliche Zeiten zwischen den Flankenwechseln. Die größere der beiden 
Zeiten wäre gleich der Bitdauer, und die andere eine halbe Bitdauer 
lang.

Ist das die volle Telegrammlänge?
Also mich stört, dass da keine Synchronisation oder sowas wie eine 
Idendifikationscode im Telegramm ist. Auf 433 tummelt sich ja einiges, 
und das muss der Empfänger doch irgendwie aussortieren könne und 
natürlich den Anfang des Telegramm finden. Ich seh aber nichts, was dazu 
brauchbar wäre.
Das sind 8 Telegramme?

[Peter G. (pit1989)]

Hi, ja - das waren 8 Telegramme. Ich habe mir das mal auf dem Oszi 
angesehen. Nicht dass da was verloren geht !?
Das Telegramm wird 12mal mit gleichem Inhalt gesendet, dazwischen ist 
eine Pause von 3800µS. Sind 36 'Pulse' pro Telegram.

Ich habe das Oszibild (unten in gelb/grün) mal deckungsgleich mit der µC 
auswertung (unten in weiss) gezogen - das stimmt jedenfalls...
Oben ist der Ausschnitt zu sehen, ...

[Detlef K. (adenin)]

Ähm, wie hast Du die demoduliert?

[Peter G. (pit1989)]

was meinst Du mit 'demoduliert' ?

Das erste Bild 'schwarzes Protokoll auf weisem Grund' entspricht dem 
'weissen Protokoll auf schwazem Grund'  - ist nur im gimp invertiert.

Die Daten kommen aus der Empfangsroutine des µC:

Beispiel:
3940,492,1940,500,1928,484,984,456,1984,492,1956,516,1732,492,1004,452,1 
976,488,988,472,1028,404,1008,472,992,456,1012,444,1024,468,980,488,992, 
440,1068,412,1992,464,1980,440,2256,432,2004,436,1988,452,1016,436,1024, 
456,2004,428,2004,432,2024,420,2024,416,1016,480,1968,452,1012,468,1960, 
460,2016,444,992,460,1028,448,1028

[Detlef K. (adenin)]

Ich meine was für eine Emfänger dran ist.
AM, FM, FSK ...
Ich vermute es ist FSK, aber falsch demoduliert.
Oder es ist doppelt codiert.

Wenn man ein neues Signal erzeugt, das zu jeder steigenden Flanke deines 
Signals einen Flankenwechsel macht (zB durch T-Flipflop), dann erhält 
man als Ergebnis etwas, das tatsächlich Manchester Code sein könnte.
Dann müsste dieser nur noch decodiert werden.

[Peter G. (pit1989)]

Ach so - ist ein ASK Empfänger - steht in der Überschrift :)
Guter Hinweis, da ich das Gerät nicht kenne sollte ich drauf achten!

[chris (Gast)]

Habe mir das mal in einem Editor angesehen, und denke, es könnte 
eventuell
OOK sein. Man müsste mehr als einen Ausschnitt haben und auch zwei,drei
unterschiedliche Telegramme mit unterschiedlichen Werten.
Hier die Annahme:
S = Sample . Wenn low > 3x Bittime ist, dann gehe auf Sample.
Sample ist das Bittime. Wenn kleiner, dann 0 und wenn gleich oder 
größer,
dann ist es eine 1. Sample = 4 x Bittime , Pause = 2x Bittime , das
Timing könnte passen.

Die Werte habe ich so decodiert:
SSSSSSSSS 1101101100 SSSSS 01 SSSS 1 S 1 SS 11

Eventuell könnte es sein, daß die Anzahl der S das Register darstellt,
in dem die Werte reingeschrieben werden. Ist eher eine unwarscheinliche 
Annahme, man müsste mehr Daten haben.

Der Anfang macht Sinn, danach weniger ist aber im Bereich des Möglichen.
Wie gesagt man müsste mehr Daten haben.

[Peter G. (pit1989)]

Ich logge gerade Daten. Ich habe aktuell einfach mal die kurzen Pausen 
zu 0 und die langen zu 1 gemacht, ... sind viele gleiche Daten, aber 
auch ein Muster - vorne steht die Uhrzeit

Wir haben gerade eine Temperatur von ca. 12 °C und eine Luftfeuchte von 
97% ^^

1:58:13.462> 110111010000000001111001111101011000
1:59:10.805> 110111010000000001111010111101011000
2:00:07.717> 110111010000000001111010111101011000
2:02:01.347> 110111010000000001111010111101011000
2:02:58.880> 110111010000000001111010111101011000
2:10:34.340> 110111010000000001111001111101011000
2:11:31.436> 110111010000000001111010111101011000
2:12:28.471> 110111010000000001111001111101011000
2:17:13.390> 110111010000000001111001111101011000
2:21:01.355> 110111010000000001111010111101011000
2:28:37.376> 110111010000000001111010111101011000
2:38:07.342> 110111010000000001111011111101011000
2:40:01.347> 110111010000000001111010111101011000
2:48:34.341> 110111010000000001111001111101011000
2:56:10.488> 110111010000000001111010111101011000
2:57:07.338> 110111010000000001111010111101011000
3:00:55.470> 110111010000000001111001111101011000
3:03:46.325> 110111010000000001111001111101011000
3:07:34.274> 110111010000000001111001111101011000
3:08:31.369> 110111010000000001111010111101011000
3:13:16.288> 110111010000000001111010111101011000
3:26:34.390> 110111010000000001111010111101011001
3:27:31.363> 110111010000000001111010111101011000
3:29:25.366> 110111010000000001111001111101011000
3:31:19.371> 110111010000000001111010111101011000
3:33:13.379> 110111010000000001111010111101011001
3:36:04.356> 110111010000000001111011111101011000
3:41:46.433> 110111010000000001111010111101011001
3:46:31.353> 110111010000000001111001111101011001
3:47:28.405> 110111010000000001111001111101011001
3:50:20.005> 110111010000000001111010111101011001
3:55:04.862> 110111010000000001111001111101011001
3:59:49.595> 110111010000000001111000111101011001
4:00:46.443> 110111010000000001111001111101011001
4:15:58.552> 110111010000000001111000111101011001
4:26:25.360> 110111010000000001111000111101011001
4:31:10.407> 110111010000000001110111111101011001
4:32:07.876> 110111010000000001110111111101011001
4:33:04.475> 110111010000000001110111111101011001
4:34:01.385> 110111010000000001110111111101011001

[Conny G. (conny_g)]

Als Inspiration....
http://www.dc3yc.homepage.t-online.de/protocol.htm

[Peter G. (pit1989)]

Könnten zwei verschiedene Sensoren sein.
Also ich habe mal folgendes angenommen:

                         TTTTTTTTTTTT
15:49:23.144> 000110101000000010001111111100000000 14.30°C Sensor 1
15:49:28.819> 110111010000000010000011111101011000 13.10°C Sensor 2
15:50:20.115> 000110101000000010001111111100000000 14.30°C Sensor 1
15:50:25.792> 110111010000000010000011111101011000 13.10°C Sensor 2

TTTTTTTTTTTT = 12 Bit Temperatur *10

also ist:

TTTTTTTTTTTT / 10 = Temperatur in °C

Ob das aber passt weiss ich nicht... Mal beobachten :)


@Conny G: Besten Dank -> ich hab einfach mal nach: 36bit, 433Mhz und 
Themperatursensor gesucht.

@chris: Ist mir nicht ganz klar was SSSSSSSSS, SSSSS, SSSS,  S und SS 
bedeuten, aber ich denke es ist der gleiche Ansatz ? Bitlängencodierung 
!

@Detlef Kunz: Dein Graph hat mich auf die richtige Spur geführ - ich 
hatte schon alle möglichen Codierungen durchprobiert - aber verm. sind 
es einfach ganz simpel lange (1) und kurze (0) bits !?!

Insgesamt weis ich nicht ob noch eine Humidity enhalten ist und ob die 
Temperatur stimmt.. Vielleicht logge ich das mal in eine Datenbank - 
wenn es Weihnachten unter Null und im Sommer über 25°C wird, sollte es 
passen :-)

Ich will ich im ersten Schritt meine möglicht universelle 
Empfangsroutine testen.

[Bernhard S. (bernhard)]

Leider sind die Daten-Telegramme der einzelnen Hersteller sehr 
unterschiedlich. Und werden auch nahezu geheim gehalten. Leider.

Oftmals wird die Nummer des Sensors, der Batteriestatus und Dummys mit 
übertragen.

Es gibt auch mehrere Arten vom Manchester Code.

Bernhard