TinyGPS++ incorrect output

Using Arduino Programming Questions
1

Hello,
for a specific application, I have customized the GY-NEO6MV2 NEO-6M pour Module GPS, so it only transmit $GPRMC sentence.
Qote from Arduiniana
Both libraries extract basic position, altitude, course, time, and date, etc. from two common NMEA sentences, $GPGGA and $GPRMC.

When $GPGGA is not received, time.isValid() and time.isValid() both rspond NO as well as date.

This is 100% confirmed with the output of the example: Full Example which returns a board of asterisks.

We can also notice that the number of characters is accumulated rather than specific to the current frame.

3:02:01.625 -> FullExample.ino
13:02:01.625 -> An extensive example of many interesting TinyGPSPlus features
13:02:01.625 -> Testing TinyGPSPlus library v. 1.0.2
13:02:01.625 -> by Mikal Hart
13:02:01.625 -> 
13:02:01.625 -> Sats HDOP  Latitude   Longitude   Fix  Date       Time     Date Alt    Course Speed Card  Distance Course Card  Chars Sentences Checksum
13:02:01.625 ->            (deg)      (deg)       Age                      Age  (m)    --- from GPS ----  ---- to London  ----  RX    RX        Fail
13:02:01.665 -> ----------------------------------------------------------------------------------------------------------------------------------------
13:02:01.665 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   0     0         0        
13:02:02.771 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   98    0         2        
13:02:03.833 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   196   0         4        
13:02:04.968 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   294   0         4        
13:02:06.061 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   392   0         6        
13:02:07.157 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   490   0         6        
13:02:08.245 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   588   0         7        
13:02:09.394 -> **** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   776   0         9
2

To work properly the TinyGPS++ library needs to read both $GPRMC and $GPGGA senetences.

3

How should we understand what is written in the Arduiniana document which claim:
Both libraries extract basic position, altitude, course, time, and date, etc. from two common NMEA sentences, $GPGGA and $GPRMC.

4

What exactly is your question? Are you concerned that the example sketch does not work when someone has custom configured the GPS module to prevent it from sending the specific sentences that are needed by the example?

2 Likes
5

The intent appears to be that those values are extracted from the combination of the $GPGGA and $GPRMC sentences. You seem to be wanting to interpreting it such that those values can be extracted from either sentence independently from the other. Looking up the actual NMEA sentence standard should tell you that interpretation is wrong.

3 Likes
6

Why?
What is the application?

Thanks..Tom.. :grinning: :+1: :coffee: :australia:

7

Hello,
I am working on an accurate clock, using the atomic clock of the GPS satellites and the 'Pulse per second' standard.

I do not want to overload the Arduino with useless NMEA sentences so I trimed the GPS receiver.
My request :
Unless I misunderstood the Ardiniana document, I want TinyGPSPlus to get the date and time from either $GPRMC or $GPGGA.

In a real life execution, I noticed that time and date are set correctly when word 2 of $GPRMC switch from A (active) to V (vide)

8

From initial power up the time printed out by the GPS could be out by 2 or 3 seconds.

It can take it can take several minutes for the the time printed out by the GPS, and read by the library, to be accurate to UTC.

9

You will need the $GPRMC sentence to get the date and time, $GPGGA does not contain date information.

The $GPZDA sentence will give you the time/date associated with the PPS output. You will need to parse that yourself since the TinyGPS library ignores it.

10

That turns out not to be the case.

With all sentences except $GPRMC turned off, date and time are still returned by the library, as expected. Below is an excerpt from a run of FullExample.ino which has been modified to turn off all sentences except $GPRMC.

FullExample.ino
An extensive example of many interesting TinyGPSPlus features
Testing TinyGPSPlus library v. 1.0.3
by Mikal Hart

Sats HDOP  Latitude   Longitude   Fix  Date       Time     Date Alt    Course Speed Card  Distance Course Card  Chars Sentences Checksum
           (deg)      (deg)       Age                      Age  (m)    --- from GPS ----  ---- to London  ----  RX    RX        Fail
----------------------------------------------------------------------------------------------------------------------------------------
**** 100.0  ********** *********** **** 00/00/2000 00:00:00 3    ****** ****** ***** ***   ******** ****** ***   392   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 695  ****** ****** ***** ***   ******** ****** ***   417   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 701  ****** ****** ***** ***   ******** ****** ***   442   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 707  ****** ****** ***** ***   ******** ****** ***   467   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 713  ****** ****** ***** ***   ******** ****** ***   492   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 718  ****** ****** ***** ***   ******** ****** ***   517   0         0        
0    100.0  ********** *********** **** 00/00/2000 00:00:00 725  ****** ****** ***** ***   ******** ****** ***   542   0         0        
0    100.0  40.801960  -101.507744 525  01/28/2024 18:43:28 525  ****** 0.00   0.17  N     7258     42.21  NE    610   1         0        
0    100.0  40.801945  -101.507713 929  01/28/2024 18:43:29 929  ****** 0.00   0.30  N     7258     42.21  NE    685   2         0        
0    100.0  40.801952  -101.507713 941  01/28/2024 18:43:30 941  ****** 0.00   0.13  N     7258     42.21  NE    758   3         0        
0    100.0  40.801960  -101.507713 946  01/28/2024 18:43:31 946  ****** 0.00   0.09  N     7258     42.21  NE    836   4         0        
0    100.0  40.801964  -101.507721 956  01/28/2024 18:43:32 956  ****** 0.00   0.17  N     7258     42.21  NE    911   5         0
11

