Bluetooth Modul HC-06-20190901

Hallo zusammen,

ich habe vor kurzem eine neue Charge HC-06 Module bekommen.
Diese haben die Version HC-06-20190901.
Soweit, so schlecht.

Bisher habe ich relativ einfach, drei unterschiedliche Arten von BT-Modulen identifizieren können:

  1. AT + 1s delay
  2. AT + Newline
  3. AT + Newline & Baudchange mit "AT+UART=57600,0,0" (Bluetooth LE)

Dazu habe ich mir eine simple "Erkennung" gebaut, welche in einer Schleife alle Baudraten durchgeht und lauscht, ob auf "AT" etwas zurück kommt.
Einmal mit Zeilenumbruch, einmal mit delay(1000).
Anschließend hole mir die Version des Moduls und ändere die Baudrate, sofern notwendig.

Das hat einige Tests erfordert bis die Methode ganz passabel funktioniert. Bis zu eben diesem o.g. Modul!

Es scheint so, als braucht es mehr als eine Sekunde, nachdem die Spannung anliegt, dass es überhaupt reagiert.
Ein AT-Command wird nicht nach einer Sekunde, sondern nach rund 1200ms quittiert.
Aber auch nicht immer :see_no_evil:

Wenn ich die Baudraten durchgehe, muss ich etwa 2 Sekunden nach einem Fehlversuch warten, bis das Modul den Buffer leert.
Doch auch hier gleicht das einem Roulettspiel ob es funktioniert oder nicht.
Selbst wenn ich meinen Sketch großflächig mit delay´s ausstatte, wird das Modul nicht korrekt erkannt.
Das kann leider auch nicht Ziel der Übung sein, dass der Start mehrere Sekunden dauert. Verbindet sich nämlich in der Zwischenzeit ein Gerät mit dem Modul, landen die AT-Befehle dort. Bei der Ersterkennung zu verschmerzen, jedoch nicht bei jedem Start.

Selbst nachdem ich die Baudrate manuell geändert habe und meinem Arduino die richtige Version in den EEPROM brenne ist es eine 50-50 Chance, ob eine Reaktion auf ein AT kommt.
-> Getestet mit verschiedenen Modulen, direkt an einem Nano und auf einem eigenen Board mit ATMega328. Die 3,3V an RX & TX berücksichtigt!

Natürlich habe ich mir gleich 10Stck davon bestellt :roll_eyes:

Hat jemand Erfahrung mit solch einem störrischen Verhalten oder gar dieser Version?
HC-06-20190901

PS eine ältere Version der Erkennungsfunktion habe ich noch hier. Muss ich mal auf den neusten Stand bringen :muscle:t2:

Möglicherweise habe ich des Rätsels Lösung bereits gefunden!

Durch das Ausprobieren der korrekten Baudrate mülle ich den Puffer vom HC-06 voll.
Die anderen Module scheinen offensichtlich im AT-Mode nach ca. 1 Sekunde den Puffer zu leeren, wenn nichts anständiges drin steht, dieses jedoch nicht.

Also muss ich "einfach" den Puffer weniger zumüllen!
Ändere ich die Prüfung von Baud 4800 -> 115200 einfach andersherum, scheint es zu klappen!

long BtFindCurrentBaud() {
  static const long rates[] = { 4800, 9600, 19200, 38400, 57600, 115200 };
  uint8_t numRates = sizeof(rates) / sizeof(long);  //6
  //for (int rn = 0; rn < numRates; rn++) {
  for (int rn = numRates-1; rn >= 0 ; rn--) {
    BT.begin(rates[rn]);        
    delay(200);
    PrintBtAt();
    BT.flush();
    if (btVersion >= 3)
      delay(100);
    else
      delay(BT_Cmd_Delay);  //No Linefeed, but 1Sec idle

    if (BtDataAvailable())
      return rates[rn];
  }
  return 0L;
}

