NEO-M9N defaultMaxWait

I posted this question in another forum as well, but this one is closer to the subject matter…

I have several M9N’s in service now, and they work great. My issue is the hold delay when I call the Sparkfun library using I2C (say with fixType = RobotGNSS.getFixType():wink: and the unit is not yet sync’d. If it is sync’d, it returns data almost immediately (2ms).

When there is no sync–at startup for example-- it hangs up for 1/2 second even when I redefine defaultMaxWait to 250. Without the redefine the call hangs for 3/4 sec.

The unit with the issue is on a robot running a realtime OS and having a solid block of 1/2 second doing nothing throws a wrench into lots of things. I would have thought it would do a quick check, see no fix, and return asap. Is there a workaround?

Hi,

I’ll explain some of the background first, and then give you the solution… Keep reading! :wink:

The u-blox modules have an internal measurement rate. This defines how often they calculate a position measurement. Normally this is 1Hz (an interval of 1000ms), but you can increase it. 4Hz works well. Some modules support 20Hz or higher. There is also a navigation rate. This defines how often the module calculates a solution. This defaults to 1 and you get a solution every measurement.

The u-blox modules can output data in two formats. NMEA is text-based and human-readable. It’s what the original GPS receivers used to output their data. u-blox have added their own, more efficient, more compact, binary protocol called UBX. The UBX PVT message contains the Position Velocity and Time of the navigation solution. It contains the latitude, longitude, altitude, speed, heading, time, date and fix type. When you call getFixType, the fix type is being read / extracted from the UBX PVT message. The parent function is called getPVT. getPVT gets / reads the full PVT data. getFixType extracts and returns just the fix type from the full PVT data. If you call getFixType on its own, the library actually calls getPVT transparently in the background, and then returns just the fix type.

UBX messages can be polled or set to periodic. The SparkFun library defaults to polling. When you call getFixType, the PVT message is polled / requested by getPVT. Here’s the important bit: the data is only returned / output at the end of the solution calculation. If you happen to call getFixType at the start of a cycle, it can be up to a full second before the data is returned. The call is blocking; it spins its wheels until the data is returned by the module - or the call times out. maxWait sets the timeout. The default is set to 1100ms (1.1s) because it is normal for it to take up to a second for the data to be returned. If you set a shorter maxWait, the function will timeout sooner. It doesn’t change the solution rate.

The solution is to use periodic. The PVT message can be set to be output automatically (periodically) every time the module has a new solution. You don’t need to poll it. In the SparkFun library, we use the term “Auto”. setAutoPVT tells the module to output the PVT message periodically. It also changes the way getPVT works. getPVT will - from then on - check for the arrival of new data and will return ~immediately. It returns true if new PVT data has arrived, false if not. It also changes the way getFixType works. getFixType will also then return ~immediately. The fix type returned is whatever was extracted from the previous PVT message and could be stale by up to one cycle. But at least it returns immediately.

Have a look at the “Auto” PVT example for more details. You have an M9, so I’d recommend using v3 of the SparkFun library. But v2 will (probably) work just fine too.

v2: https://github.com/sparkfun/SparkFun_u- … utoPVT.ino

v3: https://github.com/sparkfun/SparkFun_u- … tyTime.ino

In the v2 example, it does one extra check and only outputs data once the latitude-longitude-height is valid. You can delete this part of line 58 if you want to: && (myGNSS.getInvalidLlh() == false) leaving just ```
if (myGNSS.getPVT())


Lecture over! :D 

I hope this helps,

Paul

wow, Paul… you get an MVP for this one. I figured there had to be a good approach. thanks.