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 mehr ins Detail geht, aber kurz gesagt, bei PWM halten Sie einen festen Zeitraum ein, also ist es hier die Zeit von der steigenden Flanke zur nächsten steigenden Flanke, aber Sie variieren den Prozentsatz der Zeit, die im High verbracht wird Zustand, indem er sich ändert, wenn die fallende Flanke auftritt. Bei diesem können Sie sehen, dass es 33 % hoch für eine „1“ und 66 % hoch für eine „0“ ist.

Die anfängliche Reihe von Impulsen sind gleiche hohe und niedrige Zeiten. Dies geschieht normalerweise, damit sich der Empfänger synchronisieren kann, bevor die eigentlichen Daten empfangen werden.

Siehe http://www.micrel.com/_PDF/App-Notes/an-22.pdf für weitere Details darüber, was sie für das Modul erwarten.

Ein typischer Weg, um diese Art von Codierung empfangen zu können, wäre die Eingabe in einen Timer-Eingangs-Capture-Pin eines Mikrocontrollers. Oder Sie können einfach eine Verbindung zu einem allgemeinen Eingang herstellen und ihn mit dem 4-5-fachen der PWM-Periode abtasten lassen. Der Algorithmus zum Decodieren ist daher nicht zu 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 umwandeln und haben möglicherweise geringfügig andere Nummern in Ihrer Protokollierung als die ursprüngliche Ausgabe.

Leute meines Bekanntenkreises nennen diese Codierungstechnik normalerweise "PWM", was meiner Meinung nach eine vernünftige Beschreibung ist.

Mein erster Gedanke beim Betrachten Ihres Datenstroms und unter der Annahme, dass Sie die Polarität der Bits richtig erraten, ist, dass es sich um eine 12-Bit-ADC-Lesung handelt, LSB zuerst, mit einer führenden „1“ als Startbit. Ich gehe zuerst mit LSB, weil der Beginn des vermutlich nächsten Messwerts eine Ein-Bit-Variation zeigt und es unwahrscheinlich ist, dass ein ADC-Messwert der (Pool-) Temperatur in so kurzer Zeit um ein 2. oder 3. MSB variieren würde Rahmen.

Ich würde ein wenig weiter in das System eintauchen, zurück zu dem, was die Daten generiert (im Gegensatz zu ihrer Übertragung), sehen, ob Sie den Temperatursensor identifizieren können, und nach einer Korrelation zwischen den übertragenen Daten und der Temperatur suchen.

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 die nächsten drei Bytes die Temperatur enthalten. Diese Bytes werden auch unter Verwendung des 7. Bits gesendet, um eine gerade Parität herzustellen, und es wird nur das untere Halbbyte jedes Bytes verwendet. Ich habe ein Arduino-Programm geschrieben, um die Daten zu erfassen, und die folgenden Meldungen/Temperaturen gesehen.

