@Spatula:
I'll have a play with realterm :).
waitFor is not called from GPS loop. GPS loop grabs the current coords if available and chucks them into a kalman filter. As it uses tinyGPS it has something similar to my readAtString.
Speaking of waitFor:
void waitForOK() {
at_buffer = "";
while(true)
{
if(Serial3.available()>0) {
if(readATString(Serial3.read())) {
break;
}
}
}
at_buffer.trim();
if(at_buffer.compareTo("OK") == 0) {
Serial.println("Found OK");
return;
} else {
if(at_buffer.length() > 2) {
// |'s denoting i cant actually process the stuff atm
Serial.print('|');
Serial.print(at_buffer);
Serial.println('|');
return;
}
waitForOK();
}
}
Seems to work a lot better and was an obvious change after reading: Gammon Forum : Electronics : Microprocessors : How to process incoming serial data without blocking
It now waits for a single line of characters that is longer than 2 or "OK" before relinquishing its grasp.
Still dropping random characters though 
I believe the above may please your issues with my waitForOk. I no longer have any delays in the code.
I am unable to post my full code as it is part of a project whose Intellectual Property does not soley reside with me. I understand how this makes things difficult but I am not privy to post the exact method in which im transmitting data or storing it on removable media. I am looking more for theoretical answers if possible which largely your post is 
Could you provide a reference for your String class issue. It is on the official reference documentation and as such I thought it would be ok to use. With your reference I'll be able to evaluate things and hop to char arrays ok?
I understand that you guys all get silly questions all day but could you please try to not come across as hostile. Being firm is fine, i've already re-written waitForOK twice simply from being embarrassed at everyone pointing out it's flaws. Spatula's approach is fine PeterH I found you slightly rude. Sorry :(. I understand if that last sentence might piss you off and you might not want to continue helping. I am however grateful that you are providing new insight the state machine idea is fantastic.
Just so I understand the concept is this approach the sort of thing you had in mind:
Send a command that needs an OK
Switch to a state that solely listens for an OK and doesn't process anything else
Receive an OK and go back to the PROCESS ANYTHING state.
The problem with that is how to handle sequencing. Say the following needs to happen:
A
OK
B
OK
C
OK
When in the OK state and i get OK how do I know which command to send next? What comes to mind is a FIFO data structure? Would this work?