Zubax GNSS 2 mag Z spikes

[LorenzMeier]

@pavel-kirienko There is a problem with the GNSS 2 causing spikes on the mag Z axis: http://logs.uaventure.com/view/UKyU98TtEzD9iM7aS6JErg#IMU_Mag_PLOT

[AndreasAntener]

It should be the Zubax but also the Z spikes don't really correlate with the one jump I had?

[pavel-kirienko]

Can we see how Zubax GNSS 2 is positioned within the airframe?

[AndreasAntener]

[pavel-kirienko]

Thanks, this looks legit. I would like to have a closer look at the spikes. Could you send me the log file?

[pavel-kirienko]

The best explanation I can offer so far (I haven't seen the logs up close yet) is that there is an anomaly in the output of the sensor. We're using HMC5983 in Zubax GNSS v2.1.

Meanwhile I could propose to apply a 3 sample deep median filter to the sensor output; it will help with one-off disturbances, but it will also introduce a ~13 ms group delay, which is a lot.

[AndreasAntener]

Link to the log: http://logs.uaventure.com/logmuncher/charts/UKyU98TtEzD9iM7aS6JErg/raw_flight_log.px4log

Meanwhile Roman suggested that the change in heading is normal for EKF after takeoff but it should not be so large. So it points to a mag issue (or ground interference, but we were starting from a grass field and different spots).

[pavel-kirienko]

A closer look at the spikes reveals that the problem affects all three axes. This is not directly visible in the log muncher GUI because of aliasing effects.

This with a high degree of confidence rules out single bit upsets in the digital interfaces, and puts suspicion into the analog circuits of the sensor itself. Some googling shows that HMC5983 are allegedly susceptible to randomly lowering the gain sometimes. The Oculus Rift SDK has the following lines in their driver for HMC5983:

// the HMC5983 has a bug where it randomly applies the wrong gain to the sample,
// resulting in a value 68% of what it should be

The disturbances I'm observing in the log are varying from 50% to 80% for different axes.

I will implement the median filter I described above before the end of the week. Other suggestions are highly welcome.

[LorenzMeier]

We're not seeing this on Pixhawk, at least not with the PX4 driver. Have you compared the schematic used on Pixhawk and the driver with what you're using?

[pavel-kirienko]

I didn't, but it is no longer relevant anyway, since the sensor has been phased out, and so was Zubax GNSS v2.1. We're now manufacturing Zubax GNSS v2.2 which is based on LIS3MDL.

What we need right now is a firmware-only solution; I'm open to any suggestions.

[LorenzMeier]

Since its unclear how long that state persists the best option is to check the scale register regularly and reset it.

[pavel-kirienko]

Updated firmware v3.2 with a three sample long median filter has been uploaded to https://files.zubax.com/products/com.zubax.gnss/. The default magnetometer update rate has been increased to 100 Hz in order to reduce the latency imposed by the filter.

These are the best glitches I could obtain in a lab environment over an 8 hours long interval before the fix was applied (rows are x, y, z):

In all occurrences the glitches tend to be one sample long at most, so a three sample long window should be effective.

[mhkabir]

@LorenzMeier @pavel-kirienko Is the GNSS firmware fix satisfactory? Can we close this?

[pavel-kirienko]

@mhkabir works for me.

[mhkabir]

@AndreasAntener Can you please cross-test?