I am losing the last bytes into the checksum on my gps unit found here http://www.adafruit.com/products/746. If I comment all lines out except for line 2, then all the bytes are recieved correctly. Is there a way to finish receiving the checksum bytes?

if (mySerial.available()) {
//      Serial.print((char)mySerial.read());
  char c1 = (char)mySerial.read();
  if (c1 == '$') {
    char a = (char)mySerial.read();
    char b = (char)mySerial.read();
    char c = (char)mySerial.read();
    char d = (char)mySerial.read();
    char e = (char)mySerial.read();
//        Serial.print(a);
//         Serial.print(b);
//          Serial.print(c);
//           Serial.print(d);
//            Serial.print(e);
    if((a=='G') && (b=='P') && (c=='G') && (d=='G') && (e=='A')) {
//          Serial.println("Match");
      for(int i = 0; i <= 69; i++) {

          into[i] = (char)mySerial.read();
//              delay(100);

      for(int j = 0; j <= 69; j++) {


  • \$\begingroup\$ so .. you're saying if you uncomment all those Serial.print() calls, you lose data? Just taking a half baked guess at it, but printing takes time. Not sure what the serial input buffering is like in this system but I'd be surprised if there's much. In a seriously resource constrained system like this, you often won't have the luxury of being able to sprinkle diagnostic print statements freely. \$\endgroup\$
    – JustJeff
    May 31, 2013 at 1:18
  • \$\begingroup\$ if line 2 is the only line uncommented, then the entire sentence appears, with the checksum (something like M,,*6B). but the last couple bytes don't appear and i get something like this $GPGGA,001832.000,4228.2588,N,09042.0066,W,1,9,0.96,245.2,M,-34.0,,M088,N,- (which appears to be a byte here and there from the next sentence) \$\endgroup\$
    – dran
    May 31, 2013 at 23:43

1 Answer 1


Among other problems GPS NMEA sentences aren't normally fixed length, for example the sentence you posted in a comment with the missing checksum is:


If 10 instead of 9 satellites were in view that would become:


And the same will apply when your altitude becomes higher. This one doesn't appear to do so but some GPS receivers also drop trailing zeroes in decimal numbers so any sort of code that relies on a fixed length won't be reliable or portable. Also you are assuming the first character received is '$' which is normally the case but means your code won't recover from even a brief communications error.

The delays also shouldn't be necessary and at the moment printing the results is probably causing incoming characters to drop. You might be best to take a look around and find some existing code / projects that parse GPS sentences for a start and examine how they work.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.