Consulter impérativement PROGRAMMATEUR de BLUETOOTH.pdf
Ménage à trois pourrait également servir de titre à ce chapitre. L’idée consiste à faire dialoguer trois unités Arduino, pour aboutir à une sorte de réseau. Par cette technique on peut doubler la portée maximale d’une transmission de donnée par radio fréquences. Mais ce n’est pas le domaine d’application du BLUETOOTH qui par nature est conçu pour le pilotage d’éléments à faible distance. Le but de cette expérience consiste à anticiper un peu le thème des réseaux en anneaux qui sera imagé avec la prochaine application. Ne pas aborder ce domaine alors que le thème principal de ce didacticiel est « le dialogue entre machines » serait bien dommage.
Principe des réseaux chaînés.
Imagé sur la Fig.54 les réseaux à longue couverture hertzienne sont basés sur l’implantation de stations intermédiaires exactement comme le font les intercalaires qui fleurissent un peu partout pour établir la couverture des réseaux téléphoniques cellulaires. La grande différence de morphologie, c’est que dans notre cas on agence une ligne avec Maître à une extrémité et Esclave de l’autre, alors que dans la téléphonie les unités sont indifférenciées.
Dans ce type d’organisation on trouve, représenté par les flèches vertes la voie montante par laquelle transitent les consignes du Maître vers l’Esclave. Représentées en violet les flèches de la voie descendante par laquelle l’Esclave retourne les ACcusés de Réception. Cette terminologie vient des transmissions pour lesquelles l’Intercalaire est un satellite en orbite et qu’il n’y aurait alors pas d’esclave. Chaque fois que l’on ajoute un INTERCALAIRE, on augmente la distance à laquelle se trouve la station Esclave. La liaison peut naturellement être de type filaire ou hertzienne. Pour notre cas on va simplifier au maximum et n’ajouter qu’une seule unité, car pour un système aussi simple utilisant des transmetteurs Bluetooth, la Fig.55 montre que l’on va devoir faire dialoguer pas moins de 7 machines dont quatre devront être appairées par couple !
Pour cette expérience, nous devons utiliser trois cartes Arduino et quatre modules Bluetooth. Pour les deux extrémités, on conserve la carte UNO pour le Maître et la carte NANO élargie pour l’Esclave pour avoir à minimiser les modifications de programme à effectuer. Du reste, la présence de l’INTERCALAIRE n’est pas détectable par les deux extrémités, car il ne fait que retransmettre strictement sans les modifier les données qu’il reçoit des « deux cotés ». Donc, si l’on suppose que l’on désire strictement un comportement inchangé, en principe on peut se contenter de laisser les programmes P13 et P14. Pour effectuer la transmission par radio fréquences on se sert du couple initial en B. Bien entendu, en A il faut intercaler deux autres modules et les appairer. On peut reprendre le format de la transmission UART, par contre, il faut impérativement modifier leur mot de passe et en choisir un différent. Pour l’unité intermédiaire, j’adopte une deuxième carte NANO élargie pour disposer du petit écran OLED. Ainsi l’INTERCALAIRE disposera de son propre écran sur lequel il affichera les informations relatives à sa mission. Par exemple afficher sur la ligne du haut la consigne reçue et sur celle du bas l’ACR retourné par l’esclave. Enfin, pour éviter les frustrations, on reprend l’idée qui consiste à pouvoir suivre ce qui se passe en ouvrant trois fois le Moniteur de l’IDE. On peut ainsi s’affranchir de la présence des écrans OLED sur les trois unités. Seule contrainte financière, il faut disposer de trois cartes Arduino et de deux couples de transmetteurs Bluetooth, l’expérience de cette mise en réseaux en vaut toutefois largement la peine.
Préparer le couple de modules Bluetooth complémentaire.
Bien de bien nouveau dans les chaumières, il suffit de reprendre intégralement la procédure présentée de la page 4 à la page 10 du didacticiel. Comme il n’est pas question de chambouler les structures des deux modules actuellement en service, c’est dans l’Arduino qui va servir d’INTERCALAIRE que l’on téléverse P02_Configurer_le_module.ino dont on a fait l’expérience et qui va nous servir à conditionner le couple. En effet, il faut adopter un format UART identique, un même mot de passe, mais il ne faut pas oublier non plus à conditionner l’un des modules en Maître et l’autre en Esclave. On branche +5V et GND sur le module à conditionner. D2 va directement sur TX alors que D3 est branché comme montré sur la Fig.56 pour diminuer la tension du signal. Enfin, pour programmer le module il faut relier sa broche 3,3v au +3,3V de la carte Arduino.
Sur le couple initialisé « non standard », le code pswd ne peut pas être changé. La procédure décrite ci-avant reste toutefois compatible avec des modules Bluetooth au comportement normalisé.
C’est fait, on dispose de deux unités qui en principe sont conditionnées pour pouvoir communiquer sur 2,4 GHz. Il nous reste plus qu’à le vérifier avant de développer l’application INTERCALAIRE. Il suffit de remplacer sur les circuits de P13 et P14 les deux modules installés par les deux nouveaux sans inverser Maître et Esclave et vérifier l’établissement normal du dialogue.
Le démonstrateur P15_Maitre_H.ino.
Puisque l’on envisage un comportement identique du réseau avec uniquement augmentation de la portée par interposition d’un INTERCALAIRE, logiquement il serait possible de ne strictement rien changer aux programmes initiaux P13 et P14. Toutefois, nous allons introduire une petite différence de comportement pour améliorer la convivialité d’utilisation du réseau. Le programme P15_Maitre_H.ino est déduit de P14_Maitre_H.ino à peine modifié. Le seul changement qui est effectué dans le programme source consiste à inverser sur RESET le test du bouton poussoir déclenchant le mode INFINI. Avec P15, sur RESET il y a passage automatique en mode INFINI si le bouton poussoir placé sur D4 n’est pas activé. Il faut donc la présence humaine si l’on désire le mode Commandes manuelles. L’avantage, c’est que s’il se produit une coupure secteur durant un test de fiabilité, le système redémarrera automatiquement en mode INFINI avec pour seule pénalité le réveil des écrans OLED qu’il faudra éventuellement replacer en repos.
Le démonstrateur P16_Esclave_H.ino.
Également cloné à partir du démonstrateur précédent, le programme P16_Esclave_H.ino est directement extrait de son homologue P13_Esclave_G.ino pour déclencher avec certitude la Synchronisation entre les deux unités lorsque sur coupure secteur le courant électrique se rétablit. Dans ce but, comme le montre l’organigramme de la Fig.57, avant de passer en mode SYNCHRONISATION l’Esclave attend que les deux unités Bluetooth soient accouplées. Dans ce but, la sortie STATE du module électronique est surveillée par la broche D4 programmée en entrée binaire. Quand son état passe à « 1« , alors le système débute la phase de synchronisation. Moyennant ces deux modifications sur les unités extrêmes de la boucle, le système lors d’un test de fiabilité reprend du service avec certitude lorsqu’une coupure secteur inopinée vient le perturber. L’écran OLED affiche la page de la Fig.58 lorsque le programme est en attente de l’accouplement des deux unités radio. Dès que la communication est établie, alors les deux programmes passent en mode synchronisation. Enfin, cette dernière étant vérifiée, le système débute la boucle infinie pour laquelle les consignes sont générées automatiquement à la cadence maximale.
Intercaler le troisième Arduino.
Avant de songer à adjoindre l’INTERCALAIRE, il est sage de téléverser les deux démonstrateurs dans les unités actuelles, ne rien modifier électriquement et vérifier le comportement de l’ensemble. C’est alors que l’on pourra « couper » la ligne comme montré en Fig.59 et insérer le troisième Arduino. Fondamentalement, la logistique reste élémentaire. On commence par rechercher le dialogue entre Arduino 3 et Arduino 2. Dans ce but, on introduit le couple 
Bluetooth initial entre les deux unités, ce qui revient à couper la liaison radio qui était en A pour s’en servir en B. Il faut maintenant établir le circuit de données entre Arduino 1 et Arduino 3. Dans ce but on doit ajouter la liaison en C qui matériellement sera concrétisée par le deuxième couple Bluetooth complémentaire. Enfin, il faut encore développer le logiciel INTERCALAIRE qui doit satisfaire deux conditions :
• Se contenter de transmettre les données en voie montante et descendante sans les modifier,
• Démarrer avec une logique qui assure l’accrochage des trois machines au réseau sur RESET.
On se doute un peu que développer le programme ne sera pas vraiment élémentaire. Aussi, avant de faire intervenir les modules radio on va commencer par des liaisons filaires.
Développement du logiciel INTERCALAIRE.
Pour ne pas cumuler les nombreuses difficultés à mettre au point un tel réseau, on va donc commencer par éliminer les intermédiaires hertziens, c’est à dire les modules radio. Ainsi, remplacés par des liaisons filaires, il n’y aura aucun problème pour l’accouplement entre les quatre machines. En effet, la mise au point impose la présence d’un ordinateur à la fois pour développer le programme et le téléverser, mais également pour pouvoir transmettre les consignes manuellement. La structure du réseau ressemble alors à celle de la Fig.60 avec en vert la voie montante et en violet la voie descendante. Et encore, ce schéma est très simplifié car il ne montre pas le dialogue avec les Moniteurs de l’IDE simultanément ouverts pour suivre ce qui se passe sur chaque entité.
Comme sur chaque carte Arduino la ligne série USB sera réservée aux téléversements et aux dialogues avec les Moniteurs de l’IDE, on va devoir créer plusieurs lignes séries secondaires.
Première étape « filaire ».
Diviser les difficultés pour régner, telle sera notre stratégie. Dans cette première phase, nous allons assurer et vérifier le comportement entre INTERCALAIRE et l’Esclave. Les liaisons à réaliser sont résumées sur la Fig.61 qui montre que seul Arduino 3 est relié à la ligne USB de dialogue. C’est avec lui que l’on va transmettre les consignes manuellement et vérifier les ACR.
Noter que pour faire croire que les trois modules Bluetooth sont connectés, les entrés STATE D4, D10 et D12 sont reliées au +5Vcc. La ligne USB d’Arduino 2 n’est pas branchée pour simplifier, car on n’a pas vraiment besoin des informations du Moniteur de l’IDE, le contenu de l’ACR est suffisant même si c’est une carte NANO (NANO ou UNO.) classique et que OLED n’est pas disponible. Du coup il faut relier le +5Vcc entre les deux cartes. REMARQUE : Si vous décidez d’utiliser une ligne USB pour observer les dialogue, on peut laisser la ligne +5Vcc entre les deux cartes sans problème. Comme D3 et D8 ne vont pas sur l’entrée d’un module Bluetooth, le pont de résistances n’est pas utile. Il reste à vérifier le bon fonctionnement entre les deux cartes avec P16 et P17 :
Le dialogue entre les deux unités est confirmé et le programme semble fonctionner parfaitement. On va pouvoir passer à la deuxième phase mais avant, testez toutes les commandes.
Deuxième étape « filaire ».
Lors de cette deuxième phase il faut établir la liaison filaire entre l’INTERCALAIRE et l’unité Maître. Pour avoir un retour, on ne change strictement rien à ce qui a déjà été branché. On va se contenter d’intercaler entre le P.C. et l’unité INTERCALAIRE le module Maître alimenté par sa ligne USB1. C’est ce module qui sera en dialogue 
manuel avec le Moniteur de l’IDE du PC. On va également alimenter Arduino 3 avec sa ligne série sur une autre entrée USB2 de l’ordinateur. Il sera ainsi possible d’observer ce qui se passe sur les deux premiers maillons du réseau. La structure de la Fig.62 présente les nouvelles liaisons filaires à établir pour compléter le circuit initial. Comme c’était le cas pour Arduino 3 on fait croire que le module Bluetooth fictif est connecté en reliant D7 au +5Vcc. Les deux lignes issues de D1 et de D3 n’ont pas besoin des résistances de limitation de tension. Nous sommes toutefois confrontés à un problème assez épineux qui va nous compliquer un peu les expérimentations. En effet, sur l’unité INTERCALAIRE on a utilisé la ligne série secondaire émulée avec la bibliothèque SoftwareSerial.h qui nous limite à une seule ligne de type UART.
La première difficulté, c’est que seule la ligne USB standard Serial.begin(38400) reste disponible pour dialoguer avec le Bluetooth qui sera branché en entrée. Mais la présence de ce dernier va parasiter les échanges de données lors du téléversement du démonstrateur. Il importe donc d’intercaler provisoirement un double interrupteur sur cette ligne comme visible sur la Fig.63 et montré sur la photographie de la Fig.64 qui présente ce composant provisoire avec un dispositif faisant partie des accessoires de développement du laboratoire. Naturellement il serait tout à fait possible d’ouvrir et de fermer ces deux lignes filaires manuellement en déplaçant deux fils sur les platines d’essais. Mais c’est vraiment peu commode, et en phase de développement et de finalisation du démonstrateurs, il faut effectuer de nombreuses modifications. Aussi, il est vital que la manipulation soit facile et rapide à mettre en œuvre.
La deuxième difficulté réside dans la différence de comportement dont doit faire preuve le démonstrateur P17 entre la phase de développement du ProGRamme et celle de l’UTilisation en mode expérimentation normale. En effet, lors de la mise au point du programme, on se trouve dans la configuration de la manipulation précédente, c’est à dire que pour envoyer les consignes à l’Esclave on utilise D0 d’Arduino 3. En expérimentation de la chaîne complète, les consignes sont envoyées par Arduino 1 sur sa sortie D3. Elles s’affichent naturellement dans la fenêtre contextuelle du Moniteur propre à Arduino 3. Il faut interdire à P17 de les afficher comme c’est le cas en phase de développement, car elles sont alors considérées comme l’ACR par le Maître et la chaîne de transmission se bloque. C’est la raison pour laquelle en phase TESTER on doit interdire à P17 d’afficher la consigne reçue dans la fenêtre contextuelle de son Moniteur. Il ne reste plus qu’à faire dialoguer ce trio infernal faisant ménage à trois sans que ça ne soit la foire d’empoigne :
Fonctionnement en totale autonomie.
Arriver à un fonctionnement totalement autonome avec synchronisation automatique n’est pas du tout évident. Avec les démonstrateurs P15 à P17 vous disposez d’un ensemble « clef en main », c’est à dire que si vous respectez exactement les schémas de la Fig.61 à Fig.63 le groupe matériel et logiciel ne peut que fonctionner, et ce quelles que soient les trois cartes Arduino mises en circuit. Il nous reste toutefois à nous assurer que l’ensemble fonctionne bien en totale autonomie et que la synchronisation se produise avec certitude :
Les trois entités démarrent simultanément et la synchronisation s’obtient après un petit délai inférieur à trois secondes. Comme l’on n’a pas cliqué sur le bouton poussoir de D4 le système amorce en mode « boucle INFINIE » propice à des essais d’endurance et de fiabilité. Après affichage d’un groupe de commandes, quand on arrive au premier ‘Y‘ les trois écrans s’éteignent automatiquement. On peut ainsi laisser fonctionner durant plusieurs jours pour tester la fiabilité des échanges de données. Ce sera pertinent lorsque les modules Bluetooth seront installés. En cliquant sur le bouton poussoir de D5 on peut à tout moment réactiver les afficheurs pour observer ce qui se passe et le nombre d’alternats effectués. Puis rendormir les écrans pour continuer le test en cours. Si une coupure secteur se produit en notre absence, la seule pénalité est la remise à zéro du compteur d’alternats. Les écrans se replacent automatiquement en mode économique. Pour nous convaincre que le système redémarre proprement à chaque interruption inopinée du secteur 220V~ couper et rétablir plusieurs fois l’interrupteur de la ligne multiprise. On peut alors sereinement envisager la suite.
La suite est ICI.
