Quel codage est utilisé dans ce signal?


19

J'ai un thermomètre de piscine sans fil bon marché (AcuRite 617 1 ) et j'aimerais intercepter les données de température au niveau du récepteur et l'utiliser avec un système d'enregistrement de données informatisé.

Idéalement, à l'intérieur du récepteur se trouve une petite carte de dérivation connectée à l'antenne et dotée de broches numériques "V", "G", "D" et "SH":

Carte RF211

Voici un segment de données capturées à partir de la broche "D" pendant une transmission (celles-ci se produisent une fois par minute). Avant ce segment, il y a ce qui semble être des données beaucoup plus élevées, mais je pense que cela pourrait être du bruit - c'est le début des données à 1,36 kHz / 680 Hz.

signal capturé à partir de la broche "D"

J'ai googlé un peu et je ne trouve pas un encodage qui ressemble à ceci, mais si je devinais ce qui se passe, voici ce que je pense:

  • les 4 premiers cycles de 680 Hz doivent synchroniser les horloges mais ne contiennent aucune donnée
  • les 13 cycles de 1,36 kHz (2x le débit initial) qui suivent semblent avoir l'une des deux formes: ils tombent bas avant le milieu du cycle ou après - je suppose qu'une forme est logique et l'autre est un zéro.
  • après cela, il semble y avoir un écart étrange, mais si vous actualisez la partie du bas qui fait partie du "1" précédent, alors l'écart restant est de 735 µs, ce qui est une (phase correcte!) continuation du Préambule 680 Hz.

Suis-je en train de regarder cela correctement? Y a-t-il un nom pour cet encodage?

