Ublox.ino compile errors on Mega 2560 about neogps

[SlashDevin]

It's complaining because this needs to be uncommented in NMEAGPS_cfg.h:

#define NMEAGPS_PARSING_SCRATCHPAD

There is a check in ubxGPS.cpp, line 16, that should have emitted this error:

In file included from ...build1a60db5dae6248244897ff617f036cf2.tmp\sketch\ubxGPS.cpp:1:0:

ubxGPS.cpp:16: error: #error You must enable NMEAGPS_PARSING_SCRATCHPAD in NMEAGPS_cfg.h

   #error You must enable NMEAGPS_PARSING_SCRATCHPAD in NMEAGPS_cfg.h

    ^

If you didn't get that error, please show me your GPSfix_cfg.h and NMEAGPS_cfg.h files.

[mjs513]

NeoGPS-master.zip

Only message I received was what I sent. Scratchpad is enabled.

[SlashDevin]

Confirmed, fixed by latest commit e4ad94e. You just need the changes in ubxGPS.cpp and ublox.ino.

Thanks!

[mjs513]

Just tested both pubx and ublox sketches. Both work no problem. However, did notice that you do not have a line for Galileo satellites to filter out. If I may ask one more question, how do you get individual elements in the ublox example such as print only hdop, pdop, sog, cog, etc,

[SlashDevin]

Can it filter out Galileo satellites?

That's a great forum question! I'll respond in my NeoGPS thread, and update here when they're ready. There might be a problem with NMEA GSV sentences that's related to different talkers, still investigating.

how do you... print only hdop, pdop, sog, cog, etc,

Please see the Data Model page, or look at the Streamers.cpp file. It shows how to access every piece, for printing. For example, accessing Speed (Over Ground) from a fix is here. There are other speed-related methods in a fix, which can be found in the gps_fix class, here.

[mjs513]

That's what I thought. However, DOP values are not being returned either by the UBX command or the fix method. Here is a sample line from the trace all:

3,2016-09-24 11:40:39.60,407746042,-738146466,40 46' 28.574" N 073 48' 52.727" W,14626,2546,1932,,,,87,87,173,,25,[1 53/142@0,7 59/192@22,8 44/50@10,10 2/41@0,80 0/0@0,38 0/0@0,3 0/0@0,13 0/0@0,70 0/0@107,54 0/0@0,3 0/8552@0,1 33/1049@104,1 0/0@14,4 0/296@64,3 0/56427@50,1 0/0@41,0 0/30800@1,3 0/18214@1,18 0/56323@1,14 23/9229@3,],68,96,16499,,

Here is the fix elements
HDOP, PDOP
0, 0, 2.55, 146.26, 407746042, -738146466, 25, 2016-09-24 11:40:39.60, t

You want me to open a another issue or move this to the forum? There is question I will post to forum on polling UBX

Mike

[SlashDevin]

DOP values are not being returned by the UBX command or the fix method.

I'm not sure what you mean. A "UBX command" is a binary message that you send to a ublox GPS device. UBX is the name of their binary protocol. ublox GPS devices can also emit proprietary NMEA messages (text format), and they start with "$PUBX,".

The NMEAGPS class has a fix() method that returns the gps_fix structure that is currently being assembled, and it is not usually safe to call that method. Most of the examples declare a fix variable (of type gps_fix), and assign the return from gps.read() to that variable.

I think you might be saying that your program never gets an HDOP or PDOP value, or it's zero if you print out the variable from some fix structure.

You want me to open a another issue or move this to the forum?

Yes, that would be another issue. I can suggest a few things that you should check first:

It looks like HDOP and PDOP are enabled in GPSfix_cfg.h, because there are commas after the altitude field. Because the trace_all has empty fields, the values are not valid (i.e., they have never been parsed from a sentence). You can test fix.valid.hdop. Really, you should always test the valid flags, because printing a "default" value can be misleading. What if the GPS device really reports an altitude of zero? You wouldn't be able to distinguish between "really at zero" and "don't know". I would suggest printing either an empty field (like Streamers.CPP), a dash character ('-'), or a ridiculous value (-999).

If the valid flags are always false, it could mean that the sentence(s) that contain HDOP and PDOP fields are not enabled (they won't be parsed even if the GPS sends them), OR that the GPS device never sends a GSA (the only sentence that contains PDOP, see this table).

For the former, check that NMEAGPS_PARSE_GSA is uncommented in NMEAGPS_cfg.h. For the latter, check that the GPS device is actually sending a GSA by running NMEAorder.ino. You may also need to change LAST_SENTENCE to match what is reported.

If you still have trouble, open another issue and be sure to attach your configs: GPSfix_cfg, NMEAGPS_cfg and (if you're using ublox.ino) ubx_cfg.

[mjs513]

Think I figured out the issue based on your comments above. Since I am running the ublox.ino example it uses the ubxGPS.cpp to parse the UBX messages (I can it commands previously) so I checked the ubxCFG file and ubxGPS.h/.cpp and there is no parsing option for the UBX-NAV-DOP message that contains those fields. I will go ahead and open another issue.

[SlashDevin]

Can it filter out Galileo satellites?

I have updated my NeoGPS thread with an answer, here.