High Hdop, is it a problem? If yes then how to fix it

Hello,
I am having some issue getting a good Hdop value when using Here2 GPS with CAN bus. I have two of those set in pixhawk cube black. The satellite count is good in both but never able to achiever less than 1.2 HDOP. Following is log from one of the flights.

https://drive.google.com/file/d/1i-tyn-nuty7uKb6OQcQGqJnDBa43uQen/view?usp=sharing


This means that the horizontal precision (lower is better) of your GPS module is 1.2 meters at that given time.
As you can see from the log, higher # of sats, higher precision, lower error.
This is pretty good.
Most of time < 2 meters is good, at least for me.
If you want more precision, you need to switch the modules to RTK.

2 Likes

I have a doubt that this is the correct interpretation of this parameter. I agree with rest of your comments.
The thing that worries me is people using here2 are able to get HDOP of 0.6 or 0.7 at 15-16 sats but mine even 17 sats its that bad.

Even I doubt the compass of Here2 as you can see there in considerable difference in magX, magZ values of the two compass in both Here2 gps

HDOP is predictable here, so choose day/hour to try.

1 Like

You’re right. Sorry about that. Roughly linearly dependent though :slightly_smiling_face:

GPS modules are sensitive to voltage source fluctuations, you can take a close look if everything is OK or not. Other than that, nearby buildings affect the precision too.

This happens with GPS on CAN bus. If I put it to serial port then… Am getting 0.6 hdop

1 Like

maybe canbus is noisy? If I use usb3 on my companion it takes all sats down (usb is known to be very noisy). Just taking a guess.

Corrado

1 Like

But isn’t the CAN bus the most superior protocol?
I did tried different combinations of cubes and Here2 but the problem is with CAN bus only.
Any idea how can I check that its noise but not some software

Indeed it is.

This is really interesting. Is it repeatable?

You can take a look at it with oscilloscope for both voltage and communication terminals (CANH, CANL).
Do you have anything different from here?
Also please use the latest stable firmware if you’re not on it.

Dont know how to interpret this data but the number seems good to get a good HDOP.

Already using the latest stable firmware

Didn’t get anything here that required oscilloscope. Basically, I am not convinced that there is a chance of noise if I try different combination of three Cube and five Here2 (in CAN). Also I have tried powering via USB and battery but no luck.

Is there a chance to log with LOG_DISARMED=1 and record some logs with both CAN and I2C setup?
Post the onboard logs (*.bin files) so people can take a look at them.
If it is a bug (not something misconfigured in your setup), we may raise an issue.

Yeah, will do that and post the log here. Thanks for supplying the idea.

1 Like

Yes, HDOP 0.38 is excellent, but there are other factors as trees, buildings, etc, shadowing. You can check at different days or times.

It’s an open football field where I fly.

I am ready to do that but that shouldn’t much such big difference. getting a change in value from 0.6 to 0.8 ie 0.2 or something is can explained from this logic but. Getting it over 1.18 for five straight days that too at different times is something I don’t agree to go with this logic.

If you have a good theoretical HDOP and try on wide open sky, but get a bad HDOP, there is something strange.

Here is a simultaneous test of two RTK GPS’s with u-center utility (two instances) at a moment with HDOP around 0.5. As you see both are at RTK FIXED, showing the same coordinates (only decimal part shown; the longitud difference is their physical EW separation), and show HDOP 0.7 and 0.6, close to theoretical:

So perhaps you can try the GPS alone with u-center utility.

2 Likes