I wonder if the OP has other issues? Looking at the output shown in the original post, there are multiple checksum errors and no valid sentences received.

12

I would imagine that is not only possible, but likely. How they expected to get anything with no sentences received with good checksums is a bit of a mystery.

13

Have you tried your project with just the generic data dump from the GPS?

You are only asking for 1 second resolution in the timing.

Tom.. :grinning: :+1: :coffee: :australia:
PS. There is a danger of over thinking a project.

14

Thank you Van_der_Decken your example is crystal clear. You run version 1.0.3 while I run version 1.0.2.
I re-installed both version for ESP32 and non ESP32.
I cannot get version 1.0.3 from France.
That seems to be the problem but I have no idea to solve the issue.

15

The library and example I used came from Github.

I did my testing on an R4 Minima because a) it was handy and b) the Rx and Tx pins are for Serial1 and are separate from the USB connection. So I didn't have to use SoftwareSerial, and removed the declaration of ss, and changed any use of ss to Serial1.

My Neo-6M module ran at 9600 by default rather than 4800 so I initialized Serial1 to that in setup(), and also turned off all the unwanted sentences.

static const uint32_t GPSBaud = 9600;
.
.
.
void setup() {
   Serial.begin(115200);
   Serial1.begin(GPSBaud);
   delay(2000);
   Serial1.print(F("$PUBX,40,VTG,0,0,0,0,0,0\r\n"));
   Serial1.print(F("$PUBX,40,GSV,0,0,0,0,0,0\r\n"));
   Serial1.print(F("$PUBX,40,GLL,0,0,0,0,0,0\r\n"));
   Serial1.print(F("$PUBX,40,GSA,0,0,0,0,0,0\r\n"));
   Serial1.print(F("$PUBX,40,GGA,0,0,0,0,0,0\r\n"));

And lastly, since the NEO-6M data lines use 3.3V levels, I used a simple voltage divider between the R4's Tx line and the NEO-6M's Rx line. 1.2K above 2.2K to get about 3.2V on the Rx line.

16

I probably ave to install TinyGPSPlus from Github rather than the IDE.

17

True, you will get what the time was at the last PPS transition.

But that time given can still be 2 or maybe more seconds out due to leap seconds issues etc.

I guess it depends what the OP means by an 'accurate clock'.

18

V1.0.2 and V1.0.3 a real mess!
With all the NMEA sentences:
The Fullexample in V1.0.2 make a check gps.time.isValid() and produces NO OUTPUT
With V1.0.3, the verification has been removed and I get the nice output.

Sats HDOP  Latitude   Longitude   Fix  Date       Time     Date Alt    Course Speed Card  Distance Course Card  Chars Sentences Checksum
           (deg)      (deg)       Age                      Age  (m)    --- from GPS ----  ---- to London  ----  RX    RX        Fail
----------------------------------------------------------------------------------------------------------------------------------------
**** ***** ********** *********** **** ********** ******** **** ****** ****** ***** ***   ******** ****** ***   0     0         0        
8    1.0   49.358104  0.090116    756  01/29/2024 12:53:17 833  51.40  0.00   0.31  N     239      356.39 N     194   2         0        
8    1.0   49.358104  0.090117    831  01/29/2024 12:53:18 909  51.40  0.00   0.09  N     239      356.39 N     449   4         0        
8    1.3   49.358104  0.090115    52   01/29/2024 12:53:20 66   51.40  0.00   0.19  N     239      356.39 N     776   8         0        
8    1.3   49.358104  0.090113    58   01/29/2024 12:53:21 136  51.20  0.00   0.39  N     239      356.39 N     970   10        0

Exactly the same behavior when the only sentence is GPRMC.

An extensive example of many interesting TinyGPSPlus features
Testing TinyGPSPlus library v. 1.0.3
by Mikal Hart

Sats HDOP  Latitude   Longitude   Fix  Date       Time     Date Alt    Course Speed Card  Distance Course Card  Chars Sentences Checksum
           (deg)      (deg)       Age                      Age  (m)    --- from GPS ----  ---- to London  ----  RX    RX        Fail
----------------------------------------------------------------------------------------------------------------------------------------
**** ***** ********** *********** **** 01/29/2024 12:46:29 56   ****** ****** ***** ***   ******** ****** ***   40    0         0        
**** ***** ********** *********** **** 01/29/2024 12:46:30 168  ****** ****** ***** ***   ******** ****** ***   80    0         0        
**** ***** ********** *********** **** 01/29/2024 12:46:31 246  ****** ****** ***** ***   ******** ****** ***   120   0         0        
**** ***** ********** *********** **** 01/29/2024 12:46:32 323  ****** ****** ***** ***   ******** ****** ***   160   0         0

I suspect a bug around time.IsValid and time.IsUpdated

19

Validity, Update status, and Age

You can examine an object’s value at any time, but unless TinyGPS++ has recently been fed from the GPS, it should not be considered valid and up-to-date. The isValid() method will tell you whether the object contains any valid data and is safe to query.

Similarly, isUpdated() indicates whether the object’s value has been updated (not necessarily changed) since the last time you queried it.

20

Another quote from Arduiniana:

For built-in (non-custom) objects, the NMEA sentences must self-report themselves as valid. That is, 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 the position and altitude information is discarded (though time and date are retained).