Quelques autres notes sur le tableau de discussion:

  • la carte est marquée "RF211" et semble remarquablement cohérente avec le récepteur polyvalent 3V QwikRadio MICRF211 qui fonctionne à 433,92 MHz " 3
  • la fiche technique MICRF211 a la figure suivante (avec très peu d'explications), qui ressemble énormément à ce que je vois, à l'exception de l'onde carrée à double débit par rapport à ma capture:
    profil de données

Mise à jour du 14/02/2016: J'ai revu ce projet et semble obtenir un flux 64 bits propre entre un préambule à 4 cycles et un "postambule" à 1 cycle, après quoi la carte d'affichage arrête le module RF par tirant ^ SH bas (ligne du haut):

64 bits de données

Selon le schéma "33/66% PWM" de Micrel (qui n'apparaît nulle part ailleurs sur Google), c'est

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

Alors maintenant, je dois commencer à manipuler la température pour décoder les bits. Voici ("x") les bits qui semblent changer sans aucun changement apparent dans l'affichage:

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

Je suppose que ce sont soit les bits les moins significatifs, soit le niveau de la batterie (qui ne s'affiche que comme «faible» lorsqu'il baisse de manière significative).

Mise à jour du 15/02/2016: Je prends le spectacle sur la route pour donner au nouveau stackexchange "Reverse Engineering" une piste pour déterminer le sens: /reverseengineering/12048/what-is-contained -dans-cette-transmission-rf-piscine-capteur-de-température-unité-de-base-re


BTW - La lecture des commentaires des utilisateurs sur le site Web de Home Depot pour l'unité AcuRite 617 ne donne pas une bonne idée de la durabilité globale de ce produit. En fait, il semble que ce soit une position d'écriture par rapport à ne pas fuir dans l'unité émettrice.
Michael Karas

Oh, ça l'est. le mien a déjà fui. mais je l'ai séché et démonté et je suis certain que je peux améliorer l'étanchéité avec de la colle chaude et / ou du silicone. le compartiment des piles semble bien conçu avec un joint torique décent; c'est le reste de l'unité qui est si mauvais, et qui n'a plus jamais besoin d'être rouvert ...
Rob Starling

Écrémé d'autres réponses mais cela vient de l'apparence. L'onde carrée initiale consiste à synchroniser la tranche de données à un niveau de 50%. Faites une pause avant que les données ne garantissent que le niveau "1" a diminué. Alors 2: 1mk-spc = 1 dit et 1: 2 = 0. Avec l'hystérésis 50:50 ne bascule pas entre 1 ou 0 précédent MAIS ne devrait pas se produire pendant le flux de données. Ce qui précède est "mauvais" car il n'essaie pas de préserver le rapport moyen 50:50 et votre niveau de courant continu dérivera si les données ont plus de 1 ou de 0 mais si votre constante de temps de niveau DC est longue par rapport à une longueur de msg, elle ne le fait pas matière. Vous resynchronisez ensuite à nouveau avec un préambule 1: 1 pour le prochain msg.
Russell McMahon

Un décodeur pourrait être un ampli op avec un signal alimenté par un filtre RC pour régler le niveau DC moyen et un autre signal alimenté via une résistance plus un retour d'hystérésis + ve (peut-être environ 4R) de sorte qu'un signal 1: 1 ne retourne pas la sortie mais un 2 : 1 ou 1: 2. Un peu de jeu avec l'hystérésis% et la constante de temps DC RC et cela devrait fonctionner assez bien.
Russell McMahon

Quelques granules de carbure de calcium ou de calcium métallique au fond du boîtier devraient le garder au sec et légèrement sous pression :-). Non, je n'ai jamais essayé ça.
Russell McMahon

Réponses:


8

Micrel l'appelle un schéma PWM à 33/66%. Il semble que ce soit un protocole assez simple mais ad hoc.

PWM signifie modulation de largeur d'impulsion. Il y a une page Wikipédia qui va plus en détail, mais en bref, PWM est l'endroit où vous gardez une période fixe, donc ici c'est le temps entre le front montant et le front montant suivant, mais vous faites varier le pourcentage de temps passé dans le haut état en changeant lorsque le front descendant se produit. Pour celui-ci, vous pouvez voir qu'il est de 33% élevé pour un «1» et de 66% élevé pour un «0».

Les premières séries d'impulsions sont des temps égaux hauts et bas. Cette opération est généralement effectuée pour permettre au récepteur de se synchroniser avant la réception des données réelles.

Voir http://www.micrel.com/_PDF/App-Notes/an-22.pdf pour plus de détails sur ce qu'ils attendent du module.

Une manière typique de pouvoir recevoir ce type de codage serait de l'introduire dans une broche de capture d'entrée de minuterie d'un microcontrôleur. Ou, vous pouvez simplement vous connecter à une entrée générale et la faire échantillonner à 4-5x la période PWM. L'algorithme de décodage n'est pas trop difficile à partir de là.

Alternativement, comme suggéré par markt, vous pouvez retourner au capteur de température lui-même. Mais, s'il s'agit d'un signal de sortie analogique, vous devrez le convertir vous-même en numérique et peut avoir des nombres légèrement différents dans votre journal par rapport à la sortie d'origine.


3

Les gens de ma connaissance appellent généralement cette technique de codage "PWM", ce qui, je suppose, est une description raisonnable.

Ma première pensée en regardant votre flux de données et en supposant que vous devinez correctement la polarité des bits, c'est qu'il s'agit d'une lecture ADC 12 bits, LSB en premier, avec un `` 1 '' en guise de bit de départ. Je vais d'abord avec LSB parce que le début de ce qui est vraisemblablement la prochaine lecture montre une variation d'un seul bit et il est peu probable qu'une lecture ADC de la température (de la piscine) varie d'un 2e ou 3e MSB dans ce court laps de temps.

Je creuserais un peu plus dans le système, pour revenir à ce qui génère les données (par opposition à la transmission), voir si vous pouvez identifier le capteur de température et rechercher une corrélation entre les données transmises et la température.


Il me semble que @RobStarling devrait déjà pouvoir savoir quelle est la température transmise en regardant le récepteur et en voyant ce qui est affiché.
Michael Karas

1
vrai, mais ces choses peuvent être délicates. par exemple, l'affichage est commutable entre ˚F / ˚C, de sorte que la transmission pourrait être en ˚C ou ˚F absolu ou soit par rapport à un décalage étrange ou à une précision arbitraire en virgule fixe. aussi, il y a 3 identifiants de station commutables ("A", "B", "C") et même si cela dit que changer l'ID pourrait aider la réception, j'ai un pressentiment c'est juste un préfixe d'identification sur les messages - je vais changer et voir ce qui change sur les données.
Rob Starling

@RobStarling - Vous pouvez ouvrir l'unité émettrice pour voir si elle utilise un simple type de capteur de température tel qu'un LM75 ou l'un des autres types I2C courants. Si c'est le cas, il est probable que les données envoyées sur le lien en tant que valeur de température suivent simplement celles lues sur le dispositif de capteur de température. D'un autre côté, si l'expéditeur utilise un capteur analogique tel qu'une diode ou un transistor BJT comme capteur, il serait plus difficile de déduire les données réelles envoyées.
Michael Karas

Je soupçonne que la meilleure chance que vous ayez de comprendre le contenu des données est de placer l'expéditeur dans une situation contrôlée où vous pouvez changer la température lentement afin que vous puissiez voir la lecture changer un peu à la fois. Vous aurez l'écran du récepteur pour vous dire ce qui est réellement attendu.
Michael Karas

@MichaelKaras - il est difficile de voir ce qu'est le capteur - il est sur une petite planche coincée dans un petit support à la pointe, en pot dans une noisette de pâte thermique pour le coupler au mur extérieur sous l'eau.
Rob Starling

2

Presque tous les schémas de transmission RF devront avoir plusieurs caractéristiques dans leurs protocoles de codage des données. Cela comprendrait:

  1. Préambule au format cohérent utilisé pour verrouiller un récepteur sur la fréquence
  2. Un indicateur d'impulsion de synchronisation pour marquer le début si l'indication de trame
  3. Une méthode pour coder les données 1 et 0 avec une sorte d'horloge codée pour la récupération de données.

L'impulsion de balle impaire que vous avez notée est très certainement l'indicateur d'impulsion de synchronisation.

Le codage des données semble suivre ce que j'ai vu sous le nom de codage à largeur d'impulsion. Il s'agit d'une technique assez courante où la seule direction de transition suit une fréquence constante conduisant à des temps de cellule de bit de largeur constante. Pendant la cellule binaire, l'impulsion active est présentée comme 25% du temps de la cellule binaire ou 75% du temps de la cellule binaire. Ce schéma n'est pas un schéma de codage symétrique DC à impulsion comme les offres de codage de Manchester. C'est une technique courante avec le codage de largeur d'impulsion pour fournir un équilibre DC dans le protocole de message en envoyant des bits supplémentaires pour créer un équilibre global dans tout le message. Dans sa forme la plus simple, les données sont envoyées deux fois avec la deuxième copie inversée logiquement.

Dans votre exemple, il est étrange de voir des données modulées en largeur d'impulsion se produire avant l'impulsion de synchronisation. Cependant, c'est toujours un schéma réalisable si l'algorithme de décodage des données est conçu pour accepter les données reçues avec la synchronisation dans cette position. Il est possible que l'appareil envoie un type de données avant la synchronisation et un après. La répartition pourrait être entre l'adresse du capteur / données de température OU les données vraies / données inversées.

Éditer:

Il est intéressant de noter qu'il semble presque que l'émetteur utilise un algorithme logiciel différent pour formuler les largeurs d'impulsion positives pour les cellules de données avant le motif de synchronisation que pour la largeur d'impulsion au niveau et après le motif de synchronisation. Cela implique qu'il peut y avoir un morceau de logiciel distinct générant le modèle antérieur à celui de la partie suivante du modèle. Cette différence de modèle pourrait impliquer que la source de données dans chaque cas nécessitait une gestion différente en termes de la façon dont on y accédait bit par bit. La différence observée dans le chronogramme pourrait simplement être un timing d'instruction ou deux différences dans les boucles de génération de modèle.


je me demande si c'est: préambule (carré) + bit de départ (1) + id unique (12 bits) + impulsion de synchronisation + données. (oh, comme vous l'avez suggéré ... par exemple, il s'attend peut-être à ce que le µC se prépare pour les données pendant l'impulsion de synchronisation)
Rob Starling

