Carte du maraudeur : Différence entre versions

De Wiki de Projets IMA
(Première séance)
Ligne 32 : Ligne 32 :
 
Nous avons réalisé un premier montage pour communiquer avec le module Q5M via les broches 12(RX) et 13(TX) de l'arduino (Broche RX de l'arduino connectée sur la broche TX du module et inversement). L'arduino a été programmé de façon à récupérer une trame complète de 11 octets puis de l'afficher sur le terminal.
 
Nous avons réalisé un premier montage pour communiquer avec le module Q5M via les broches 12(RX) et 13(TX) de l'arduino (Broche RX de l'arduino connectée sur la broche TX du module et inversement). L'arduino a été programmé de façon à récupérer une trame complète de 11 octets puis de l'afficher sur le terminal.
 
Malheureusement , nous avons seulement été capable de récupérer un octet contenant 0x00 lorsqu'une carte est présente vers l'antenne , et rien autrement.
 
Malheureusement , nous avons seulement été capable de récupérer un octet contenant 0x00 lorsqu'une carte est présente vers l'antenne , et rien autrement.
 +
 +
{{boîte déroulante|titre=Modèles destinés aux copies multiples|contenu={{Avertissement|Une page ou partie de page peut être incluse dans une autre sans création d'un modèle.}}}}
  
 
==== Deuxième séance ====
 
==== Deuxième séance ====

Version du 8 mars 2012 à 16:09

Liste du matériel

Présent

  • Transpondeurs RFID (inventaire à réaliser)
  • Antennes RFID
  • Tags
  • Puces Xbee
  • Supports Xbee Xplorer
  • Supports Xbee Shields
  • Cartes Arduino Duemilanove

A acheter

  • Modules Xbee suivant inventaire

Avancement du projet

Première séance

Objectifs :

  • Prise en main du sujet
  • Familiarisation avec les composants

Réalisations :

Pour cette première séance , nous avons dans un premier temps cherché les datasheets des transpondeurs RFID (Q5M-005) sur le site Lextronic. Cette datasheet nous informe que le module Q5M communique via une liaison série type RS232 (compatible TTL) , nous avons donc cherché un moyen de communiquer avec le module Q5M à l'aide d'un arduino. L'arduino UNO ne comportant qu'un seul "port série" qui est déjà utilisé par le port USB , nous avons dû utiliser la librairie <SoftwareSerial.h> qui permet d'émuler un port série sur des broches "classiques". Nous avons réalisé un premier montage pour communiquer avec le module Q5M via les broches 12(RX) et 13(TX) de l'arduino (Broche RX de l'arduino connectée sur la broche TX du module et inversement). L'arduino a été programmé de façon à récupérer une trame complète de 11 octets puis de l'afficher sur le terminal. Malheureusement , nous avons seulement été capable de récupérer un octet contenant 0x00 lorsqu'une carte est présente vers l'antenne , et rien autrement.

Modèle:Avertissement
#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
        echo "$date $time Fichier recu: $file";
        rm -rf $DIR/$file;
        ls $DIR;
        echo "Has $file been removed ?";
done

Deuxième séance

Objectif :

  • Récupérer l'identifiant d'une carte Unique à l'aide du Q5M

Réalisations :

Suite à l’échec de la semaine dernière et après une relecture de la datasheet , nous avons compris que le Q5M fonctionne sur le principe de requête/réponse. Afin de simplifier le problème , nous avons laisser de coté l'arduino , et nous avons tenté de communiquer avec le module Q5M directement en utilisant le logiciel officiel FRAMER qui intègre les trames à envoyer. Pour ces tests , nous utilisons un convertisseur USB/Série connecté à notre module. Malheureusement , là encore , le module n'envoie qu'un seul octet 0x00 lorsque une carte est présente et rien d'autre , peut importe les requêtes que nous envoyons via le programme FRAMER. Dans le doute , nous avons voulu vérifier si les trames envoyé via FRAMER étaient correctes en les récupérant sur l'arduino en utilisant le programme réalisé la semaine d'avant. Après quelques tests , nous somme bien capable de récupérer les octets envoyés via FRAMER mais ceux-ci sont complètement incohérents avec ceux envoyés. Après quelques recherches sur internet , il se trouve que les signaux envoyés par l'ordinateur sur le convertisseur USB/Série sont inversés par rapport à des signaux RS232 compatible TTL ( http://kubuntu.free.fr/blog/index.php/2010/05/13/272-liaison-serie-rs232-vs-ttl ). Nous avons donc placé un inverseur entre le convertisseur USB/Série et l'arduino , et surprise , nous arrivons bien a récupérer les trames envoyées par FRAMER. Nous avons ensuite placé l'inverseur entre le convertisseur USB/Série et le module Q5M mais une fois encore , le module ne retourne qu'un octet 0x00 peut importe les requêtes envoyées via FRAMER.

Troisième séance

Objectif :

  • Récupérer l'identifiant d'une carte Unique à l'aide du Q5M

Réalisations :

Après de nombreuses réflexions et de nombreux tests , nous avons voulu observer ce qu'il se passait sur les autres broches du module ... et nous avons remarqué que la communication série se faisait en fait sur une autre broche ... laissant supposé que notre module n'est pas un Q5M005 mais un UM005 (qui ne fonctionne qu'en "auto-read") ! Nous avons donc repris notre "programme de lecture" de la première séance et nous avons enfin réussi à lire un identifiant avec succès ! Maintenant que la lecture des identifiants des cartes RFID se fait correctement , nous avons cherché un moyen de réaliser une interface graphique qui afficherai cet identifiant dans une fenêtre windows. Pour cela nous utilisons le programme "Processing" qui permet de programmer toutes sortes d’éléments graphiques ainsi que de prendre en charge des périphériques USB tel un arduino (ou un Xbee).