I’m using the Navio2 version from sometime around May 2017, ArduPlane 3.7.1 and an HMC5893 compass installed externally. I have the compass configured as Compass #3 and as the primary.
I also have internal compasses #1 and #2 set as “not used.”
Lately I have been getting a “Bad Compass Health” alarm. In two test flights this week the airplane accurately and successfully finished the test missions both times - with the Bad Compass Health showing. I replaced the compass with another HMC5893 and the same Bad Compass Health alarm came in.
How can I check to see if the external compass is having the problem?
How can I check to see if the alarm is being generated on behalf of one of the internal compasses?
Where did the compass calibration take place? It’s recommended to do it outside.
Is there also a way you could share your onboard logs and
dmesg log at the time of these errors?
Yes I can provide the logs provided you tell exactly the name of the file - there are several from my last flight yesterday.
Also, what is the dmesg log and where may I recover that, in the Pi?
I moved the compass to a new spot away from other electronics and am still getting the Bad Compass Health error.
All logs from the flights with this error triggered would help.
I don’t think recovering this is possible at the moment but you can launch ArduPlane on the ground and see if the error comes up. If it does, ssh into the Pi and type
dmesg. This is the log I’m after.
I think these are the ciorrect logs. Thanks for any tips.
dataflash-bad-compass-health-2017-12-28 15-08-33.tlog (741.3 KB)
dmesg-log-bad-compass-health-1.txt.log (80.0 KB)
Telemetry-Log-bad-compass-health-2017-12-28 16-10-03.log (7.6 MB)
I jusr re-calibrated outside, still got the Bad compass Health error, and also got a Compass Variance Error. Shouldn’t the external compass be the only one in effect? I’ve got the external compass set as compass #3, external, and the two other compasses #1 and #2 unchecked.
AFAIK the external compass will always be number one. S I guess you disabled the external one, are are using one of the internal ones (number 3) and marking it as internal.
Thanks for the information. Seems like there are different recommended setups for autopilots:
Navio2 - External compass configured as #3, external, numbers 1 and 2 not used
Pixracer: External compass gets configured as #1, external, numbers 2 and 3 not used
I hope Emlid weighs in here with the official recommendation.
Just saw this data (please see red circled section in the Mission Planner HUD status screenshot below). Apparently the Z axis value and magfield are not being reported by compass #3, the one being used.
Am I seeing this correctly?
This happened on two different HMC5893 units so I do not think it is the compass itself. What could be causing this?
the numbers in your red circle refer to mz, magfield and ax2 and NOT mx3 my3 and mz3!
they belong to the left side!
“bad compass health” means no signal from compass!
when connecting external compass, it is being recognised automatically as “external”!
Yes I see now that the numbers I saw were for the other equipment and not Compass #3. #3 does have numbers corresponding to its names in the status list. They are in general about 100 unit lower than #1 and #2.
My external compass does get recognized as an external compass.
I will try a new cable next.
I’m interested in the results of
i2cdetect -y 1. Could please post the output? You can also try lowering
i2c_baudrate to 100KHz in
Here is the i2cdetect output while the Bad Compass Health indication was in effect:
root@navio:/home/pi# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- 1e –
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – 77
Changed i2c baudrate from 1000000 to 100000. The system still reported Bad Compass Health after a few minutes of operation. The compass still appeared to be accurately changing heading. In the EKF Status screen the compass bar graph had absolutely no indication.
Another observation: Compass #1 and #2 while not “being used” show some small fluctuations of a few points either way in their mx3, my3, mz3 and magfield3 values in the Mission Planner status screenwhile the plane is sitting still. Compass #3 however shows very little fluctuation, maybe in the tenth’s place now and then.
Can I use the scl, sda, 5v and ground ports on the raspberry pi header if the Navio2’s i2c connector has gone bad?
are you sure navio is correctly screwed down to raspberry pi?
you can use the i2c pins from rpi directly, but you would still end up with bad baro health;
Does the barometer also use i2c?
If you meant compass instead of baro, then how do you deduce that I’d still get Bad Compass Health? Does the i2cdetect output show that the i2c and compass are working?
The more I look at this problem the more I am confused.
In this excerpt from a Telemetry from an actual flight where the “Bad compass Health” alarm was active, the Mission Planner status screen showed all three compasses updating.
If they were all working, then what could the alarm represent?
Here is a new dmesg output file taken during a Bad Compass Health incident.
Even though Mission Planner continues to report the Bad Compass Health indication, the compass seems to be working fine. It is an HMC-5893 connected to the Navio2 by way of the I2C port.
FlyingW-Bad-Compass-Health-20-January-2018.pdf (23.6 KB)
Alarm represent a discrepancy between compass data.
I have also a setup with an external HMC5893 compass. It is an i2c working with a Drotek GPS. As the compass is below the GPS antenna, I set a Roll180° in the compass calibration screen. It is my primary compass.
Navio2 Compass#2 offsets are out of range (as yours may be).
Here are my magfield data:
Emlid is latest Strecht image with Arducopter 3.5.4 firmware (custom upload).
Thanks for the tips Marc.
I recalibrated the two internal compasses. After that I unchecked their respective “use this compass” settings.
The bad compass health alarms are no longer present at least for my first few bench tests of several minutes each.
Got the Bad Compass Health alarm again. Here is the dmesg output taken while the condition was present.
I looked in the file and saw this entry:
[ 384.726620] i2c-bcm2835 3f804000.i2c: i2c transfer timed out
I Googled the entry and there seems to be some kind of bug with the Raspberry Pi driver for the i2c bus (I think).
I hope someone from Emlid can help figure out what this problem is.
flyingw-dmesg-bad-compass-health.pdf (23.6 KB)