Bad AHRS fault, is the pixhawk faulty?

I need help please, I have for days been trying to solve the Bad AHRS fault.
I am setting up a pixhawk 2.4.8, in mission planner and have installed version rover V3.5.
I have the pixhawk stuck down to a board with the UBLOX NEO M8N along side it. I have the receiver plugged into the RC in and the transmitter / receiver is working OK . The buzzer is working as is the push switch…
I have spent a couple of days on youtube and reading all I can but all that I have tried hasn’t solved the problem.
I just can’t get the AHRS problem solved.
Any help please.

1 Like

Are you getting a good GPS lock and is the compass calibration been done? IMU calibration also?

Could be several things. Good compass + good accelerometer calibration first things to check, as has been stated. Then check GPS - Bad AHRS can be a result of bad GPS lock. If your GPS is really next to the pixhawk, interference from the pix could be the cause, the GPS should be at least several inches away. Also, check GPS “HDOP”, it’s possible to have a 3D GP lock and still have a problem if the GPS HDOP is too high.

I think so, the blue light on the m8n is flashing and I have 7 or 8 sats.
Can I remove the ublox and test that the pixhawk is working ok? If so what test should I do?

Thanks for your reply.
I will re position the GPS in relation to the pixhawk and re calabrate, I will try to calabrate outside, although I would have thought 7 sats would have been enough, which i am getting.
I dont know about HDOP so not sure what to do about checking that.

HDOP is a better check than number of sats, look for 1.0 or less.
It equates to horizontal position reliability.

You can check the GPS HDOP in Mission Planner on the Quick screen section. In my limited experience a bad AHRS means the compass and/or the IMU need to be calibrated. If I move my compass which is mounted on a cover dome I get the AHRS error and when I realign with the direction of the IMU it goes away.

I am doing a re calibration via Wizard outside to get better access to satellites and I now, during Battery Monitor Configuration I get “Missing BATT_CAPACITY param, something is wrong”… is this a clue?
I have tried to enter 3300 in the what size battery and I still get that message.
I have entered PX4 in what version
none for sensor

I have since done a manual setup and have fixed the AHRS problem but still an ARM problem.
When I ARM I get Pre arm check 33. and forced arm I get error rejected by MAV.
The HDOP is between 0.8 and 1, there is about 15 or 16 Sats. but the compass is pointing about 15 to 30 degs out, keeps shifting.
maybe the GPS M8N is faulty?

That HDOP is good . The compass “shifting” is the problem. Where have you been doing your compass calibrations? Newish ublxes seem to highly susceptible to interference, like from inside a garage or on a metal picnic table (which were the problems I had). I solved the problem by re-calibrating my compass and accelerometer in an open area where the vehicle was six feet or more from any metal, including the keys and cell phone I usually carry. Try doing something similar before you replace the GPS. I’ll look for the info I read about interference and post it if I can find it.

Duh - it’s in the wiki

I have changed the GPS for a new one and have the same problems, still can’t calibrate the GPS.
I have tried calibrating outside on a wooden table (still getting 16 Sats) I have tried a different computer, with a different mission planner version. I have turned the board with the pixhawk and GPS mounted 100mm above it, in every conceivable direction and still can’t get the GPS calibrated.
Just about time to give up on this pixhawk 2.4.8 from China.

What does the mini SD card tell us ?? any thing?


Yes, the data log files written to the sd card might be very helpful

Re the “bad ahrs”, have your read this and done the calibrations it suggests?

Thanks Jeff, I decided to calibrate an brand new APM 2.6 with the GPS module (i am rotating on all 6 axis pointing to the ground) and although I didn’t get the “bad AHRS” error I did get an unstable compass reading.
For example I had the APM taped down on a piece of plastic wth gps along side, both pointing north. I had a real compass indicating north. Mission planner yaw pointed at 84 degs and it was shifting from 20 degs.
Although the HDOP reading was 0.7 with 14 Sets. I still got very unstable results. Would this indicate a faulty gps module?
I tried to up load a photo but it’s too big.

Anyway to cut a long story short I sent the photo to Banggood and explained the problem and they are going to send replacements.

It sounds like you may be confusing GPS with the magnetometer’s. If you GPS unit has a Mag in it you do not want it close to the 2.6. You are also setting yourself back using a 2.6 instead of a newer controller.

1 Like

On the top of the module it reads, GPS/Compass UBLOX NEO M8N.
In using the APM 2.6 I was trying to determine if the GPS modules were faulty and from a faulty batch.
I was hoping it would work as for what I want to use it for, doesn’t need to be too complicated.
All I want is to drive a rudder on a torpedo to take my fishing line out to see. maybe there is something more suitable you could suggest.

For now I will shift the GPS module and see if there is any improvement.

Yes. Move the GPS unit with the Mag in it away from the controller and then recalibrate.

#On the top of the module it reads, #GPS/Compass UBLOX NEO M8N. In using the #APM 2.6 I was trying to determine if the GPS # modules were faulty and from a faulty batch.

Just to be clear (and possibly redundant) there is a magnetometer (compass) in the GPS dome and another in the pixhawk itself. Each can be used for AHRS, there are parameters which you can change which will control which magnetometer/compass is primary. Since AHRS uses GPS and compass data, in theory either of your compasses OR your GPS could be bad or even ALL of them could be bad. So, try to be methodical and test each separately (changing your parameters can help with this). Otherwise youll end up very frustrated and broke from all the parts you’ve replaced needlessly. Good luck!

A parameter list with offsets or a .bin log would solve this pretty quick I think