read() could be reading garbled data since sensor updates them synchronously to DRDY

[bootchk]

As far as I understand the LIS3MDL, it repeatedly measures the magnetic field and updates the magnetometer data registers. The DRDY bit goes high when all of x,y,z have been updated, and after that, the sensor pauses a finite time (according to the data rate) before taking a new measurement (in continuous mode.) An app reading the mag data should do so just after DRDY goes high, else the app could read the data while it was being changed by the device (i.e. it could be garbled?) So an app should poll the DRDY bit in the status register (using readReg()). Reading the X high byte clears DRDY bit. In other words, calls to read() should be synchronized to the DRDY bit going high. Is that a correct assessment?

[kevin-pololu]

I think you might be right about this. Have you noticed any issues with your sensor data that you think is caused by this issue?

I think an easier way to partially resolve it might be to set the BDU bit in CTRL_REG5:

Block data update for magnetic data. Default value: 0 (0: continuous update; 1: output registers not updated until MSb and LSb have been read)

That should ensure that at least the high and low bytes are synchronized, although the readings from different axes might still be from different times. Section 4.4 on page 7 of this app note for a similar sensor contains the note:

Note: BDU only guarantees that the LSB part and MSB part have been sampled at the same moment. For example, if the reading speed is too slow, X and Y can be read at T1 and Z sampled at T2.

Synchronizing reads with DRDY (whether by polling the register or with an interrupt pin) is probably the best solution, but it would involve changing the library and/or example program more substantially, so I'm considering just setting the BDU bit by default since it's a minimal change that should still improve things.

[bootchk]

I don't have any evidence that the issue happens, my question is theoretical.

(I found a more surprising and important issue is that the breakout board, which doesn't seem to have much soft iron or hard iron power traces near the magnetometer, seems to deliver skewed magnetometer readings , so that calibration (obtaining an offset to correct raw magnetometer data) is required.)