Ingénierie inverse

Fil des billets - Fil des commentaires

Jeudi, mai 19 2011

Hacking d'un écran à Led de DealExtreme

Led matrix

Je reviens à la charge avec un joujou récupéré sur le site http://www.dealextreme.com/ avec, cette fois ci, non pas un régulateur à découpage pas chèr mais un afficheur à led pas chér (~ 8€) vendu sous l'appelation « Programmable Scrolling LED Name/Message/Advertising Tag Card Badge », intéressant, la description de l'article nous apprend également qu'il possède une connection USB, chouette, je le vois parfaitement bien sur la face avant de mon serveur pour indiquer des infos comme la charge du système, l'espace disque restant, etc...

Omar m'a hacker

Malheureusement, déception : la connectique USB est propriétaire et bien évidemment, le cable n'est pas fourni, l'envie m'est alors rapidement venue d'ouvrir la bête pour y souder un connecteur standard et là, ce fût la seconde mauvaise surprise, la prise n'est reliée à ... rien. Alors, bien évidemment, on peut programmer cet écran à l'aide des boutons situés sur son dos mais ce n'est franchement pas pratique pour en faire quelque chose d'automatisé...

L'écran est piloté par un unique micro-controleur d'Atmel, un AtMega88, de la même famille que les Arduino, il est donc assez aisé de développer un micro-logiciel libre.

J'ai donc fait une petite séance de reverse engineering, ingénierie inverse en bon français afin de comprendre comment fonctionnait cet écran et j'ai ensuite développer un micro-logiciel de remplacement permettant de piloter l'écran facilement directement avec une interface série.

Dans la vidéo ci-dessous, l'écran est simplement relié à l'ordi par le biais d'un convertisseur série / USB 3V, on y voit un des 2 modes de pilotage de l'écran en action qui permet à l'aide de menu de venir le paramétrer simplement, un autre mode est aussi disponible et est parfaitement adapté à la commande automatisée par le biais de script bash ou autre...

Vous trouverez TOUT en détail sur le fonctionnement de cet écran sur le lien suivant LedMatrix hacking sur le wiki, voici le sommaire de cette page :

LedMatrix hacking
    Introduction
    Ouverture du boitier
    Comment ça marche ?
        Vue globale
        Le coeur
        Interface de programmation
        L'interface USB
        La gestion des boutons
        La matrice de LED
        Accès à la mémoire EEPROM externe
    Ajoutons une connection série
        Vous voulez piloter le montage directement depuis un module USB          
        Si vous possédez déjà une connection série RS232
    Le micro-logiciel libre
        Mode interactif
        Mode non interactif

Cet article est également paru sur :

Logo Made in fr

Mardi, décembre 15 2009

Capteur température/humidité 433MHz

Histoire de continuer dans la domotique j'ai acheté des capteurs de température/humidité sans fils. Normalement ces capteur sont fait pour fonctionner avec une station météo base qui affiche les températures des différents capteurs. La station de base coute assez chère mais les capteur coute dans les 10 euros pièce ce qui est assez raisonnable. L'objectif est donc de comprendre le protocole qu'ils utilisent pour pouvoir recevoir leur signaux et par exemple commander les radiateurs.

Après avoir relativement facilement compris le protocole utilisé pas les prises télécommandés je ne m'attendait pas a passer plus de 8 heures a me gratter la tête pour décoder 2 valeurs (température et humidité). Pas facile du tout !

Voici la tête d'une trame (10ms/div):

Le problème c'est que j'ai cru que c'était du Manchester ou du Manchester différentiel mais j'ai fini par essayer le code Biphase qui s'est avéré plus concluant.

Ensuite le problème a été de retrouver les données dans les trames. La plupart des capteur sans fil (comme les Oregon) ont l'air d'utiliser un codage BCD pour coder les valeurs mais ce n'est pas le cas de ces capteurs.

