GPS Status = 4

Log Analysis -- deprecated Copter Logs -- deprecated
1

In recent flights I’ve noticed that GPS status has been recorded as 4 in the data flash log. This happens either from the outset or part way through the flight.

Where this happens from the outset it causes Mission Planner to fail to calculate the date/time stamp for any of the messages, and causes Mission Planners geotagging to fail. It also prevents Mission Planner from correctly naming the log file when downloaded via MavLink - instead of being named after the date and time of the mission, it takes the date time of the download.

For flights where the status changed from 3 to 4 mid flight this was not problematic for Mission Planner.

Does anyone know why the status might be recorded as 4? It is not mentioned in the Wiki and it seems Mission Planner can’t cope with it.

I was able to resolve the geotagging and time stamp problems (not the download naming problem) by editing the log file and changing all the 4s to 3s. Then Mission Planner accepted it.

I’m running Arducopter 3.3 on a Pixhawk with Neo 8 gps/compass module (well, supposedly, but I’m not sure how to check it really is an 8) and Mission Planner 1.3.32.

Many thanks

Jeremy

2

3.3 changed to show low HDOP or good position by outputting a 4. A 3 means it has a 3D fix and a 4 means it has a good position. Date and time just comes from the GPS unit as a value so don’t know why it would mess with the logs unless your GPS unit is not outputting the Date and time.

Mike

3

Thanks Mike that’s helpful to know.

If 4 is an accepted value for GPS status then it suggests a Mission Planner problem.

The log file is fine, with date/time values from the GPS all being OK. What I suppose is that Mission Planner doesn’t recognise 4 as a legitimate value for GPS status and that’s causing it problems reading the gps date/time value which it needs to set the start point for the on board counter. But that’s all a guess.

Jeremy

4

OK, just tried an experiment and confirmed it:

If the first gps message in the data flash log file happens to have GPS Status = 4 then Mission Planner can’t work out the dates/times for all messages. Dates aren’t displayed in DATAFLASH LOG REVIEW panel and GEOTAGGING won’t work and the log file (and associated kmz etc) will be named with the download time when downloading over mavlink. If you ensure the first GPS message status is a 3, then it’s fine.

So I’d say that’s a Mission Planner issue if 4 is a legit GPS status value.

Cheers

Jeremy

5

Mission Planner update 1.3.33 of 8/12/2015 resolves this issue.

6

Hi,

I know this is an older post but I am getting the same problem now, I have firmware 3.3.3 and MP 1.3.37. All my tests where starting with GPS Status = 3 (so I don’t have the date/time issue) and changes to 4 a few seconds later. Mission Planner is reporting “3D dgps” as my GPS Status, which is correct if GPS Status = 4. Mavlink records status = 4 as DGPS fix and I only have the standard ublox receiver. Making GPS Status = 4 for a “better” 3D Fix sounds like a bad idea, isn’t that why we have HDOP to evaluate the GPS lock quality?

Anyway my real problem is that I would like to fit a real DGPS, so how will I then know if its really DGPS or just a good 3D fix?

7

A good GPS fix is when the satilites are the correct angle away from each other to produce a good fix. This means a low HDOP and good fix. Status 4 is indicated when this angle calculation is very good and means it has a better fix and also means low HDOP.
On the Pixhawk in Stabilize mode you will see the LED turn to green when it has a 3D fix. It will start to flash rapidly when it gets a status 4 GPS lock. If you are using Tower it will report status 4 GPS lock when it has one.

Mike

8

My understanding is the status 4 is just 3d+DGPS or Differential GPS fix. You can read about it here: https://en.m.wikipedia.org/wiki/Differential_GPS

9

Thanks for the feedback guys, I guess my problem is more with Mission Planner reporting DGPS fix when the status is 4. But then again that is correct if translating it from MAVlink, message #24 states:

0-1: no fix, 2: 2D fix, 3: 3D fix, 4: DGPS, 5: RTK. Some applications will not use the value of this field unless it is at least two, so always correctly fill in the fix

To me it seems the problem is not with Mission Planner but rather with the developers of ArduPilot changing the meaning of fix type 4.

So if I have a real DGPS fitted (using base and rover receivers sending correction data), then how will I know if its a better 3D fix using a single receiver or actually a real DGPS fix when both will report 4?

10

We are currently setting up RTK on Copter using Mission Planner and I am wondering if this issue has been resolved or there is any movement on resolving it?

11

According to a post in another thread:

That would seem to jive with MAVlink #24 4:DGPS.

13

Hi everyone, anybody heard about status 6? I have a log, and Im not sure what status 6 means. Thanks!

1 Like
14

From ardupilot/AP_GPS/AP_GPS.h

 /// GPS status codes
    enum GPS_Status {
        NO_GPS = GPS_FIX_TYPE_NO_GPS,                     ///< No GPS connected/detected
        NO_FIX = GPS_FIX_TYPE_NO_FIX,                     ///< Receiving valid GPS messages but no lock
        GPS_OK_FIX_2D = GPS_FIX_TYPE_2D_FIX,              ///< Receiving valid messages and 2D lock
        GPS_OK_FIX_3D = GPS_FIX_TYPE_3D_FIX,              ///< Receiving valid messages and 3D lock
        GPS_OK_FIX_3D_DGPS = GPS_FIX_TYPE_DGPS,           ///< Receiving valid messages and 3D lock with differential improvements
        GPS_OK_FIX_3D_RTK_FLOAT = GPS_FIX_TYPE_RTK_FLOAT, ///< Receiving valid messages and 3D RTK Float
        GPS_OK_FIX_3D_RTK_FIXED = GPS_FIX_TYPE_RTK_FIXED, ///< Receiving valid messages and 3D RTK Fixed