void PrintBtAt() {
  if (btVersion >= 3)
    BT.println(F("AT"));
  else
    BT.print(F("AT"));  
}

bool BtDataAvailable() {
  if (BT.available()) {
    //Read what´s on the buffer
    while (BT.available())
      BT.read();
    return true;
  }
  return false;
}

Durch die zu hohen Baudraten kommt offensichtlich nix an und somit bleibt der Puffer zumindest einigermaßen leer.
Nun gilt es meine anderen BT-Module zu testen, ob die nicht allergisch auf diese Anpassung reagieren...

Was ein Gefrickel...

Die anderen HC-06 Module haben sich von der Anpassung glücklicher Weise unbeeindruckt gezeigt.
Aktuell funktioniert es mit folgenden Versionen:

Beschriftung AT+Version Zeilenumbruch AT-Delay
ohne HC-06-20190901 Nein ~1200
FC-114 hc01.comV2 Nein 1000
1744 VERSION:3.0-20170609 Ja 0
ZS-40 Firmware V3.0.6,Bluetooth V4.0 LE Ja 0
ZS-040 DX_smartv2.0 Nein 1000

Es müssen allerdings für das erst genannte Modul beim Start gut 1-2 Sekunden gewartet werden.
Dann läuft die Erkennung erst mit Zeilenumbruch, anschließend ohne.
Mit der höchst möglichen Baudrate beginnend. Nach BT.begin() warte ich 200ms.
Zwischen den AT-Befehlen warte ich aktuell 2 Sekunden, bevor ich auf eine Reaktion prüfe.

Daher dauert bei der ersten Verwendung das Ganze schon recht lange, da das aber nach dem FW brennen passiert ist das nicht Zeitkritisch.
Anders sieht es beim regulären Start aus, wo ich mindestens 2 Sekunden warten muss, bis das BT-Modul "warmgelaufen" ist.
Dann der Sicherheits-Check ob die Baud-Rate + Version passen und erneut 2 Sekunden auf die Antwort warten...
Nach reiflicher Überlegung ist das Überflüssig! Sobald die Bluetooth Version im EEPROM != 0xff ist, sollte alles passen! Also fire & forget :grimacing:
Das erfordert natürlich, sofern irgendwas bei der Initialisierung fehlschlägt, die Version intern immer wieder auf 0xff gesetzt wird, bis es klappt.

Vielleicht hilft es ja jemandem.

Hallo allerseits

Ich glaube, ich habe das gleiche Problem wie du sagst. Da die Module mit der Version HC-06-20190901 ankommen, kann ich nichts so Einfaches wie die Geschwindigkeit des Moduls ändern.

Ich kann nicht alles verstehen, was es erklärt, vielleicht wegen des Übersetzungsproblems Deutsch-Spanisch.

Könnten Sie mir den richtigen Weg zum Ändern der Geschwindigkeit in diesen Modulen (in meinem Fall 38400) sagen und überprüfen, ob die Änderung erfolgreich durchgeführt wurde.

Dankeschön.

Mit Google Übersetzer erstellt


Hi everyone

I think I have the same problem as you say. Since the modules arrive with the HC-06-20190901 version, I cannot do something as simple as modifying the speed of the module.

I can't understand everything it explains, perhaps because of the German-Spanish translation problem.

Could you tell me the correct way to change the speed in these modules (in my case 38400) and verify that the change has been made successfully.

Thank you.

Made with google translate

Hallo @cas6678,
ich habe mein Gist auf GitHub mit meinem aktuellen Stand aktualisiert.
Ist allerdings aus meiner Lösung etwas zusammen kopiert und kompilierbar gemacht.
Also nicht unbedingt schön oder 1:1 zu übernehmen.

Vielleicht hilft es Dir ja!


Hello cas6678,
I´ve updated my gist to my latest findings.
The code is just copy ´n pasted from my unique solution and just made to compile. So don´t expect clean code or using it as is :smiley:
Hope it helps!

I will study and test this and comment. Thanks @TriB

1 Like