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

[David Lechner]

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.
> 
> So to my understanding, OSR2 is true oversampling. OSR1 is a filter.

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)

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

> 
> 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.

>   (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