Duplication signal IR paterne précis

[Revan]

Bonjour!

Je possède plusieurs bracelets jouets avec 2 modes, l'un mode jouet, l'autre mode jeu:

Le mode jouet envoie un signal simple de tir à un autre jouet avec des points de vie. Le signal en question lui fait perdre 1 point de vie. J'ai réussi à dupliquer ce signal simplement à l'aide d'une télécommande universelle.

Le mode jeu quant à lui émet un signal infrarouge qui, lorsqu'il est capté par le jeu, donne un bonus particulier lié à l'accessoire en question, sachant que chaque accessoire a son signal.

Après avoir observé le signal IR des bracelets avec une caméra, j'ai remarqué une sorte de paterne du genre : l'un fait 2 clignotements, pause 1 clignotement et un autre va faire 3 clignotements rapides sans pause. Cependant, lorsque j'ai tenté de dupliquer ce signal avec la télécommande, celui-ci n'est pas reconnu dans le jeu.

Ma question est la suivante : est-il possible que le signal doive être copié et exécuté avec le même paterne et d'autres données pour qu'il soit reconnu? Si oui, comment copier un signal IR et le restituer avec précision exactement comme la source d'origine?

D'avance merci pour votre lecture
-----

[jiherve]

bonsoir
si c'est codé il faut utiliser un récepteur IR TSOP et un oscilloscope pour le décoder, le fait qu'une télécommande universelle ai pu dupliquer le premier signal indique que c'est de l'IR modulé à 38..40 kHz mais que les autres codes sont inconnus pour elle.
Il existe plein de protocoles differents.
JR

[Pascal071]

Bonjour

Le signal doit être analysé avec un oscilloscope, la séquence "allumé" contient certainement du Data, la caméra n'est pas assez rapide.

cordialement

edit: Jiherve: en même temps.

[Murayama]

Bonjour!

Il existe plein de protocoles differents.

Pas tant que ça pour l'IR. On peut partir du fait que ce système utilise un protocole
"standard". On peut faire varier:
- Le nombre de bits d'une trame
- La façon de coder un 0 et un 1
- La présence ou l'absence d'un préfixe et / ou suffixe.

Ce qui fait que la trame peut toujours se résumer par:

[Prefixe] - [0|1] x n [Suffixe]

Comme la fréquence est très faible (ne pas oublier que c'est une porteuse de l'ordre
de 40 kHz), on peut tout gérer avec un µP qui tourne à très basse fréquence. Un compteur
qui compte à 32 kHz est largement suffisant.

Pour le codage d'un bit, il y a 2 versions.
bit 0 court, bit 1 long ou le contraire. Je ne me souviens plus des valeurs, mais disons
qu'un délai court pourrait être par exemple 10 ms et un délai long 30.

Le préfixe et le suffixe (quand il y en a) sont beaucoup plus longs.

Alors évidemment, quand on compte les combinaisons entre les
divers paramètres cités plus haut, on peut avoir une kyrielle de protocoles
différents, mais je vois ça comme de simples variantes d'un unique protocole.

Pascal

[A voir en vidéo sur Futura]

[jiherve]

bonsoir,
oh que si il y a plein de protocoles car en plus de ce que tu cites :
le nombre de bits est variable
la sécurisation est souvent assurée par une redondance par émission de la valeur inversée (mais pas toujours tous les bits)
etc etc
j'ai bricolé un démodulateur qui donne la valeur brute du flux sur un maximum de 32 bits et c'est la fête surtout avec les jouets.
il faut donc un TSOP en réception et un bon scope numerique
JR

[Murayama]

Bonjour!

oh que si il y a plein de protocoles car en plus de ce que tu cites :
le nombre de bits est variable

