al1fch:
Le décodage Manchester me parait être la voie la plus efficace.
On perd vite le fil en faisant ce décodage à la main...
Je suis justement en train de décoder la trame ... mais je suis fasse à un probléme ... un gros probléme !
J'ai fait quelques statistiques sur les durées des temps haut / temps bas :
Temps haut : 812us en moyenne
Temps bas : 410us en moyenne
Problème n°1: Il ya de relativement grosses variations dans les temps haut / temps bas au cours de l'émission de la trame !
On peut quand même dire sans trop s'avancer que la fréquence porteuse à une période de 400us soit 2500Hz.
Problème n°2 : Après un petit tour sur Codage Manchester — Wikipédia
J'ai découvert qu'il 'était impossible de décoder en code manchester la trame en question ...
(T = 400us, 2T = 800us)
Au début on as 0:T 1:2T 0:T 1:2T ...
L'encodage manchester spécifie qu'il doit y avoir absolument un changement d'état durant une portion de temps T
Si on découpe en morceau de longueur T cela donne :
0 11 0 11
Ensuite (normalement) c'est tout con pour avoir les bits d'origine :
- on groupe par lot de 2 bits
- si c'est 10 -> 1, si c'est 01 -> 0 (ou l'inverse suivant la logique utilisé)
Donc :
01 10 11 -> 0 1 ... probléme 11 est tout simplement impossible en manchester ?
Du coup je vois pas comment faire .. Une possible erreur de ma pars ? Trame de codage inconnu ? ... ?
al1fch:
Un petit soft de décodage travaillant sur PC en aval d'OLS pourrait booster la recherche.
Le top : un plugin Manchester pour OLS avec l'aide d'un connaisseur de java !!
Je sait coder en java mais de là à faire un plugin OLS c'est hors de ma porté.
Par contre je sait utiliser un tableur 
J'ai fait un petit truc de décodage (voir pièce jointe)
al1fch:
Après un petit nettoyage manuel de mon blyss.vcd (recherche et remplacement) j'en ai fait un blyss.csv
Je n'ai pas eu le temps de trouver la bonne macro sous tableur.....
Tu fera attention j'ai l'impression que tu as décalé tes valeurs de un bits au début 
Artouste:
Là je ne te suis pas (ou je n'ai pas bien compris ce que tu exprime 8) )
Tu part du principe que le motif (la trame) de transmission appliqué à l'emetteur (et reçu par le recepteur)
et un simple "copié collé" d'une trame I2C juste conditionnée/reconditionnée ? , que l’émetteur UHF (du bouton) et le récepteur (la prise) ne transmettent que de la trame "standardisée" I2C ( avec diminution de débit ) ?Perso , je ne le pense pas , les MCU embarqués (bouton, prise) ont surement d'autres fonctions que la seule de simplement remettre en forme/vitesse une trame I2C emise/reçue en RAW.
Arf je crois que t'as pas compris
Ma carte bus pirate embarque un sniffer I2C relativement sommaire, qui marche jusqu'à ~100KHz ... en théorie.
En pratique c'est trés variable, il suffit que le µc fasse de l'i2c software et que les timings soit pas tiptop pour que le sniffer se plante.
Ce qui me conforte dans l'idée de l'i2c software c'est tout simplement que le datasheet du sonic machin truc ... dit que celui ne possède aucun périphériques de communication !
De plus le fait que l'analyseur de trames de OLS ne puisse pas décoder la trame en I2C laisse vraiment penser que celle ci est plus que bancale niveau timing ...
(Je parle bien de la trame sniffé sur la partie réceptrice, entre le µc et l'eeprom, pas de la trame RF envoyé via le module 433MHz)
Donc en gros on ne peut pas se baser sur les données du bus I2C ... il faut réussir par un moyen quelconque à décoder la trame RF puis regarder si les info quelle contient auraient un rapport avec les brides de données sniffé sur le bus I2C ...
De belle heures de prises de tête en perspective 
blyss.ods (19.4 KB)