GPS parsing for Taoglass GPS

I am using Taoglas GPS (http://www.taoglas.com/images/product_images/original_images/CGGBP.35.6.A.02.pdf) Here are the photos(Dropbox - Error)They say it has good accuracy. The problem is I don't have a library for parsing data, and it seems no one has written one. I have tried TinyGPS(Release Version 13 · mikalhart/TinyGPS · GitHub), tinygpsplus(TinyGPS++ | Arduiniana) and Adafruit (Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates [PA1616S] : ID 746 : $29.95 : Adafruit Industries, Unique & fun DIY electronics and kits). All are not working with this GPS, It seems each library is specific to the to its GPS model. I need the my Taoglas capture location and time at specific time. Any help on how I can do it, or code I can borrow ?

Now, I used the following code on arduino
void Setup(){}
void loop(){}

and I got the following data on serial port
$GLGSV,2,1,05,65,83,105,28,66,35,339,28,72,30,151,,76,21,346,60
$GLGSV,2,2,05,77,26,288,25
51
$GNGLL,0105.60759,S,03701.70246,E,225625.00,A,A65
$GNZDA,225625.00,21,09,2015,00,00
70
$GNRMC,225626.00,A,0105.60761,S,03701.70240,E,0.022,,210915,,,A7C
$GNVTG,,T,,M,0.022,N,0.041,K,A
38
$GNGGA,225626.00,0105.60761,S,03701.70240,E,1,05,2.41,1535.0,M,-22.0,M,,43
$GNGSA,A,3,06,17,30,,,,,,,,,,3.79,2.41,2.93
1D
$GNGSA,A,3,65,66,,,,,,,,,,,3.79,2.41,2.931D
$GPGSV,2,1,07,05,15,316,,06,23,224,38,07,15,020,21,08,03,057,20
79
$GPGSV,2,2,07,17,35,176,36,28,75,324,23,30,25,349,2748
$GLGSV,2,1,05,65,83,105,28,66,35,339,28,72,30,151,,76,21,346,60
$GLGSV,2,2,05,77,26,288,25
51
$GNGLL,0105.60761,S,03701.70240,E,225626.00,A,A
6B
$GNZDA,225626.00,21,09,2015,00,0073
$GNRMC,225627.00,A,0105.60764,S,03701.70233,E,0.023,,210915,,,A
7D
$GNVTG,,T,,M,0.023,N,0.043,K,A*3B
$GNGGA,225627.00,0105.60764,S,03701.70233,E,1,05,2.41,1535.2,M,-22.0,M,,*4

How do I parse the data?

The link is to a GPS antenna, not a GPS receiver.

It seems each library is specific to the to its GPS model.

Wrong. GPS units output data in standard formats. TinyGPS and TinyGPS++ collect and parse standard data.

mwangilbert:
I am using Taoglas GPS (ttp://www.taoglas.com/images/product_images/original_images/CGGBP.35.6.A.02.pdf). They say it has good accuracy. The problem is I don't have a library for parsing data, and it seems no one has written one. I have tried TinyGPS(Release Version 13 · mikalhart/TinyGPS · GitHub) and Adafruit (Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates [PA1616S] : ID 746 : Adafruit Industries, Unique & fun DIY electronics and kits). Both wont work, It seems each library is specific to the to its GPS model. I need the my Taoglas capture location and time at specific time. Any help on how I can do it, or code I can borrow ?

Send some 'raw data output' that you capture from the Serial monitor with some test code!

Typically GPS receivers send standard NMEA sentences.

But your receiver is not a GPS receiver, it is a GPS, GLONASS and BEIDOU receiver, which also receives signals from the Russian and Chinese positioning systems.

Most likely your NMEA sentences may generate slightly modified sentences, such like instead the normal "$GPRMC" prefix there might be a "$GLRMC" prefix to show GLONASS reception instead of GPS reception.

Show received raw data!

You can do a test sketch by yourself? Or need help with that?

jurs:
But your receiver is not a GPS receiver, it is a GPS, GLONASS and BEIDOU receiver,

It isn't a receiver at all; if it were, the spec sheet would list the serial interfaces and protocols supported.

It's just an antenna.

AWOL:
It isn't a receiver at all; if it were, the spec sheet would list the serial interfaces and protocols supported.

It's just an antenna.

Indeed, that's correct!
The link the TO posted links to a "Embedded Patch Antenna" only and not to a GPS receiver.

I'm wondering how he managed to connect that to a serial port on his Arduino board as he seems to expect to receive serial data? I'm clueless.

Yes, which GPS device are you using with that antenna? And, like jurs suggested, start with a simple echo program to see what data is being emitted by your GPS device.

I wrote NeoGPS, which will accept all forms of the typical NMEA sentences, unlike TinyGPS, TinyGPS++ and Adafruit_GPS. For example, $GLGGA (GLONASS) , $GNGGA (GPS+GLONASS), or even $XXGGA will be accepted.

It's also faster and smaller than the other libraries, which may be important if you are at the limit of your Arduino's RAM or processing speed. It is more complicated "under the hood", but it comes with several example programs and configurations.

NeoGPS comes pre-configured for many Arduino boards, including Mega, Uno, Nano, Micro, and 32-bit platforms like Teensy 3.x, Due and Maple (or so I've heard... personally, I haven't tried these boards).

Cheers,
/dev

Photos of GPS: Dropbox - Error

I used the code
void setup(){}
void loop(){}

On serial port, at 9600 bound rate, I got this : $GNGSA,A,3,65,66,,,,,,,,,,,3.79,2.41,2.931D
$GPGSV,2,1,07,05,15,316,,06,23,224,38,07,15,020,21,08,03,057,20
79
$GPGSV,2,2,07,17,35,176,36,28,75,324,23,30,25,349,2748
$GLGSV,2,1,06,65,83,105,28,66,35,339,28,72,30,151,,76,21,346,63
$GLGSV,2,2,06,77,26,288,25,78,04,240,6F
$GNGLL,0105.60764,S,03701.70233,E,225627.00,A,A
6B
$GNZDA,225627.00,21,09,2015,00,00
72
$GNRMC,225628.00,A,0105.60767,S,03701.70226,E,0.025,,210915,,,A
73
$GNVTG,,T,,M,0.025,N,0.046,K,A38
$GNGGA,225628.00,0105.60767,S,03701.70226,E,1,05,2.41,1535.5,M,-22.0,M,,4E
$GNGSA,A,3,06,17,30,,,,,,,,,,3.79,2.41,2.93
1D
$GNGSA,A,3,65,66,,,,,,,,,,,3.79,2.41,2.93
1D
$GPGSV,2,1,07,05,15,316,,06,23,224,38,07,15,020,22,08,03,057,207A
$GPGSV,2,2,07,17,35,176,36,28,75,324,23,30,25,349,27
48
$GLGSV,2,1,06,65,83,107,28,66,35,339,28,72,30,151,,76,21,346,*61

I am still not able to parse any data using the above libraries? Is there a way I can do it without libraries?

am still not able to parse any data using the above libraries?

Yes, your device is outputting "GPS" and "GLONASS" satellite information. TinyGPS, TinyGPS++ and Adafruit_GPS will not parse these sentences.

Here's a program that will parse your hard-coded data, using the NeoGPS library:

/*
  This test program uses PROGMEM sample data

  Serial is for debug/trace output.
*/

#include <Arduino.h>

#include "Streamers.h"

// Set this to your debug output device.
Stream & trace = Serial;

#include "NMEAGPS.h"

static NMEAGPS gps;

//--------------------------
// Hard-coded sentence(s)

const char sentence1[] __PROGMEM =
  "$GNGSA,A,3,65,66,,,,,,,,,,,3.79,2.41,2.93*1D"
  "$GPGSV,2,1,07,05,15,316,,06,23,224,38,07,15,020,21,08,03,057,20*79"
  "$GPGSV,2,2,07,17,35,176,36,28,75,324,23,30,25,349,27*48"
  "$GLGSV,2,1,06,65,83,105,28,66,35,339,28,72,30,151,,76,21,346,*63"
  "$GLGSV,2,2,06,77,26,288,25,78,04,240,*6F"
  "$GNGLL,0105.60764,S,03701.70233,E,225627.00,A,A*6B"
  "$GNZDA,225627.00,21,09,2015,00,00*72";
  
const char sentence2[] __PROGMEM =
  "$GNRMC,225628.00,A,0105.60767,S,03701.70226,E,0.025,,210915,,,A*73"
  "$GNVTG,,T,,M,0.025,N,0.046,K,A*38"
  "$GNGGA,225628.00,0105.60767,S,03701.70226,E,1,05,2.41,1535.5,M,-22.0,M,,*4E"
  "$GNGSA,A,3,06,17,30,,,,,,,,,,3.79,2.41,2.93*1D"
  "$GNGSA,A,3,65,66,,,,,,,,,,,3.79,2.41,2.93*1D"
  "$GPGSV,2,1,07,05,15,316,,06,23,224,38,07,15,020,22,08,03,057,20*7A"
  "$GPGSV,2,2,07,17,35,176,36,28,75,324,23,30,25,349,27*48"
  "$GLGSV,2,1,06,65,83,107,28,66,35,339,28,72,30,151,,76,21,346,*61";

//--------------------------

static bool parse_P( const char *ptr )
{
    char c;

  while ( (c = pgm_read_byte( ptr++ )) != '\0' ) {
    gps.decode( c );
  }
  trace_all( gps, gps.fix() );
}

//--------------------------

void setup()
{
  // Start the normal trace output
  Serial.begin(9600);

  trace_header();
}

void loop()
{
  parse_P( sentence1 );
  parse_P( sentence2 );
  
  for (;;); // hang here...
}

And here's the floating-point output:

Status,UTC Date/Time,Lat,Lon,Hdg,Spd,Alt,HDOP,Sats,[sat elev/az @ SNR],Rx ok,Rx err,Rx chars,
3,2015-09-21 22:56:27.00,-1.093461,37.028369,,,,2.410,6,[65 83/105@28,66 35/339@28,72 30/151@-,76 21/346@-,77 26/288@25,78 4/240@23,],7,0,355,
3,2015-09-21 22:56:28.00,-1.093461,37.028369,,0.025,1535.50,2.410,6,[65 83/107@28,66 35/339@28,72 30/151@-,76 21/346@-,],15,0,804,

And the integer output:

Status,UTC Date/Time,Lat,Lon,Hdg,Spd,Alt,HDOP,Sats,[sat elev/az @ SNR],Rx ok,Rx err,Rx chars,
3,2015-09-21 22:56:27.00,-10934607,370283722,,,,2410,6,[65 83/105@28,66 35/339@28,72 30/151@-,76 21/346@-,77 26/288@25,78 4/240@23,],7,0,355,
3,2015-09-21 22:56:28.00,-10934612,370283710,,25,153550,2410,6,[65 83/107@28,66 35/339@28,72 30/151@-,76 21/346@-,],15,0,804,

Note loss of precision in the floating-point lat/long.

Is there a way I can do it without libraries?

You could write your own version of TinyGPS, TinyGPS++, Adafruit_GPS or NeoGPS. We call that "re-inventing the wheel". Having done this several times, I can tell you it's not a begginer's project.

Cheers,
/dev

mwangilbert:
I am still not able to parse any data using the above libraries? Is there a way I can do it without libraries?

TinyGPS is evaluating two NMEA messages: $GPGGA and $GPRMC

Your receiver is sending slightly different sentences: $GNGGA and $GNRMC

So if you want to use TinyGPS you just need to patch the library a little bit:

  • Find where TinyGPS looks for $GPGGA and $GPRMC lines
  • Replace code so that the library looks for $GNGGA and $GNRMC lines
    All the rest stays the same.

These are the sentences from your receiver which contain the relevant information:

$GNRMC,225628.00,A,0105.60767,S,03701.70226,E,0.025,,210915,,,A*73
$GNGGA,225628.00,0105.60767,S,03701.70226,E,1,05,2.41,1535.5,M,-22.0,M,,*4E

Of course it would also be possible to retrieve the information with some own functions. But the programmer should know how to program and should not be a beginner when trying to do so.

if you want to use TinyGPS you just need to patch the library a little bit:

  • Find where TinyGPS looks for $GPGGA and $GPRMC lines
  • Replace code so that the library looks for $GNGGA and $GNRMC lines
    All the rest stays the same.

It may not be that simple. I think this receiver will output $GPGGA if only GPS satellites are used for the location, $GLGGA if only GLONASS satellites are used for the location, and $GNGGA if a mix of GPS and GLONASS satellites are used. ublox has a setting which will force the talker id to always be GP, but it's only accessible from the UBX binary protocol.

I didn't bother downloading from his dropbox. Does anybody know the make/model?

Cheers,
/dev

Thanks all, I now know the GPS is LEA-M8T, Taoglas is the antenna. I will be trying your tips libraries I am now trying the libraries.

Ok, that's a u-blox Neo-M8 with active antenna capabilities, the NEO-LEQ-M8T. That confirms the GN/GL/GP talker ID issue with other libraries.

First, I would suggest that you decide what information you really need:

  • fix status (none, time only, standard, differential [really good!] or estimated [questionable])
  • date
  • time
  • latitude and longitude
  • altitude
  • speed
  • heading
  • number of satellites being tracked
  • horizontal, vertical and position Dilutions Of Precision (DOPs)
  • latitude, longitude and altitude errors
  • Talker ID (identifies which group of satellites is being used)
  • Satellite Constellation (ID, azimuth, elevation, SNR and tracking)Most applications use some combination of the first 6. A few will display the number of satellites being tracked or DOPs, but I'm never sure why they show that, as the lat/lon/alt errors are the useful bits for navigation. Satellite count and DOPs can tell you how your antenna is doing, though.

I can't think of a reason to know the Talker ID. Why would you only care about GPS fix information and not GLONASS fix information? Or any of the other combinations? I suppose there could be some programmer, somewhere, who thinks he can use it to improve the fix. I'm skeptical.

And there's always one guy that shows a text list of satellites being tracked. -_- The u-blox utility, u-center, is good for visualizing that graphically, and it's what I'd use to make sure the antenna was working and in a good position. So I'm not sure why you would save and display this information with an Arduino...

Whatevs, NeoGPS can parse it all for you. Deciding what you really need will help keep the RAM, program space and processing time as small as possible. This will also determine which sentences have to be enabled. For example, if you only need time, you would only have to enable the ZDA sentence.

Cheers,
/dev

/dev:
I can't think of a reason to know the Talker ID. Why would you only care about GPS fix information and not GLONASS fix information? Or any of the other combinations? I suppose there could be some programmer, somewhere, who thinks he can use it to improve the fix. I'm skeptical.

Selective Availability

If, for example, the USA decides in one of its future military campaigns, to take back the decision of not using any longer "Selective Availability", which adds an extra portion of inaccuracy to the GPS signal to make GPS positions less accurate when SA is active, a GPS user possibly might make his decision, to avoid the GPS signal for navigation in his country and possibly likes to avoid GPS and better uses GLONASS. Or another system supported by his receiver and available in earth orbit.

Great explanation, thanks! So... SA means "Selective Avoidance"? :slight_smile:

Thanks all. I am now able to parse data using NeoGPS(GitHub - SlashDevin/NeoGPS: NMEA and ublox GPS parser for Arduino, configurable to use as few as 10 bytes of RAM). Cool! Now at this stage I am only interested with Time and Location(longitude and latitude). Is there a way of enabling time, latitude and longitude and hopefully reduce the number of libraries?
//Gil

Thanks all. I am now able to parse data using NeoGPS(GitHub - SlashDevin/NeoGPS: NMEA and ublox GPS parser for Arduino, configurable to use as few as 10 bytes of RAM). Cool! Now at this stage I am only interested with Time and Location(longitude and latitude). Is there a way of enabling time, latitude and longitude and hopefully reduce the number of libraries?
//Gil

/dev:
Ok, that's a u-blox Neo-M8 with active antenna capabilities, the NEO-LEQ-M8T. That confirms the GN/GL/GP talker ID issue with other libraries.

First, I would suggest that you decide what information you really need:

  • fix status (none, time only, standard, differential [really good!] or estimated [questionable])
  • date
  • time
  • latitude and longitude
  • altitude
  • speed
  • heading
  • number of satellites being tracked
  • horizontal, vertical and position Dilutions Of Precision (DOPs)
  • latitude, longitude and altitude errors
  • Talker ID (identifies which group of satellites is being used)
  • Satellite Constellation (ID, azimuth, elevation, SNR and tracking)Most applications use some combination of the first 6. A few will display the number of satellites being tracked or DOPs, but I'm never sure why they show that, as the lat/lon/alt errors are the useful bits for navigation. Satellite count and DOPs can tell you how your antenna is doing, though.

I can't think of a reason to know the Talker ID. Why would you only care about GPS fix information and not GLONASS fix information? Or any of the other combinations? I suppose there could be some programmer, somewhere, who thinks he can use it to improve the fix. I'm skeptical.

And there's always one guy that shows a text list of satellites being tracked. -_- The u-blox utility, u-center, is good for visualizing that graphically, and it's what I'd use to make sure the antenna was working and in a good position. So I'm not sure why you would save and display this information with an Arduino...

Whatevs, NeoGPS can parse it all for you. Deciding what you really need will help keep the RAM, program space and processing time as small as possible. This will also determine which sentences have to be enabled. For example, if you only need time, you would only have to enable the ZDA sentence.

Cheers,
/dev

/dev:
Ok, that's a u-blox Neo-M8 with active antenna capabilities, the NEO-LEQ-M8T. That confirms the GN/GL/GP talker ID issue with other libraries.

First, I would suggest that you decide what information you really need:

  • fix status (none, time only, standard, differential [really good!] or estimated [questionable])
  • date
  • time
  • latitude and longitude
  • altitude
  • speed
  • heading
  • number of satellites being tracked
  • horizontal, vertical and position Dilutions Of Precision (DOPs)
  • latitude, longitude and altitude errors
  • Talker ID (identifies which group of satellites is being used)
  • Satellite Constellation (ID, azimuth, elevation, SNR and tracking)Most applications use some combination of the first 6. A few will display the number of satellites being tracked or DOPs, but I'm never sure why they show that, as the lat/lon/alt errors are the useful bits for navigation. Satellite count and DOPs can tell you how your antenna is doing, though.

I can't think of a reason to know the Talker ID. Why would you only care about GPS fix information and not GLONASS fix information? Or any of the other combinations? I suppose there could be some programmer, somewhere, who thinks he can use it to improve the fix. I'm skeptical.

And there's always one guy that shows a text list of satellites being tracked. -_- The u-blox utility, u-center, is good for visualizing that graphically, and it's what I'd use to make sure the antenna was working and in a good position. So I'm not sure why you would save and display this information with an Arduino...

Whatevs, NeoGPS can parse it all for you. Deciding what you really need will help keep the RAM, program space and processing time as small as possible. This will also determine which sentences have to be enabled. For example, if you only need time, you would only have to enable the ZDA sentence.

Cheers,
/dev

Thanks! Finally it worked. I am interested in Time and Location (latitude &longitude) only. Is there a way of only enabling time and location(latitude and longitude) and hopefully reduce the number of libraries?

Is there a way of enabling time, latitude and longitude and hopefully reduce the number size of libraries?

Yes! I just want to be sure that you are getting a bunch of values in the Serial Monitor window, like this:

   Local time,Status,UTC Date/Time,Lat,Lon,Hdg,Spd,Alt,HDOP,
   2015-09-14 15:07:30,3,2015-09-14 19:07:30.00,472852332,85652650,,1262,,
   2015-09-14 15:07:31,3,2015-09-14 19:07:31.00,472852338,85652646,,1678,,

If you are NOT getting this kind of data, there is some problem with the GPS setup. Review the Troubleshooting section for some suggestions. Or post some output.

If you are getting this kind of data, you can now eliminate some of the things you don't need. If you look at the Configurations page, it describes all the pieces you can enable or disable. If you only want Time and Lat/Lon, edit your GPSfix_cfg.h and comment out all the other #define lines:

//#define GPS_FIX_DATE
#define GPS_FIX_TIME
#define GPS_FIX_LOCATION
//#define GPS_FIX_ALTITUDE
//#define GPS_FIX_SPEED
//#define GPS_FIX_HEADING
//#define GPS_FIX_SATELLITES
//#define GPS_FIX_HDOP
//#define GPS_FIX_VDOP
//#define GPS_FIX_PDOP
//#define GPS_FIX_LAT_ERR
//#define GPS_FIX_LON_ERR
//#define GPS_FIX_ALT_ERR

You can also disable parsing GPS messages that don't have Time and Lat/Lon (I assume you don't want the Date). Your GPS device is probably sending several kinds of messages, which contain a bunch of information you don't need.

Actually, you just need to parse any single message that has both pieces: GGA, GLL or RMC would work (see Choosing Your Configuration). GLL is the shortest, so that would be quickest to parse.

To enable just the GLL message, edit your NMEAGPS_cfg.h and comment out these lines:

//#define NMEAGPS_PARSE_GGA
#define NMEAGPS_PARSE_GLL
//#define NMEAGPS_PARSE_GSA
//#define NMEAGPS_PARSE_GSV
//#define NMEAGPS_PARSE_GST
//#define NMEAGPS_PARSE_RMC
//#define NMEAGPS_PARSE_VTG
//#define NMEAGPS_PARSE_ZDA

When you get this working, you could send some commands to the GPS device to tell it to send only the GLL sentence, not the GSV, RMC, etc. That will save some processing time, because the Arduino won't have to ignore all those sentences. Even though the Arduino doesn't parse them, it still spends a little time receiving them and then throwing them away.

Cheers,
/dev

Oh, yes... If you disable the RMC message because you only want the GLL message, you will have to change this line in NMEA.ino:

      if (gps.nmeaMessage == NMEAGPS::NMEA_RMC) {

...to this:

      if (gps.nmeaMessage == NMEAGPS::NMEA_GLL) {

Otherwise, the fix data that is printed will be empty, because the RMC never fills it out.

Uncommenting this line in NMEAGPS_cfg.h would have the same effect:

#define NMEAGPS_ACCUMULATE_FIX

Cheers,
/dev