Oui, je crois bien l'avoir écrit ci-dessus. C'est en effet un des paramètres
du protocole IR, les autres étant la présence ou l'absence d'un préfixe et d'un
suffixe, et la "polarité" des bits (i.e. si l'impulsion large signifie 1 ou 0).
Un peu come les paramètres PHASE et POL pour le bus SPI.

Le fait qu'il y ait ou non une partie du signal utilisé pour vérification n'entre
pas en ligne de compte. On aura toujours:
[préfixe] [n bits de données] [suffixe]
Les n bits de données peuvent inclure un mécanisme de sécurisation, CRC ou autre.

Exemple: on va prendre 32 bits. Préfixe et suffixe, on s'en fout, ce sont des balises
qui ne contiennent pas d'information, ça ne change rien.
Méthode 1: 1 code de 16 bits envoyés suivi de son inverse.
Méthode 2: 1 code de 32 bits.

Méthode 1
Admettons que le fabricant choisisse un certain nombre de codes en 16 bits. Disons 64
codes(*). 64, c'est 2^6. Un exemple pourrait être 0xABCD. Donc un code pris au hasard
dans 2^16 codes théoriquement possibles aura une chance sur 1000 (enfin 1024) de
coïncider avec un code existant dans la télécommande, 0xABCD pour reprendre le même
exemple.

(*) J'ai devant moi une vieille télécommande de télé avec DVD, etc... 56 touches.
J'ai arrondi à la puissance de 2 supérieure.

Ensuite, si le code est pris au hasard dans un ensemble à 32 bits, commençant par ce
nombre de 16 bits, il faudra aussi tenir en compte de la probabilité que la partie
inversée soit réellement l'inverse de la premiere partie. Toujours avec le même exemple,
ce serait sauf erreur, 0xABCD5432. En combinant la probabilité que le début du code
reçu soit dans les 64 codes possibles avec la probabilité que la fin du code soit exactement
l'inverse binaire de la première partie, on a:
2^6 / 2^16. // probabilité qu'un code de 32 bits quelconque ait le même début (ex: 0xABCDxxxx)
1/2^16. // Probabilité pour que le même nombre de 32 bits finisse par 0x5432.
Ce qui nous fait 1/2^26.

Méthode 2
Admettons maintenant que le bricoleur (moi par exemple) ne remarque pas que tous
les codes valides sont en 2 parties, et qu'il les considère comme des valeurs 32 bits.
Il y aura donc parmi 2^32 codes possibles 2^6 codes qui correspondent à ce que le
récepteur sait interpréter. Là aussi, on aura un taux de dilution des codes interprétables
qui sera de 2^6 / 2^32, soit 2^-26 ou encore 1/2^26, exactement comme ci-dessus.

Bref, la "sécurisation" ne sert à rien puisque les codes sont déjà extrêmement
dilués. En choisissant tous les codes pour qu'ils aient 2 à 2 une distance de Hamming de,
disons 10 bits, on peut en plus donner une certaine tolérance à la réception.
La sécurisation sert quand on a une connexion comme celles que nous utilisons
chaque jour, où il n'y a aucun code non-utilisé. Dans ce cas, on ajoute de la redondance.
Mais de la redondance plus chiadée. Par exemple CRC. Si un seul bit du nombre à sécuriser
change, tous les bits de la CRC vont potentiellement changer.

Conclusion:
Le fait d'envoyer un code en 2 parties n'a aucune influence sur l'efficacité ni sur
la sécurisation d'une zapette. Une CRC ou un autre mécanisme de vérification ne
changerait rien. On peut donc considérer tous les codes IR comme des nombres
dilués dans le nombre total de bits et le fait qu'une partie soit ou non une donnée
de vérification quelconque ne change rien, ce qui fait qu'il n'existe qu'un seul protocole
de zapette, dont les caractéristiques sont paramétrables.

Pascal

[jiherve]

bonjour
comme il n'existe que 26 lettres dans l'alphabet latin dont l'ordre est paramétrable !
Ton analyse est pertinente au niveau théorique mais d'un point de vue pratique cela n'aide pas beaucoup, si le bricoleur part à l'aveuglette il a moins de chance de trouver le bon code que de gagner au loto.
Donc récepteur basique et scope !!!!
JR

[Revan]

Bonsoir et merci à tous pour vos retours!

Est-ce que c'est obligatoire de le décoder ? N'est t'il pas possible de juste capter le signal en brut tel qu'il est pour le restituer exactement de la même façon?

Qu'est ce qui fait que lorsque la télécommande capte le signal du bracelet en mode jeu celui-ci ne le restitue pas de façon reconnaissable alors que l'autre qui envois une impulsion plus simple (je pense) en mode jouet lui c'est ok?

Merci encore pour vos réponses

[jiherve]

bonjour
non ce n'est pas si simple, à ma connaissance les zapettes dites universelles s'attendent à un type de codage et ne sauront le reproduire que si celui ci est déjà prévu dans leur logiciel.
JR

[Murayama]

Bonjour!

non ce n'est pas si simple

En fait, le problème n'est pas que ce soit compliqué, mais c'est surtout que cela
prendrait énormément de ressources pour rien.

Exemple:
1. "enregistrement" du codage brut.
On va dire pour simplifier qu'on reçoit / envoie un seul byte, par exemple 69, qui
s'écrit en binaire 0x45.
Comme une télécommande a un préfixe, par exemple 50 ms, ainsi que le suffixe, on peut
créer 2 tableaux comme suit, qui contiennent les valeurs en ms.

uint8 high[FRAME_LEN]; // Tableau des durées hautes
uint8 low[FRAME_LEN]; // Tableau des durées basses

Supposons que les paramètres de configuration du protocole soient:
- préfixe 50 ms
- valeur haute fixe 10 ms
- valeur basse codeuse. 0 = 20 ms, 1 = 30 ms
- Suffixe 75 ms

high        low            69
--------------------------
50            10            0
10            30            1
10            10            0
10            10            0
10            10            0
10            30            1
10            10            0
10            30            1
75            timeout (FF)

Par contre, si vous "enregistrez" le code 69 de manière asynchrone, comme dans le cas
d'une télécommande, vous aurez plutôt quelque chose comme ça:

high        low            69
--------------------------
51            10            0
11            29            1
9              10            0
10            11            0
11            10            0
9              31            1
10            10            0
10            30            1
74            timeout (FF)

Le timeout FF ne sert à rien en tant que nombre mais indique les fins de trame
(et non pas les trains de femmes).

Pour gérer le fait que les nombres ne tombent pas pile, il faut faire une fonction

uint8 egal_a_un_poil_pres(a, b, poil);

qui retourne 1 si (b - poil) < a < (b + poil) et 0 dans le cas contraire en faisant bien
attention que le poil ne soit pas plus grand que b, sinon (b - poil) nous fout dans les
ronces. Pareil si (b + poil) > 255. Enfin je vous dis ça, mais vous êtes de grands garçons,
vous le savez certainement.

Donc pour stocker un code de 1 byte, il vous faudra 18 bytes. Pour rejouer ce
code sur la sortie, il faudra ligne par ligne émettre 51ms, faire une pause de de 10 ms,
émettre 11 ms, faire une pause de 29 ms, etc...
Exemple concret: pour stocker tous les codes 32 bits d'une télécommande, il faudrait
pour chaque commande 2b+2 (b = nombre de bits), donc 66 bytes par code. Comme une
télécommande peut avoir dans les 50 touches ou plus, il faut au bas mot 3 kBytes de
mémoire sans compter la mémoire programme. C'est beaucoup pour une zapette.
Si vous voulez stocker une trentaine de télécommandes comme je l'ai fait, ce n'est plus
gérable sans flash externe ou EEPROM.

Ce n'est donc pas infaisable, mais c'est vraiment une méthode "bourrin" imprécise,
inefficace, etc. En plus, quand vous avez acquis le tableau, le décodage est tellement
simple que ça ne vaut pas le coup de s'en priver. Et émettre le code 69 (01000101) est
très simple: prendre le bit qui vient, si c'est 0, émettre la longueur correspondant
à 0, et inversement pour le 1, décaler, recommencer jusqu'au dernier bit.

Je me suis fait il y a très longtemps une zapette universelle, avec un petit LCD de
Nokia 3300 à l'époque. Elle permettait d'ajouter une télécommande avec des menus.
Premierement nommer la télécommande, par exemple AirCon Salon (ici, on dit air con
pour air conditionné. J'ai l'air con chez moi comme partout ailleurs). Et ensuite,
des instructions: presser sur la touche + / -, des messages d'erreur: code incomplet,
retour sur presser la touche +, etc, sauver ...
Ensuite à l'utilisation, choisir l'appareil à commander: AirCon salon, téloche, chasse
d'eau (véridique, les toilettes ont des télécommandes ici), magnétoscope (à l'époque,
il y en avait encore) etc.

Dans ce projet, les tableaux ci-dessus existaient, mais uniquement en RAM le temps
de détecter le type de télécommande puis de décoder. Le tout écrit sur un MSP430F169.

D'ailleurs c'est un super projet pour quelqu'un qui voudrait apprendre.

Pascal