I need to use HM-10 with Arduino Uno or Nano.
I'm not able to figure out how to send AT commands and read the reply.
The commands work from serial monitor, but not from code.
Here's what I've tried so far:
#include <SoftwareSerial.h>
SoftwareSerial blueToothSerial(0,1); // RX, TX
void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(115200);
Serial.println("Serial began");
blueToothSerial.begin(9600);
delay(2000);
}
void loop()
{
Serial.println("looping...");
blueToothSerial.print("AT+DISC?");
delay(5000);
if (blueToothSerial.available())
{
Serial.println("bluetooth serial available");
Serial.write(blueToothSerial.read());
}
}
However, I'm not able to read any reply, I feel the command is not firing. The execution doesnt go inside if(blueToothSerial.available())
Make sure you set noth NL&CR in the serial monitor options.
You need to learn the difference between an AT command and an AT command line. Reading all of chapter 5 in the V.250 specification is the perfect starting point since it will teach you almost everything you need to know about basic AT command handling. And even after becoming an expert you will read this document.
The modem will not start processing AT commands until it has received a complete command line, so you should fix that. But you also need to rework the logic significantly to read and parse the response sent back from the modem. This is described in the answer linked above.
Update: It seems that the HM-10 manufacturer should learn the difference between an AT command and an AT command line, because HM-10 does not behave as a modem at all. Its documentation says
AT Command format: Uppercase AT command format. string format, without any other symbol. (e.g. \r or \n)
The command handling of HM-10 is wrong on so many levels. If the manufacturer want to invent their own text protocol for communicating with device, by all means they are free to do so. But then they should not call it AT commands when it is not that it is. This is like going to a dance class where the teacher claims that he or she is teaching you salsa but in reallity is just teaching something arbitrary he/she invented on their own, just being inspired by watching someone else dance salsa once...
First of all, HM-10 developers have either a complete lack of understanding of what an AT command line is, or they wilfully chose to ignore that and implement something completely different while still calling it AT commands. I do not know which is worst. A modem accepts AT command through a command line which might contain several commands, e.g. "ATI\r" is a command line sending one I command while "ATI I I\r" is a command line sending three I commands. HM-10 apparently only accepts a command just by itself.
Secondly, the syntax for the parameters are completely mixed up by using Extended syntax command names but using Basic syntax command parameters. Basic syntax commands are single character and have the numeric value following immediately, e.g. ATM1 while extended syntax command have parameters starting with an equal sign, e.g. AT+IPR=9600.
HM-10 is using some weird extended/basic hybrid syntax like AT+BAUD[para1].
Again I am not sure if this is due to ignorance or indifference.
Thirdly the order of the result code and information is reversed and mixed. A normal AT command will print information text before printing the final result code, e.g.
AT+IPR?
+IPR:9600
OK
HM-10 both reverses the order and combine them into one thing like OK+Set:[para1]. This I think most likely can be explained by indifference to how a modem actually operates.
Forth, the naming of the commands seems to just start with "AT+" and then append whatever name for the command, without using any proper prefix as written in chapter "5.4.1 Command naming rules" and "Appendix I" in V.250. I guess this is due to ignorance.
Fifth, the names of what corresponds to Unsolicited result codes have the exact syntax as the command result codes (e.g. OK+CONN, OK+LOST versus OK+WORK, OK+Get:[para1]) making responses from HM-10 impossible to parse generically. And when new commands with new responses are added to HM-10 this might break existing software. This is horribly bad protocol design.
Sixth, HM-10 amazingly seems to have no concept of returning an error indication when commands fail. The NAME command have 12 character limit, so what will issuing AT+NAMEthis_name_is_longer_than_12_characters return? I do not know but I will guess either OK+SetName:previousname or OK+SetName:this_name_is, but who knows - it seems that you have to resort to trial and error to find out. Trying to parse the success of commands executed from this would be a nightmare. This again is horribly bad protocol design.
Seventh, some commands (e.g. AT+RSSI?) have the question mark embedded in the name instead of letting the question mark indicate parameter read command syntax like modems do.
Other syntax flaws include allowing single characters as parameter values. AT command have just two types of parameters, numeric values and strings, and strings always start and end with double quote characters. And at this point I do not bother trying to find more flaws.
I absolutely do get that this is an embedded device where implementing something that supports a full modem syntax might be too much and something simpler is needed. That is perfectly fine, but then you should not claim that this is AT commands.
HM-10 seems like the bad salsa teacher you should avoid contact with and stay away from as far as possible. Maybe if you only ever would dance with other persons from that class you could stay ignorant happy imagining that you danced salsa, but you would fail whenever tried to dance with other people.
Maybe the actual HM-10 hardware is good, I do not know. But the command protocol have severe problems in addition to the fact that this is not AT commands at all. I recommend looking for alternatives.
