Hdop0.5
Sat 32
I thought this was enough to know it has good gps lock.
So by solving gps issues means
Gps configuration issues right, compass variance issues later on
Hdop0.5
Sat 32
I thought this was enough to know it has good gps lock.
So by solving gps issues means
Gps configuration issues right, compass variance issues later on
Sat count is irrelevant as long as it is more than 6 or so.
High sat counts are counterproductive, because they tend to increase the latency and decrease the update rate of the GPS location output. Ass soon as the update rate drops bellow 5Hz you start getting issues.
Hdop is a measurement of the constellation geometry quality. Not a measurement of accuracy.
GPS accuracy is measured using GPS accuracy, yes there is a GPS accuracy measurement, and it is not HDOP.
You need a stable GPS fix signal. GPS1/2 still configuring is not that.
You have a CAN GPS right? Try increasing BRD_BOOT_DELAY.
That is the reason why GPS is configured before the compass in the ArduPilot Methodic Configurator.
Only once GPS issue is solved, should you look at the compass issue.
PS: and make sure you have pre-arm checks activated and fence is also activated.
The magfit utility is not working properly because the logging is wrong - you dont have any attitude logged at all.
Set:
LOG_BITMASK,180222
then do another flight with turns, circles, figure 8 (if you can), yaw on the spot and some ascents and descents. It doesnt have to be a long flight, just a lot of maneuvers.
Notch filter is OK for now, leave it how you have it set. There might be a minor improvement but it would only be very minor and unlikely to improve flight, the amplitude of remaining noise is very low. Turn down the notch filter logging a bit.
INS_LOG_BAT_MASK,1
Youâll be able to disable it later.
Yes can gps
Yes we have out boot delay already as mentioned by you previously here.
Tommorow we are testing with gps being slight more above than previous position more away from FC and Wiring hopefully that might sought out the gps 1/2 still configuring msgs if not then will try to put gps in can1 instead of can2 port
New position of gps (4cm is typo itâs 2.5cm)
Ok I shall do this once I fix the gps 1/2 still configuring issues. Then will do a magfit flight.
This is another re-occurring issue. It seems to be set in the Configurator perhaps with a wrong input by the user? The same thing has happened with the Raw Logging parameter.
@dkemxr Is that the correct fix?
It was default in the configurator software I guess , will confirm it tomorrow
Yes, I think so. Please check how the INS_RAW_LOG_OPT is being enabled also. On some logs which have been thru the configurator all options are checked. User error I imagine.
The configurator deliberately sets INS_RAW_LOG_OPT,9
because the ardupilot wiki recommended to do so. If that no longer is the case, then I can change it.
If you check all the options the Filter Review Tool will error with âBoth post and pre+post logging option selectedâ
Note: This is not the case here but it has arisen several times now.
@amilcarlucas @dkemxr do you suggest any other tests I should do along with this to solve the gps issues
Sorry not 15, I meant 9
15 is a user error from @sauravhobyy, that propagated to the configurator when I integrated his template.
Raw IMU Logging for FFT Analysis â Copter documentation tells to use 9, webtool says âBoth post and pre+post logging option selectedâ. Which one is correct?
should we do:
INS_RAW_LOG_OPT,9
INS_LOG_BAT_OPT,0
or is it better to do:
INS_RAW_LOG_OPT,0
INS_LOG_BAT_OPT,4
@iampete can you share your opinion on what is best for your webtool?
Something like for small props use these settings, for big props use these other settings.
You donât want to check âPost Filterâ and âPre and Post Filterâ and you donât need to log all gyros. So 9 would be the best choice IMO.
Increase BRD_BOOT_DELAY some more, it is not enough.
6000 should do the trick.
And perform another notch data collection flight.
Will do it tom and share
Where is this?
INS_RAW_LOG_OPT
is the best if your logging can keep up.
So on H7 processors use:
INS_RAW_LOG_OPT,9
INS_LOG_BAT_OPT,0
and on F4 processors use:
INS_RAW_LOG_OPT,0
INS_LOG_BAT_OPT,4
Is that correct?
That was posted by dave above:
I think what we need is clarity on setting the options on these parameters:
INS_LOG_BAT_MASK
INS_LOG_BAT_OPT
INS_RAW_LOG_OPT
LOG_BITMASK