Go Down

Topic: Interrupteurs domotique Blyss de castorama (Read 54824 times) previous topic - next topic

Artouste



(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 :smiley-zipper:

8)
Ha ba voilà  :smiley-mr-green:
Quand on m'explique bien , en règle générale je comprend assez vite  8)
Bien d'accord , il faut déjà acquérir et eplucher  les data envoyé en driver  de l'émetteur UHF (ou sortie du recepteur )  , avant de voir ensuite comment cela joue (eventuellement) sur la gestion de l'EEprom par le MCU.

J'ai vu que la telco avait plusieurs "boutons" , perso je ferais déjà des acquisitions de trame au niveau de l'entrée du module UHF (en ON/OFF) pour ensuite les comparer entre elles et voir ce qui est variant (et déjà bien verifier que le motif est identique pour une même action) .


skywodd


Ha ba voilà  :smiley-mr-green:
Quand on m'explique bien , en règle générale je comprend assez vite  8)

J'avais un peu tout mélangé désolé :smiley-sweat:


Bien d'accord , il faut déjà acquérir et eplucher  les data envoyé en driver  de l'émetteur UHF (ou sortie du recepteur )  , avant de voir ensuite comment cela joue (eventuellement) sur la gestion de l'EEprom par le MCU.

C'était surtout pour avoir idée de la taille des données qui pouvait transiter entre E / R.
Vu que j'imagine qu'il y a dans la trame RF une adresse, et un (ou plusieurs) octet de statut (on / off, ...)


J'ai vu que la telco avait plusieurs "boutons" , perso je ferais déjà des acquisitions de trame au niveau de l'entrée du module UHF (en ON/OFF) pour ensuite les comparer entre elles et voir ce qui est variant (et déjà bien verifier que le motif est identique pour une même action) .

Oui chef !
Voir piéces jointes chef ! :smiley-mr-green:

J'ai enregistrer la trame complète ON + OFF : ça permet déjà de voir qu'il faut 13 envois de la portion de données à chaque appui / relâchement pour être pris en compte.
J'ai aussi pris les trame séparément en basse définition pour avoir 2 portion de trame et en haute définition pour avoir une portion complète avec des timings précis.

On remarque que les deux trames ON et OFF sont identique sur le début puis différentes sur la fin.
A mon avis c'est entête + 4 bits de syncro + 5 octets d'adresse + 1 octets de statut On / Off ... maintenant comment décoder le tout ... mystère ...
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#17
Jun 14, 2012, 04:35 pm Last Edit: Jun 14, 2012, 04:39 pm by al1fch Reason: 1
Manchester ?  faut y regarder de plus près et pas s'emballer !
Je n'ai pas été loin dans la trame mais pour l'instant  je vois des fronts descendants à intervalle de temps régulier...
Si ça se confirme on serait en présence d'un banal codage basé sur la position du front montant.
le premier octet pouvant être 0x01 ou 0xFE
Je vais aller voir un peu plus loin dès que possible

skywodd


Manchester ?  faut y regarder de plus près et pas s'emballer !
Je n'ai pas été loin dans la trame mais pour l'instant  je vois des fronts descendants à intervalle de temps régulier...

Je vois du manchester partout de tout façon :smiley-sweat:
A force d'utiliser cette méthode partout je ne jure que par ça :smiley-zipper:


Si ça se confirme on serait en présence d'un banal codage basé sur la position du front montant.
le premier octet pouvant être 0x01 ou 0xFE
Je vais aller voir un peu plus loin dès que possible

Hoho C'est prometteur !
J'ai vu passer ces deux octets pendant le dump de l'eeprom !

