Good afternokn guys.Long overdue latest update. I am having great success the tc35i using the above code + some tweeks. However I'm rather stuck in tackling a problem with this code. When I attach my other functions temperate reading, setting and LCD updates, because of the delays used it misses the incoming message signal.Is there any way to attach an interrupt with the serial? Or am I looking down the wrong path.

I basically need the program to constantly monitor temperature readings and display them on the LCD. But in doing this the software misses the moment the serial recieves the new message command.

Any help is much appreciated guys, if you need any further information or my latest could just let me know.

When I attach my other functions temperate reading, setting and LCD updates, because of the delays used it misses the incoming message signal.

It should not be missed since it will stay in serial port buffer waiting to be read.You must insure you are "looking" in your loop if there is something to read (if (Serial.available()) and if there is something read it to prevent Serial buffer overflow.

Thank you for the prompt response Hugo.From my understanding/small experience so far, if the programming is calculating something in a loop. The serial.available misses the transmission as it isn't being called for looked at whilst in a processing loop. Does the serialevent function manage to capture serial data received whilst processing something else?

In a nutshell I need to capture serial command (+CMTI) sent by the GSM modem which alerts a received SMS. The code earlier in this thread works as a live serial stream, but not whilst processing something.

Yes.The serial interface still received data while the cpu is doing another things, and will put the incoming bytes in a Serial buffer to be read in a near future.This buffer has a limit and if you don't read it, it will overflow and you loose data.

if(strstr(data, "+CMGR:") && strstr(data, "+44XXXXXXXXXX")) { // Reads the +CMGR line to check if SMS is from a known Phone number // This if statement could cover the whole of the process_data function // then only known a phone number could control the Arduoino }

if(strstr(data, "+CMTI:")) { // An SMS has arrived char* copy = data + 12; // Read from position 12 until a non ASCII number to get the SMS location SMS_location_number = (byte) atoi(copy); // Convert the ASCII number to an int gsmSerial.print("AT+CMGR="); gsmSerial.println(SMS_location_number); // Print the SMS in Serial Monitor } // this SMS data will go through this process_data function again // any true if statements will execute

In lot of boards pin 9 does not support interrupts and the rx event e captured using an interrupt caused on the RX pin.You have a strong probability that your pin 9 does not support interrupts unless you are using the DUE boardSee here the pins that support interrupts

Thanks for the Advice given so far, but the solution was far simpler than anticpated as I was (we was) look to far outside the box.The key was to remove the delays i.e. delay(1500); and use the implement the blink without delay method for the LCD updates.Giving LCD updates every 1000millis, and still processing everything else.

if(strstr(data, "+CMGR:") && strstr(data, "+44XXXXXXXXXX")) { // Reads the +CMGR line to check if SMS is from a known Phone number // This if statement could cover the whole of the process_data function // then only known a phone number could control the Arduoino }

if(strstr(data, "+CMTI:")) { // An SMS has arrived char* copy = data + 12; // Read from position 12 until a non ASCII number to get the SMS location SMS_location_number = (byte) atoi(copy); // Convert the ASCII number to an int gsmSerial.print("AT+CMGR="); gsmSerial.println(SMS_location_number); // Print the SMS in Serial Monitor } // this SMS data will go through this process_data function again // any true if statements will execute

I'm glad you make it but now I'm very confused with somethings that if possible I like to discuss with you.You told you are using the Arduino Uno R3 but in your code you again have RX pin 9 which clearly does not support interruptsSo how can your code work?Are you sure if you upload that, does it still work?About the delays, in general using delays are a bad practice so you have done a good move replacing delays with millis().But even if you have a gigantic delay like 20 seconds the data is still captured because the virtual serial port will fire an interrupt for every byte it gets and place it in serial buffer.So the conclusion is, even using delays you will not loose those incoming bytes!I had prepared a small test to prove that.

I connect my ftdi232 interface TX pin to arduino pin 2 and when it enters in the delay for 10 seconds I start send the data.After the 10 seconds has passed I get printed all the bytes I had entered, probing I don't lose nothing even when my chip was running a delay(a nop operation).