Ich habe ein billiges kabelloses Poolthermometer (AcuRite 617 1 ) und möchte die Temperaturdaten am Empfänger abfangen und mit einem computergestützten Datenerfassungssystem verwenden.
Praktischerweise befindet sich im Empfänger eine kleine Breakout-Platine, die an die Antenne angeschlossen ist und über digitale "V" -, "G" -, "D" - und "SH" -Pins verfügt:
Hier ist ein Segment von erfassten Daten vom "D" -Pin während einer Übertragung (diese treten einmal pro Minute auf). Vor diesem Segment scheint es Daten mit einer viel höheren Rate zu geben, aber ich glaube, das könnte Rauschen sein - dies ist der Beginn der 1,36-kHz- / 680-Hz-Daten.
Ich habe ein bisschen gegoogelt und kann keine Codierung finden, die so aussieht, aber wenn ich raten würde, was los ist, denke ich Folgendes:
- Die ersten 4 Zyklen mit 680 Hz dienen zum Synchronisieren der Uhren, enthalten jedoch keine Daten
- Die folgenden 13 Zyklen mit 1,36 kHz (2x die Anfangsrate) scheinen eine von zwei Formen zu haben: Sie fallen entweder vor dem Mittelpunkt des Zyklus oder danach auf ein niedriges Niveau - ich würde annehmen, dass eine Form eine logische und die andere ist ist eine Null.
- danach scheint es eine merkwürdige Lücke zu geben, aber wenn Sie den Teil des Tiefs, der Teil der vorhergehenden "1" ist, abrechnen, dann beträgt die verbleibende Lücke 735 µs, was eine (phasenkorrekte!) Fortsetzung der ist 680 Hz Präambel.
Schaue ich das richtig an? Gibt es einen Namen für diese Kodierung?
Einige weitere Hinweise zum Breakout Board:
- Die Platine ist mit "RF211" gekennzeichnet und sieht bemerkenswert konsistent mit dem MICRF211 "Allzweck-3V-QwikRadio-Empfänger, der mit 433,92 MHz betrieben wird" 3 aus
- Das MICRF211-Datenblatt enthält die folgende Abbildung (mit sehr wenigen Erläuterungen), die mit Ausnahme der Rechteckwelle mit doppelter Datenrate im Vergleich zu meiner Erfassung verblüffend aussieht:
14.02.2016 Update: Ich habe dieses Projekt überarbeitet und sehe so aus, als würde ein sauberer 64-Bit-Stream zwischen einer 4-Takt-Präambel und einer 1-Takt- "Postambel" erzeugt, wonach die Anzeigetafel das HF-Modul durch herunterfährt ^ SH low ziehen (oberste Zeile):
Laut dem "33/66% PWM" -Schema von Micrel (das bei Google nirgendwo sonst zu finden ist) ist das so
-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_
Also muss ich jetzt anfangen, die Temperatur zu manipulieren, um die Bits zu dekodieren. Hier ("x") sind die Bits, die sich ohne erkennbare Änderung der Anzeige zu ändern scheinen:
0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx
Ich gehe davon aus, dass es sich entweder um niedrigstwertige Bits oder um den Batteriestand handelt (der nur dann als "Niedrig" angezeigt wird, wenn er erheblich abfällt).
15.02.2016 Update: Ich mache mich auf den Weg, um der neuen Stapelbörse "Reverse Engineering" einen Sprung in die richtige Richtung zu geben: /reverseengineering/12048/what-is-contained -in-diesem-Getriebe-RF-Pool-Temperatursensor-Basiseinheit-re
Antworten:
Micrel bezeichnet es als 33/66% PWM-Schema. Es scheint ein ziemlich einfaches, aber ad-hoc Protokoll zu sein.
PWM steht für Pulsweitenmodulation. Es gibt eine Wikipedia-Seite, die ausführlicher beschrieben wird. Kurz gesagt: In PWM wird ein fester Zeitraum festgelegt. Hier ist also die Zeit von der ansteigenden Flanke zur nächsten ansteigenden Flanke. Sie variieren jedoch den Prozentsatz der Zeit, die im Hoch verbracht wird Zustand durch Ändern, wenn die fallende Flanke auftritt. In diesem Fall sehen Sie, dass es 33% für eine "1" und 66% für eine "0" ist.
Die anfängliche Reihe von Impulsen ist gleich hoch und niedrig. Dies geschieht normalerweise, damit der Empfänger synchronisiert werden kann, bevor die eigentlichen Daten empfangen werden.
Unter http://www.micrel.com/_PDF/App-Notes/an-22.pdf finden Sie weitere Informationen zu den erwarteten Modulen.
Ein typischer Weg, um diese Art von Codierung empfangen zu können, besteht darin, dies in einen Timer-Eingangserfassungsstift eines Mikrocontrollers einzugeben. Oder Sie können einfach eine Verbindung zu einem allgemeinen Eingang herstellen und diesen mit dem 4-5-fachen der PWM-Periode abtasten lassen. Der Algorithmus zum Dekodieren ist von dort nicht allzu schwer.
Alternativ können Sie sich, wie von markt vorgeschlagen, zum Temperatursensor selbst zurückarbeiten. Wenn es sich jedoch um ein analoges Ausgangssignal handelt, müssen Sie es selbst in ein digitales Signal umwandeln und haben möglicherweise geringfügig andere Zahlen in Ihrer Protokollierung als bei der ursprünglichen Ausgabe.
quelle
Bekannte Leute bezeichnen diese Codierungstechnik normalerweise als "PWM", was meiner Meinung nach eine sinnvolle Beschreibung ist.
Mein erster Gedanke bei der Betrachtung Ihres Datenstroms und der Annahme, dass Sie die Polarität der Bits richtig erraten, ist, dass es sich um einen 12-Bit-ADC-Lesevorgang handelt, LSB zuerst, mit einer führenden '1' als Startbit. Ich gehe zuerst mit LSB vor, weil der Beginn des voraussichtlich nächsten Messwerts eine Ein-Bit-Variation zeigt und es unwahrscheinlich ist, dass ein ADC-Messwert der (Pool-) Temperatur in diesem kurzen Zeitraum um ein zweites oder drittes MSB variiert.
Ich würde etwas weiter in das System eintauchen, zurück zu dem, was die Daten erzeugt (anstatt sie zu übertragen), nachsehen, ob Sie den Temperatursensor identifizieren können, und nach Korrelationen zwischen den übertragenen Daten und der Temperatur suchen.
quelle
Fast alle HF-Übertragungsschemata müssen in ihren Datencodierungsprotokollen mehrere Merkmale aufweisen. Dazu gehören:
Der ungerade Ballpuls, den Sie notiert haben, ist höchstwahrscheinlich die Synchronisationspulsanzeige.
Die Datencodierung scheint dem zu folgen, was ich als Pulsbreitencodierung bezeichnet habe. Dies ist eine ziemlich verbreitete Technik, bei der die eine Übergangsrichtung einer konstanten Frequenz folgt, was zu Bitzellenzeiten konstanter Breite führt. Während der Bitzelle wird der aktive Impuls als 25% der Bitzellenzeit oder 75% der Bitzellenzeit dargestellt. Dieses Schema ist kein symmetrisches Impuls-zu-Impuls-Gleichstrom-Codierungsschema, wie es die Manchester-Codierung bietet. Es ist eine übliche Technik mit Impulsbreitencodierung, einen Gleichspannungsausgleich innerhalb des Nachrichtenprotokolls bereitzustellen, indem zusätzliche Bits gesendet werden, um einen Gesamtausgleich in der gesamten Nachricht zu erzeugen. In der einfachsten Form werden die Daten zweimal gesendet, wobei die zweite Kopie logisch invertiert wird.
In Ihrem Beispiel ist es merkwürdig, dass pulsbreitenmodulierte Daten vor dem Synchronisationspuls auftreten. Es ist jedoch immer noch ein praktikables Schema, wenn der Datendecodierungsalgorithmus so ausgelegt ist, dass er die empfangenen Daten mit der Synchronisation in dieser Position akzeptiert. Es ist möglich, dass das Gerät vor und nach der Synchronisierung einen Datentyp sendet. Die Aufteilung kann zwischen Sensoradresse / Temperaturdaten ODER wahren Daten / invertierten Daten erfolgen.
Bearbeiten:
Es ist interessant zu bemerken, dass es fast so aussieht, als würde die Sendeeinheit einen anderen Softwarealgorithmus zum Formulieren der positiven Impulsbreiten für Datenzellen vor dem Synchronisationsmuster verwenden als für die Impulsbreite bei und nach dem Synchronisationsmuster. Dies impliziert, dass möglicherweise ein separater Software-Block vorhanden ist, der das frühere Muster als das für den nachfolgenden Teil des Musters generiert. Dieser Unterschied des Musters könnte bedeuten, dass die Datenquelle in Bezug auf die Art und Weise, wie Bit für Bit auf sie zugegriffen wird, jeweils eine andere Behandlung erfordert. Der Unterschied im Zeitdiagramm kann einfach ein Befehlstiming oder zwei Unterschiede in den Mustererzeugungsschleifen sein.
quelle
Ich habe mit der Dekodierung des Acurite 617 begonnen und hier sind meine ersten Beobachtungen. Ich kann Ihnen sagen, dass das letzte Byte eine Art "Prüf" -Byte ist und das neben den letzten drei Bytes die Temperatur enthält. Diese Bytes werden auch mit dem 7. Bit gesendet, um eine gerade Parität zu erzielen, und nur das untere Halbbyte jedes Bytes wird verwendet. Ich habe ein Arduino-Programm geschrieben, um die Daten zu erfassen und habe die folgenden Meldungen / Temperatur gesehen.
40 ce c0 00 00 0c 03 sei
(00 0C 03) => 0C3 => 67F
40 ce c0 00 00 0c 84 39
(00 0C 04) => 0C4 => 67F
40 ce c0 00 00 0c 05 b8
(00 0C 05) => 0C5 => 67F
Andere Daten / Temperaturen, die ich gesehen habe, sind:
E2 => 73F
F5 => 76F
108 => 80F (81 00 88)
109 => 80F
Mit dieser sollten Sie in der Lage sein, die "Gerade" (Annahme) -Konvertierung durchzuführen.
Da ich keinen guten Umfang (und die Tatsache, dass die Daten einmal pro Minute gesendet werden) habe, bin ich mir nicht sicher über mein Timing. Ich sehe die Synchronisation HI und LO als 720 usec und die Datenbits als 240 und 480 usec.
Hoffentlich werde ich später mehr Infos haben. Ich habe ein paar davon. Sobald sie zu lecken beginnen, entferne ich sie aus dem Pool und trockne sie für den Gebrauch im ganzen Haus aus. Die späteren 617-Module (mit abschraubbarer Unterseite und O-Ring) scheinen länger zu halten.
Ich habe noch etwas dekodiert. Das letzte Byte (Prüfbyte) macht das XOR aller acht Bytes gleich 0FFH. Zum Beispiel für "40 CE C0 00 00 8D 0C 30" ist 40 xoder CE xoder C0 xoder 00 xoder 00 xoder 8D xoder 0C xoder 30 gleich 0FF.
Außerdem habe ich die Temperatur auf 34 ° F gesenkt und 10 Dezimalstellen (d. H. 00 00 0A) und bei 80 ° F 264 Dezimalstellen (d. H. 81 00 88 oder 108H) gezählt.
Von diesem verwende ich Temp (F) = 0.1811 * Count + 32.1889. Wenn ich einen Fehler sehe, kann ich möglicherweise eine größere Zeitspanne abrufen, um bessere Daten zu erhalten.
Blick auf Rob Starlings Saite am 14.02.2016:
00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA
XOR = FF
Count = 0E4 oder 228
Temp = 73,5F
quelle
228ist, dass es ist22.8C. Mach für Farenheit das ÜblicheF=C*9/5+32.