Étape 2: Collecte de données
Hors nous allons.
Note1 : enregistrement de la commande est un processus répétitif et un peu ennuyeux, mais nécessaire.
Note 2: je ne possède pas un oscilloscope ainsi la seule façon pour mon pour tracer les valeurs enregistrées est d’utiliser un programme de traçage (gnuplot) sur les données brutes. Cela peut utile d’avoir une idée visuelle de ce qui se passe, mais elle nécessite certaines adaptations en données brutes et est à mon avis pas nécessaire du tout. Pour cette raison que je n’ai pas compris tout graphe.
J’ai utilisé les instructions de cette page : http://alexba.in/blog/2013/01/06/setting-up-lirc-... pour brancher le récepteur sur la facture pro forma et préparer lirc.
J’ai ensuite enregistré de commandes avec l’option - raw et rediriger la sortie vers un fichier. L’objectif est d’avoir un enregistrement de chaque valeur pour ON et hors cours, mais aussi pour chaque mode (AUTO, froid, chaleur, sèche), pour chaque valeur de swing et de fan et, disons, pour température min et max (16 à 30 ° C dans mon cas). L’élément important ici est de faire un enregistrement de référence et de faire un enregistrement pour chaque changement d’option, ne faire qu’une seule possibilité de changer à chaque fois. Une fois qu’un enregistrement est terminé, appuyez sur CTRL + C pour mettre fin à la commande et le faire encore avec la prochain commande/fichier
Il peut être nécessaire d’obtenir des privilèges super pour exécuter cette commande ("sudo mode2...") et le démon lirc peut bloquer le fichier, il est donc nécessaire de le tuer, tout d’abord :
En lisant les fichiers générés, ce que nous voyons, c’est tous les nombres, organisée en 6 colonnes. Ces chiffres indiquent la durée (en microsecondes). Les colonnes fonctionnent en paire, alors
signifie: « L’IR LED était ON pour 740us, puis OFF pour 1495us, puis ON pour 920us, puis OFF pour 1345us, etc. ».
Exemple :
OK, cela semble fou:)
Notez que le fichier commencera par une ligne avec une valeur unique : c’est le temps écoulé entre le début de l’enregistrement et l’arrivée du premier signal IR. Cette ligne doit être ignorée.
Bien sûr, comme ce sont des mesures, avec une échelle de temps aussi petite que la microseconde, tous les horaires sont différents, ce qui rend la détection de petites différences entre les 2 commandes impossibles.
On peut constater que les valeurs sont toujours proches de 400 ou 1300us, à l’exception de 3 (proche de 4400, 9900 et 1700). Donc ce que nous ferons pour rendre les chiffres comparables est « rond » les chiffres pour la plus proche de ces 2 valeurs « de référence » (une feuille de calcul est très pratique dans un premier temps).
Ce que cette manipulation montre, c’est que, sauf pour les 3 valeurs singulières ON temps est toujours 400us, ce qui change est seulement le temps d’arrêt.
Faisons l’hypothèse que le temps d’arrêt est codage 0 et 1 et supposons que 400us est 0 et 1300us pour 1. Avec cette hypothèse, il est possible de changer chaque paire de colonnes d’un seul bit.
Nous allons aussi faire une observation : la partie comprise entre les 3 « du singulier timings » est toujours la même, dans tous les enregistrements. Il peut être supposé que :
-la partie est une introduction, peut-être identifier la télécommande ou du climatiseur, et il ne changera jamais
-les minutages différents sont les serrures et les séparateurs entre l’introduction et la charge réelle
Il convient donc de prendre cette partie du message comme un invariant et ne pas de l’étudier.
Pour la facilité d’exploiter les données, j’ai écrit un petit programme c pour arrondir les valeurs et les transformer en chiffres binaires. Pour faciliter la lecture du code ignore la partie intro. Si vous souhaitez utiliser ce code, que les valeurs de minuterie sont définies au début du programme, vous aurez probablement besoin de l’adapter.
Après la compilation (gcc -o décoder decode.c) vous pouvez l’utiliser sur chaque fichier de données :
Exemple avec le mode auto cible température 25 ° C:
