XBee & Arduino

2014.11.14

Note : nouvel article sur le réseau en étoile sur le wiki.

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.

Agrandir la photo

  1. Présentation du XBee
  2. Notions de réseaux
  3. Configuration
  4. Montages
  5. Ressources

1. Présentation du XBee

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 :

  • fréquence porteuse : 2.4Ghz
  • portées variées : assez faible pour les XBee 1 et 2 (10 - 100m), grande pour le XBee Pro (1000m)
  • faible débit : 250kbps
  • faible consommation : 3.3V @ 50mA
  • entrées/sorties : 6 10-bit ADC input pins, 8 digital IO pins
  • sécurité : communication fiable avec une clé de chiffrement de 128-bits
  • faible coût : ~ 25€
  • simplicité d'utilisation : communication via le port série
  • ensemble de commandes AT et API
  • flexibilité du réseau : sa capacité à faire face à un nœud hors service ou à intégrer de nouveaux nœuds rapidement
  • grand nombre de nœuds dans le réseau : 65000
  • topologies de réseaux variées : maillé, point à point, point à multipoint

1.1. Applications

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.

Agrandir la photo

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.

Agrandir la photo

Ici un couple d'oiseaux de papier communiquent ensemble. Quand l'un est manipulé, l'autre s'allume (Jie Qi messenger).

Agrandir la photo

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.

Agrandir la photo

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.

1.2. Pourquoi choisir le sans fil ?

À 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 :

  • La communication sans fil ne sera jamais aussi fiable qu'une communication filaire. Le signal peut être déformé par d'autres ondes et par des obstacles.
  • Par conséquent, commencez toujours à tester votre système avec une communication filaire.
  • À moins de récupérer l'énergie des ondes électromagnétiques ambiantes (Free Energy), vous aurez toujours besoin d'un fil pour alimenter votre module.
  • L'environnement semble aujourd'hui saturé d'ondes électromagnétiques, on parle de pollution électromagnétique. Le XBee génère des radiations électromagnétiques alors pourquoi en rajouter ?
  • La communication n'est pas 1-1 entre l'émetteur et le récepteur. En effet les ondes radio rayonnent en cercle autour de l'émetteur. Seuls les appareils décryptant le bon protocole peuvent différencier les informations provenant d'un module Zigbee, d'un module Bluetooth ou de routeurs Wi-Fi, pourtant tous modulés par la même fréquence de 2,4Ghz.
    Agrandir la photo
    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.

1.3. Xbee ou Zigbee ?

Agrandir la photo

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 ?

Agrandir la photo

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.

1.4. ZigBee et 802.15

Agrandir la photo

Dans cette 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.

1.5. Séries 1 et 2 ?

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.

Agrandir la photo

Ce qu'il faut retenir :

  • les modules des séries 1 et 2 ne sont pas compatibles entre eux ;
  • la portée et la consommation sont sensiblement les mêmes ;
  • le nombre d'entrées et sorties est différent et surtout la série 2 ne possède pas de sorties analogiques PWM ;
  • les topologies de réseaux possibles ne sont pas les mêmes. Avec la série 1, l'architecture est simple : point à point (pair) ou multipoint (star). La série 2 permet en plus de créer des réseaux plus complexes : maillés (mesh) ou en "arbre" (cluster tree). Agrandir la photo

1.6. Antennes

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.

Agrandir la photo

Ce qu'il faut retenir :

  • wire : simple, radiations omnidirectionnelles ;
  • chip : puce plate en céramique, petite, transportable (pas de risques de casser l'antenne), radiations cardioïdes (le signal est atténué dans certaines directions) ;
  • U.FL : une antenne externe n'est pas toujours nécessaire;
  • RPSMA : plus gros que le connecteur U.FL, permet de placer son antenne à l'extérieur d'un boîtier.

1.7. Communication avec l'ordinateur

Agrandir la photo

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.

1.8. Alimentation

Agrandir la photo

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é.

Agrandir la photo

Agrandir la photo

1.9. Matériel nécessaire

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 : Agrandir la photo

2. Notions de réseaux

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.

2.1. Protocoles de communication

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.

Agrandir la photo

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.

Agrandir la photo

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.

Agrandir la photo

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.

Agrandir la photo

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.

Agrandir la photo

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.

2.2. Communication série

Agrandir la photo

Pour transmettre des données, il faut :

  • coder les données (émetteur) pour qu'il y ait le moins de pertes possibles ;
  • les acheminer via un support physique ;
  • les décoder (récepteur) suivant les mêmes règles.

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.

2.2.1. Duplex / transceiver

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).

Agrandir la photo

2.2.2. Liaison série / parallèle

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.

Agrandir la photo

"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)

Agrandir la photo

"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)

2.2.3. Synchrone / asynchrone

Agrandir la photo

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).

2.2.4. Baud / bits par seconde

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.

Agrandir la photo

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.

Agrandir la photo

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.

2.2.5. Norme RS 232

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)

2.3. Réseaux sans fils

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 ...

Agrandir la photo

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.

Agrandir la photo

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).

Agrandir la photo

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.

Agrandir la photo

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

Agrandir la photo
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

3. Configuration

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.

3.1. Montage

Agrandir la photo

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.

3.2. Connaître son matériel

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*

Agrandir la photo

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.

3.3. Terminal

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 :

  • dans le logiciel Arduino, il y a un moniteur série
  • sur Linux, installer le logiciel screen pour avoir un utilitaire ultra simple : sudo apt-get install screen. Et ensuite, vous avez accès au port série avec la commande : screen /dev/ttyUSB0 9600. Le logiciel screen se connecte au port série de notre adaptateur FTDI. Si vous avez lu la partie concernant la communication en série (partie 3), vous ne serez pas surpris de voir le chiffre 9600. En effet, comme il s'agit d'une communication asynchrone, il faut se mettre d'accord sur le débit en binaire (bits/seconde). Commandes utiles de screen : Ctl-A ? : help et Ctl-A \ : quit (en tapant "y" pour "yes")
  • Une autre solution, sans doute la meilleure, car très agréable à utiliser et multi-plateforme : télécharger le programme de Tom Igoe
    • xbeeSerialTerminal : http://www.itp.nyu.edu/physcomp/uploads/xbeeSerialTerminal.zip
    • ce programme est écrit avec le logiciel Processing (à télécharger aussi si vous ne l'avez pas). Ouvrez-le avec et lancer-le, ou mieux, exportez-le en une application java pour un confort d'utilisation optimale.
    • il permet de visualiser les commandes et les retours les uns à la suite des autres, contrairement au logiciel screen qui n'utilise qu'une seule ligne pour l'envoi et la réception, ce qui est une source de confusion.
    • faire attention, le programme ouvre par défaut le premier port série ouvert. Donc si deux modules séries sont connectés (une Arduino en est un), seul un, que l'on ne peut pas choisir (sauf en modifiant le programme de Tom Igoe) est accessible.

Agrandir la photo

Voici un exemple de communication avec le programme de Tom Igoe.

3.4. Modes

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.

3.5. Commandes AT

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 :

  • Taper +++ et attendre 1 seconde sans appuyer sur aucune autres touches, le message OK devrait alors s'afficher comme sur l'image du terminal juste en haut. Par ce OK, le XBee nous signale qu'il passe en mode COMMAND et qu'il est prêt à recevoir les messages de configuration.
  • Si vous attendez plus de 10 secondes sans appuyer sur une touche, le XBee revient en mode TRANSPARENT. Vous devez alors retaper +++ pour revenir en mode COMMAND.

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 :

  • +++ (attendre OK)
  • > OK
  • ATMY1234 <Enter>
  • > OK
  • ATMY <Enter>
  • > 1234

Vous avez défini ici l'adresse du module à 1234 (ATMY 1234) puis demander quelle était votre adresse (ATMY).

3.6. Adressage

Agrandir la photo

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.

3.7. Entrées / sorties

Agrandir la photo

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 associée à la configuration souhaitée, on peut se référer au pages 12, 31, 39 et 43 du manuel (.pdf) ou à l'image ci-dessous.

Agrandir la photo

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.

Agrandir la photo

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.

3.8. Mode API

En mode API, on peut reconstituer la trame ZigBee pour communiquer directement en binaire avec le module.

Agrandir la photo

Voilà, ce que ça pourrait donner en langage Arduino, pris sur http://www.faludi.com/classes/sociableobjects/code/XBee_Analog_Duplex_Sender.pde.

Agrandir la photo

Une autre solution, au lieu de reconstituer la trame, utiliser une bibliothèque spéciale :

D'autres infos :

4. Montages

4.1. XBee > XBee

Agrandir la photo

On peut faire un montage très simple, le montage direct entre deux modules XBee. On 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)

Agrandir la photo

XBEE#1 : receveur (OUTPUT)

Agrandir la photo

Configuration

INPUTOUTPUT
+++
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'échantillons à 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

4.2. XBee > XBee/ordinateur

Agrandir la photo

Avec le même montage, on peut visualiser dans le terminal, les informations reçues par le XBee#1 avec le convertisseur relié à 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.

4.3. XBee/Arduino > XBee/ordinateur

Agrandir la photo

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

Agrandir la photo

Code émetteur

Téléchargement : ./ressources/xbee-arduino/code/emetteur. Simplification du code de Robert Faludi.

Agrandir la photo

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.

4.4. XBee/Arduino > XBee/Arduino

Agrandir la photo

Montage récepteur

L'émetteur est le même que précédemment, une Arduino avec un bouton poussoir et le XBee#2.

Agrandir la photo

Code récepteur

Téléchargement : ./ressources/xbee-arduino/code/recepteur. Simplification du code de Robert Faludi.

Agrandir la photo

On configure tout d'abord le module XBee#1 pour qu'il reçoive les données de l'autre XBee.

Agrandir la photo

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 donné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.

5. Ressources

5.1. Livres
  • Building Wireless Sensor Networks, de Robert Faludi. Cet ouvrage se consacre uniquement au XBee de la série 2 pour la mise en place de réseaux maillés.
  • Making Things Talk, de Tom Igoe. Le livre présente les communications Ethernet, infra-rouge, radio, XBee, GPS. Attention, le XBee utilisé est de la série 1 et un seul montage XBee est disponible, ce qui est décevant. Il faut plutôt choisir ce livre pour le support d'informations concernant l'ensemble des techniques de communication.
5.2. Manuels et références

5.3. Téléchargements

5.4. Sites

En savoir plus sur les réseaux :