Ublox M8Q. Question for default config

Hi. Im have question for users of this module. Is GPS + GALILEO + SBAS enabled by default in these modules? Thanks for reply.

Myself, I dont remember.

The datasheet probably has the details;

My hint is not to use NMEA but instead the ublox mode (Avaiable over I2C an Uart)

I searched, but nowhere can I find information about the default configuration.

And in case your using the plain old M8Q, look in here;

when you power on the chip everything should be turned on, why not?

Not so. Configurations are set in battery backed memory and retained during power off.

@OP: Use the U-Center software to determine the current configuration, and if necessary change it.

I have a problem, I use mac os x, I can't run u-center, I can only connect to my ublox via uart. How to download the current configuration?

The easiest way to get this done is to find a Windows machine and run U-Center.

Otherwise you have to send UBX messages to set the configuration. The firmware manual details those, and there are many, many of them.

You dont need to download the current configuration really, just power the GPS up and it will have the configuration as described in the datasheet. However you do need to read the datasheet to find that information.

Hi. I usually wait a few minutes for fix quality in rmc sentences to indicate SBAS as the source for dgps correction. Is this normal? can it be faster? I must have the maximum repeatability of the position accuracy. The effect is that when I save the position indicating by the module, after a few minutes DGPS will change the correction from SBAS, when returning to the position it shows me 2-3 meters in another place.

Good question, i'm also interested for my project. As i can see in the u-blox docs:

For receiving correction data, the u-blox receiver automatically chooses the best SBAS satellite as its primary source. It will select only one since the information received from other SBAS satellites is redundant and/or could be inconsistent. The selection strategy is determined by the proximity of the satellites, the services offered by the satellite, the configuration of the receiver (Testmode allowed/disallowed, Integrity enabled/disabled) and the signal link quality to the satellite.

If corrections are available from the chosen SBAS satellite and used in the navigation calculation, the DGPS flag is set in the receiver's output protocol messages (see UBX-NAV-PVT, UBX-NAV-SOL, UBX-NAV-STATUS, UBX-NAV-SVINFO, NMEA Position Fix Flags description). The message UBX- NAV-SBAS provides detailed information about which corrections are available and applied.

So i would say the variable time slot to SBAS correction you mentioned is caused by the visibilty of the SBAS sat, isn't it? So the only way to check this is to read out that DGPS flag and wait with keeping the position until the SBAS is up. I'm using the sparkfun lib for the M8Q and with a quick view i did not see the call to read out this flag. Have you?

It would be interesting if the Ublox GPS default firmware setup does not provide the maximum possible position accuracy.

How can you be sure that it provides the maximum possible accuracy? How can we have maximum accuracy when the SBAS is corrected after a few minutes? will show me a different position than I marked a few minutes earlier ..

I think it does, why not? The question is at what point are the positions so accurate that they should be used? obviously there should first be a 3d fix that can be queried. The question pem111 raises (I think) is, when does the SBAS correction come (a sat is visible) and how can you tell?

Have you tested the getPositionAccuracy?
This could be a more elegant way to do it -> use the position if (getPositionAccuracy < xy)

//Get the current 3D high precision positional accuracy - a fun thing to watch
//Returns a long representing the 3D accuracy in millimeters
uint32_t SFE_UBLOX_GPS::getPositionAccuracy(uint16_t maxWait)
  packetCfg.cls = UBX_CLASS_NAV;
  packetCfg.id = UBX_NAV_HPPOSECEF;
  packetCfg.len = 0;
  packetCfg.startingSpot = 0;

  if (sendCommand(&packetCfg, maxWait) != SFE_UBLOX_STATUS_DATA_RECEIVED) // We are only expecting data (no ACK)
    return (0);                                                           //If command send fails then bail

  uint32_t tempAccuracy = extractLong(24); //We got a response, now extract a long beginning at a given position

  if ((tempAccuracy % 10) >= 5)
    tempAccuracy += 5; //Round fraction of mm up to next mm if .5 or above
  tempAccuracy /= 10;  //Convert 0.1mm units to mm

  return (tempAccuracy);

UPDATE: this function is only valid for NEO-M8P and ZED-F9P.

Do you know what the confidence level is for the provided position accuracy ?

No, i can't even test because these functions are not implemented for my gps chip

Any news on this topic? I'm coding around this problem at the moment.
I observed that out of a sudden the number of sat in view SIV drops down from 14 to 6 which brings an offset of up to 30 meters.
As all the special commands like getPositionAccuracy etc are not implemented in this chip, i use the primitive way of if(SIV > 8) because i saw that with a minimum of 9 sats the accuracy is +- 10 to 15 meters.


  • Did someone found a more elegant way?
  • Is there a suggestion for a better chipset without these jumps?
  • Any experience with these issue in the new 2.0 lib from sparkfun? As i oversaw it's mainly a update for automatic callbacks in high speed applications. Am i wrong?

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.