Serial communication with GPS - Continuous data transfer

Question

I am getting data from a Hemisphere GPS unit in C++ to do some post-processing. I am using a serial library to communicate with the unit. You are only allowed to subscribe to data from this GPS unit. The rates that you can receive your location range from 20Hz, 10Hz, 5Hz, ... up to once ever 5 seconds. The previous experience I have with serial communication is send a command and wait for a response. I am having two issues.

The first issue that I am encountering is that there seems to be a latency between when I move the GPS and when it reports that it has moved (about 3-5 seconds). Could there be a queue-like buffer of some sort that is being filled up? So when I stand still the stationary location fills up the queue and when I move a few meters away, the stationary location is still being reported. If so how could I remove this buffer so I'm only getting the most recent data?

The second issue is that the results I get back, two results are merged together or pieces take out. Here is a sample of the raw data that I get:

$GPGLL,5804.7646091,N,11407.8367957,W,035009.40,A,D*7C
$GPGLL,5804.7646449,N,11407.8368155,W,035009.50,A,D*79
$GPGLL,5804.7646737,N,11407.8368444,W,035009.60,A,D*75
$GPGLL,5804.7647076,N,11407.8368787,W,035009.70,A,D*7B
$GPGLL,5804.7647484,N,11407.8368970,W,035009.80,A,D*7B
$GPGLL,5804.7647751,N,11407.8369257,W,035009.90,A,D*7E
$GPGLL,5804.7648048,N,1.7650578,N,11407.8372036,W,035010.80,A,D*77 //bad data
$GPGLL,5804.7650880,N,11407.8372280,W,035010.90,A,D*73
$GPGLL,5804.7651175,N,11407.8372626,W,035011.00,A,D*71
$GPGLL,5804.7651413,N,11407.8372992,W,035011.10,A,D*75
$GPGLL,5804.7651673,N,11407.8373189,W,035011.20,A,D*71
$GP,N,11407.8374179,W,035012.90,A,D*72 //bad data
$GPGLL,5804.7652561,N,11407.8374194,W,035013.00,A,D*79
$GPGLL,5804.7652545,N,11407.8374191,W,035013.10,A,D*7B
$GPGLL,5804.7652553,N,11407.8374223,W,035013.20,A,D*75
$GPGLL,5804.7652543,N,11407.8374190,W,035013.30,A,D*7E
$GPGLL,580407.8374360,W,035015.00,A,D*76 //bad data
$GPGLL,5804.7652603,N,11407.8374404,W,035015.10,A,D*75
$GPGLL,5804.7652625,N,11407.8374373,W,035015.20,A,D*75
$GPGLL,5804.7652647,N,11407.8374386,W,035015.30,A,D*7A
$GPGLL,5804.7652668,N,11407.8374359,W,035015.40,A,D*72
$GPGLL,5804.76526W,035017.10,A,D*7F //bad data
$GPGLL,5804.7652684,N,11407.8374404,W,035017.20,A,D*7B

Here is a code snippet for how I'm reading it in:

int baudrate = 9600;
serial::bytesize_t databits = serial::eightbits;
serial::parity_t parity = serial::parity_none;
serial::stopbits_t stopbits = serial::stopbits_one;
serial::flowcontrol_t flowcontrol = serial::flowcontrol_none;
Serial* serialObj = new serial::Serial(ss.str(), baudrate, serial::Timeout(),
                      databits, parity, stopbits, flowcontrol);

while (true)
{
    std::string rawData = serialObj->readline();
    std::cout << rawData << std::endl; 
    //decode and do other processing - takes about 0.5 seconds
}

I've tried playing around with the subscription rate, but it still seems to have the same result. Any ideas what could be messing with the communications?

Note: the data subscription is done with the setup tool provided by the manufacturer.

Answer 1

The issue here doesn't look like a C++ problem, but rather a GPS system one. I don't know about your experience with GPS systems, but its likely a few things are happening here:

The first issue that I am encountering is that there seems to be a latency between when I move the GPS and when it reports that it has moved (about 3-5 seconds).

Explanation: As a rule, GPS is imprecise. If you're stationary, which it sounds like you are, GPS has a zone of error that is about 10-30 meters, even up to 100 meters or more, from the center position. Additionally, GPS is most accurate while moving.

However, if the receiver is being moved from one stationary point to another, it becomes even more difficult to have a good signal because it must:

1. Detect it moved in the first place, which is difficult for the receiver to detect from one stationary point to another in close proximity.
2. Then recalculate its position, which depends greatly on the environment, especially if testing is conducted in a city or near buildings. Which makes it especially worse if the receiver calculated it's position in what is almost by default a multipath environment.

So the receiver will very likely take 3-5 seconds before it updates its position, and until then it will send its last known best position, which is the original position (that is now even less accurate).

(Side note: This is why GPS drift occurs in automobiles; where, when stationary, the GPS loses its orientation and begins to drift from its actual position. Google and Apple maps try to reduce this by "fixing" (A better word is "affixing," but colloquially, it's fixing.) the GPS point when smartphones detect stationary movement; this process is made much easier because GPS in smart phone is enhanced GPS —— which means the GPS receiver is augmented by cellular technology and also the smart phone's on-board sensors, such as gyroscopes, accelerometers, magnetometers, and gravity sensors. (Or also known WiFi access points which were previously HEAT mapped, which is when GPS coordinates are associated with MAC addresses and signal environments, like what Google Maps does with its Maps vehicles and Indoor Maps.) Nearly all the various integrated sensors can detect movement (or lack) much easier and more quickly than a discreet GPS sensor system can; even a very expensive one.)

The second issue is that the results I get back, two results are merged together or pieces take out.

Bad data is caused by many reasons, usually miscalculations, caused by:

1. Electromagnetic interference, such as being near a power source, vehicle, or another (i.e., any) emitter.
2. Incomplete data from one or more GPS satellites. This happens in proximity to tall buildings, especially many, or if there is an overhang. Even satellites near the horizon can cause this because the earth itself block a clear signal path.
3. Or the usual suspect, an unsecured signal cable.

Most receivers "throw out" bad data as a rule, selecting the location by which solution polls the highest determined by a rolling average. And while "bad data" is visible in the raw data, the location is not affected.

It looks like there is nothing wrong the code from the libary you used, but rather the GPS sensor is behaving like it should which is often imperfect without hugely expensive precision timing units in combination with very expensive digital compasses, et cetera; and these are still slow to detect movement without enhancements from a multitude external sensors, and will certainly behave with a certain degree of expected imprecision when stationary.