Re: [PATCH v3 0/5] iio: magnetometer: add driver for QST QMC5883P

[Jonathan Cameron]

On Sun, 17 May 2026 15:28:22 -0500
David Lechner <dlechner@xxxxxxxxxxxx> wrote:

> On 5/17/26 2:17 PM, Hardik Phalet wrote:
> > On Mon Apr 20, 2026 at 7:15 PM IST, Jonathan Cameron wrote:  
> >> On Sun, 19 Apr 2026 22:32:09 +0000
> >> Hardik Phalet <hardik.phalet@xxxxx> wrote:
> >>  
> >>> This series adds an IIO driver for the QST QMC5883P, a 3-axis
> >>> anisotropic magneto-resistive (AMR) magnetometer with a 16-bit ADC,
> >>> communicating over I2C. To my knowledge there is no existing
> >>> upstream driver for this device (see "Prior-art register-map check"
> >>> below).
> >>>
> >>> The driver supports:
> >>>   - Raw magnetic field readings on X, Y and Z axes
> >>>   - Four full-scale ranges (+/-2 G, +/-8 G, +/-12 G, +/-30 G),
> >>>     selectable via IIO_CHAN_INFO_SCALE
> >>>   - Four output data rates (10, 50, 100, 200 Hz), selectable via
> >>>     IIO_CHAN_INFO_SAMP_FREQ
> >>>   - Four oversampling ratios (1, 2, 4, 8), selectable via
> >>>     IIO_CHAN_INFO_OVERSAMPLING_RATIO  
> >>
> >> I'm suspicious about this one based on a very quick read of the datasheet.
> >> Conventional oversampling would involve running the internal sampling
> >> engine at a multiple of the sampling frequency, and then averaging the
> >> results.  The datasheet describes this as:
> >> "Over sample Rate (OSR1) registers are used to control bandwidth of an
> >>  internal digital filter. Larger OSR value leads to smaller filter bandwidth,
> >>  less in-band noise and higher power consumption. It could be used to reach a
> >>  good balance between noise and power. Four over sample ratios can be selected,
> >>  8,4,2 or 1."
> >>
> >> That sounds like a boxcar filter to me not oversampling (which would be
> >> a combination of box car and reducing the output data rate).
> >>
> >> If possible, can you enable the data ready output and put a scope on it
> >> to see if that changes frequency when OSR or OSR2 are modified.
> >>
> >> Trickier to do would be looking at the noise levels whilst playing with
> >> these filters and see if they at least match with standard filter types.
> >>
> >> If we can't figure these out, then it may be a case of picking something
> >> that works well and hard coding that rather than letting userspace
> >> change things in a fashion that might not match the ABI.  
> > 
> > I could not arrange a oscilloscope. So wrote a small standalone tool that drives
> > the chip directly over /dev/i2c-N (skipping the driver) on a Pi 4 and
> > characterised all three fields in CTRL_1 with timing + noise measurements.
> > Summary:
> > 
> >   Field    Bits     Role per measurement
> >   ODR      [3:2]    output rate, accurate to ~3% of nominal in Normal Mode
> >   OSR1     [5:4]    low-pass filter (bandwidth control), no rate change
> >   OSR2     [7:6]    N-sample averaging, no rate change (real oversampling)
> > 
> > 1. DRDY interval vs each field (median of 500 samples per setting,
> >    ms; SCHED_FIFO, pinned CPU):
> > 
> >    vary ODR (OSR1=1, OSR2=1):
> >      ODR=10 Hz  -> 100.9 ms       ODR=100 Hz -> 10.30 ms
> >      ODR=50 Hz  ->  20.5 ms       ODR=200 Hz ->  5.14 ms
> > 
> >    vary OSR1 (ODR=200 Hz, OSR2=1):
> >      OSR1=1 -> 5.142 ms           OSR1=4 -> 5.139 ms
> >      OSR1=2 -> 5.143 ms           OSR1=8 -> 5.141 ms
> > 
> >    vary OSR2 (ODR=200 Hz, OSR1=1):
> >      OSR2=1 -> 5.142 ms           OSR2=4 -> 5.142 ms
> >      OSR2=2 -> 5.140 ms           OSR2=8 -> 5.141 ms
> > 
> >    ODR is the only knob that changes the rate.
> > 
> > 2. Per-axis noise stddev (2000 samples, sensor still, ratios vs N=1):
> > 
> >    vary OSR1:                   vary OSR2:
> >      OSR1=1 -> 1.000              OSR2=1 -> 1.000
> >      OSR1=2 -> 0.723              OSR2=2 -> 0.706
> >      OSR1=4 -> 0.544              OSR2=4 -> 0.494
> >      OSR1=8 -> 0.416              OSR2=8 -> 0.333
> > 
> >    Reference for N-sample averaging (1/sqrt(N)):
> >      1.000 / 0.707 / 0.500 / 0.354
> > 
> >    OSR2 matches within measurement noise; OSR1 trails the curve,
> >    which is the expected signature of a bandwidth-limiting filter
> >    on non-white input noise.

