I think we found the issue. this version of the holybro compass has the magometer mounted upside down and turned 90 right. we were able to orient the sensor in QGCS.
thanks for the help

we are using PX4 v1. 12.3

here is the logs
link text

We are having massive problems getting the compass to read true. the voxel is set 90 deg due to space constraints. compass is aligned forward. adding a yaw 90 setting corrects the AHRS and GPS however puts the compass 90s off and we get a heading swing.

We believe that the version of drone code we are using accounts for a magometer on the board.. which after talking to Chad Voxel does not have. What version of drone code do you recommend as we think something has been compensated that is not clear in the documentation.

We have tested this whole set up also in a pizza box and we are getting the same response. (we did this to make sure it was not anything on the drone. (also we have two voxels. an older version from last year and one we just purchased.. that is why you will read below about two voxels. we didn't' realize their was modifications between the boards when I bought and extra for backup)

We are using "Q Ground Control" in a Windows environment.

Here is the latest report from my developer.....

Last night I plugged in the secondary gps to J1009 (we can use other connections technically but this is the only one that did not require redoing the connectors. I’m using the TELEM2 setting and that provides GPS data, though ModalAI doesn’t publish that as being connected to the J1009 serial output - I determined that with logic of what connectors used the other TELEM ports and trial and error trying all settings to confirm that this enables a GPS output.

I verified we are getting 2 GPS data results - again it lumps into IMU0 and 1. This could be QGC’s display approach. I have a few other variance parameters to read out that aren’t in that location. But looking at the data the variance isn’t that big.

I did calibration a few times and the GPS is rock solid, the direction is wandering still. So the two voxels do the same thing in the pizza box. I should confirm that this was happening in the drone, I thought it was not. Now it could be I need to do it again to be sure but I’ve done the calibration well. I have a suspicion that the EKF (Kalman filter), which has many settings, is somehow fusing the data wrong between the IMU and Magnetometer. The heading wanders all over in all three axes continuously as if the EKF is making really bad estimates.

I removed the micro hard add on board to test if it was a temperature thing because the board gets incredibly hot. I think it might be wise to include a fan. I’ll test with a fan to determine if there’s any improvement. My initial test seems to show a no to that question. Need to test more carefully with a fan on it. We should look at the operating temperature range. I have an IR temp tool I haven’t pulled it out to check yet. If we are within operating range it’s acceptable.

The next thing to do is to double check that we didn’t change EKF parameters oddly by accident during experimentation.

After that I’d like to save the parameters and move the flight controller to the MODAL AI branch of PX4 and do basic configuration to check if behavior is the same.

This is in a pizza box, aligned, no interference, everything ideal, so we know it’s not the drone causing this issue. This is really good in the sense that we don’t have to make major changes to the drone batteries at this time. It could be we get this right in the pizza box then transfer to drone and all goes bad again, but I doubt it since the behavior is pretty much identical between the two setups.

I will do these things and get back to you.

Best,
Alex

============================
C. Alexander Simpkins, Ph.D.
Owner and CEO RDPRobotics, LLC