Pour l'humidité relative la valeur est simplement codée en binaire sur 8bits (pas trop compliqué).

Pour la température j'ai eu plus de mal car la valeur est codée sur 12 bits Soit x l'entier correspondant aux 8 premier bits et y l'entier correspondant au 4 derniers. La valeur de la température est T = x - 50 + y / 16 J'ai bien galéré pour en arriver la !!! mais ça se vérifie bien aussi bien pour les températures positives que négatives.

Au final voila ou j'en suis:

  • 0..4 : Les 4 premiers bits on l'air d'être toujours 1100, probablement un préambule identifiant le type de capteur.
  • 4..8 : Code maison (valeur réglable entre 1 et 15 sur chaque capteur, le 0 a l'air inutilisé)
  • 8..10 : Code canal (valeur entre 1 et 4 réglable sur chaque capteur)
  • 10..12 : ???
  • 12..20 : Humidité. Entier sur 8 bits (poids fort en premier)
  • 20..32 : Température (voir plus haut pour le codage)
  • 32..36 : ???

Dans les inconnu il y a peut être qqch sur les unités de mesure (°C ou °F) et/ou sur le niveau de la batteries...

Au total donc 36 bits par trame à 2 ms par bit donc 72 ms par trame. A chaque fois que le capteur transmet les donnée 3 trames sont envoyées avec une pause de 70ms environ.

Voila pour aujourd'hui !

Dimanche, décembre 13 2009

Un peu de domotique

Comme il n'y a pas d'interrupteur dans notre appartement j'ai acheté des interrupteur sans fils et des prises (et dimmeurs) télécommandé:

Ça marche bien mais quand on en ai la on a envie de faire un peu plus, comme par exemple de commander/monitorer les equipements a partir d'un PC. La technologie utiliser est par radio a 433MHz (comme plein d'autre équipements). Ca tombe bien j'avait justement un recepteur 433MHz dans un tiroir:

Il ne reste plus qu'a étudier le signal transmis pas les interrupteurs et la télécommande, excellente occasion de de tester mon nouvel oscilloscope :-).

Les équipements que j'utilise (marque Waveman) propose 16 "code maison" et 16 canaux differents ce qui fait un total de 256 (16x16) canaux différents. Lorsque l'on active un interrupteur il émet un message qui contient le code maison, le canal et la commande (on ou off). Les récepteurs réglé sur ce canal recoivent le message et réagissent en conséquence.

Voici un message complet capturé a l'oscilloscope:

Il semble que chaque message est composé d'un "start" suivi de 12 bits, voici le début d'un message qui montre comment les 0 et 1 sont codés:

Et voici une capture avec une meilleur résolution pour détermine les durée:

Après avoir essayé et capturer différent interrupteurs réglés sur différents canaux il semble de le protocole soit le suivant:

  • Chaque trame commence par un "start": haut (0.42ms), bas (1.30ms)
  • 4 bits correspondant au "code maison" (0x0 à 0xF pour code de A à P) en transmettant les bits de poids faible d'abord.
  • 4 bits correspondant au "code canal" (0x0 à 0xF pour canal de 1 à 16) en transmettant les bits de poids faible d'abord.
  • 4 bits correspondant a la commande. 0x0 pour OFF et 0xE pour ON toujours avec les bits de poids faible d'abord.

Chaque bit est codé par deux impulsions:

  • 0 : haut (0.42ms), bas (1.30ms), haut (0.42ms), bas (1.30ms)
  • 1 : haut (1.30ms), bas (0.42ms), haut (0.42ms), bas (1.30ms)

Par conséquence la transmission de chaque bit prend 3.44 ms (ce qui fait un débit de 290 bps, pas vraiment rapide:-). Pour une trame complète ("start" + 12bits) on retrouve bien 43ms.

Voila qui semble pas mal, reste maintenant a sortir un microcontroleur et tenter de développer un émetteur/récepteur compatible. Très satisfait de l'oscilloscope en tout cas !