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":
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.
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:
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):
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
Réponses:
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.
la source
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.
la source
Presque tous les schémas de transmission RF devront avoir plusieurs caractéristiques dans leurs protocoles de codage des données. Cela comprendrait:
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.
la source
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
la source
228
sont que c'est le cas22.8C
. Pour Farenheit, faites comme d'habitudeF=C*9/5+32
.