Go Down

Topic: TinyGPS library reporting checksum errors, but no visible corruption (Read 1 time) previous topic - next topic


Hi!  I am working on a GPS project and I turned to TinyGPS for parsing the NMEA data.  I have been able to get the most basic example sketch to work fine ("simple_test"), and it was reporting no checksum errors up until I tried to add code to extract the time from the NMEA sentences.  The "CSUM" error counter suddenly starting going up even when data wasn't being received.  The counter will go up by one and sometimes two for ever 1-10ish chunks of data it parses.  While this concerns me, the time data is shown accurately and without fault.

Even if these errors have no consequence, it will make it harder to detect when errors of consequence actually do happen.  Here is the full code.  Can somebody please help me?  Thanks!

Code: [Select]

#include <SoftwareSerial.h>

#include <TinyGPS.h>
#include <string.h>

/* This sample code demonstrates the normal use of a TinyGPS object.
   It requires the use of SoftwareSerial, and assumes that you have a
   4800-baud serial GPS device hooked up on pins 2(rx) and 3(tx).

TinyGPS gps;
SoftwareSerial ss(2, 3);

void setup()
  Serial.print("Simple TinyGPS library v. "); Serial.println(TinyGPS::library_version());
  Serial.println("by Mikal Hart");

void loop()
  bool newData = false;
  unsigned long chars;
  unsigned short sentences, failed;

  // For one second we parse GPS data and report some key values
  for (unsigned long start = millis(); millis() - start < 1000;)
    while (ss.available())
      char c = ss.read();
      // Serial.write(c); // uncomment this line if you want to see the GPS data flowing
      if (gps.encode(c)) // Did a new valid sentence come in?
        newData = true;

  if (newData)
    float flat, flon;
    unsigned long age;
    int year;
    byte month, day, hour, minute, second, hundredths;
    gps.crack_datetime(&year, &month, &day, &hour, &minute, &second, &hundredths, &age);
    char datastring1[80];
    sprintf(datastring1,"%02d:%02d:%02d", hour, minute, second);
    gps.f_get_position(&flat, &flon, &age);
    Serial.print(flat == TinyGPS::GPS_INVALID_F_ANGLE ? 0.0 : flat, 6);
    Serial.print(" LON=");
    Serial.print(flon == TinyGPS::GPS_INVALID_F_ANGLE ? 0.0 : flon, 6);
    Serial.print(" ALT=");
    Serial.print(gps.f_altitude() == TinyGPS::GPS_INVALID_F_ALTITUDE ? 0.0 : gps.f_altitude(), 2);
    Serial.print(" SPD=");
    Serial.print(gps.f_speed_mps() == TinyGPS::GPS_INVALID_F_SPEED ? 0.0 : gps.f_speed_mps(), 2);
    Serial.print(" CRS=");
    Serial.print(gps.f_course() == TinyGPS::GPS_INVALID_F_ANGLE ? 0.0 : gps.f_course(), 6);
    Serial.print(" TIM=");
    Serial.print(age == TinyGPS::GPS_INVALID_AGE ? 0 : datastring1);
    Serial.print(" SAT=");
    Serial.print(gps.satellites() == TinyGPS::GPS_INVALID_SATELLITES ? 0 : gps.satellites());
    Serial.print(" PREC=");
    Serial.print(gps.hdop() == TinyGPS::GPS_INVALID_HDOP ? 0 : gps.hdop());
  gps.stats(&chars, &sentences, &failed);
  Serial.print(" CHARS=");
  Serial.print(" SENTENCES=");
  Serial.print(" CSUM ERR=");


I use the same library And I 'think' that the 'bad' or failed checksum sentences are discarded... Or I remember reading that somewhere Re: Mikal Harts TinyGPSV12

--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard


Code: [Select]
  for (unsigned long start = millis(); millis() - start < 1000;)
This is what a while statement is supposed to be used for, not a for loop.

How often does the GPS actually report a new sentence? It may not really be necessary to use that while/for loop at all.

Code: [Select]
    char datastring1[80];
    sprintf(datastring1,"%02d:%02d:%02d", hour, minute, second);

2 + 1 + 2 + 1 + 2 + 1 < 80.


The Arduiniana page says: "If the $GPRMC sentence reports a validity of "V" (void) instead of "A" (active), or if the $GPGGA sentence reports fix type "0? (no fix) then those sentences are discarded."

I'm not sure if this is what the error counter is keeping track of, but even if the invalid data is being discarded, I still think it is a problem if I cannot find other invalid data.

Hello from another Seattleite!  The GPS updates every second, whether it has data or not.  I'll try fiddling around with that loop later in the day, thanks!


The GPS updates every second, whether it has data or not.

One of the fields is whether the data is good, or not. I'd eliminate that while loop, and let the GPS tell you when it has (good) data.

Go Up