Bad GPS Health when I have RTK Fix

Some comment to this will be appreciated
I am working with the Pixhawk 1 with Rover firmware 3.2.1. Mission Planner is the latest version. I have 2 GPS connected and one is providing a RTK fixed position. ie status 6
Both gps see at least 12 satellites. However I am getting a “Bad GPS Health” message. If I disconnect the second GPS and retain the rtk gps I still get the message.When the rover is working the gps seems to be working well

What needs to be off to get this message.

Last week I was not getting this message. It started apparently with out making any changes to the gps settings. I will post a data flash log in a follow on post as I can not find the include button

regards

Hopefully this is a link to the data flash file

When I remove the gps stream (ie disconnect it from the pixhawk ) from the ublox C94- M8P the error message goes away.Currently I am using a NMEA data format for the GPS_TYPE
I will check the gps output to see why this is happening

The GPS must maintain at least a 5 Hz update rate for the EKF to be happy. Because of this if the GPS goes below 5 Hz update rate we consider that unhealthy. You can look at the GPS.Delta field to get the time interval (in milliseconds) from a log.

Why use the M8P in NMEA mode? We will configure it in UBX mode, check appropriate settings and provide a much higher performance/assurance level with it in that mode then in NMEA.

I appreciate your reply. I will check it out today and respond with the results
Thanks
Max

GPS.Delta is reading 100. So is that 1 Hz?
GPS_RATE was set to 200 which is 5 Hz
I set it to 100 to ensure I am above the 5 Hz lower limit
Still got a “Bad GPS Health” message

Regarding the format of the GPS. The Ublox C94-m8p evaluation board can output the following
UBX
NMEA
RAW
RTCM3
Various user
UBX+NMEA
UBX+NMEA+RTCM3
At various baud rates I have 19200 selected

The Mission planner can receive
AUTO, uBlox, NMEA and various other formats

The only combo that I can get to work so far is

C94 outputting NMEA and MP receiving NMEA

What is strange is that setting uBlox in MP does not accept uBlox from the C94 which is a Ublox M8P evaluation board

Can you suggest anything else or combinations

Regards
Max

MISTAKE GPS.Delta is reading 1000 NOT 100

I fixed the Ublox C94-M8P to an arduino to read the gps output and it seems that most of the outputs do not produce a data stream.
However NMEA does provide a gps sentence with 5 different strings.
I also changed the output from 1Hz to 10Hz and that cured the Bad GPS Health issue.
Thanks for your help…on to the next thing
Do you know why MP sometime connects in 20 seconds and sometime it takes 2 minutes even on the same baud rate (ie not on USB)

I am still getting “Bad GPS Health”. Now it is intermittent. Are there other parameters that cause this to happen.
regards

100 milliseconds is 10Hz
200 milliseconds is 5Hz
1000 milliseconds is 1Hz

GPS_RATE will only have an effect if GPS_TYPE is set to 2, otherwise the parameter is ignored. If you had set GPS_TYPE 2 instead of 5 then we would have automatically moved the GPS to 5Hz updates for you.

It’s worth noting that depending on your constellation settings an M8P cannot produce a 10Hz RTK stream.

The baud rate of 19200 is quite slow (and would actually be rejected for a GPS_TYPE 2). We can barely get enough data through the link at 10Hz for that, and we can’t afford to run any GPS validation at that baud rate. In NMEA which is a much larger output set I’m sure you are saturating the link. This is one of the worst things you can do to the GPS driver. What ends up happening is that you slip on timing because the data for an update isn’t received in time, then data can’t be fit onto the port so it’s dropped. I’ve seen examples where this causes a vehicle to go crazy on it’s position estimate, even though it had a very high end GPS connected. Raise the baud rate to at least 38400, preferably 115200.

To be perfectly clea: unless you spliced the GPS output stream into some other device on your system that only understands NMEA you should just be using the GPS with the ublox protocol. All of the GPS problems you are encountering would have been fixed for you without you ever having to deal with them if GPS_TYPE was set to 2.

1 Like

I do appreciate your responses.

For making changes to the C94-M8P I use the Ublox U-Center Software. I can make changes to the Baud Rate (now 115200 on the Rover) and the data rate (now 5 Hz) and I can make changes to the protocol out statement in PRTS .

However only NMEA seems to out put as I can check the data with an Arduino. The option that I guess we want is the UBX format. I have contacted a friend who is an expert on the C94 board and U-Center to get his ideas.

My test is not over as tonight I could not change the Baud rate in the base station to 115200 as it is on the roof and can wait till morning.

When I do use NMEA the “Bad GPS Health” message is intermittent or occurs very little.
Maybe now I have upped the Baud and sorted out the data rate to be 5 Hz maybe it will be OK ? Lets see in the morning when I re establish the error messages from the Base
regards
Max

You don’t need your base station to be at the same baud rate as the GPS on the aircraft assuming you are injecting via ArduPilot rather then using a second port on the GPS.

You neeed your aircraft GPS to be accepting all forms of input (UBX + NMEA + RTCM) in order for it to accept the correction data. It should only be outputting UBX to ArduPilot though.

Again the correct way to connect this GPS to ArduPilot is to connect the Rx/Tx lines from your autopilot to the GPS, then set GPS_TYPE 2 and let ArduPilot takeover. U-Center should only be needed for firmware updates, everything else should be managed via the autopilot. The issues you are encountering appear to all be from attempting to work around the configuration system without having followed it.