2

J'ai commencé à décoder l'Acurite 617 et voici mes premières observations. Je peux vous dire que le dernier octet est une sorte d'octet de "vérification" et que les trois derniers octets contiennent la température. Ces octets sont également envoyés avec l'utilisation du 7e bit pour établir une parité paire et seul le quartet inférieur de chaque octet est utilisé. J'ai écrit un programme Arduino pour capturer les données et j'ai vu les messages / températures suivants.

40 ce c0 00 00 0c 03 be
(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

D'autres données / temps que j'ai vus sont:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

En utilisant cela, vous devriez pouvoir faire la conversion "en ligne droite" (hypothèse).

Comme je n'ai pas une bonne portée (et le fait que les données soient envoyées une fois par minute), je ne suis pas sûr de mon timing. Je vois la synchronisation HI et LO comme étant 720 usec et les bits de données étant 240 et 480 usec.

J'espère que j'aurai plus d'informations plus tard. J'en ai un tas. Dès qu'ils commencent à fuir, je les retire de la piscine et je les sèche pour les utiliser dans la maison. Les derniers modules 617 (avec le fond dévissé et le joint torique) semblent durer plus longtemps.


J'ai fait un peu plus de décodage. Le dernier octet (vérifier l'octet) rend le OU exclusif des huit octets égal à 0FFH. Par exemple pour "40 CE C0 00 00 8D 0C 30", 40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 est égal à 0FF.

