Add support for auto-reporting of navigation solutions using UBX_NAV_PVT

[tve]

This PR implements the suggestion in #3, which is to enable auto-reporting of navigation solutions and switching getPVT to report the data of the most recent one. Docs added to readme and Example13 shows the use.

NB: I'm testing on a Particle mesh device, so I have to do some minor cleanup to generate a PR, please test on a regular arduino (I don't own any, oops) before merging.

[tve]

oops, this isn't yet fully working, I overlooked the startingSpot stuff...

[nseidle]

I really like this PR but I'm hitting a problem. When running on a ZED-F9P (not sure it makes a difference) the PVT responses are inconsistent with some delays reaching over a second.

In the above output I've set the update rate to 10Hz and I often (but not regularly) get large 1000ms+ delays.

void setup() { Serial.begin(115200); while (!Serial); //Wait for user to open terminal Serial.println("SparkFun Ublox Example"); Wire.begin(); Wire.setClock(400000); if (myGPS.begin() == false) //Connect to the Ublox module using Wire port { Serial.println(F("Ublox GPS not detected at default I2C address. Please check wiring. Freezing.")); while (1); } myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise) myGPS.setNavigationFrequency(10); //Produce two solutions per second myGPS.setAutoPVT(true); //Tell the GPS to "send" each solution myGPS.saveConfiguration(); //Save the current settings to flash and BBR } long timeSinceLastPVT = 0; void loop() { // Calling getPVT returns true if there actually is a fresh navigation solution available. if (myGPS.getPVT()) { Serial.println(); Serial.print(F("TimeDelta: ")); Serial.print(millis() - timeSinceLastPVT); timeSinceLastPVT = millis(); long latitude = myGPS.getLatitude(); //Serial.print(F(" Lat: ")); //Serial.print(latitude); long longitude = myGPS.getLongitude(); //Serial.print(F(" Long: ")); //Serial.print(longitude); //Serial.print(F(" (degrees * 10^-7)")); long altitude = myGPS.getAltitude(); Serial.print(F(" Alt: ")); Serial.print(altitude); Serial.print(F(" (mm)")); byte SIV = myGPS.getSIV(); Serial.print(F(" SIV: ")); Serial.print(SIV); Serial.println(); } else { Serial.print("."); delay(50); } } 

Above is the code.

Additionally, once the above code is run the ZED-F9P goes pretty wild. I am seeing some really weird behaviors over the USB connection (I2C is connected to Uno, USB is connected to PC running u-center). The module is behaving then it completely goes bonkers once Ex 13 is run. Stays bad until a power cycle.

Above is good data.

Above is immediately after Example 13 is run. I'm going to try the original branch and see if I can pin down what the problem is.

[nseidle]

Ok, the weird u-center display is caused because NMEA can't keep up at higher rates so ucenter struggles to display the current data. Please disregard my u-center 'going bonkers' concern.

Switching to the SAM-M8Q and lowering the update rate back to 2Hz:

Your PR works like a charm. I'm not sure what the ZED-F9P issue is but I'll continue to look into it. (As an aside, SAM-M8Q getting a lock on the lower level of a two story building is pretty wild).

[tve]

Cool, thanks!

[IanCampbell-Kelly]

I'm new to C++, and GPS, but I found this library easy to understand and helped my learning experience with GPS! I had similar issues to @nsidle with occasional timeouts. Also, I only have a ublox 6 chip. So the attached 3 files which read a ublox 6 chip using the NAV-POSLLH solution, with a CFG-MSG which automatically sends this twice a second. It's very untidy but I hope informative; all modifications should be commented, and the original code is not deleted, it's just commented out. This library is about ublox 8 and 9 and modules from SparkFun, so I don't expect a formal fork or whatever. Just, the code is here if you have a ublox 6 and want to use it.
Example3_GetPosition ublox 6.zip