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
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?
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, ...
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
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.
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.
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.
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
UnbenanntesGeraet.png
(63 KB)
