I am having a problem with the arduino reading and building a string from incoming serial data from my GSM module. It's reading most of the string but not all of it. Attached is my code.
#include <NewSoftSerial.h>
NewSoftSerial GSM(2, 3);
char inData[100];
byte index = 0;
void setup()
{
Serial.begin(115200); // initialize the serial port on the device
Serial.println("Retrieving Information...");
GSM.begin(9600); // set the data rate for the NewSoftSerial port attached to the GSM module
ReadSerialString();
Serial.print("inData: ");
Serial.println(inData);
}
void loop()
{
}
void ReadSerialString()
{
GSM.println("AT+CMGL");
delay(1000);
while(GSM.available() > 0)
{
char aChar = GSM.read();
if(aChar == '\n')
{
// End of record detected. Time to parse
index = 0;
inData[index] = NULL;
}
else
{
inData[index] = aChar;
index++;
inData[index] = '\0'; // Keep the string NULL terminated
}
}
}
when I want to get this: +CMGL: 1,"REC READ","+19998887777",,"11/12/02,23:06:29-32"
Ideally I want to get all of this in 3 strings (line 1 as a string) (line 2 as a string) (line 4 as a string) but I figured I'd work on it one string at a time: +CMGL: 1,"REC READ","+19998887777",,"11/12/02,23:06:29-32" Yeah it works! OK
AWOL I thought of that being a potential problem as well and changed the While statement but that didn't help either. while(GSM.available())
The number of text message and the phone number will very so the string length will not always be the same so I'm telling it to take all incoming characters up to the line feed and store them in a string.
In case you guys wanted to know what was wrong it wasn't my code =) the string that was being sent from the GSM was too big for the NewSoftSerial library to handle and it was dropping all the rest of the data. It was a simple fix. I went into the NewSoftSerial.h file and changed the buffer size from 64 to 256 and that made everything all better and now working!
wasn't my code it was the library NewSoftSerial. Nothing in there documentation says that there buffer is small then that of the hardware serial port. The changes I made were in the library not my code.
9600 bps is pretty slow compared to what the Arduino is running at. Receiving a byte should take about 1ms at 9600 bps which a lot slower than your loop is running.
it is an arduino 3.3V pro so it is running at 1/2 the speed of the UNO. NewSoftSerial goes crazy if i run it any faster than 9600 on the 3.3V Pro =( All that really matters is I got my problem solved and my code is running. I was looking on the GPS and GSM forms around the web and it seams like a lot of people run into buffering problems with NSS and really large strings like that of GPS and GSM.
Thanks all for your input. It's always appreciated.
I actually did lower the delay to 450ms. the GSM module takes it time before it sends the string back and I've tested it with no delays, varying time delays, etc.. and if I don't put a delay in there the While loop times out before it ever receives the first byte of data. With my current code a delay of 450m -2s reads all the data every time. I'm not using the arduino GSM shield, I'm using a ublox LEON G100 module. I'm quite happy with the way the code is running now.
No, really, you're misunderstanding the problem, and this kind of thing will bite you on the ass again if you don't address it.
There is no reason a 16MHz processor shouldn't be able to do this with a serial buffer of a single character at 9600 bps.
Rewriting the serial library is a sticking-plaster solution.
AWOL. The unit I'm running as mentioned before is not a 16Mhz processor. It is an 8Mhz processor. Processor speed has nothing to do with the software buffer either. Looking at the TinyGPS library support forms they also recommend increasing the software buffer from the NewSoftSerial Library to 256 byte from 64 bytes. The Hardware Serial buffer is a different item all together. If you look at the data stream i posted above you will see that including terminators I was receiving 84 bytes of data at 9600bps from the GSM module(including 2 byte terminators). This means that 20bytes of data were being truncated and not stored in the software buffered in the NewSoftSerial library. For small information being sent this is not a problem but for large strings of data such as in my case and in the case of NMEA data from a GPS module using a "virtual Software Serial port" needs extra space and needs to be adjusted accordingly. The hardware serial buffer is 128bytes. As you can see if I were to reverse the pin out and make the Software Serial hooked up to the computer and the Hardware serial hooked to the GSM the problem goes away because of the buffer size difference. No i didn't need to make the buffer 256bytes, 128bytes would have been fine but I'd rather have overkill when there is room in the code to do it.
You're quite right, I did miss the fact that your processor has only 8 300 instruction cycles per received character period to process the incoming data, and not 16 600.
I apologise.
I did, however notice that you'd provided a one hundred character buffer for the received data in your sketch.