0

I'm trying to write a C++ app, that is able to make some phone calls. For this, I ordered a USB GSM Module, and a SIM Card with a prepaid contract.

I tested the module in PuTTY and everything works as expected. I choose a COM Port and can send/receive messages. See example:

AT
OK

AT+CMEE=2
OK

But when I try sending these commands via my own application, SOME of them fail (e.g. AT+CMEE=2).

AT
OK

AT+CMEE=2
+CMEE ERROR: Syntax Error

Other commands, such as unlocking the SIM Card work fine as well. But e.g "ATD" doesn't work. Here is the code for writing to the serial port. Keep in mind this is just for testing purposes:

DWORD dummy;

// "buffer" is just an std::string
char* string = new char[buffer.length() + 3]; // "+3" because I append '\0' later when printing
strcpy(string, buffer.c_str());
string[buffer.length()] = ' ';
string[buffer.length() + 1] = '\r';

WriteFile(m_hCom,
    string,
    (buffer.length() + 2) * sizeof(char),
    &dummy,
    0
);

I tried several variations ('\0' at the end, no space in between, etc) but all of those led to no commands working at all. So this is the solution where at least some commands are working and responding.

Any more ideas what could be wrong here?

DasMork
  • 1
  • 2
    Why the use of c-arrays you can pass `std::string.c_str()` directly to `WriteFile` ? – Richard Critten Mar 08 '21 at 15:49
  • Right now, simply because it was easier to debug the c-array when appending and reading characters. VS tends to remove chars like '\r' when trying to display the std::string. – DasMork Mar 08 '21 at 17:04
  • 1
    You are correct terminating commands with `\r`. That's how AT commands are terminated according to ETSI specification. What I infere from your description is that short commands seem to fail, while long commands. Just like `buffer` is some way dirty. Could you please state what the contents of `buffer` is before sending it? What if you define `char str[] = "AT+CMEE=2\r";` and send it with `WriteFile(m_hCom,str,strlen(str), &dummy, 0);` – Roberto Caboni Mar 08 '21 at 19:04
  • I tried your approach and indeed the command worked! By this I was able to spot the difference. The added space in my code was not necessary and causing the syntax error. Removing the space, and using strlen fixed the issue. Seems like the space was not necessary in the first place, but caused simpler commands to work. I'm still not sure why this is working now, and did not before. Guess I had some mistake in appending strings and calculating the correct length to pass in "WriteFile" Thank you! – DasMork Mar 08 '21 at 20:30
  • @DasMork Do you need an answer summarizing my suggestions, or you prefer removing your answer? If you want to understand what you did wrong it would be useful posting also the code containing `buffer` initialization. – Roberto Caboni Mar 09 '21 at 11:51

1 Answers1

0

It depends on the operating mode, but sometimes you should terminate the AT command with a \r\n when working with GSM modems. See this post. It looks like you are only adding a \r

Jan Gabriel
  • 1,066
  • 6
  • 15
  • I tried that as well before. by simply increasing the buffer by one more character, and adding '\n' the same way I add '\r'. That results in no answer from the module at all. – DasMork Mar 08 '21 at 17:02
  • 1
    Maybe it's the additional [space] you are adding between the line termination and the message, with this line `string[buffer.length()] = ' ';` I'd remove that whitespace. What I've done before was to check with putty which mode it is using thus or just . You can also check the raw bytes. If it is responding with CRLF then you know. Also, do you have a delay between the messages or are you waiting for the OK from the AT command before sending the next message? – Jan Gabriel Mar 08 '21 at 17:19
  • Oh, I just saw that you've tried the no whitespace in your post description. I only have two ideas, one is still the delay / wait for an OK response (preferred) before sending the next message, and two it couldn't hurt to double-check the baud rate :-). – Jan Gabriel Mar 08 '21 at 17:47
  • I've tried every possible combination now. "string" + ' ' + '\r' is the only one I'm even getting an answer from. Removing the Space or adding '\n' at the end always results in a timeout when waiting for an answer. Doesn't matter how long I wait. About PuTTY. Where can I see/change what line endings are currently used? – DasMork Mar 08 '21 at 18:35
  • `(PortDCB.DCBlength = sizeof(DCB); // Get the default port setting information. GetCommState(m_hCom, &PortDCB); // Change the DCB structure settings. PortDCB.BaudRate = 9600; // Current baud PortDCB.ByteSize = 8; // Number of bits/bytes, 4-8 PortDCB.Parity = NOPARITY; // 0-4=no,odd,even,mark,space PortDCB.StopBits = TWOSTOPBITS; // 0,1,2 = 1, 1.5, 2 SetCommState(m_hCom, &PortDCB); )` Here the baud rate is set to 9600. Do you spot any mistake in the initial opening of the port? – DasMork Mar 08 '21 at 18:36
  • Hi @DasMork, some modems use by default auto-baud. Thus, they will communicate automatically at the baud rate you start with, meaning 9600 is good. Speed it up later. I do see a problem with the use of TWOSTOPBITS. The default is 8N1, thus, 8-bits, No parity, 1 stop bit. That might solve your problem. I will also recommend a better serial utility such as my fav [hercules](https://www.hw-group.com/software/hercules-setup-utility) or even [Tera Term](https://osdn.net/projects/ttssh2/downloads/72009/teraterm-4.105.exe/). You can print out raw hex with Hercules to troubleshoot your comms. – Jan Gabriel Mar 08 '21 at 20:54