16 bit values in LSM303

I am playing with a few different versions of the LSM303 - for now the LSM303 DLHC.

I want to make sure I understand the 16 bit register pairs. For example, when I read the two temperature register (TempH/TempL) they are 01h / 40h.

I understand the LO register is really only 4 bits, so taking 0140h and shifting right 4 I get 14h, or 20d. Yet when I use the algorithm in an LSM303 DLHC driver I got from the manufacturer, it comes with 25d + TempH or 26d.

So is the TempH really the temperature in celcius -25 ?

I am playing with a few different versions of the LSM303 - for now the LSM303 DLHC.

I want to make sure I understand what the 16 bit register pairs really are. For example, the temperature registers (TempH / TempL).

If I use the algorithm in the LSM303-DLHC driver from the manufacturer, I read TempH and my code says the temperature is 26 - when TempH / TempL was 01h / 40h.

That suggests to me that TempH is the temperature in celcius - 25.

So, what is TempL ? Is it the non-integer portion ? So, would TempH / TempL of 01h 40h really mean 26.4 degrees celcius ?

Is this the same for all of the 16 bit register pairs ?

Hello, accny.

We merged your two posts into a single topic.

Unfortunately, all the information we have about the LSM303 sensors come from their datasheets, and the datasheets don’t have much detail on the temperature sensors. The LSM303DLHC datasheet does state that the resolution of the temperature reading is 8 LSB (least significant bits)/deg, which means that the reading should change by 8 for every 1 degree change in temperature, so your reading of 14h should correspond to a temperature measurement of 2.5 degrees. It’s likely you have to add an offset to this value to get an absolute temperature measurement. The offset is not specified in the datasheet, and in the past we’ve suggested determining it experimentally, but I would be interested to know more about this algorithm from the manufacturer that you mentioned. Could you tell us where you obtained it?

The other 16-bit register pairs (the acceleration and magnetic field strength readings) are better documented, so we are more confident about how to interpret them. The process generally involves combining the high and low registers, discarding any bits that are not meaningful, and then multiplying that value by a conversion factor (resolution) specified in the datasheet, which will depend on the full scale setting you have selected for the sensor. You can find some notes on how to interpret some example readings in the Serial example included with our LSM303 library, which can be viewed here.

- Kevin

I obtained the driver from


I saw in the datasheet that the TempL register was really only 4 bits. Then I saw in the
driver the algortihms for reading BOTH the ACC and MAG data used this

buff->AXIS_X = (i16_t)( (valueH << 8) | valueL )/16;

So I wondered if the axes registers were also just 12 bit. I saw on the page you
suggested I look at that the ACC registers were only 12 bit. So I still wonder
about the MAG registers.

So I show some of my ignorance here :slight_smile: If the device is held perfectly still, shouldn’t the
ACC registers read 0 ?


  • Does the BDU feature apply to the individual sets of 16 bit registers - OR - all 6
    axes registers at once. Also, doe it apply to BOTH the ACC and MAG registers ?

  • What does the high resolution HR bit control ? I got several accelerometer readings
    with it set and not set - it did not seem to make any difference.

  • Is it true that the BLE bit applies ONLY to the Accelerometer registers ?

  • My testing shows the auto address increment mode applies to both the Acc and Mag
    components - is that correct ?

  • I am very confused by DRDY. What exactly is the DRDY pin ? I see the datasheet calls
    it “Data Ready” … but what data - ACC / MAG / both ? I don’t see that explained

  • The datasheet says “The LSM303DLHC features two data-ready signals (RDY) which indicate
    when a new set of measured acceleration data and magnetic data are available …”.
    What does that refer to ?

  • Can anyone explain the DRDY1 and DRDY2 interrupts ?

  • What is Pad2 ? The only mention of it is on page 28, and only in that table.

Thank you for your reply and the helpful page you pointed me to.

Thanks for the link to the driver. Yes, both the accelerometer and magnetometer on the LSM303DLHC have 12-bit precision. However, I’m not sure I trust the driver provided by ST to be correct: in our experience, the lowest 4 bits of the 16-bit accelerometer readings are always zero (left-justified), while the highest 4 bits of the magnetometer readings are always zero (right-justified), so the magnetometer readings should not be divided by 16. We have some notes about that on the product page for our LSM303DLHC carrier (under “Protocol Hints”).

If the driver is wrong in that regard, it might be wrong in the way it reads the temperature sensor too.

As I mentioned, all that we know about these sensors is from their datasheets and from a small amount of experience using (testing) them. A lot of useful information is on the product page that I linked above, and I can try to give some quick answers to your other questions:

  • If the device is perfectly still, it will still detect the acceleration of the earth’s gravity (unless you happen to be in free-fall), so you should see an acceleration with a magnitude of 1 g.

  • I think the BDU applies to individual pairs of registers (see this app note for a similar sensor).

  • The accelerometer gives low-resolution 10-bit readings by default (the lowest 6 bits of the output are always 0). To get the full 12-bit resolution, you must set the HR (high resolution) bit in the CTRL_REG4_A register. (quoted from product page)

  • Yes, I think BLE only applies to the accelerometer; it’s in CTRL_REG4_A, which is an accelerometer register (the magnetometer registers end with _M).

  • Yes, auto increment applies to all registers.

  • The DRDY pin is for the magnetometer only and is always active. The INT1 pin can be set up to output a Data Ready signal for the accelerometer with the CTRL_REG3_A register. I don’t know/remember the reason for or difference between “DRDY1 interrupt on INT1” and “DRDY2 interrupt on INT1” (you might have to experiment with those).

  • I think Pad2 is supposed to mean the INT2 pin.


Thank you for the information.

So for me to create a plain “data ready interrupt” on the INT1 pin, all I have to do is set the I1_DRDY1 bit in CTRL_REG3_A, nothing in any other register ?

Yes, I think that is the case.

- Kevin

Yes, that worked for me.

I set the I1_DRDY1 bit in CTRL_REG3_A, and set CTRL_REG5_A = 00.
I trigger off the INT1 pin, read the Acc data, then clear the interrupt via read of the INT1 src register.

My testing suggests that if one of the Mag data registers goes negative, the high order 4 bits will be read as all 1’s, not 0’s.

That makes sense - it means the 12-bit number is actually sign-extended to fill the 16-bit register combination.

I’m facing another issue now. I would really like to continuously read data, for as long as 8 hours at a stretch, at either 200 or 400 hz rate.

I can do 200 hz, and transmit my data from my 8051 out to my PC at 115200, but doubt I would have time to send the data if I try 400 hz.

I’m looking for an inexpensive solution - something along the lines of a FTDI parallel to USB module (though I may want to build 8 of these systems, and at they are a bit pricey) or maybe a CH375 USB module. They have a parallel connection, and I believe allow the use of USB FLASH drives. At $5 each, it is interesting. I’m not finding documentation and sample code for those modules though.

Do you sell any such modules ?

No, unfortunately, we do not have anything similar to those parallel USB interface devices.