Gestion de nouveaux protocoles, trames RFLink et firmware open source

Bonjour,

Le RFPlayer est un produit séduisant par bien des aspects : gestion des bandes 433 et 868 Mhz simultanément, détection de jamming, mode parrot permettant la gestion des protocoles les plus simples, répéteur, transcoder. C’est vraiment un produit complet.

Cependant, le nombre de protocoles gérés reste assez limité sachant qu’il existe visiblement une pléiade de protocoles plus ou moins exotiques utilisés par des produits bas de gamme notamment (écrans de vidéoprojecteur, lumières de piscine, etc). Beaucoup utilisent un rolling code ou un masque jetable et ne peuvent donc pas être géré par le mode parrot. Un grand nombre de ces protocoles sont apparemment gérés par des modules concurrents.

Les « trames RFLink » me semble, à tort ou à raison, permettre de faire du RFPlayer une sorte d’analyseur de trames RF. Cette fonctionnalité permettrait peut-être de pouvoir plus facilement faire du retro engineering de certains de ces protocoles, voir de les implémenter logiciellement (puisqu’il semble possible d’envoyer ces trames). Mais mes connaissances au sujet des protocoles RF sont limitées et la documentation concernant cette fonctionnalité n’est pas très claire.

Serait-il possible, de mettre, au moins, les bouts de code les moins documentés du firmware open source ? Pas forcément au sens que lui donne l’OSI, le code peut rester propriétaire tout en étant disponible et donc « ouvert ». L’idée n’est pas forcément que les gens puissent le recompiler et mettre à jour leur module avec leur code, mais plutôt qu’ils puissent comprendre comment cela fonctionne et proposer des fixes/améliorations et pourquoi pas pistes pour l’implémentation de nouveaux protocoles.

Après, je ne suis pas sûr, pour ma part, d’avoir ni les compétences, ni le temps nécessaire pour faire quoique ce soit de ce code mais je serais curieux d’essayer. Et surtout, je me dis que d’autres personnes pourraient, elles, faire des choses intéressantes avec.

Cordialement.

1 « J'aime »

Bonjour @Ping

Pour le moment publier une ou la totalité du code source n’est pas prévu.
Un code radio qui utilise un rolling code est quasiment incassable sauf si le constructeur décide de publier la clef. Ce sera donc compliqué de rajouter ce type de protocole.
Le protocole RF Link permet de découper un signal radio dans un format binaire. Il faut ensuite analyser ce signal, le comparer à une bibliothèque pour pouvoir le reconnaître et le reproduire. Ce travail de décryptage et d’analyse est impossible à faire dans le RF Player car cela demande trop de puissance.
Par contre n importe qui peut utiliser un RF Player pour transformer une trame radio en RF LINK puis travailler sur la partie décryptage et analyse des signaux RF Link. Il est ensuite tout à fait possible de créer des plugins pour intégrer cette partie codage/décodage RF LINK à des logiciels type HA ou Jeedom. Ces plugins pourraient du coup intégrer d’autres protocoles que ceux supportés nativement par le RF Player et etre enrichis au fur et à mesure.

Cordialement,

Bonjour,

C’est donc bien la vision que je pouvais avoir de cette fonctionnalité :slight_smile:.

Serait-il possible d’étoffer un peu plus la documentation RFLink ?
L’envoi de trame RFLink est peu documenté. Il est juste dit que le format de la trame est identique qu’en réception mais j’ai essayé d’envoyé le message reçu tel quel mais en activant les trace RFLINK et TRANSMITTER, je ne reçois aucune trace indiquant l’envoi du message. J’ai essayé de forgé moi même la trame (header ZI+SourceDestQualifier+Length+BinaryData de la trame RFLink) sans plus de succès. C’est sans doute un problème dans mon code mais sans confirmation dans la doc que c’est bien comme cela qu’il faut faire, ou que les traces d’envoi de trames RFLink sont bien implémentées, on se demande si on creuse dans la bonne direction.
On trouve des « tutos » ici et là de gens qui font du retro engineering de protocoles RF à l’aide d’un module RF, d’un arduino et d’un oscilloscope mais c’est difficile (pour moi) de faire le liens entre ce qu’il visualisent sur l’oscillo et la trame RFLink que je reçois (je pense avoir à peu près compris mais pareil, quand on est pas sûr faute d’une doc qui nous conforte dans notre idée, c’est pas simple de savoir si on part pas sur une voie sans issue). Un petit tuto pour les noobs pour expliquer plus en détail le contenu des trames RFLink, ce serait top.

Merci en tout cas pour votre réponse.
Cordialement

J’ai eu le temps de me remettre un peu dessus hier soir. En ce qui concerne les pulses des trames RFLink, il s’agit bien des temps des fronts (alternativement) montants et descendants d’un signal carré. J’ai pû analyser les signaux d’une télécommande RF, et il s’agit d’un signal issu d’une puce EV1527 (ce que j’ai pû confirmé en la démontant et en regardant le chipset). Il envoi 20bits d’un ID fixé aléatoirement en usine + 4bits de commande. Ce protocole devrait pouvoir fonctionner en mode parrot mais je ne m’explique pas pourquoi, l’apprentissage échoue.

Je pensait recevoir 48 « pulses » dans la trame (un front montant et un descendant par bit), mais j’en reçoit 49. J’aurais pu comprendre d’en avoir 50 (pour un bit de parité par exemple) mais le fait que ce nombre soit impair me rend perplexe. Cela dit, en ignorant ce front supplémentaire, je reçois bien des informations cohérentes (même ID quelque soit le bouton et un champ de bits correspondant au états de boutons).

Par contre, je n’ai pas réussi à émettre une trame RFLink (ou en tout cas, je ne vois rien qui indique l’envoi dans les traces (J’ai même fait un TRACE * pour être sûr). J’ai essayé de supprimer le 49ème front en me disant que le module vérifiait peut-être que le nombre soit pair, sans plus de succès.

Désolé, j’ai encore fait un mur de texte… Difficile d’être concis quand on parle d’un sujet un peu technique, mais j’espère que ça pourra servir à des personnes intéressé par le sujet.

Cordialement

2 « J'aime »

J’ai testé avec une télécommande équipée d’un chipset PT2262. Mon code qui tente de détecter l’EV1527 le reconnait comme tel et j’ai bien des données cohérentes, du coup, je ne vois pas trop la différence… Par contre, j’ai tenté des trucs pour envoyer la trame et malheureusement, je n’ai pas réussi. Il semble qu’il se passe quelque chose quand je l’envoi (diode rouge par exemple) mais il faut que j’envoi la trame 2 fois, et il semble que le traitement soit long ce qui me laisse pensé que la taille de la trame qu’il attend est supérieur à celle que j’envoie. J’ai essayé des bidouiller et j’ai réussi à avoir par exemple un clignotement rouge à chaque envoi. Du coup, je pense que quelque chose est envoyé mais rien dans les traces (pourtant activées avec TRACE *). C’est assez frustrant, je pense pas être très loin et si j’arrivais à envoyer ces trames, je pense que je pourrais commander mon écran de vidéoproj notamment…

@GCE, auriez-vous des réponses à ces questions :

  • Pouvez-vous me dire plus en détail comment forger une trame RFLink pour l’envoyer ?
  • L’envoi des trames RFLink est-elle bien tracée ?
  • Est-ce normal de recevoir 49 « pulses » pour une trame EV1527 ?
  • Les trames EV1527 ne semble pas pouvoir être apprise par le mode Parrot, est-ce normal ? (il n’y a pas de code tournant, on recoit bien le même pattern à chaque fois)

Cordialement