Nice data.

> > 
> > So to my understanding, OSR2 is true oversampling. OSR1 is a filter. 

Oversampling might also be tied to an integration period which would
reduce as oversampling goes up, somewhat undoing the noise improvements.
So it might be worse than an averaging.  Without introducing
some dynamic motion it's going to be hard to figure this out. Maybe stick
the thing on a pendulum or if you happen to have one a record deck?
(assuming you can wire it!)
Anything to be able to repeat something that will vary the signal.
That should let you separate box car across a fixed sampling rate
from oversampling.
 
> 
> The datasheet says that power consumption changes based on OSR1,
> so that makes me think that OSR1 is really oversampling since it
> would take more energy to do more conversions in the same amount
> of time. (Note 1 on table 2.1)
Is it possible it's a sampling / resampling ADC or similar so the
actual resolution is dropping? That saves some power.  Mind you
puttting that in a place called OSR1 would be odd ;)

Or as you suggest it's actually triggering burst conversion and averaging.
So datarate fixed but actual sampling time is much lower so it can
do lots of samples without the effective sampling rate changing.
> 
> Another chip by the same mfg that looks like it has the same OSR1/
> OSR2 has a bit more info in the same table [1]. It looks like OSR2
> affects the sensitivity (and calls OSR2 a low pass filter instead
> of "down sampling rate").
> 
> [1] https://www.qstcorp.com/upload/pdf/202601/CF382A94E1424763B3DE87DC967757FC.pdf

Ah ok. Good detective work.  Though it would be far from the first datasheet
to confuse oversampling with straight forward filtering.
> 
> > 
> > v4 plan, pending your input on (c):
> > 
> >   (a) Add an OSR2 regmap_field and expose it as
> >       IIO_CHAN_INFO_OVERSAMPLING_RATIO with values {1, 2, 4, 8}.
> >   (b) Drop the OVERSAMPLING_RATIO mapping on OSR1.
> >   (c) For OSR1, two options:
> >         i)  expose as IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY.
> >             The public datasheet does not give cutoff frequencies,
> >             so I'd have to either characterise them empirically and
> >             document them in the driver, or use placeholder values
> >             derived from the OSR1 setting alone (which feels wrong).
> >         ii) hard-code OSR1=1 in chip_init and not expose it. Loses
> >             the noise-vs-bandwidth tradeoff but keeps the ABI clean.
> >       Slight preference for (ii) unless you'd rather see the filter
> >       knob exposed.  
> 
> It sounds like we already figured out that OSR2 is just a moving average
> so might as well implement IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY.

Maybe... We might have to just go for best guess and document it clearly.

Jonathan

> 
> >   (d) Keep ODR mapped to IIO_CHAN_INFO_SAMP_FREQ as in v3.
> > 
> > One other finding worth mentioning: the datasheet's setup examples
> > (sec 7.1, 7.2, 7.3) all write 0x06 to register 0x29 before entering
> > an active mode, with the comment "Define the sign for X Y and Z axis".
> > This register is not listed in the documented register map but the
> > write is required for axes Y and Z to come out with the documented
> > orientation. v4 will add this write to chip_init().
> > 
> > If you have other measurements you'd like to see before v4, happy to
> > run them.
> >   
> >>  
> >>>   - Runtime PM with a 2 s autosuspend delay
> >>>   - System suspend/resume delegated to the runtime callbacks  
> > 
> > Best regards,
> > Hardik  
> 
>