maintenant que je baigne dedans depuis 48H je sais faire !!
si je peux t aider !!
il me faudrait la liste des codes touches et de l identité du device
sur les schemas qu on trouve souvent tx et rx sont inversé
si tu utilise ce schema je ne suis pas d accord ça correspond aux premiers modeles
la broche 2(jp1) correspond au reset D2(LPT)
la broche 4 (jp1) est RX TC mais TX coté LPT donc pour moi D1 (LPT) sur le plan
la broche 6 (jp1) est TX TC mais TX coté LPT donc pour moi D0/Busy (LPT) SDA sur le plan
la broche 3 (jp1) est la masse
la broche 1 (jp1) est le +5 +3.3 si tu n a pas de piles
C’est ce plan là que j’ai utilisé.
Je l’utilise pour l’URC3445 qui est JP1 « tout court », je pense que c’est un des premiers modèles (2005) et c’est juste pour faire un essai.
Tu penses que le plan n’est pas bon pour ce modèle ?
si peut etre le 1er mode jp1.1 concernait les modeles à eeprom i2c
maintenant tous les modeles sont type « flash » jp1.3/4…
du coup les programmes sont puissant je pense qu ils installent une routine suplementaire dans une zone
de la memoire flash du microproc intégré c est plus une usine à gaz mais un site industriel à gaz !!
L’URC3445 n’a qu’un seul chip (monté sans boitier directement sur le circuit imprimé et protégé par une couche de résine noire). A moins qu’il n’y ait 2 chips sous la résine mais ça serait surprenant car le circuit imprimé a aussi des pads pour souder un boitier QFP (quad flat pack) autour de la zone de résine noire.
c’est le cas de toutes les TC récentes
si la tienne est de type « flash » alors le montage ne convient pas ! par contre je n’ai trouvé nul part de schéma parallèle pour les version « flash »
bon moi j’ai constaté que ça ne marche pas avec des circuit ftdi232rl (certains ne sont même plus reconnu c’est des circuit pirates qui ont été mis à 0 par les drivers récents)
par contre avec un circuit cp2102 Silab ça marche …
chez RS il y en a , de même que des « vrais » FTDI 232rl , mais vu qu’ ils sont plus cher que les silab et dans le doute je m’abstiens !!!
PS est ce que l urc3345 fait partie de la liste ? je ne la trouve pas .
C est celle là ?
Hello,
Je ne sais pas si ça peut aider ou si vous avez déjà consulté ces données, mais voici un tableau actualisé des télécommandes compatibles JP1 : http://www.hifi-remote.com/wiki/index.php/RemoteChart
Bon courage !
l’objectif est de remplacer toutes les télécommandes infrarouges de la maison par un seul module infrarouge, qui recevra des ordres en bluetooth depuis un smartphone, pour piloter tous les appareils :
le module de réception bluetooth et émission infrarouge est très compact :
l’anarchie avec le schéma un appareil = une télécommande infrarouge :
la solution proposée, avec un module infrarouge qui intercepte les ordres d’un smartphone :
le module bluetooth est de type « Bluetooth Smart », qui consomme moins d’énergie, une pile bouton CR2032 suffit à l’alimenter pendant une longue durée,
certains ont ajouté des panneaux solaires pour rendre le dispositif auto-suffisant en matière de consommation d’énergie.
Ce projet s’inspire de la télécommande logitech harmony ultimate, qui utilise le même principe d’un hub bluetooth qui envoie les commandes infrarouges aux appareils, une télécommande vendue très cher (200 à 500 euros selon les boutiques) :
Intéressant intellectuellement mais le problème reste de trouver les codes de tous les appareils à commander (ce que fait IR protocol analyzer).
Des choses similaires ont été faites il y a plus de 15 ans avec des PDA sous Windows CE, directement à partie de l’émetteur infrarouge qu’ils contenaient (donc sans nécessiter de hardware supplémentaire) mais le succès a été plus que limité parce que l’ergonomie s’avère peu pratique à l’usage.
Ce que faisait aussi le Philips Pronto qui est passé de mode …
Bien sûr que si mais ce tableau est bordélique et je ne comprends pas pourquoi la liste des télécommandes dans la première colonne ne suit par un ordre alphanumérique simple …
On retrouve entre autres des listes d’URC-xyx à plusieurs endroits sans raison évidente …
L’auteur propose d’utiliser un nano-arduino avec une led pour récupérer les codes des télécommandes, pour ensuite les intégrer dans le programme du module bluetooth.
sur le site JP1 il y a en section fichiers des centaines de fichiers config de telecommande et c est un fichier texte
qu on peut ouvrir en notepad et recuperer les codes en notation hexa
Si je comprends bien ce fichier texte tu utilises le setup code 1367 de la Dreambox pour l’Octagon en modifiant ses paramètres (adresse NEC et codes touches) mais ce qui me surprend c’est que je ne vois pas l’adresse A05F dans ce texte.
Je vois bien 005F00 dans fixed data mais nulle part A0 …
D’autre part si je comprends bien la signification des codes de fonction (touches) je ne retrouve pas les mêmes valeurs hexa que tu m’avais indiquées pour les touches 1 et 2 notamment.
Pourrais-tu m’expliquer ces différences ?
Edit: je crois comprendre que A0 n’est pas nécessaire dans ce cas car 5F est en fait A0 avec les bits inversés. C’est une adresse sur 8 bits répètée avec les bits inversés, ce qui correspond au protocole NEC initial où il n’y avait que 256 adresses (l’adresse et le code touche étaient répétés avec les bits inversés pour maintenir une durée de message constante quel qu’en soit le contenu et pour une détection d’erreur éventuelle).
En effet étant donné que 1 et 0 n’ont pas la même durée il faut le même nombre de 0 et de 1 dans le message pour que sa durée soit constante.
C’est sans doute ce que le groupe « JP1 » appelle le protocole NEC1.
Par la suite beaucoup de fabricants se sont affranchis de cette durée de message constante, ce qui a permis d’étendre le champ d’adresse à 65536 valeurs en utilisant les 16 bits sans répétition inversée pour l’adresse.
Si mon hypothèse est juste alors l’adresse décodée par IR protocol analyser devrait être $5FA0 (24480d) et non $A05F, sauf si les bits 0 et 1 sont inversés comme semblent l’indiquer les codes touches.
En effet tu m’avais indiqué 90 pour la touche 1 et là c’est 6F, ce qui est la même valeur avec 0 et 1 inversés.
Idem pour la touche 2: 47 au lieu de B8.
Pourquoi faire simple quand on peut faire compliqué. :mrgreen:
Pour entrer une adresse quelconque sur 16 bits il doit falloir utiliser ce qu’ils appellent protocole NEC2, dans ce cas l’adresse complète devrait apparaître dans le texte descriptif.
cest a peu pres ça j ai mis 48h avant de comprendre la syntaxe de remote master
sur le forum jp1 Robman m a aidé
je te passe un fichier excel qui permet de calculer les valeurs pour la config et la valeur lue dans le fichier txt
pour le code touche la premiere etant toujours le complement de la 2eme certain se base sur la 1ere (moi) remote se base sur la 2eme …
dans le fichier texte les valeurs ne sont qu informative si tu les changent rien ne change dans la TC
il faut modifier device et sub device
si nec1 1ere generation (ou si id1 = complement de id2) mode simple
sinon on donne les 2 valeurs mais lue de droite à gauche (???)
Entretemps j’ai vu ta question à Rob et sa réponse qui m’a aussi permis de comprendre un peu mieux les paramètres des fichiers RMDU et j’ai téléchargé le fichier Excel de Rob afin de pouvoir utiliser ses formules de calcul.
Comme toi je l’ai étendu pour pouvoir l’appliquer à d’autres appareils en partant des infos fournies en décimal par IR protocol analyzer (pour l’adresse comme pour les codes touches).
Mais c’est tout de même assez tordu et je ne comprends pas trop l’intérêt de passer par l’intermédiaire de device et subdevice pour trouver FixedData…
En effet il apparaît que le premier octet est 00 si c’est une adresse sur 8 bits, le deuxième octet est le deuxième de l’adresse hex et le troisième le même avec les bits inversés.
Si c’est une adresse sur 16 bits le premier octet est 0x20, le 2ème est le deuxième octet de l’adresse hex et le 3ème est le premier.
La manière dont c’est calculé par RM n’est pas évidente et la signification de « ProtocolParms=5 null null 0 0 » non plus …
toutes ces « elucubrations » sont une presentation des valeurs mais en fait c est les quelques octets engendrés à la fin qui sont transmis par la liaison série .
onglet raw data ou output
Je viens d’essayer de créer un fichier RMDU pour le Cahors Veox ou Teox sur l’URC3445.
Dans l’onglet « fonctions » je ne comprends pas trop la signification des colonnes EFC et OBC avant le code touche …
Je suis surpris que « output » ne donne que 22 octets (je ne peux malheureusement pas tester le résultat avec RMIR faute du câble adéquat).
Voilà ce que j’obtiens. Qu’en penses-tu ?
tant que tu n a pas lu ta telecommande le fichier final n est pas construit et là tu a tous les octets
pour les cartes pas chere seule la mikroelektronica marche avec un ftdi232 mais il faut mettre une resistance de tirage au +5v sur rts (c est dis nul part !!) mikroe.com/usb-uart-board
par contre ce modele est un piege le pilote officiel efface l eeprom interne et il n est plus reconnu
toutes les cartes avec silab 2104 ou 2102 avec broche RTS marchent
En principe celle que j’ai commandé à un CP2102 et un connecteur 6 pins (donc avec RTS).
On devrait aussi pouvoir utiliser un port RS232 standard en limitant les niveaux à +3V / 0V au lieu de +12: -12 mais outre les niveaux la polarité n’est pas la bonne.
Il faudrait un MAX232 (mais je crois qu’il ne traite que TxD et RxD) ou un transistor inverseur sur chaque signal utile.
Il me semble que j’avais fait ça à une époque lointaine pour reflasher un récepteur Aston qui avait un port série à niveaux TTL.
Doctsf (Modèles & Marques)
Annonces
:mrgreen:
