Bref, pour ceux qui sont un peu largu\u00e9s, voici le r\u00e9sum\u00e9<\/strong> de l’\u00e9pisode pr\u00e9c\u00e9dent<\/a> : en branchant un r\u00e9cepteur infrarouge \u00e0 un Arduino, j’ai pu commencer \u00e0 r\u00e9cup\u00e9rer les diff\u00e9rents codes envoy\u00e9s par la t\u00e9l\u00e9commande de ma clim r\u00e9versible. Les codes en question \u00e9taient reconnus en tant que protocole NEC, mais l’appui sur diff\u00e9rentes touches donnait toujours le m\u00eame code. Il y avait donc un truc qui cloche, et j’allais devoir me creuser le citron pour trouver ce que c’\u00e9tait…<\/p>\n Avant d’aller plus loin : cet article est assez technique. Toute lecture effectu\u00e9e cerveau d\u00e9branch\u00e9 en p\u00e9riode de cong\u00e9s se fait \u00e0 vos risques et p\u00e9rils. Donc, \u00e0 ce stade de l’aventure, je me pose quelques questions sur la fiabilit\u00e9 de la biblioth\u00e8que de d\u00e9codage de codes infrarouges\u00a0(lib IRremote<\/a> de Ken Shirriff) que j’ai r\u00e9cup\u00e9r\u00e9e. Celle-ci soutient que le protocole utilis\u00e9 par ma t\u00e9l\u00e9commande Airton est du NEC, alors que de toute \u00e9vidence \u00e7a ne peut pas \u00eatre du NEC. Afin d’en avoir le c\u0153ur net, je t\u00e2tonne<\/strong> en regardant ce que la sortie du programme affiche avec diff\u00e9rentes t\u00e9l\u00e9commandes. Le programme ne les reconnait pas toutes, mais il ne me sort pas forc\u00e9ment du NEC pour tout et n’importe quoi. J’obtiens un minimum de coh\u00e9rence lors de mes essais.<\/p>\n Essais par t\u00e2tonnement gr\u00e2ce aux diverses t\u00e9l\u00e9commandes \u00e0 ma disposition.<\/p><\/div>\n Laissons-nous un instant nous impr\u00e9gner par l’esprit de d\u00e9duction du grand Sherlock Holmes, l\u00e9g\u00e8rement imbib\u00e9 \u00e0 la coca\u00efne pour bien clarifier l’esprit : si le programme (en l\u2019occurrence la lib de d\u00e9codage) me soutient mordicus que ce que je lui envoie est du NEC, c’est parce qu’il croit<\/strong> que c’est du NEC. Magnifique d\u00e9monstration de ce qui saute aux yeux.<\/em> Il faut donc plonger \u00e0 l’int\u00e9rieur, comprendre comment il d\u00e9code les diff\u00e9rents signaux, et lui donner les moyens de diff\u00e9rencier mon protocole Airton du protocole NEC. En parall\u00e8le, un peu de culture g\u00e9n\u00e9rale sur les protocoles infrarouges<\/strong> (ci-joint : document PDF<\/a>) permet de mieux appr\u00e9hender les diff\u00e9rents concepts rencontr\u00e9s dans le code.<\/p>\n Puisque l’appui sur des touches diff\u00e9rentes de la t\u00e9l\u00e9commande donne le m\u00eame code selon le programme, c’est certainement parce que celui-ci arr\u00eate le d\u00e9codage<\/strong> du signal trop t\u00f4t. \u00c9l\u00e9mentaire, mon cher Watson.<\/em> Pour le protocole NEC, la limite est connue \u00e0 32 bits de donn\u00e9es. Mais pour Airton le nombre de bits \u00e0 d\u00e9coder est peut-\u00eatre plus important. Je modifie donc le programme pour continuer la d\u00e9tection sur du NEC m\u00eame si les 32 bits attendus ont d\u00e9j\u00e0 \u00e9t\u00e9 trouv\u00e9s. Et l\u00e0, c’est tout de suite probant ! Le programme me trouve toujours 32 bits pour une v\u00e9ritable t\u00e9l\u00e9commande NEC, mais 48 bits<\/strong> pour ma t\u00e9l\u00e9commande Airton. On peut donc commencer l’analyse en appuyant sur toutes les touches.<\/p>\n Le protocole Airton est maintenant clairement diff\u00e9renci\u00e9 du NEC.<\/p><\/div>\n Malheureusement l’analyse est de courte dur\u00e9e<\/strong>, car malgr\u00e9 les 48 bits affich\u00e9s, je trouve encore de nombreux boutons de ma t\u00e9l\u00e9commande qui affichent le m\u00eame code<\/strong>. Alors, tel l’extracteur devant pratiquer une inception, je plonge dans un niveau encore plus profond du code. Et je d\u00e9couvre que le coupable, c’est un buffer, qui est utilis\u00e9 tous protocoles confondus, dont la taille est trop faible<\/strong>. Ce buffer est capable d’enregistrer les dur\u00e9es relatives \u00e0 100 alternances de niveaux de tension hauts ou bas. M’\u00e9tant au pr\u00e9alable document\u00e9 sur les diff\u00e9rents protocoles IR, je sais qu’un bit est g\u00e9n\u00e9ralement cod\u00e9 par 2 niveaux de tension successifs dont les dur\u00e9es, ou dont la phase, diff\u00e8rent en fonction du bit \u00e0 transmettre. Par exemple, pour NEC, un appui sur une touche de la t\u00e9l\u00e9commande g\u00e9n\u00e8re un en-t\u00eate cod\u00e9 sur 2 niveaux de tension d’une dur\u00e9e sp\u00e9cifique, suivi de 32 bits, suivi d’un bit stop, ce qui donne 2+32*2+2 = 68 alternances<\/strong>, nombre inf\u00e9rieur aux 100 alternances enregistrables. Mais dans mon cas, avec un en-t\u00eate du m\u00eame type, suivi de 48 bits, plus un bit de stop, on obtient un total de 2+48*2+2 =100 pile<\/strong>, comme par hasard. Je suis donc arriv\u00e9 \u00e0 la limite du buffer et je dois augmenter celui-ci pour capturer plus de bits. Je d\u00e9cide de le passer arbitrairement \u00e0 300. La taille du buffer est donn\u00e9e par la constante RAWBUF dans IRremote.h.<\/p>\n Avec cette manipulation, j’arrive enfin \u00e0 un signal d\u00e9cod\u00e9 sur 120 bits<\/strong> (15 octets tout de m\u00eame), cod\u00e9 sur 244 alternances<\/strong>, ce qui reste inf\u00e9rieur \u00e0 ma nouvelle limite de 300 alternances capturables. Cette fois-ci, on peut reprendre l’analyse en appuyant sur toutes les touches de la t\u00e9l\u00e9commande et en relevant les codes affich\u00e9s. Je me rends compte au passage que, m\u00eame si cette fois-ci j’obtiens bien des codes diff\u00e9rents pour chaque bouton press\u00e9 ou fonction activ\u00e9e, je ne comprends pas la logique dans le codage de la temp\u00e9rature souhait\u00e9e. Et pour cause, le signal est envoy\u00e9 bit de poids faible d’abord (LSB first<\/strong>), comme pour NEC. En r\u00e9alit\u00e9, les deux protocoles ont de nombreuses similitudes, Airton s’\u00e9tant probablement fortement inspir\u00e9 de la structure du protocole NEC pour cr\u00e9er le sien. Un mode de transmission en LSB-first n’a donc rien d’\u00e9tonnant. Je rajoute alors, dans ma version de la lib, une fonction permettant de convertir les donn\u00e9es d\u00e9cod\u00e9es avec bit de poids fort d’abord (MSB first<\/strong>) lorsqu’il s’agit de les afficher ; car en bons humains occidentaux moyens que nous sommes, on a plus de facilit\u00e9 \u00e0 lire les nombres lorsque les dizaines sont indiqu\u00e9es avant les unit\u00e9s.<\/p>\n S’ensuit un appui sur toutes les touches de la t\u00e9l\u00e9commande, un dump complet des codes, un peu de r\u00e9flexion pour faire correspondre un ensemble de bits \u00e0 une fonction sp\u00e9cifique, et un petit cassage de t\u00eate sur le dernier octet qui ne correspond ni plus ni moins qu’\u00e0 un checksum<\/strong>. Mais c’est la partie amusante de l’activit\u00e9. J’arrive au final \u00e0 comprendre l’int\u00e9gralit\u00e9 de la structure des messages par r\u00e9tro-ing\u00e9nierie, que je consigne rigoureusement dans une documentation des plus carr\u00e9es, que j’ai h\u00e2te de pousser sur la toile. Seul ombre au tableau \u00e0 ce stade, je ne sais pas si un document obtenu par r\u00e9tro-ing\u00e9nierie du protocole dans un but d’interop\u00e9rabilit\u00e9 est l\u00e9galement diffusable. Je suis en train de me renseigner \u00e0 ce sujet, je diffuserai donc le pr\u00e9cieux document si j’en ai le droit dans un prochain article.<\/p>\n En attendant, ce que je peux diffuser sans probl\u00e8me, c’est l’adaptation de la biblioth\u00e8que IRremote<\/strong> qui est capable de reconnaitre le protocole Airton et d’en afficher les donn\u00e9es brutes. La biblioth\u00e8que est dispo dans la section t\u00e9l\u00e9chargements<\/a> (chercher \u00ab\u00a0Airton Receiver for Arduino\u00a0\u00bb). \u00c0 ce stade, j’estime l’avancement du projet \u00e0 environ 10%. C’est peu, il y a encore pas mal de boulot, mais avec un peu de chance certaines \u00e9tapes seront plus simples. Ou pas.<\/p>\n La prochaine \u00e9tape, pour moi, c’est maintenant l’\u00e9mission d’un signal par l’Arduino<\/strong>, afin de valider qu’il est correctement envoy\u00e9 et reconnu par le climatiseur. Pour cela, c’est tr\u00e8s simple : on rajoute simplement une LED IR au montage. Le concept est le suivant :<\/p>\n Mais le r\u00e9sultat de ce montage sera abord\u00e9 ult\u00e9rieurement.<\/p>\n Autrement dit, c\u2019est tout pour aujourd\u2019hui. Dans mon prochain article, je m’entrainerai \u00e0 Surgeon Simulator sur un meuble Ikea.<\/p>\n","protected":false},"excerpt":{"rendered":" Publier un article qui traite du pilotage automatique du chauffage en plein \u00e9t\u00e9, il fallait oser. Mais bon, \u00e0 mon rythme actuel de publication, le prochain article pourrait bien voir le jour en d\u00e9cembre \ud83d\ude41<\/p>\n \u00c0 vrai dire, le but de cet article \u00e9tant le pilotage automatis\u00e9 de ma climatisation r\u00e9versible<\/strong>, des avanc\u00e9es sur le sujet sont toujours les bienvenues, \u00e9t\u00e9 comme hiver.<\/p>\n Bref, pour ceux qui sont un peu largu\u00e9s, voici le r\u00e9sum\u00e9<\/strong> de l’\u00e9pisode pr\u00e9c\u00e9dent<\/a> : en branchant un r\u00e9cepteur infrarouge \u00e0 un Arduino, j’ai pu commencer \u00e0 r\u00e9cup\u00e9rer les diff\u00e9rents codes envoy\u00e9s par la t\u00e9l\u00e9commande de ma clim r\u00e9versible. Les codes en question \u00e9taient reconnus en tant que protocole NEC, mais l’appui sur diff\u00e9rentes touches donnait toujours le m\u00eame code. Il y avait donc un truc qui cloche, et j’allais devoir me creuser le citron pour trouver ce que c’\u00e9tait…<\/p>\n\t
\n<\/span><\/p>\n![\"Essais](\"http:\/\/cdn.alphak.net\/news\/wp-content\/uploads\/sites\/2\/2014\/07\/arduino-et-telecommandes-300x225.jpg\")
<\/a>![\"Le](\"http:\/\/cdn.alphak.net\/news\/wp-content\/uploads\/sites\/2\/2014\/07\/airton-protocol-decoding-attempt-300x250.png\")
<\/a>![\"ir-receiver-emitter-breadboard\"](\"http:\/\/cdn.alphak.net\/news\/wp-content\/uploads\/sites\/2\/2014\/07\/ir-receiver-emitter-breadboard.png\")
<\/p>\n![\"ir-receiver-emitter-schematics\"](\"http:\/\/cdn.alphak.net\/news\/wp-content\/uploads\/sites\/2\/2014\/07\/ir-receiver-emitter-schematics.png\")
<\/p>\n