Par contre ... je ne vois pas du tout comment fonctionne ton "banal codage basé sur la position du front montant" :smiley-sweat:
Une ch'tite explication m'sieur ? :smiley-mr-green:
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#19
Jun 14, 2012, 04:48 pm Last Edit: Jun 14, 2012, 04:53 pm by al1fch Reason: 1
rapport cyclique 1/3 ou 2/3 entre deux fronts descendants
on peut essayer de lire en se concentrant sur la durée des états bas
ça serait plus habituel en inversant les niveaux logiques.
Disons qu'on serait, si l'hypothèse se vérifie,  en PWM mais en logique négative

skywodd


rapport cyclique 1/3 ou 2/3 entre deux fronts descendants
on peut essayer de lire en se concentrant sur la durée des états bas
ça serait plus habituel en inversant les niveaux logiques.
Disons qu'on serait, si l'hypothèse se vérifie,  en PWM mais en logique négative

Ce qui pourrait collerai avec le fait que le µc ne comporte qu'un timer avec un générateur de PWM associé ...
Je vais regarder le datasheet voir si la broche d'émission du signal est celle permettant de faire de la PWM ou celle associé au timer.
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#21
Jun 14, 2012, 05:05 pm Last Edit: Jun 14, 2012, 05:07 pm by al1fch Reason: 1
Quand j'écrivais PWM c'était juste pour évoquer l'allure du signal, pas sa production.
si ça e trouve c'est codé en assembleur avec des boucles de temporisation.
Un petit µC 4 bits ferait même l'affaire côté emetteur !

skywodd


Quand j'écrivais PWM c'était juste pour évoquer l'allure du signal, pas sa production.
si ça e trouve c'est codé en assembleur avec des boucles de temporisation.
Un petit µC 4 bits ferait même l'affaire côté emetteur !

Bon bin ya effectivement de forte chance que ce soit basé sur des boucles + tempo ...
Pour ceux qui est du code c'est quasi sur c'est de l'assembleur ...
1Ko flash, 48o ram ... http://www.sonix.com.tw/sonix/product.do?p=SN8P2501B

Le brochage :
Bouton externe : P1.0
Bouton interne : P1.2 (bouton inutile ... il fait la même chose que le bouton externe)
Led de statut : P2.1 (semble clignoter au même rythme que la sortie RF)
Module RF : P2.2

Au passage c'est un peu mal foutu l'interrupteur externe est cablé sur une broche ne supportant pas le mode "wake up" donc le truc reste h24 en marche ...
En réveillant le CI juste au moment de l'appui ça permettrai d'économiser la batterie ... bref :smiley-mr-green:

Je retourne sous paint.net décodé tout ce petit monde suivant ton principe ^_^
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

skywodd

Bon en suivant ton principe je trouve :

Code: [Select]
0000 00011000 01101010 00001000 01111111 00100101 01101110

Ou en logique inversé :
Code: [Select]
1111 11100111 10010101 11110111 10000000 11011010 10010001
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#24
Jun 14, 2012, 05:50 pm Last Edit: Jun 14, 2012, 05:58 pm by al1fch Reason: 1
est tu sûr et certain que les 4 premiers bits sont une synchro ?

Si tu reportes les 4 bits 'excédentaires' à la fin (Checksum modulo 16 ?) tu peux arriver à trouver 0x01 et 0xFE dans trame_ON

En codage Manchester il faut une synchro pour la PLL qui, côté récepteur, reconstitue l'horloge indispensable au décodage. Içi plus besoin de synchro , juste un petit préambule pour amorcer la CAG du récepteur (on est en modulation d'amplitude ASK)

Exemple avec 6 octets + 4bits en fin et en considérant que le poids fort est envoyé en premier
(Si je savais réellement exploiter un tableur je pourrais être plus productif !... colonnes F et J !!!)

skywodd


est tu sûr et certain que les 4 premiers bits sont une synchro ?

Non ... en faite ... j'ai encore réfléchi en code manchester :smiley-sweat:


Si tu reportes les 4 bits 'excédentaires' à la fin (Checksum modulo 16 ?) tu peux arriver à trouver 0x01 et 0xFE dans trame_ON

