Quand il s'agit de concevoir des systèmes embarqués, interactifs ou bien quand des objets doivent communiquer entre eux, plusieurs solutions sont possibles. Nous explorerons ici le protocole Zigbee qui permet de communiquer par ondes radio, c'est-à-dire sans fil. Je m'efforcerais dans un premier temps de présenter les caractéristiques de ce protocole et d'éviter certaines confusions (partie 1). Ensuite je présenterais des cas pratiques avec et sans la carte Arduino (parties 3 et 4). Pour en savoir plus sur la carte Arduino, vous pouvez consulter ma page Arduino. À noter que ces cas pratiques ne concernent pour l'instant (01/2013) que la série 1 du module XBee.
Nous aborderons des domaines variés faisant appel à des notions plus ou moins avancées en réseaux informatiques. Loin d'être un obstacle, ce sera l'occasion d'apporter quelques éléments de compréhension dans l'apprentissage classique des systèmes informatiques (partie 2).
N'hésitez pas à me faire part de vos remarques pour améliorer ce document, rectifier certaines erreurs sur la page contact.
Les produits MaxStream XBee™ sont des modules de communication sans fil très populaires fabriqués par l'entreprise Digi International. Ils ont été certifiés par la communauté industrielle ZigBee Alliance en 2006 après le rachat de MaxStream par Digi International. La certification Zigbee se base sur le standard IEEE 802.15.4 qui définit les fonctionnalités et spécifications des réseaux sans fil à dimension personnelle (Wireless Personal Area Networks : WPANs). Nous verrons plus loin chacun des termes qui peuvent poser problème.
Les principales caractéristiques du XBee :
Le ZigBee semble avoir été conçu pour réaliser ce qu'on appelle l'Internet des objets, un ensemble d'objets communiquants voir "autonomes", une extension d'Internet aux objets physiques. La domotique est l'exemple le plus parlant.
S'en entrer dans les détails car ce n'est pas le propos ici, la vision d'un monde où tout doit être connecté, du frigo aux enfants, se rapproche pour ma part plus du cauchemar que du rêve. Les technologies de communication sont aussi utilisées par des groupes mercantiles et cyniques qui ne cessent de faire reculer la démocratie. Voir à ce propos le chapitre "Intrusion" page 53 de ma présentation sur la vie des objets.
Heureusement, des artistes s'approprient ces technologies et les utilisent à des fins plus poétiques.
Ici un couple d'oiseaux de papier communiquent ensemble. Quand l'un est manipulé, l'autre s'allume (Jie Qi messenger).
Dans Robotics drums, des servo-moteurs contrôlés à distance tapent sur 18 percussions Darbukas pour créer des rythmes inédits dans la ville.
Une autre application peut s'avérer très utile : programmer à distance une carte Arduino. En effet, d'habitude on relie sa carte avec câble USB, mais comment faire quand la carte est située à trois mètres de hauteur comme c'est le cas dans mon projet Chimères Orchestra ? La programmation à distance est donc la solution : programming Arduino Wirelessly.
À première vue, le sans fil présente bien des avantages. Il permet de ne pas encombrer un espace de travail, d'équiper des appareils mouvants, de communiquer dans des endroits innacessibles. Cependant, il faut aussi prendre en considération d'autres paramètres :
Par exemple, l'artiste Benjamin Gaulon démontre dans son projet 2.4Ghz qu'il est possible de recevoir dans l'espace public le signal des vidéos de surveillance sensé rester privé ...
Note : certains éléments de cette rubrique s'inspirent de la page 178 du livre Making Things Talk de Tom Igoe.
Bee signifiant "abeille", le choix du nom donne l'image qu'il peut y avoir plusieurs petits modules connectés ensemble comme une colonie d'abeilles. Au début, on peut confondre les termes XBee et ZigBee. En fait, comme expliqué au début de l'article, le ZigBee est un protocole de communication qui s'appuie sur le travail du groupe IEEE 802.15.4 et définit par le groupe de professionnels ZigBee Alliance. Le XBee est une marque, un produit qui utilise le protocole ZigBee. Do you bien compris ?
Le XBee étant devenu populaire, sa forme si particulière est aujourd'hui reprise par des fabricants de puces Bluetooth. Comme il existe beaucoup de shields arduinos et d'adaptateurs XBee, cela sera sans doute compatible avec les puces Bluetooth.
Dans cet image, on voit bien la répartition des rôles entre le standard 802.15 et le protocole ZigBee. Tout cela est expliqué dans la partie 2 qui traite des réseaux, des protocoles et des couches du modèle OSI.
Plusieurs produits XBee existent, ce qui peut créer quelques confusions. Il faut retenir qu'il y a deux catégories de XBee : la série 1 et la série 2. Les modules de la série 1 ont souvent un "802.15.4" qui s'ajoutent à leurs noms. Les modules de la série 2 sont disponibles en plusieurs versions : XBee ZNet 2.5 (obsolète), le ZB (l'actuel) et le 2B (le plus récent). Vous avez aussi des XBee Pro, qui font la même chose, mais avec de plus grandes capacités, notamment la portée qui semble pouvoir aller jusqu'à 1000 mètres ! Pour en savoir plus, télécharger le tableau de comparaison des modules XBee : http://www.digi.com/pdf/chart_xbee_rf_features.pdf.
Ce qu'il faut retenir :
Vous aurez aussi à choisir le type d'antennes du module. En effet, les ondes radios ont besoin d'antennes pour émettre et recevoir les signaux.
Ce qu'il faut retenir :
Pour établir une communication avec l'ordinateur, il y a deux options : l'assemblage de différents éléments comme sur l'image ou le XBee USB Explorer. J'ai choisi la première option car un peu moins cher et plus flexible. L'inconvénient est que ça nécessite un peu de soudure (3 minutes) et un petit montage sur plaque à essais. Bref, cela revient au même.
La communication en direct sans passer par une Arduino vous permet de configurer rapidement votre XBee. On verra plus loin dans les cas pratiques (partie 4) qu'on peut aussi configurer le module en le branchant à l'Arduino. Donc se procurer un explorateur n'est pas indispensable, mais c'est à conseiller pour débuter car c'est tout de même plus simple.
La communication entre l'ordinateur et le XBee se fait via une liaison série, que je détaille dans la partie 2.
L'alimentation doit être comprise entre 2,8V et 3,4V. Dans mes montages j'utilise l'alimentation stabilisée 3.3V. Dans d'autres exemples, il semblerait qu'assembler deux piles 1,5V ensemble soit suffisant.
Pour être plus autonome, on peut trouver des montages sur le Web avec le régulateur de tension LM7833 qui sort directement une tension de 3,3V ou bien avec le LM317 qui permettrait avec des valeurs de résistances adaptées d'obtenir ce que l'on souhaite, mais je ne l'ai pas testé.
Vous trouverez une liste intéressante de magasins en ligne sur codelab.fr/177. Je vous conseille de prendre tout dans le même magasin pour limiter les frais de transports et en France ou en Europe pour éviter les taxes (TVA) qui ne sont pas incluses dans certains pays, je pense surtout aux magasins situés aux États-Unis. En gros, essayez d'éviter Sparkfun.
Synthèse de ce dont nous aurons besoin :
Exemple de réalisation pour voir comment tout s'articule :
Comme l'ordinateur, Internet est une œuvre collective, composée de briques, d'astuces mathématiques, physiques et électroniques. Pour utiliser les réseaux informatiques de façon constructive, il faudrait connaître un minimum leur fonctionnement. Rester sur la couche applicative, celle la plus proche de l'utilisateur ne nous permet pas d'appréhender les concepts et les mots clés auxquels nous sommes confrontés quand nous devons nous-même gérer notre propre réseau.
Je mettrais l'accent sur deux notions qui nous serviront directement à appréhender le XBee : les protocoles et la communication série.
Entre 1960 et 1964, l'idée géniale de commutation de paquets est formulée conjointement par Leonard Kleinrock, Donald Davies et Paul Baran.
Paul Baran part du constat qu'un réseau centralisé est vulnérable. Si un nœud tombe en panne, l'information n'arrivera pas à son destinataire. C'est l'époque de la guerre froide, ces questions sont stratégiques. Une architecture distribuée avec des nœuds interconnectés parait la solution la plus flexible et la plus fiable.
Le message à envoyer est découpé en paquets (datagram). On leur ajoute généralement une étiquette composée de son adresse, celle du récepteur et son ordre dans le message original. Il est envoyé par des chemins divers évitant les congestions du réseau. Le destinataire remet ensuite le message dans l'ordre grâce aux étiquettes. On oppose cette technique à la commutation de circuits utilisée par le réseau téléphonique qui bloque un circuit pour une seule communication. Avec la commutation de paquets les ressources sont mutualisées, une ligne physique achemine différents bouts de messages provenant de différents expéditeurs.
Le modèle Internet qui est une simplification du modèle OSI donne une cohérence à la construction et l'envoie de messages. Il propose une architecture en couches, on parle aussi de pile (stack), définies et délimitées avec les notions de service, de protocole et d'interface. Chaque couche effectue des tâches spécifiques (services) et doit respecter certaines règles pour communiquer avec les couches inférieures et supérieures (protocole). Noter que le "P" à la fin des acronymes HTTP, TCP, UDP, PPP, POP, IP, ICMP, FTP signifie bien "protocole". Cette notion est donc centrale. On fait souvent une analogie avec les langages humains : dire "bonjour" pour commencer une conversation ne se fait pas de la même façon selon les cultures, les protocoles sont différents. De même, je ne serais peut-être pas sensible aux protocoles de séduction des koalas, ce qui serait regrettable tant cet animal a l'air sympathique.
Le modèle OSI nous permet de ne plus confondre le Web et Internet : le Web, via le protocole HTTP, est seulement une des nombreuses applications fonctionnant sur Internet, qui lui est un ensemble de réseaux interconnectés.
Les protocoles peuvent être ouverts et devenir des standards. Ils sont alors décris dans des textes publics dont nous avons accès et qui sont approuvés par des organismes de normalisation nationaux, internationaux ou privés. L'intérêt est de poser un référentiel commun pour rendre le système ouvert, stable et modulaire. Vous verrez en fouillant sur le Web, beaucoup d'acronymes concernant les documents et organismes. Il est intéressant d'avoir une petite idée de ce que signifient les plus connus : RFC, IEN, ISO, ANSI, AFNOR, IETF, IEEE. Le protocole UDP par exemple, est décrit dans la RFC 768 (Requests For Comments) datant de 1980 selon les mécanismes définis par l'IETF. C'est une évidence, mais il y a bien des hommes et une histoire derrière ces protocoles.
Dans la construction d'un paquets, les données utiles, celles de l'utilisateur ou du processus sont entourées, on dit encapsulées, par des informations gérées par les protocoles inférieures, comme les en-têtes (header). Celles-ci répondent aux besoins de chaque protocole et identifie le paquet à travers le réseau.
Chaque en-tête a des champs spécifiques qui ont une taille précise mesurée en octets et qui sont codés. Par exemple, dans l'en-tête IPv4, un champ codé sur 8 bits définit le protocole utilisé par la couche supérieure, la couche transport. S'il s'agit d'un paquet UDP, ce champ est 00010001, soit 17 en décimal ou 0x11 en hexadécimal. Une liste des nombres utilisés permet de déterminer le protocole. Ces champs peuvent être visualisés par des programmes qui analysent les paquets ou "sniffers)" comme Wireshark.
Nous aurons besoin plus loin de connaître la composition de la trame ZigBee.
Pour transmettre des données, il faut :
Au niveau physique, il s'agit surtout de l'envoi en série d'états électriques binaires (0 ou +5V par exemple). Le signal numérique est converti en signal analogique par des modems et transporté sur des supports filaires à base de cuivre ou de fibre optique, ou bien à travers le milieu aérien pour les transmissions non filaires. La transmission numérique des données est un ensemble de techniques fascinantes, qui consiste à trouver la meilleure solution pour transmettre les niveaux électriques représentant les bits.
La communication avec le module XBee s'établit par une communication série asynchrone. C'est très pratique, il suffit de quatre fils : deux pour l'alimentation (la masse et le +), un pour la réception et un pour l'émission. En effet le XBee permet de recevoir et d'émettre des données en même temps, on dit qu'il est full duplex, contrairement à la radio FM qui envoient les informations dans un seul sens (simplex) et au talkie-walkie qui ne permet pas à deux émetteurs de parler en même temps (half-simplex). On dit aussi que le XBee est un transceiver qui est la contraction de TRANSmitter (émetteur) et de reCEIVER (récepteur).
On distingue ensuite deux types de communications : série ou parallèle. La première nécessite moins de fils, toutes les données sont envoyées à la suite les unes des autres sur le même fil. La seconde est aujourd'hui moins utilisée du fait des perturbations dûes à la promiscuité des fils sur une nappe parallèle et aussi grâce à la rapidité de traitement des ordinateurs actuels.
"Dans une liaison en série, les données sont envoyées bit par bit sur la voie de transmission. Toutefois, étant donné que la plupart des processeurs traitent les informations de façon parallèle, il s'agit de transformer des données arrivant de façon parallèle en données en série au niveau de l'émetteur, et inversement au niveau du récepteur. Ces opérations sont réalisées grâce à un contrôleur de communication (la plupart du temps une puce UART, Universal Asynchronous Receiver Transmitter). Il fonctionne grâce à un registre à décalage. Le registre de décalage permet, grâce à une horloge, de décaler le registre (l'ensemble des données présentes en parallèle) d'une position à gauche, puis d'émettre le bit de poids fort (celui le plus à gauche) et ainsi de suite." (source : http://www.commentcamarche.net/contents/transmission/transnum.php3).
"Serial : Used for communication between the Arduino board and a computer or other devices. All Arduino boards have at least one serial port (also known as a UART or USART): Serial. It communicates on digital pins 0 (RX) and 1 (TX) as well as with the computer via USB. Thus, if you use these functions, you cannot also use pins 0 and 1 for digital input or output." (source : http://arduino.cc/en/Reference/Serial).
Toute l'astuce d'une liaison série asynchrone repose sur la forme des signaux envoyés ; signaux qui permettent une synchronisation du récepteur sur chaque caractère reçu. Examinez la figure ci-dessus qui représente la transmission asynchrone de l'octet 01010010 (caractère ASCII "R", valeur décimale 82). Au repos (idle) la ligne de transmission est à l'état logique haut. La transmission débute par le passage à 0 de cette ligne pendant une période de l'horloge de transmission ce qui constitue le bit de start (ce qui signifie début ou départ). Les bits du mot à transmettre sont ensuite envoyés derrière ce bit de start comme dans une transmission série synchrone et, après le dernier bit utile, la ligne passe à nouveau à l'état haut pendant une ou deux périodes d'horloge pour constituer ce que l'on appelle le ou les bits de stop (source : http://www.tavernier-c.com/serie.htm).
On distingue encore deux modes de communication qui spécifie le type de synchronisation entre l'émetteur et le récepteur : synchrone et asynchrone. Il faut en effet échantillonner le signal à la même cadence pour récupérer les bits dans l'ordre qui constituront le message d'origine. Dans le mode asynchrone, il s'agit de se mettre d'accord à la connexion sur une vitesse de transmission, la synchronisation se faisant ensuite par les bits de start et de stop. Le mode synchrone dédie un fil pour la synchronisation, c'est le signal d'horloge (clock).
La vitesse de transmission est mesurée en bauds qu'il ne faut pas confondre avec le débit binaire qui mesure la quantité d'informations en bits par seconde bps. Le baud est le nombre de symboles transmis physiquement par seconde, alors que le bit désigne une unité d'information. La confusion vient du fait qu'au début les modems transmettaient seulement 1 bit par baud, le débit en bits par seconde était donc équivalent au nombre de bauds. Aujourd'hui, il est souvent possible de transmettre plusieurs bits par symbole. La mesure en bps de la vitesse de transmission est alors supérieure à la mesure en baud. La forumle est la suivante : bps = baud * number of bits per baud.
Dans l'exemple ci-dessus, le nombre de symboles possible à un instant donné est de quatre : 00, 01, 10, 11. Ces symboles peuvent correspondre à des états électriques différents comme -5V, -3V, +3V, +5V ou à des modulations d'amplitude, de fréquences ou de phases différentes. Le tout est de pouvoir distinguer au mieux les symboles. Dans cet exemple, le débit en bauds est de 4 symboles par seconde, et 2 bits sont transmis par symbole. Le débit binaire est donc le double du débit en bauds. 8 bps = 4 baud x 2 bits per baud.
La valeur 9600 bps est souvent utilisée. Elle reflète la limite (ancienne) de certains modems de ne transmettre que 1200 baud et la technique communément utilisée de modulation. Cette modulation d'amplitude en quadrature permet de coder 8 bits par baud en associant une modulation d'amplitude à une modulation de phase. 9600bps = 1200 baud * 8 bits per baud. Pour Arduino, les débits possibles sont : 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 38400, 57600, or 115200 bps.
Cette norme est encore très souvent utilisée notamment au travers des puces FTDI qui équipent les anciennes Arduinos et dans les cartes d'interface qui permettent de communiquer en série avec le module XBee. Les nouvelles cartes Arduino Uno utilisent un ATmega328 à la place.
"Les signaux logiques aux niveaux TTL ou CMOS acceptent assez mal de voyager sur plus de quelques centimètres car leurs formes se dégradent alors à un point tel que leur exploitation devient impossible. Pour établir une liaison série sur une distance raisonnable, allant de quelques dizaines de centimètres à plusieurs centaines de mètres, diverses normes ont donc vu le jour. Même si elle commence à être quelque peu attaquée par la norme RS 422 ; la célèbre norme RS 232 a encore un bel avenir devant elle vu sa présence quasi constante sur tous les équipements informatiques. Cette norme RS 232, appelée aussi CCITT V24 ou encore V24 « tout court », est d'origine américaine et définit deux choses : les niveaux électriques des signaux utilisés pour la transmission mais aussi un certain nombre de lignes, autres que les lignes d'émission et de réception de données, ayant des fonctions de contrôle. Cette norme est très précise et, théoriquement, il est possible de connecter directement et sans problème deux équipements qui la respectent ; malheureusement ce n'est pas toujours le cas car de nombreux appareils ne suivent qu'une partie de la norme. Au point de vue niveau, cette norme est très simple : tout signal de niveau compris entre +3 et +25 volts est considéré comme étant au niveau logique A alors que tout signal compris entre -3 et -25 volts est considéré comme étant au niveau logique B. A et B sont quelconques et peuvent être 0 ou 1 selon que l'on travaille en logique positive ou négative." (source : http://www.tavernier-c.com/serie.htm)
Le standard IEEE 802.15.4 décrit les règles et fonctionnalités sur lequel se base le ZigBee mais pas uniquement. Il fait partie d'un ensemble plus vaste, dont la racine est le groupe de travail 802.15 et encore plus en amont le groupe 802 qui spécifie les standards des réseaux personnels sans fil (WPAN). Voyez ici, les différents groupes concernés et leurs buts. Familiarisons-nous rapidement avec ces nombres à rallonge ...
Quand on aborde les réseaux sans fil, on est confronté au paramètre de portée, c'est-à-dire jusqu'à quelle distance l'information peut-elle être transportée en bonne état. Des catégories de réseau ont ainsi été créées pour différencier les zones géographiques : PAN, LAN, MAN, WAN. Cela ne concerne pas uniquement les réseaux sans fils puisqu'un réseau Ethernet, très commun dans les entreprises ou les associations, peut être un PAN ou un LAN.
Pour la transmission de données dans le milieu aérien, plusieurs options sont possibles. On utilise souvent des ondes électromagnétiques dans le domaine radio utilisant des fréquences porteuses réservées selon les pays. Vous verrez souvent les mêmes valeurs en France : 433Mhz et 2,4Ghz (comme le four micro-ondes).
Ne sont répertoriés ici que les systèmes utilisant les radio-fréquences. Il existe aussi des transmissions par infra-rouges, qui sont directionnelles alors que les ondes radio sont omnidirectionnelles. Cela limite beaucoup leur utilisation. Les infra-rouges sont aussi des ondes électromagnétiques mais leur fréquence est beaucoup plus élevée. Elles n'utilisent donc pas d'antennes mais des émetteurs et récepteurs infra-rouges sous la forme de LEDs le plus souvent. C'est le cas des télé-commandes de garage ou de télévision par exemple.
Vous pouvez utiliser n'importe quelle technique, cependant il faut prendre de soin de cerner les buts de votre réseau sans fil et les contraintes des technologies disponibles : infra-rouge, 433Mhz, Bluetooth, Wi-Fi, ZigBee, GPS, RFID et bien d'autres que je ne connais sûrement pas. Dites-vous qu'il existe des montages avec Arduino pour toutes ces techniques.
Notes sur le 433Mhz
Les montages avec des dispositifs 433Mhz sont très économiques (~8€), ils peuvent suffire dans certains cas. La différence de taille avec une transmission Bluetooth, Wi-Fi ou ZigBee c'est que les données sont envoyées sans contrôles, c'est-à-dire que l'on n'est pas sûr qu'elles soient arrivées correctement du fait des interférences, des obstacles et de tout ce qui peut gêner les ondes. Si l'application n'est pas vitale, si quelques erreurs de temps en temps sont acceptables par le système alors cette solution peut être pertinente. En revanche, si les données sont critiques, reliées par exemple à un robot géant dans un lieu public ou à des appareils médicaux, cela n'est pas envisageable. On préfèrera dans ce cas des transmissions contrôlées et sécurisées par un protocole comme le Bluetooth, le Wi-Fi ou bien le ZigBee. Pour le 433Mhz, deux autres solutions sont tout de même possibles pour contourner le problème : essayer de vérifier vous-même les erreurs dans votre programme mais cela demande une bonne compétence en programmation ou le APC220 qui semble pouvoir fournir les vérifications demandées.
Exemples de montages Arduino / 433Mhz :
ZigBee/Bluetooth/Wi-Fi
Le schéma ci-dessus permet de comparer le ZigBee, le Bluetooth et le Wi-Fi en termes de portée et de débits. Une courte vidéo présente les caractéristiques principales dans le choix des technologies sans fil : http://www.youtube.com/watch?v=buV11ZPJ7MQ
Une fois le matériel acheté comme indiqué dans la partie 1, il ne reste plus qu'à assembler notre premier montage, à établir une connection avec l'ordinateur et connaître la syntaxe pour configurer le module XBee.
Souder l'adaptateur XBee, il permet juste d'avoir des contacteurs avec le bon espacement pour pouvoir enfoncer le module dans une platine d'essais. Placer la carte FTDI. Connecter l'ensemble suivant le schéma.
Sous Linux et Mac OSX, en ouvrant un Terminal, on peut taper quelques commandes pour savoir si le module est bien reconnu par votre ordinateur : dmesg | tail , lsusb, ls /dev/tty*
Les réponses du terminal à ces commandes indiquent que l'adaptateur série est bien connecté à l'ordinateur, vous voyez FTDI USB Serial Device ou FT232 USB-Serial, son identifiant est ttyUSB0.
L'idée maintenant est de pouvoir envoyer des commandes au module et de recevoir ses retours. Pour cela il faut utiliser un programme, appelé Terminal ou plus précisément émulateur de terminal. On l'utilise, dans notre cas, pour communiquer en série avec le port ouvert par le contrôleur USB. Des spécifités existent entre les systèmes d'exploitation que je ne peux répertorier (pour Windows : programme Putty et Xctu à télécharger).
Trois possibilités :
Voici un exemple de communication avec le programme de Tom Igoe.
Le XBee possède trois modes : TRANSPARENT, COMMAND et API. Le mode TRANSPARENT est le mode par défaut à la mise en marche du module, celui qui reçoit et envoie les données. Le mode COMMAND permet de configurer le module, ses entrées, ses sorties, son adresse, l'adresse de destination de ses messages, etc.
Le mode API est un peu plus compliqué et pour dire vrai, je n'ai pas encore pu l'expérimenter avec succès. Une API (Application programming interface) est un terme bien connu en informatique. Il désigne une interface fournie par un programme informatique, c'est-à-dire un ensemble de fonctions qui facilitent la programmation d'un côté et qui de l'autre communique en langage binaire pour le XBee, sous forme de paquets. Je crois comprendre que ce mode devient utile quand il s'agit de construire des messages au format XBee à partir d'un ordinateur ou d'un microcontrôleur comme Arduino. Le mode API n'est possible qu'avec une connection locale en série et filaire avec l'ordinateur ou la Arduino, pas entre modules XBee.
MODE COMMAND Ouvrez le terminal choisi. Avant tout, il faut dire au XBee que l'on veut quitter le mode TRANSPARENT pour entrer dans le mode COMMAND. Pour cela il faut prendre le coup de main, suivez bien ces instructions à la lettre :
COMMAND AT
Dans les télécommunications, l'ensemble de commandes Hayes est un langage de commandes spécifiques développé pour le modem Hayes SmartModem 300 en 1981. Les commandes sont une série de mots courts qui permettent de contrôler le modem avec un langage simple : composer un numéro de téléphone, connaître l'état de la ligne, régler le volume sonore, etc. Ce jeu de commandes s'est ensuite retrouvé dans tous les modems produits (sources : http://fr.wikipedia.org/wiki/Commandes_Hayes, http://en.wikipedia.org/wiki/Hayes_command_set).
Pour avoir un aperçu rapide des commandes disponibles pour le XBee, télécharger le guide de référence des commandes AT de Sparkfun
TEST La syntaxe est simple, il faut taper AT, puis le nom de la commande, les options si besoin et appuyer sur la touche <Entrée>. Essayez donc ces commandes pour faire vos premiers tests :
Vous avez défini ici l'adresse du module à 1234 (ATMY 1234) puis demander quelle était votre adresse (ATMY).
Pour tout XBee, il faut impérativement définir l'adresse du réseau ATID, son adresse personnelle ATMY et si besoin, l'adresse de destination des paquets ATDL.
Le XBee series 1 possède un certain nombre d'entrées et sorties. Les sorties analogiques sont PWM0 et PWM1. Les entrées et sorties numériques sont DIO1, DIO2, DIO3, DIO4, DIO5, DIO6, DIO7 ("DIO" pour Digital Input Output). Les entrées analogiques sont : AD1, AD2, AD3, AD4, AD5 ("AD" pour Analog Digital, l'échantillonnage des tensions analogiques converties en numérique). Pour trouver la bonne commande AT, on peut se référer au pages 12, 31, 39 et 43 du manuel (.pdf) ou à l'image ci-dessous.
Par exemple, si l'on veut configurer le XBee pour qu'il capte un bouton poussoir sur l'entrée numérique 1, il faudrait écrire ATD1 3. D1 pour pin19 (DIO1, AD1) et 3 pour Digital Input.
Il faut savoir que les entrées fonctionnent par paire, c'est la notion de "line passing". L'entrée 0 du XBee#2 correspond à la sortie 0 du XBee#1. Comme il y a deux sorties 0 (PWM0, DIO0), alors si on veut avoir deux sorties différentes il faut choisir une autre sortie DIO1 pour l'autre LED.
En mode API, on peut reconstituer la trame ZigBee pour communiquer directement en binaire avec le module.
Voilà, ce que ça pourrait donner en langage Arduino, pris sur http://www.faludi.com/classes/sociableobjects/code/XBee_Analog_Duplex_Sender.pde.
Une autre solution, au lieu de reconstituer la trame, utiliser une bibliothèque spéciale :
D'autres infos :
On peut faire un montage très simple, le montage direct entre deux modules XBee. Il met deux capteurs sur le XBee#2, un bouton poussoir et un potentiomètre et deux actionneurs sur le XBee#1, deux LEDs. Le bouton allume et éteint une LED en on/off (digital), le potentiomètre allume et éteint l'autre LED de façon progressive (en PWM).
XBEE#2 : émetteur (INPUT)
XBEE#1 : receveur (OUTPUT)
Configuration
| INPUT | OUTPUT | |||
|---|---|---|---|---|
| +++ | ||||
| ATRE | Restaure les paramètres par défaut | |||
| ATID | 1111 | 1111 | Adresse du réseau | |
| ATMY | 1 | 0 | Adresse du module dans le réseau | |
| ATDL | 0 | 1 | Adresse du destinataire dans le réseau | |
| ATIR | 14 | - | Taux d'échantillonnage 20ms (14 en hexadecimal) (p.43 du manuel) | |
| ATIT | 5 | - | Nombre d'échantillon à effectuer avant l'envoi des données | |
| ATIU | 1 | - | I/O output enabled : autoriser émission des I/O sans passer par l'UART | |
| ATIA | - | 1 | I/O input from address 1 | |
| ATD0 | 2 | - | POTENTIOMETRE : D0 pour pin20 (DIO0, AD0) et 2 pour ADC (p.12, p.39) | |
| ATP0 | - | 2 | LED : P0 pour PWM 0 et 2 pour PWM mode (p.31) | |
| ATD1 | 3 | BOUTON : D1 pour pin19 (DIO1, AD1) et 3 pour Digital Input | ||
| ATD1 | 4 | LED : D1 pour pin19 (DIO1, AD1) et 4 pour Digital Out Low Support | ||
| ATWR | Écrit la nouvelle configuration dans la mémoire flash du module | |||
| ATCN | - | - | Sort du mode configuration | |
Avec le même montage, on peut visualiser dans le terminal, les informations reçues par le XBee#1 avec le convertisseur relier à l'ordinateur. Ces informations ne sont cependant pas tout à fait compréhensibles dans le terminal, on ne voit pas de chiffres par exemple car il s'agit de paquet ZigBee.
L'Arduino capte un bouton poussoir et envoie un message tout ou rien au XBee#1 pour allumer la LED. Cette fois, on peut voir dans le terminal les informations de façon compréhénsible.
Montage émetteur
Code émetteur
Téléchargement : ./ressources/xbee-arduino/code/emetteur. Simplification du code de Robert Faludi.
Le code n'a rien de compliqué. Tout d'abord on configure le module XBee connecté avec RX et TX comme indiqué ci-dessus. On écrit "+++" en communication série, on attend la réponse du XBee avec le caractère '\r' qui marque la fin d'une ligne et ensuite on écrit seulement cinq commandes pour configurer uniquement l'adressage du module comme vu dans la partie précédente. On récupère ensuite les informations numérique de l'entrée numérique de l'Arduino et on envoie le chiffre reçu en série, donc au module XBee.
L'émetteur est le même que précédemment, une Arduino avec un bouton poussoir et le XBee#2.
Montage récepteur
Code récepteur
Téléchargement : ./ressources/xbee-arduino/code/recepteur. Simplification du code de Robert Faludi.
On configure tout d'abord le module XBee#1 pour qu'il reçoive les données de l'autre XBee.
Et on récupère les données du port Série. Ce bout de code est un peu plus compliqué. Pour l'instant il ne permet de recevoir qu'une donée à la fois.
Limites
En pratique, on voudrait avoir la possibilité d'envoyer plusieurs données différentes provenant de plusieurs capteurs et d'actionner plusieurs sorties. Les méthodes présentées ici ne le font pas. Pour cela, deux options semblent envisageable : construire des messages série plus compliqués avec un identifiant (comme ici) ou bien utiliser l'API XBee pour Arduino.
En savoir plus sur les réseaux :