When requesting com port returns the same request

Solution 1:

Busy waiting like while (!isReceived) {} will yield horrible performance so if keeping that structure you should change the variable from a boolean to a mutex/semaphore or something similar. But you should not keep it, so I mention this just for reference.


Start by fetching a copy of the V.250 modem standard and read at least all of chapter 5. That will teach you a lot of basic AT command handling, like for instance that an AT command line should be terminated with \r.

The AT^SCFG command is obviously a proprietary manufacturer specific command so I do not have a documentation reference for that. Most mobile phone related AT commands standardized by 3GPP are given in 27.007, although some (SMS related) are given in 27.005

As mentioned at the beginning the structure needs to be changed. You should never, never, never, ever use waitTime, sleep or anything similar to wait for response from a modem. It's as useful as kicking dogs that stand in your way in order to get them to move. Yes you might be lucky and have it actually work sometimes, but at some point you will be sorry for taking that approach...

The only reliably approach is to do something similar to

serialPort.openPort();
...
// start sending AT^SCFG?
serialPort.writeBytes("AT^SCFG?\r");
do {
    line = readLine(serialPort);
} while (! is_final_result_code(line))
// Sending of AT^SCFG? command finished (successfully or not)
...
serialPort.closePort();

where the readLine function reads one and one byte from the serial port until it has received a complete line terminated with \r\n and then returns that line.

You can look at the code for atinout for an example for the is_final_result_code function (you can also compare to isFinalResponseError and isFinalResponseSuccess in ST-Ericsson's U300 RIL, although note that CONNECT is not a final result code, it is an intermediate result code, so the name isFinalResponseSuccess is strictly speaking not 100% correct).


The issue with the command send being received back is related to the modem echoing the command. This can be disabled with the ATE command but with a proper parsing structure like above this normally does not matter because you just read the echoed command as a line that will be ignored.