Checksum mod 16 ... ce serait pas con vu qu'on travail en RF 433MHz, avec une forte probabilité d'interférences donc.
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

Artouste

Vous l'avez trouvé où le soft pour (re)lire les fichier .ols
j'ai fureté un peu mais rien trouvé de concluant

skywodd

#27
Jun 14, 2012, 07:20 pm Last Edit: Jun 14, 2012, 07:53 pm by skywodd Reason: 1

Vous l'avez trouvé où le soft pour (re)lire les fichier .ols
j'ai fureté un peu mais rien trouvé de concluant

C'est le client alternatif pour la carte OpenLogicSniffer :
http://www.lxtreme.nl/ols/

Bon sinon j'ai bien avancé ;)
J'ai un dump complet de l'eeprom : j'ai pas cherché à comprendre, j'ai désoudé la 24C02, j'ai fait mon dump, et je l'ai resoudé :smiley-mr-green:
J'ai aussi dump la trame "ON" de la télécommande, dont l'adresse est forcément dans le dump de l'eeprom.
Je fait les analyses de trames qui vont bien et je vous post le tout ;)

--

EDIT:

J'ai fait le dump de la trame RF de la télécommande avec un récepteur 433MHz donc il y a un peu de bruit avant la trame.
-> voir le fichier .olp vers ~96ms

En suivant la méthode al1fch j'obtiens :
Code: [Select]
00000001 11000110 11011110 01010111 11110110 01111000 1001
0x01          0xC6          0xDE          0x57          0xF6          0x78          0x09


Ou en logique inversé :
Code: [Select]
11111110 00111001 00100001 10101000 00001001 10000111 0110
0xFE           0x39          0x21          0xA8         0x09          0x87          0x06


Le dump de l'eeprom contenait ceci :
Code: [Select]
0x0F 0xE3 0x92 0x1A 0x80 0xFF 0xFF 0xFF 0x0F 0xE7
0x95 0xF7 0x80 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x03 0x00 0x00 0x55 0x80 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF


On peut y voir très clairement trois séries de 5 octets :
Code: [Select]
0x0F 0xE3 0x92 0x1A 0x80
0x0F 0xE7 0x95 0xF7 0x80
0x03 0x00 0x00 0x55 0x80


Traduit en binaire :
Code: [Select]

00001111 11100011 10010010 00011010 10000000
0x0F      0xE3      0x92      0x1A      0x80

00001111 11100111 10010101 11110111 10000000
0x0F      0xE7      0x95      0xF7      0x80

00000011 00000000 00000000 1010101 10000000
0x03      0x00      0x00      0x55      0x80


Voila voila ...

Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

barbudor

J'ai lu en vitesse
1) Je ne connais pas de moyen d'utiliser l'OLS en générateur et c'est bien dommage mais étonnant que ca n'existe pas

2) Pourquoi vouloir utiliser un decodage I2C ?
l'I2C est très spécifique avec ses notion de START, d'adresse comprenant le bit de read/write, ...

Je vais relire un peu mieux

Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

skywodd


J'ai lu en vitesse
1) Je ne connais pas de moyen d'utiliser l'OLS en générateur et c'est bien dommage mais étonnant que ca n'existe pas

Ça semble t'il déjà était demandé :
http://gadgetforge.gadgetfactory.net/gf/project/butterflylogic/tracker/?action=TrackerItemEdit&tracker_item_id=27


2) Pourquoi vouloir utiliser un decodage I2C ?
l'I2C est très spécifique avec ses notion de START, d'adresse comprenant le bit de read/write, ...

Ok ça fait un peu bordélique mon topic, mais en gros je capture des trames RF avec un récepteur 433MHz et la carte OLS.
Et en parallèle je capture l'activité du bus I2C du récepteur prise murale (qui possède un eeprom ou sont stocké les adresses des émetteurs associé).
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

Go Up