CREATE Ceiling Fan Custom RF Controller

Objectif

J’ai équipé ma maison de plusieurs ventilateurs de plafond, dont deux dans le salon. Comme chaque ventilateur vient avec sa propre télécommande, j’ai eu envie de fabriquer une télécommande qui centraliserait leur gestion.

Capter les signaux

La Bonne fréquence

Note: Si la fréquence de communication entre la télécommande et le controleur du ventilateur est connue, cette étape est inutile.

La première chose à connaitre est la fréquence radio utilisée par la télécommande. Pour ce genre de télécommande, les fréquences habituellement utiliséées sont 315Mhz, 330Mhz et 433Mhz. Pour le déterminer, j’ai fait l’acquisition d’un récepteur USB RTL-SDR DVB-T (~30€). Il en existe des “officiels” (~80€) et des “copies” (~30€). Ce qui compte, c’est que l’appareil soit basé sur une puce RTL2832U et qu’il soit reconnu par l’ordinateur (d’où le “danger” d’acheter une copie). J’ai pris le risque d’acheter une copie sur Amazon.

Maintenant que je peux capter les ondes radio, il faut pouvoir les “voir”. J’ai utilisé le logiciel Spektrum mais il en existe d’autres (SigDigger, Air#, …).

Par défaut, le récepteur USB est détecté comme un “tuner TV” et, comme le stipule la documentation de Spektrum, il faut désactiver ce driver. Pour cela, il faut créer le fichier:

/etc/modprobe.d/rtl-sdr.conf

Et écrire dedans:

blacklist dvb_usb_rtl28xxu

br> Il faut aussi s’ajouter des droits en ajoutant une “udev rule” en créant le fichier:

/etc/udev/rules.d/20.rtlsdr.rules

Et en écrivant dedans:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666"

On peut vérifier que l’idVender et l’idProduct correspondent bien grâce à la commande:

lsusb

Qui donne:

Bus 007 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

Il ne reste plus qu’à ouvrir Spektrum, sélectionner le récepteur et modifier les paramètres du logiciel pour connaître la fréquence utilisée par la télécommande.

La plage de fréquence de base est vraiment trop large (24Mhz/1.8Ghz) car nous savons que ce genre de télécommande utilise des fréquences entre 300Mhz et 500Mhz. Il suffit de renseigner les champs (en Hz, ça fait vite beaucoup de zéros) en haut à gauche. Il ne faut pas oublier de cliquer sur “Set Range” pour que les valeurs soient prises en compte.

Lorsque l’on appuie sur un bouton de la télécommande, on voit alors la courbe jaune qui fait un pic. C’est là que se situe la fréquence que nous recherchons. Il ne reste plus qu’à modifier les valeurs pour s’approcher au plus près.

Pour être vraiment précis (ce qui n’est pas fondamentalement utile), on peut se servir de la fonction “Max” située dans l’onglet “Measure”.

Ainsi, j’ai pu déterminer que la télécommande et le controleur du ventilateur communiquent sur la fréquence 433.9Mhz. Spektrum - Plage de fréquences Spektrum - Fonction “Max”

Intercepter les codes

Je sais maintenant que je dois travailler avec la fréquence de 433.9Mhz. Pour obtenir les codes envoyés au controleur du ventilateur, il existe plusieurs méthodes. br> J’ai commencé par continuer à me servir du récepteur USB en conjonction avec un logiciel de traitement du signal (surtout “urh”) mais je ne suis arrivé à rien. br>

Cela m’a tout de même permis de confirmer que les communications s’effectuent en ASK (Amplitude Shift Keying), plus précisemment en OOK (On-Off Keying). Ce n’était pas une grosse surprise, les tutos que j’ai lus étaient tous basés là-dessus. Je me suis alors tourné vers des bibliothèques “pour Arduino” car je possèdais déjà des modules recépteur/émetteur en 433.9Mhz (ouais, la chance ! bon, je les aurais commandés de toutes façons). Après en avoir testés plusieurs (OneWire, RadioHead, etc.), je me suis arrêté sur RCSwitch.

Justement RCSwitch ne fonctionne qu’en OOK et permet de configurer des “protocoles”. La bibliothèque vient avec une dizaine de protocoles pré-définis mais aucun ne semblait correspondre à ma télécommande. Il a donc fallu découvrir le protocole utilisé. Heureusement, RCSwitch met à disposition un sketch (un script Arduino) qui écoute et enregistre le signaux radio envoyés pendant quelques secondes ainsi qu’un script PHP qui analyse ces données pour afficher une visualisation.

Spektrum - Montage Arduino avec récepteur radio

Pour la seconde étape, une fois le sketch envoyé et lancé, il faut ouvrir le “Serial Monitor” du Arduino IDE. Il faut bien penser à le configurer en 9600 baud. Le sketch fonctionne en “one shot”, il lance un décompte pendant lequel il faut appuyer (et rester appuyé) sur un bouton de la télécommande. Si on faut recommencer, il faut reset l’Arduino. Si le sketch capte bien les signaux, alors il va afficher dans le “Serial Monitor” une suite de nombres séparés par des virgule. Il faut copier ces nombres et les coller dans le convertisseur/afficheur (la page PHP).

Note: La seconde fois que j’ai voulu utiliser la page PHP directement sur le site de RCSwitch, aucune image ne pouvait être générée, j’ai dû faire tourner le site en local.

Avant de soumettre les nombres, en appuyant sur “Submit Query”, il faut nettoyer la fin du “copier/coller” en supprimant le retour à la ligne ainsi que la dernière virgule. Serial Monitor avec les valeurs captées Affichage des signaux

Analyser les signaux

À partir de là, j’ai des nombres et une belle image mais je n’ai encore rien à indiquer à la bibliothèque pour définir le protocole. Heureusement, RCSwitch indique une méthode pour analyser les nombres.

Documentation pour analyser les nombres

Les nombres ne sont pas générés au hasard. Ils correspondent au temps qui sépare un changement d’amplitude ; dis autremenet, la durée entre un état haut et un état bas. Dans notre cas de modulation (OOK), un état (haut ou bas) peut rester un certain temps mais il y a une durée minimale. C’est cette durée minimale qui permet de découper les modulations en valeurs. Par exemple, un état haut qui dure 3 “durée minimale” indique que le signal vient de transmettre 3 “1”. On comprend alors que déterminer cette durée minimale est déterminant. Notre suite de nombres contient des groupes de valeurs plus ou moins proches. Par exemple, dans mon cas, j’ai 3 groupes:

En faisant la moyenne des valeurs du groupe contenant les plus petites valeurs, j’obtiens 250. Il s’agit de la durée minimale. Je peux maintenant déduire les autres paramètres du protocole. D’ailleurs que faut-il pour le protocole ?

C’est là que l’image générée par le site PHP devient utile. On peut identifier des motifs pour déterminer le signal de synchronisation, le signal du 0 et le signal du 1. Il faut savoir qu’un signal commence toujours par un état haut (c’est important ça !). Le signal de synchronisation est un signal long qui permet de séparer 2 “mots” (un ensemble de plusieurs signaux 1 et 0). On peut déterminer la longueur du signal de synchronisation en divisant la moyenne des valeurs du groupe contenant les plus grandes valeurs par la durée minimale. Toujours dans mon cas, ~7980/250 ~= 32. Je cherche donc un motif qui commence par un état haut et dure 32 durée minimale. Dans l’image, je vois que ce motif est constitué d’un état haut d’une seule durée minimale suivie d’un état bas qui dure 31 durée minimale. Les signaux 0 et 1 sont les motifs les plus fréquents et sont relativements faciles à identifier. Dans mon cas, ils durent 4 durée minimales. Le 0 est constitué d’un état haut d'1 durée minimale suivie d’un état bas de 3 durée minimale. Le 1 est constitué d’un état haut de 3 durée minimale suivie d’un état bas d'1 durée minimale.

Analyse des signaux

Et donc mon protocole peut se paramétrer comme ceci:

Déchiffrer les codes

J’ai le protocole et la visualisation des signaux. D’après RCSwitch, il est possible de soit modifier la bibliothèque soit ajouter un nouveau protocole “à chaud” afin de laisser la bibliothèque déchiffres les codes mais je n’ai pas réussi à faire fonctionner cette solution ; la bibliothèque n’associe jamais le signal au protocole que j’ajoute (que ça soit en modifiant la bibliothèque ou en le donnant “à chaud”). Je me suis donc servi de la visualisation des signaux.

Décodage

J’ai décodé un premier message ! Je peux constater qu’il est constitué de 32 bits (c’est bon signe). On remarquera que je n’ai pas pris en compte le dernier état haut car il correspond au début du signal de synchronisation, m’indiquant au passage que le “mot” est terminé. Il ne reste plus qu’à faire cela pour tous les boutons de la télécommande !

Réferences