Nous venons de voir dans l'article précédent comment les 8 bits constituant le message allaient être envoyés, le tout maintenant est de les réceptionner correctement.

Nous savons que l'état haut se manifeste par une oscillation de la led infrarouge à 36kHz, et que pour réceptionner ce signal il existe un composant du nom de TSOP qui change d'état quand il reçoit une émission à une fréquence bien déterminée, dans notre cas nous utilisons un TSOP1836 qui change d'état s'il reçoit une émission infrarouge à 36kHz (à quelques pourcents près).

Nous allons donc avoir à la sortie du TSOP soit 1 soit 0 pendant des durées déterminées dans le protocole, il faut donc recevoir correctement les différents états, connaître leurs durées et les enregistrer. Pour cela nous utiliserons de nouveau un Pic 16f84. Ce dernier contrôlera dans notre application 4 sorties 220 Volt et 4 sorties analogique 0-10Volt (sur 8bits). (que nous analyserons plus tard)

Comment réceptionner correctement ?

La première étape est de recevoir le premier signal qui est d'une durée d'environ 1280µs, pour ça nous pourrions utiliser les interruptions du pic mais vu que nous n'avons pas à nous en faire au sujet de la consommation de la carte (car celle-ci sera branchée sur le secteur, donc pas de batterie à décharger), nous pouvons simplement utiliser une boucle qui ne s'interrompt que quand la broche sur laquelle la sortie du TSOP est branchée change d'état :

main
btfss PORTB, 0
goto rx
goto main

Quand celle-ci change d'état, le pic passe dans la procédure « rx ». A ce moment on doit s'assurer que le signal reçu est bien celui de départ. La procédure 1280µs va générer un temps légèrement plus court que celui de l'émetteur, le signal doit toujours être à l'état haut après cette période pour signifier que celui ci est bien le signal de départ.

rx
movlw h'08';
movwf boucle; le compteur qui va faire la boucle pour qu'on reçoive 8 bit
call pause1280; une pause de 1280µs
btfsc PORTB, 0; si le signal est déjà repassé a 0 c'est que c'est le mauvais,
goto main; mauvais signal!!!

Dans rx nous initialisons directement le registre boucle à 8… Celui-ci va permettre de compter les bits reçus…

Si le signal d'initialisation est correct, ça signifie que 8bits vont être envoyés. Nous allons donc attendre la fin du signal d'initialisation, afin d'obtenir le niveau 0 qui dure soit 640µs dans le cas d'envoie d'un 1, soit 1280µs dans le cas d'envoie d'un 0.

bouclerx
btfss PORTB, 0;
goto bouclerx; attendre que le signal repasse a 0
call pause640; attend 640µsec
rlf cle, 1;
btfss PORTB, 0; le signal est repassé a 1 après la pause de 640µsec
goto rx1;
bcf cle,0; le signal est toujours a 0;

rxend
call pause820;
btfsc PORTB, 0; le signal doit être a 1, sinon le signal est perdu
goto main; signal incorrect!!!
decfsz boucle, 1; boucle jusqu'a 8 bit reçu
goto bouclerx
goto analyse; les 8 bits sont réçu correctement, on va les analyser pour savoir ce qui faut faure

rx1
bsf cle, 0; 1 à été reçu, on met le bit a l'état haut
goto rxend;

Nous remarquons donc, que en premier lieu, il attend un temps légèrement supérieur à 640µs. Si le signal après cette pause est passé à 1 dans ce cas la, nous savons que le bit envoyé est 1 et nous le plaçons dans la variable « clé » qui enregistre les 8bits afin de reconstituer la clé. Si maintenant le signal est toujours à 0, c'est que le bit envoyé est 0… Une fois le bit enregistré dans la clé, nous attendons 820µs, comme nous le savons, il va y avoir une envoie pendant 640µs qui sépare l'émission de 2 bit, vu qu'il reste approximativement 640µs avant la fin de l'envoie des information relative au bit, si nous attendons 820µs, nous sommes sur de tomber pile dans la phase qui sépare l'émission de deux bits, et nous pouvons dire que sauf cas de problème, à ce moment là, le signal doit obligatoirement être 1, si c'est le cas contraire c'est que le signal est perdu, et nous annulons toutes les opérations en retournant dans la boucle main (boucle qui attend le signal d'initialisation) . Une fois les 8 bits envoyés, nous partons dans une procédure d'analyse qui va simplement faire une action en fonction de la valeur qu'aura pris le registre « clé », c'est-à-dire le message envoyé par la télécommande…

Pour résumer ça, un petit schéma vaut plus que toutes les explications du monde :