Arduino et bluetooth (HC-06 ou HC-05)

Pour beaucoup d’applications, il est utile de déconnecter l’arduino de l’ordinateur pour lui donner de la mobilité. Je veux donc pouvoir utiliser des applications android permettant de commander un montage arduino. Dans cette première partie d’une série () sur le bluetooth et arduino, j’explique comment régler les modules HC-O6 ou HC-05 (commandes AT). 

Les modules bluetooth HC-05 et HC-06

Il existe deux sortes de module bluetooth, tous deux compatibles arduino et utilisables sur un breadboard (plaque d’essai en français). On les distingue par le nombre de pattes d’entrées / sorties :

  • HC-05 : 6 sorties. Ce module peut être « maître » (il peut proposer à un autre élément bluetooth de s’appairer avec lui) ou « esclave » (il ne peut que recevoir des demandes d’appairage). Ce module fait l’objet d’un autre article car il y a quelques différences pour le régler.
  • HC-06 : 4 sorties. Ce module ne peut être qu’esclave. C’est ce module que nous utilisons dans cet article.

Les deux modules peuvent être utilisés en mode COMMANDE, pour les programmer avec des « commandes AT »,ou en mode DATA, pour échanger des données.

Le montage pour HC-06

Noter que TXD et RXD du module BlueTooth HC-06 doivent être « inversés » : TXD arrive au port RX de l’arduino (soit le port #3 dans les sketch qui suivent) et RXD au port TX de l’arduino (#2 ici).

Noter aussi le diviseur de tension pour la liaison RXD à TX (#2) : la tension d’entrée des données doit être de l’ordre de 3.3V et non 5V.

Schéma des connexions

Attention, à chaque fois qu’on téléverse un nouveau sketch dans l’arduino, par la connexion USB de l’ordinateur à l’arduino, il faut déconnecter RX. Durant le téléversement l’arduino ne doit avoir qu’une seule connexions série. 

Commandes AT pour module bluetooth HC-06

Par défaut les modules HC-06 sont réglés sur une vitesse de 9600 bauds. C’est donc la vitesse de communication que l’on choisira pour ce programme lorsqu’on l’utilise sur un module qu’on vient d’acheter.

Le sketch est fortement inspiré de l’article « Module bluetooth JY-MCU V1.04 pour Arduino« .

Le sketch complet est disponible ici, sur GitHub. Voici quelques explications sur son fonctionnement.

ATTENTION !!! Pour que ce sketch fonctionne, le module HC-06 ne doit PAS être appairé (sa led doit clignoter). 

#include <SoftwareSerial.h>  demande à l’arduino d’utiliser la librairie SoftwareSerial.h, nécessaire pour que l’arduino puisse utiliser deux connexions séries distinctes, l’une avec le PC, l’autre avec le module BlueTooth. J’en explique le fonctionnement plus bas.

Dans notre cas, la liaison série entre arduino et module bluetooth s’appelle BTSerie , tandis que celle entre l’ordinateur et l’arduino s’appelle Serial .

On utilise l’ordinateur pour taper les commandes. La console doit être réglée (en bas à droite), à la même vitesse que celle indiquée dans Serial.begin(). Et le réglage à côté doit être sur « Pas de fin de ligne« .

Si je tape AT , l’arduino répond « OK ».

Si je tape AT+NAMEname , l’arduino répond « OKSetname » et le module bluetooth prend le nom « name ».

Enfin si je tape AT+BAUD9 , l’arduino répond « OK230400 », ce qui signifie que le module bluetooth a reçu l’instruction de se régler à une vitesse de 230 400 bauds. 9 peut être remplacé par 1 à 8 ou A, B, C. Les vitesses correspondantes sont :

code Vitesse (bauds)
1 1 200
2 2 400
3  4 800
4  9 600
5  19 200
6 38 400
7 57 600
8 115 200

Attention, on peut régler le module bluetooth à des vitesses supérieures à 115 200 bauds mais dans ce cas on ne peut pas utiliser un arduino car il ne peut pas dépasser cette vitesse.

Pour plus de détails sur toutes les commandes disponibles, voir ce pdf en ligne.

La boucle de notre sketch contient les éléments suivants :

la première partie lit le contenu de ce qui est transmis par le module bluetooth via BTSerie.read() puis l’imprime sur la console de l’ordinateur.

La seconde partie lit ce qui est écrit dans la console de l’ordinateur par l’utilisateur et l’envoie au module bluetooth.

Nos commandes AT sont ainsi transmises au module Bluetooth et sa réponse est affichée sur la console arduino de l’ordinateur.

Les commandes sont appliquées lorsque le module est éteint puis rallumé.

Montage pour HC-05

On utilise presque le même montage que ci-dessus, à 3 différences près :

  • on n’utilise pas de résistances diviseuses de tension (rien ne prouve que c’était indispensable dans le montage du HC-06)
  • Le HC-05 a 6 pattes au lieu de 4, avec en plus STATE, que l’on n’utilise pas, et EN ou KEY, que l’on connecte à la sortie 3.3V de l’arduino.
  • On doit appuyer sur le petit bouton poussoir au dessus de la patte EN (ou KEY) lorsqu’on met l’arduino sous tension. Sinon, la led du HC-05 clignote rapidement, ce qui signifie qu’elle cherche à s’appairer et pas du tout à recevoir des commandes AT. Si le démarrage est correctement fait la led du HC-05 clignote lentement, toutes les 2 secondes environ.

Commandes AT pour le module HC-05

Le sketch ci-dessus ne fonctionne pas avec un HC-05, même démarré correctement (la led clignote lentement) pour 3 raisons :

  • les commandes AT ne sont pas strictement identiques (noter le ? à la fin de BTSerie.print("AT+VERSION?");  et l’existence de la ligne BTSerie.print("\r\n");  juste après  ;
  • la vitesse par défaut d’un HC-05 est 38 400 bauds et pas 9 600 comme pour le HC-06 ;
  • La console série de l’ordinateur d’où l’on envoie les commandes AT ne doit pas être réglée pareil : elle doit être réglée de telle sorte que les fins de ligne soient « les deux, NL et CR », ce qui revient à envoyer \r\n à la fin de chaque commande.

Réglage de la console série de l'arduino avec HC-05

Le sketch qui fonctionne est disponible ici (Sketch Bluetooth HC-05 pour commandes AT (.ino)) ou sur github.

Lorsque tout est correct, la console série sur l’ordinateur affiche les éléments suivants :

Les deux dernières lignes correspondent au retour du module bluetooth provoqué par cette partie du sketch :

Les commandes AT utilisables avec un HC-05

Des « questions » au module, avec les réponses associées :
  • AT : si tout va bien, le module répond OK
    AT+NAME? : le nom du module + OK
    AT+VERSION? : Sa version + OK
    AT+UART? : sa vitesse, et OK (par exemple +UART:38400,0,0  )
    AT+ROLE?: Son rôle (1=master /0=slave)
    AT+PSWD?: le mot de passe (en général +PSWD:1234  ) lorsque le mot de passe par défaut (1234) a été conservé.
Des ordres au module

Pour plus d’informations, voir ce pdf ici.

  • AT+NAME=NoRobo-HC-05 –> OK mais bizarrement AT+NAME? ne dit pas quel est le nom du module
  • AT+UART=57600,0,0 règle la vitesse à 57600 bauds et AT+UART? renvoie bien +UART:57600,0,0

Les commandes sont appliquées lorsque le module est éteint puis rallumé.

HC-05 visible d'un appareil androidLorsque je rallume mon circuit (sans appuyer sur le bouton du HC-05 !), la led du hc-05 clignote rapidement et mon téléphone android voit bien un appareil nommé NoRobo-HC-05 ! Tout est donc parfait.

Conclusion de ce premier article

Maintenant que nous avons réglé le module bluetooth (HC-05 ou HC-06) à une vitesse de 57 600 bauds et lui avons donné un nom, il est temps d’aller voir comment utiliser une application android avec notre montage arduino. Ce sera l’objet du deuxième article de cette série () sur le bluetooth et arduino.

25 commentaires


  1. Anne-Laure va commencer à croire que je squatte son site… Mais voila les dernières trouvailles et elles sont surprenantes…
    1) Le HC-06, une fois paramétré, garde ses réglages. Donc si je lance le Sketch la toute première fois je vais faire BTSerie.begin(9600); puisque le HC est à cette vitesse (apparemment) en sortie d’usine. Si ensuite je fait un AT+BAUD5, il va passer à 19200 bauds. Si maintenant je relance le Sketch, je ne pourrais plus régler le HC. Pour pouvoir à nouveau le régler, il faudra modifier le Sketch pour mettre BTSerie.begin(19200); donc la vitesse actuelle du HC.
    2) Ayant réussi à changer le nom, le code PIN et mis la vitesse à 115200, j’ai commencé à pousser les essais plus loin. Je bosse sur un système d’accès avec code. A ma grande surprise, j’ai eu des réponses de l’Arduino du genre « Code faux » alors que le code envoyé était le bon… En mettant un Log côté Android pour voir le code que j’envoyais et un Serial.print du code reçu, j’ai constaté avec stupeur que je ne recevais pas exactement ce que j’avais envoyé!! En gros, on a jusqu’à 5% des octets qui sont faussés! Après pas mal de recherche, la cause est simple: la bibliothéque SoftwareSerial est bugguée. Elle n’est pas bonne au niveau de la gestion des interruptions et de divers autres trucs. En fait elle est fiable jusqu’à 19200 Bauds, mais pas après… Or à 19200 Bauds, ça pèdale dans la choucroute (ou dans le kig a farz). Et pour Julie qui voulait savoir comment transmettre des images, ça va pas le faire.

    Problème? Solution!
    L’Arduino a 2 PINs pour la com série: 0 et 1. Comme on veut une com série avec le HC et une avec le moniteur série, on est bien embêté (2 liaisons nécessaires pour une seule dispo). On utilise donc SoftwareSerial qui crée un autre port série virtuel, par exemple sur les PIN 10 et 11 de l’Arduino (ou ici, dans le code d’Anne-Laure, sur les PIN 2 et 3). Anne-Laure écrit donc avec Serial.print vers le moniteur en passant par le hardware et les PIN 0 et 1 et elle utilise aussi SoftwareSerial pour faire des BTSerie.write qui eux passent par la biblio et utilisent les PIN 2 et 3, pour communiquer avec le HC.
    Dés qu’on passe à + que 19200 Bauds, cette écriture virtuelle ne fonctionne plus correctement. La solution c’est de coder « en aveugle ». En clair, on utilise plus SoftwareSerial et on branche directement le HC sur les PIN 0 et 1. On recevra donc du HC avec Serial.read() et on lui écrira avec Serial.write(). On aura donc un « hardware serial » et plus un « software serial » et on pourra bosser à 115200 Bauds, ce qui permettra à Julie de transférer ses images.
    Pour débugger, il restera pas exemple à mettre un petit écran LCD sur l’Arduino. Moins facile que le moniteur, mais au moins, ça marchera.

    Répondre

    1. Merci Pierre-Louis pour toutes ces informations !
      Lorsque je réutiliserai un HC-06 ou 05, je reviendrai lire tout ça pour le mettre en pratique.
      Tu es le bienvenu pour « squatter » ce site, tu peux même y écrire un article complet si tu le souhaites.
      Anne-Laure

      Répondre

    2. Merci Pierre-Louis pour cette aide. J’ai enfin pu brancher mon module sur ma uno !!

      Répondre

  2. Bon, en fait ça ne marche pas super bien…

    Si on veut comprendre ce qui se passe, il suffit de modifier la partie du sketch qui lit le port série et qui envoi au Bluetooth. Au lieu d’envoyer directement le caractère au Bluetooth, on le renvoi d’abord au terminal pour voir ce que l’Arduino a reçu.
    On va alors constater un truc bizarre: le Bluetooth commence à répondre AVANT d’avoir reçu toute la commande.
    Ainsi, si je tape « AT+VERSION? » et que je « échoe » ce que j’envoi + ce qu’il répond, je vois s’afficher « AT+OVKERSION? ». En clair, dés que le HC a reçu les 2 premiers caractères, donc « AT », comme c’est un ordre pour lui, cet imbécile répond, sans attendre la suite!
    Par contre, que je lui envoi les ordres d’un coup par exemple:
    BTSerie.write(« AT+NAMEMyNewName »);
    là, ça marche puisqu’il reçoit tout d’un coup.
    La solution consisterait donc à bufferiser les données reçues par le Terminal, tout concaténer et quand c’est prêt, on balance tout au HC.

    Répondre

    1. Je répond à mon message suite à de nouveau tests qui expliquent pourquoi on a un manque de fiabilité. Le HC-05 et le HC-06 diffèrent par un point fondamental: sur le HC-05 les ordres AT sont suivis d’un retour de fin de ligne mais PAS sur le HC-06. Or TOUTES nos difficultés viennent de là.
      Exemple: sur un HC-05, je vais envoyer « AT+NAMECoucou*AT « avec * symbolisant le retour à la ligne. Le HC-05, se repérant sur ce retour, va savoir que je lui ai envoyé 2 ordres (« AT+NAMECoucou » puis « AT »). Mais sur un HC-06, comme je n’ai pas de séparateur, je vais envoyer « AT+NAMEcoucouAT ». Question: est-ce que le HC-06 va ensuite s’appeler « coucouAT » ou bien va-t-il s’appeler « coucou » et ensuite me répondre « OK »? Et bien tout dépend de la vitesse de transmission!

      1) il faut transmettre la TOTALITE de chaque ordre super vite. Dont si vous lisez octet par octet ce qui vient du port série, que cette liaison est lente et/ou que vous réalisez des traitements, vous allez envoyer votre ordre très lentement. C’est ce qui expliquait le résultat décrit dans mon message précédent avec AT+VERSION qui en fait était considéré comme un simple ordre « AT » suivi de truc que le HC-06 ne comprenait pas. Et évidement, cela va dépendre de l’ordre que vous envoyez puisque « AT » tout seul va marche mais d’autres ordre ne vont pas marcher! 🙁

      2) il faut laisser du temps entre les ordres. 1 seconde parait un minimum. Mais là encore, cela dépend des ordres. Par exemple pour un « AT+NAMEcoucou » comme ordre numéro 1 et « AT » comme ordre numéro 2, sans delay entre les deux il y a de forte chance que le HC-06 prenne ça comme « AT+NAMEcoucouAT » et pas comme 2 ordres distincts.

      Pour le fun, je me suis rendu compte de ça pour une raison simple: je développe une application couplant de Android, Arduino et PHP pour gérer l’ouverture de portes de casernes de pompiers, au Brésil. Le programme se nomme « Sésame ouvre-toi », ce qui, en Portugais et en abrégé donne… « ATS ». J’avais donc décidé (super idée!) de renommer ma carte HC-06 « ATS » ce qui donnait évidement « AT+NAMEATS »….
      J’y retourne!

      Répondre

      1. Pour lecture, data sheet du HC-06:
        https://www.olimex.com/Products/Components/RF/BLUETOOTH-SERIAL-HC-06/resources/hc06.pdf
        1) l’intervale entre les ordres et d’une seconde
        2) le nouveau nom, le nouveau code PIN et la vitesse en Bauds restent valident même si on débranche le module.
        3) les commandes AT ne sont acceptées par le module que si celui-ci n’est pas « couplé ».

        Des points 3 et 4, on déduit:
        1) ne PAS mettre les ordres de changement de nom, de PIN et de vitesse dans le setup() de votre sketch car sinon à chaque fois que vous allez lancer le sketch, cela va tout re-régler ce qui ne sert à rien. Il faut donc faire un premier sketch qu’on va lancer une seule fois et qui va faire les réglages et ensuite bosser avec un autre sketch qui ne refera pas les réglages!
        2) si vous faites un sketch comme celui d’Anne-Laure c’est à dire un sketch qui ne communique pas avec un autre périphérique, ça ira. Par contre dés que vous aurez une app Android donc un appareil « couplé » avec votre HC-06, si vous continuer à avoir de l’init de nom PIN et vitesse dans le setup() de votre sketch, plus rien ne va marcher! Pour ma part, en continuant à envoyer les ordres AT alors que le HC-06 était couplé, j’ai complètement bloqué le module qui ne comprend plus rien, ne change plus de nom, reste visible mais n’accepte plus de data etc… 🙁

        Répondre

  3. J’ai pas mal réfléchis cette nuit et je pense avoir un début de réponse si ça peut vous aider.
    Il semblerais qu’une fois le message envoyé, l’arduino y obéit jusqu’à ce qu’il y ai un nouvel ordre.
    Je pense donc qu’il faudrait que l’arduino génère à intervalle régulier l’ordre précédemment donné.
    j’ai tenté ce changement pour arriver à cette conclusion:

    while (BluetoothData == ‘1’) {
    digitalWrite(trig, HIGH); //partie du programme qui me
    delayMicroseconds(10); //permet de calculer une distance
    digitalWrite(trig, LOW); //…
    lecture_echo = pulseIn(echo, HIGH); //…
    cm = lecture_echo / 58; //…
    if (cm<50){
    digitalWrite(motor1Pin1, LOW);
    digitalWrite(motor1Pin2, LOW);
    digitalWrite(motor2Pin1, LOW);
    digitalWrite(motor2Pin2, LOW);

    }else{

    digitalWrite(motor1Pin1, LOW);
    digitalWrite(motor1Pin2, HIGH);
    digitalWrite(motor2Pin1, LOW);
    digitalWrite(motor2Pin2, HIGH);
    break;

    mais le problème est que si la distance est trop importante lorsque l'ordre est donné, alors l'ordre ne peut être arrêté en s'approchant d'un obstacle. Je pense donc qu'une fois le else{} finit, la boucle doit recommencé au début et l'arduino doit régénérer lui même l’ordre du bluetooth.

    Répondre

      1. merci beaucoup,
        Je vais essayer et je vous tiens au courant.
        bonne journée

        Répondre

  4. Bonjour,
    Ce tutoriel est très bien fait merci beaucoup.
    Il y à peu j’ai fais un véhicule commandé par bluetooth, il fonctionne très bien mais j’ais voulus avec un module HC-SR04 faire que mon véhicule s’arrête si un objet se trouve proche de lui (une sorte de sécurité en gros).
    Seulement, la télécommande bluetooth n’est pas désactivé par l’arduino et mon véhicule ne s’arrête pas.
    Est-ce que vous savez comment faire pour que l’ordre bluetooth ne soit pas obéit.
    cordialement

    Répondre

    1. Bonjour Martin,
      Merci pour votre commentaire.
      A priori il faut qu’il y ait une « interruption » durant laquelle les données du détecteur sont analysées et éventuellement prennent le pas sur les instructions transmises par bluetooth.
      Le sujet des interruptions est complexe et je le maîtrise encore très mal. Mais j’aimerais bien essayer de reproduire votre véhicule et ce problème. Donc si vous voulez me communiquer photos, instructions de montage et code actuel de votre véhicule, ça m’intéressera d’essayer de trouver une solution !
      Anne-Laure

      Répondre

      1. #include
        SoftwareSerial Genotronex(10, 11);
        int BluetoothData;
        int motor1Pin1 = 3;
        int motor1Pin2 = 4;
        int enable1Pin = 9;
        int motor2Pin1 = 2;
        int motor2Pin2 = 7;
        int enable2Pin = 5;
        int trig = 13;
        int echo = 12;
        long lecture_echo;
        long cm;

        void setup() {
        Genotronex.begin(9600);
        Genotronex.println(« Bluetooth 0 1 ou 3 .. »);
        pinMode(motor1Pin1, OUTPUT);
        pinMode(motor1Pin2, OUTPUT);
        pinMode(enable1Pin, OUTPUT);
        pinMode(motor2Pin1, OUTPUT);
        pinMode(motor2Pin2, OUTPUT);
        pinMode(enable2Pin, OUTPUT);
        pinMode(trig, OUTPUT);
        digitalWrite(trig, LOW);
        pinMode(echo, INPUT);
        digitalWrite(enable1Pin, HIGH);
        digitalWrite(enable2Pin, HIGH);
        }

        void loop(){

        if (Genotronex.available()) {
        BluetoothData = Genotronex.read();

        if (BluetoothData == ‘0’) {
        digitalWrite(motor1Pin1, LOW);
        digitalWrite(motor1Pin2, LOW);
        digitalWrite(motor2Pin1, LOW);
        digitalWrite(motor2Pin2, LOW);

        }
        if (BluetoothData == ‘1’) {
        digitalWrite(motor1Pin1, LOW);
        digitalWrite(motor1Pin2, HIGH);
        digitalWrite(motor2Pin1, LOW);
        digitalWrite(motor2Pin2, HIGH);

        }
        }
        if (BluetoothData == ‘2’) {
        digitalWrite(motor1Pin1, HIGH);
        digitalWrite(motor1Pin2, LOW);
        digitalWrite(motor2Pin1, LOW);
        digitalWrite(motor2Pin2, HIGH);

        }
        if (BluetoothData == ‘3’) {
        digitalWrite(motor1Pin1, LOW);
        digitalWrite(motor1Pin2, HIGH);
        digitalWrite(motor2Pin1, HIGH);
        digitalWrite(motor2Pin2, LOW);

        }
        if (BluetoothData == ‘4’) {
        digitalWrite(motor1Pin1, HIGH);
        digitalWrite(motor1Pin2, LOW);
        digitalWrite(motor2Pin1, HIGH);
        digitalWrite(motor2Pin2, LOW);
        }
        }

        voila j’ai mis au début quels broches j’utilisais pour le module ultrason mais je n’ais pas mis d’ordre dans le programme car je ne sais pas comment les intercaler dans mon programme

        Répondre

        1. j’utilise un L293DNE pour le controle des moteurs

          Répondre

          1. je ne parviens pas à envoyer de photos dsl.


  5. Bonjour,
    Comment récupérer des images à travers un HC-06 svp?
    Merci d’avance

    Répondre

    1. Bonjour Julie
      Je ne sais pas comment on peut transmettre des images au travers d’un dispositif bluetooth. Je pense qu’il faut plutôt utiliser l’appareil connecté (un PC ? un téléphone ?) pour aller chercher le fichier sur l’arduino. Dites-nous si vous avez trouvé une solution et partagez-la.

      Répondre

    2. Je pense que la solution passe par un encodage de ton image en Base64. La question qui se posera sera surtout celle de la taille. Je doute fort que ton Arduino ait assez de place pour stocker. Si tu veux t’en servir pour simplement servir de « pont » entre deux autres systèmes (par exemple un PC d’un côté et une tablette de l’autre), j’aurais tendance à opter pour un découpage des données en petites paquets: ton PC envoi un petit paquet de données à l’Arduino, celui-ci répond « OK j’ai reçu », puis les envoi à la tablette, puis l’Arduino demande la suite au PC et ainsi de suite. Mais tout dépend beaucoup de ce que tu veux faire et des appareils que tu mets en oeuvre.

      Répondre

  6. Bonjour,

    J’ai effectué la même démarche pour le HC 05 mais sur le moniteur série j’ai tout jusqu’ à « -1 » uniquement. Aprés rien du tout quel est le problème svp?

    Mercii

    Répondre

    1. Bonjour,
      Je ne sais pas répondre à cette question, désolée.
      êtes-vous sûre qu’il s’agit d’un hc-05 ?
      Anne-Laure

      Répondre

  7. Bonjour, merci pour ce tuto très bien expliqué !
    J’ai actuellement un hc-06 et un hc-05 que j’aimerais connecter ensemble pour pouvoir faire communiquer deux arduino(s) grâce à une liaison série. Le hc-06 serai esclave et le hc-05 serai maître, mais comment puis-je les associer ?
    Que faut-il faire pour gérer le connexion et l’association automatique des que les deux modules sont alimenté?
    Pas de soucis pour contrôler une led avec un smartphone, mais je n’ai aucunes idées pour connecter deux modules ensemble.
    Bien à vous.

    Répondre

    1. Bonjour Anatyber
      Merci.
      Je n’ai jamais fait ce genre de connexion, mais je viens d’aller regarder sur ce site, en anglais, dans la partie « pairing and bonding ». Ca me parait bien fait et assez simple.

      Tenez nous au courant !
      Anne-Laure

      Répondre

  8. Bonjour,

    Tout d’abord, merci pour ce tuto, il me sera bien utile 🙂
    J’aurais aimé savoir quel est la version du protocole bluetooth géré par les modules HC-05 et HC-06?

    Répondre

    1. Bonjour Raphael,
      Merci pour ce commentaire.
      J’ai cherché sur une fiche technique d’un module hc-05 et le protocole supporté est Bluetooth 2.0+EDR.
      Je ne sais pas pourquoi ça peut être important de savoir quel est le protocole supporté. J’imagine que c’est lié aux protocoles supportés par l’appareil client. Un ami a un smartphone ancien et il ne peut pas se connecter à mon module bluetooth. Les personnes qui ont des smartphones plus récents (android ou ios)y arrivent sans difficulté.
      Cordialement,
      Anne-Laure

      Répondre

  9. bonjour,
    a propos de l’ ino hc06
    schema avec le hc06 pretant a confusion :
    dans le sketch disponible sur github, vous déclarez la pin2 en INPUT
    donc la pin 2 arduino doit recevoir les data du hc06 ligne tx de celui-ci
    les fleches indiquent que rx pin 0 d’arduino devient pin3 avec sofwaresérial,
    dans l’en tete de l’ino le plan de cablage indiqué est correct
    * cablage btooth -> arduino
    * VCC –> +5V
    * GND –>GND
    * TXD –> Pin 2 (RX)
    * RXD –> Pin 3 (TX)
    inutile de pinmode dans le setup
    //pinMode(RxD, INPUT);
    //pinMode(TxD, OUTPUT);
    softwareserial le fait automatiquement

    cordialement

    Répondre

    1. Merci ‘Elektrax’ pour vos commentaires.
      C’est vrai, dans le schéma, RX devrait aller vers 2, TX vers 3….
      On a bien TXD du HC-06 qui se connecte à la broche 2 de l’arduino et RXD du HC-06 vers la broche 3 de l’arduino.

      Cordialement
      Anne-Laure

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *