Long delay in Venus GPS

Using Arduino Networking, Protocols, and Devices
#1

Hi,

I am using a SparkFun Venus GPS with SMA Connector in my project with following code:

#include <SoftwareSerial.h>

SoftwareSerial gpsSerial(10, 11); // RX, TX (TX not used)
const int sentenceSize = 80;

char sentence[sentenceSize];

void setup()
{
  Serial.begin(9600);
  gpsSerial.begin(9600);
}

void loop()
{
  static int j= 0;
  if (gpsSerial.available())
  {
    char ch = gpsSerial.read();
    if (ch != '\n' && j< sentenceSize)
    {
      sentence[j] = ch;
      j++;
    }
    else
    {
     sentence[j] = '\0';
     j= 0;
     displayGPS();
    }
  }
}

void displayGPS()
{
  char field[20];
  getField(field, 0);
  if (strcmp(field, "$GPRMC") == 0)
  {
    
    Serial.print(" Time: ");
    getField(field, 1);  // number
    Serial.print(field);
    
    Serial.print(" Validity: ");
    getField(field, 2);  // number
    Serial.print(field);
    
    Serial.print(" Lat: ");
    getField(field, 3);  // number
    Serial.print(field);
    getField(field, 4); // N/S
    Serial.print(field);
    
    Serial.print(" Long: ");
    getField(field, 5);  // number
    Serial.print(field);
    getField(field, 6);  // E/W
    Serial.print(field);
    
    Serial.print(" Speed: ");
    getField(field, 7);  // number
    double veh_spd=atoi(field)*1.852;
    Serial.print(field); //speed in knot
    
    Serial.print(" km/h: ");
    Serial.print(veh_spd);
  }
    if (strcmp(field, "$GPGGA") == 0)
  {
    Serial.print(" Alt: ");
    getField(field, 9);  // number
    double Alt=atoi(field);
    Serial.println(field);
  }
}

void getField(char* buffer, int index)
{
  int sentencePos = 0;
  int fieldPos = 0;
  int commaCount = 0;
  while (sentencePos < sentenceSize)
  {
    if (sentence[sentencePos] == ',')
    {
      commaCount ++;
      sentencePos ++;
    }
    if (commaCount == index)
    {
      buffer[fieldPos] = sentence[sentencePos];
      fieldPos ++;
    }
    sentencePos ++;
  }
  buffer[fieldPos] = '\0';
}

The GPS works fine, but when I tested it in my car I noticed a very long delay (about 4 seconds) in the speed comparing with actual speed of the car (I am assuming location has the same delay).
Is this issue caused by the wrong code or it’s a hardware problem?

Thanks

#2

I can think of a few possibilities:

1) Printing 110 characters per second to Serial would not normally be a problem for SoftwareSerial, but is this the exact program you are using in the car? If not, other libraries may disable interrupts, which would interfere with SoftwareSerial.

2) The RX/TX wires are noisy. You would also see strange values for other fields.

3) The GPS device is performing filtering or smoothing, which can slow down the response time. The documentation describes a "navigation mode", and SparkFun has several versions of firmware for different vehicles.

The first thing I would try is NeoSWSerial, a library I maintain. It is much more efficient than SoftwareSerial. If you could use pins 8 & 9 for the GPS, AltSoftSerial would be even better. That would eliminate #1

The next thing I would try is one of the NeoGPS example programs. I wrote NeoGPS after having size and reliability problems with other approaches. Your sketch does not validate the checksum, so you could be getting old data if the '\n' is missed.

Your current sketch prints while the GPS is still sending other sentences. The NeoGPS library returns one fix structure per second, after all the sentences have been parsed and accumulated. This causes the examples to print the fix information after the GPS enters its "quiet time". That's the best time to do other things, like printing, updating a display, or writing to an SD card. All the examples are structured the same way, and this is most common problem with GPS sketches (see also here)

The NMEA.ino example will display the same pieces of information as your sketch in a Comma-Separated Value (CSV) format, including chars received and checksum errors. If the wires are noisy, you would see an increasing error count. NeoGPS rejects sentences that fail the checksum, so you should not see any "weird" values in any fields.

Next, I would suggest trying the NMEAloc.ino example. It is very close to your current program, so if it continues to show a lagged speed, then you can be pretty sure that the problem is not #2.

That leaves #3. SparkFun has a GPS Viewer/Configuration utility that you can use to determine and change its current settings. Or you could try the alternative firmwares.

Cheers,
/dev

#3

Thanks for your detailed answer. I am going to start with updating the firmware, but I don't know exactly how to do that. Is there any document that I can use in this regard?

#4