1 Like

In my setup I am not injecting the GPS like the “Here” system. They have a Base connected to the PC that runs Mission Planner and then it injects the error messages via the telemetry to the rover.

With the C94-M8P development boards the Base is remote and not connected to a PC. The corrections are passed by radio to a port on the rover. This is the protocol in message.

The corrected gps position is then exported to the Pixhawk by serial. This is the protocol out message.

I can assure you that I want a simple life and I am not trying to short cut /circuit any system. I would like this to plug and play.

For my set up I do need to use U-Center to configure the GPS otherwise nothing works. The problem I have is that when I try to send UBX data to the autopilot from the GPS the data stream stops. As seem on the Arduino

I have a second set of C94 boards I will see if they have the same UBX issue

Most appreciated chat sorry to bother you. Many thanks

Apparently the UBX protocol is binary so I will not see this on my arduino as it is currently configured. So UBX may being sent from the Rover GPS however this does not explain why I get No GPS message
Regards

Hi! I am trying to do the exact same thing you are, Maxbirley. Were you successful? The schematic shows that the radio on the C94 board and the serial lines are combined (Anded, but since I tihink serial data is active low, that performs an OR). So, I was wondering when you changed the baud rate in the C94, did your RTK corrections from the base still come through? I would think you would have to change the baud rate in the RTK base C94 also.

I have my GPS giving very accurate location with NMEA, but I am getting bad health. I’m sure it is the 1Hz issue. I am about to change that but I am unsure if I can change the baud rate without affecting the RTK corrections from the base.

Any progress on your end (help from anyone is appreciated!).

I’m not much of a GPS expert but a few things:

  • if the GPS is outputting NMEA and you want to use these NMEA messages, then the GPS_TYPE must be set to “5”. We don’t automatically detect NMEA any more because we had a lot of problems with UBlox GPSs being recognised as NMEA GPSs which leads to bad performance because NMEA messages have less info in them than the Ublox binary messages.
  • the update rate from the GPS must be at least 4hz (preferably 5hz).

If anybody comes up with ways our GPS wiki pages could be improved, I’m happy to add more info.

Thank you. I do have the GPS type set to 5 (NMEA). I am getting very good accuracy and Mission Planner is showing a status of “RTK fixed”. I am getting the Bad Health message, however, which you explained above is because updates are not coming fast enough at 1 Hz.

The C94-M8P is a little bit of a strange beast, unfortunately. If you dig into the schematics, you see that there is one UART that has its transmit signal split to 3 ways and its receive signals "ored together 3 ways: (1) to a 3.3V logic level header, (2) through a typical RS-232 level shifter to a DB9 connector, and (3) to the radio that is used for RTK corrections. So, it is OK for up to 3 devices to be listening but only one device can transmit into the C94-M8P.

Since we are trying to use the built-in radio for the RTK corrections, the C94-M8P acting as rover can’t also receive setup info from the PixHawk. At least, that is my belief, because the two “transmitters” are not synchronized so data would be garbled and lost.

Also, according the the C94-M8P docs, the baud rate for the radio needs to be 19,200. That means we are stuck with that since we are sharing the UART as described above.

That is probably as clear as mud!

Anyway, I plan to try using Mission Planner for now as the RTK correction device to see how that goes.

I am fighting another issue with the compass being off. I will post that in its own thread, I guess, as I have already been accused (correctly, I might add) of highjacking someone elses post the other day!

Thank you all for the excellent work!

Hi Kenny
I have not worked on this for some time as I have been doing other things. I will return to this in about a week. So what I am writing here is what I think. It still needs to be proven by putting into practice

You are getting the bad health message because you are using NMEA messages and not UBX messages. The NMEA message that you are sending does not contain all the data required by the ardupilot software.

I have been advised by several people that we need to send UBX messages.

The C94 is very configurable you can select one, some or all of the NMEA or UBX messages to send. I would start by switching off all NMEA messages and switch on UBX messages one by one until the “bad” message goes away.

The alternative is to just live with the message

I will also ask Michelle Osbourne the author of Mission planner what UBX messages are required.

Regarding the radio coms part I use radios with different frequencies and keep the baud at 19200. What I mean by this is. The two rtk radios are at one frequency (set at the factory) and the mission planner radios need to be at an other frequency so they do not interfer
Regards
Max

Regarding the rate at which data is sent from the c94 unit it is controlled by the message config…UBX Rates you can set it to 5hz no problem. The many problem with the c94 is that it is so configurable and has so many options that if they are not set properly you do not get the desired outcome.
I suggest you re read the manual especially on configuring messages. It will hopefully make things clearer. I personally fall asleep when I read the manual however if you can stay awake it is worth the effort.

Hi Randy
As explained in another response in this post the c94 is very configurable and the UBX message is not just one message. It can be made up from multiple different messages. From the C94 I can send one, some or many different UBX or NMEA messages. In any combination.
I just need to know the nature of the UBX messages to send. It seems to be the main difference between NMEA and UBX is that NMEA is made of text messages and UBX are binary. The content of the messages are both very configurable. Unless I know what Mission Planner wants I will be in the dark. I will try some pot luck until I find out the actual required message just for fun