40 ce c0 00 00 0c 03 sein
(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 / Temps, die ich gesehen habe, sind:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Damit sollten Sie in der Lage sein, die "geradlinige" (Annahme) Konvertierung durchzuführen.

Da ich kein gutes Zielfernrohr habe (und die Daten nur einmal pro Minute gesendet werden) bin ich mir über mein Timing nicht sicher. Ich sehe Sync HI und LO als 720 usec und die Datenbits als 240 und 480 usec.

Hoffentlich habe ich später mehr Infos. Ich habe ein paar davon. Sobald sie zu lecken beginnen, entferne ich sie aus dem Pool und trockne sie für den Gebrauch im Haus. Die späteren 617-Module (mit abschraubbarem Boden 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. Beispielsweise ist für „40 CE C0 00 00 8D 0C 30“ 40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 gleich 0FF.

Außerdem habe ich die Temperatur auf 34F heruntergenommen und die Zählung war 10 Dezimalstellen (dh 00 00 0A) und bei 80F war die Zählung 264 Dezimalstellen (dh 81 00 88 oder 108H).

Daraus verwende ich Temp(F) = 0,1811 * Count + 32,1889. Ich bekomme möglicherweise eine größere Spanne, um bessere Daten zu erhalten, wenn ich einen Fehler sehe.

Betrachtet man die Saite von Rob Starling am 14.02.2016:

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

Anzahl = 0E4 oder 228

Temperatur = 73,5F

Nahezu alle HF-Übertragungsschemata müssen mehrere Merkmale in ihren Datencodierungsprotokollen aufweisen. Dazu gehören:

1. Konsistente Formatpräambel, die verwendet wird, um einen Empfänger auf eine Frequenz zu sperren
2. Eine Sync-Impulsanzeige zum Markieren des Starts, wenn die Rahmenanzeige angezeigt wird
3. Eine Methode zum Codieren von Daten 1 und 0 mit einer Art codierter Taktung für die Datenwiederherstellung.

Der ungerade Ballimpuls, den Sie notiert haben, ist mit Sicherheit die Synchronisationsimpulsanzeige.

Die Datencodierung scheint dem zu folgen, was ich als Impulsbreitencodierung bezeichnet habe. Dies ist eine ziemlich übliche Technik, bei der die eine Übergangsrichtung einer konstanten Frequenz folgt, was zu Bitzellenzeiten mit 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 Impuls-zu-Impuls-DC-symmetrisches Codierungsschema, wie es die Manchester-Codierung bietet. Es ist eine übliche Technik mit Impulsbreitencodierung, einen Gleichstromausgleich innerhalb des Nachrichtenprotokolls bereitzustellen, indem zusätzliche Bits gesendet werden, um einen Gesamtausgleich in der gesamten Nachricht zu erzeugen. In ihrer einfachsten Form werden die Daten zweimal gesendet, wobei die zweite Kopie logisch invertiert wird.

In Ihrem Beispiel ist es seltsam, dass pulsweitenmodulierte Daten vor dem Sync-Impuls auftreten. Es ist jedoch immer noch ein praktikables Schema, wenn der Datendekodieralgorithmus so ausgelegt ist, dass er die empfangenen Daten mit dem Sync in dieser Position akzeptiert. Es ist möglich, dass das Gerät einen Datentyp vor der Synchronisierung und einen danach sendet. Die Aufteilung könnte zwischen Sensoradresse / Temperaturdaten ODER wahren Daten / invertierten Daten erfolgen.

Bearbeiten:

Es ist interessant festzustellen, dass es fast so aussieht, als würde die Sendeeinheit einen anderen Softwarealgorithmus verwenden, um die positiven Impulsbreiten für Datenzellen vor dem Sync-Muster zu formulieren als für die Impulsbreite bei und nach dem Sync-Muster. Dies impliziert, dass möglicherweise ein separates Stück Software vorhanden ist, das das frühere Muster erzeugt als das für den nachfolgenden Teil des Musters. Dieses unterschiedliche Muster könnte darauf hindeuten, dass die Datenquelle in jedem Fall eine unterschiedliche Handhabung hinsichtlich des bitweisen Zugriffs erforderte. Der im Zeitablaufdiagramm ersichtliche Unterschied könnte einfach ein Befehlszeitablauf oder zwei Unterschiede in den Mustererzeugungsschleifen sein.

Wie heißt es?

Diese Art der Kodierung taucht überall auf. Viele Leute stoßen darauf, wenn sie sich mit adressierbaren Pixeln (WS281x/Neopixels) mit "Single Wire" befassen. Es wird auch im DShot-Protokoll verwendet, das für die Steuerung von bürstenlosen ESCs in "Drohnen" / Drehflüglern beliebt ist. Irgendwie hat sich die Branche nicht für einen einheitlichen Namen entschieden.

Man könnte argumentieren, dass es sich um ein NRZ(L)-Signal handelt, da es keinen voreingestellten „Pegel“ gibt, der sich von den beiden möglichen Pegeln unterscheidet. Das Fehlen eines Impulses könnte jedoch als dritter Zustand betrachtet werden (und wird häufig zum Synchronisieren/Abgrenzen von Paketen verwendet). Daher denke ich, dass die Verwendung von NRZ zur Beschreibung dieser Signale bestenfalls nicht hilfreich und schlimmstenfalls irreführend ist.

Die Impulsbreiten werden moduliert, daher ist "PWM" nicht ganz fehl am Platz, aber PWM bedeutet normalerweise, die analoge Breite des Impulses proportional zu einem analogen Wert zu verwenden.

„Codieren“ bedeutet, ein Datenformat in ein anderes umzuwandeln. Alle diese Protokolle sind ein Strom binärer Bits mit einem Bittakt (und verwenden eine Pause, um anzuzeigen, welches das "erste" ist).

PWEB (Pulse Width Encoded Bits/Binary) erfasst die Kerndetails dieses Codierungsschemas, unabhängig von der digitalen Codierung/Verifizierung oder den erwarteten Impulslängen.