De plus, j'ai abaissé la température à 34F et le nombre était de 10 décimales (i, e., 00 00 0A) et à 80F, le nombre était de 264 décimales (soit 81 00 88 ou 108H).

À partir de cela, j'utilise Temp (F) = 0,1811 * Count + 32,1889. Je pourrais obtenir une plus grande durée pour obtenir de meilleures données si je vois une erreur.

En regardant la chaîne de Rob Starling le 14/02/2016:

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

XOR = FF

Nombre = 0E4 ou 228

Temp = 73,5F


Merci les gars!!! Je suis à peu près sûr que le nombre n'est pas seulement un "compte", mais plutôt la température exacte à 0,1 ° C - c'est-à-dire que les "mathématiques" pour le décodage 228sont que c'est le cas 22.8C. Pour Farenheit, faites comme d'habitude F=C*9/5+32.
Rob Starling

résumé sur le Reverse Engineering SE: reverseengineering.stackexchange.com/a/13593/15076
Rob Starling

1
Rob, vous avez raison - j'aurais dû voir ça. F = 0,18 * Nombre + 32,0. Heureusement que vous l'avez fait remarquer, j'allais bientôt le mettre dans de l'eau chaude pour obtenir un meilleur "m" et "x" en utilisant une plage plus large.
Ken S

Vous voudrez peut-être toujours faire l'étalonnage pour obtenir des chiffres plus précis, car plusieurs critiques se sont plaints que l'affichage était éteint de quelques degrés. Cependant, cela pourrait également refléter le fait qu'il n'est qu'à ≈4 "sous la surface et que la plupart des thermomètres de piscine à l'ancienne sont sur une longue chaîne.
Rob Starling

Mise à jour: j'ai écrit une bibliothèque Arduino - github.com/robstarling/ArduRight - faites-moi savoir si cela fonctionne pour vous! Il a un exemple et tout. En faisant référence à l'image dans ce post, vous devrez souder les fils aux broches "SH", "D" et "G". Pour exécuter l'exemple d'esquisse, connectez ces fils aux broches 2, 7 et GND, respectivement.
Rob Starling
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.