Creative Commons images are CC BY-NC-SA 3.0


added to your
shopping cart

In stock 226 in stock
29.95 1+ units
26.96 10+ units
23.96 100+ units

Description: This is the LSM9DS0, a versatile motion-sensing system-in-a-chip that houses a 3-axis accelerometer, 3-axis gyroscope, and 3-axis magnetometer. That's right, 9 degrees of freedom (9dof) from a single IC!

Each sensor in the LSM9DS0 supports a wide range of, well, ranges: the accelerometer’s scale can be set to ± 2, 4, 6, 8, or 16 g, the gyroscope supports ± 245, 500, and 2000 °/s, and the magnetometer has full-scale ranges of ± 2, 4, 8, or 12 gauss. Additionally, the LSM9DS0 includes an I2C serial bus interface supporting standard and fast mode (100 kHz and 400 kHz) and an SPI serial standard interface. 


  • 3 acceleration channels, 3 angular rate channels, 3 magnetic field channels
  • ±2/±4/±6/±8/±16 g linear acceleration full scale
  • ±2/±4/±8/±12 gauss magnetic full scale
  • ±245/±500/±2000 dps angular rate full scale
  • 16-bit data output
  • SPI / I2C serial interfaces
  • Analog supply voltage 2.4 V to 3.6 V
  • Programmable interrupt generators
  • Embedded self-test
  • Embedded temperature sensor
  • Embedded FIFO


Comments 23 comments

  • If anyone is interested in trying this out with the Raspberry Pi (or similar embedded Linux system), the RTIMULib 9-dof IMU library has just been updated to include support for the LSM9DS0 and has been tested with this breakout. RTIMULib outputs fully Kalman-fused pose with just a few function calls. It achieves sample rates of up to around 700 Kalman-fused samples per second. Incidentally, the library also supports the MPU-9150 - that can achieve the full 1000 samples per second supported by the MPU-9150. The repo is here - It’s all very new and there will be bugs - please feel free to open issues on GitHub as necessary. There’s also a second set of apps (SyntroPiNav and SyntroNavView) that provide OpenGL-based 3D visualization.

    • I was able to get MPU-9150 filter update rates of 1000 Hz without the magnetometer reads on the 3.3 V 8 MHz Pro Mini and 165 to 250 Hz with magnetometer reads at a 10 Hz rate. This is all with direct data register reads; i.e, without reading from the DMP, of course. I wonder how the filter update rates depend on 1) the specific filter, i.e., Kalman vs. Madgwick, and 2) the speed of the microcontroller’s processor? I measure about a 50% speed up in the filter update rate with the Mahony sensor fusion algorithm versus the Madgwick. I guess I’ll try both using the below sketch with a 16 MHz Uno and see if the times change…

      • Something that would be interesting would be to put those two filters into RTIMULib as alternatives to the (highly unoptimized) Kalman filter that’s there currently.

        • I was going to copy your Kalman filter to do a timing test on the Pro Mini. Are you saying it would be better to wait for a better optimized version? Is the optimization straightforward, like reducing the number of operations, or is there more to it?

          • The current performance of the Kalman on a Pro Mini would be far inferior to the highly optimized alternatives (on the other hand, it does seem to perform nicely on the Pi, even if it is wasteful). Now that the RTIMULib drivers are in a reasonable state for 9-dof operation at least, I will take a look at stripping down the Kalman. This is exactly what RTIMULib was designed for - to make filter (and driver) development, testing and tuning easy to do. A lot of things are getting multiplied by zero in the Kalman so there’s a fair bit of waste. It’s not so much of a problem on the Raspberry Pi which has pretty decent floating point performance. The problem there is getting the data through the OS. It’s the opposite to a bare metal microcontroller where it’s easy to get the data but there’s less processing power.

            • I appreciate the info on the Kalman filters. I took a look at the library and I think I could adapt it to a simpler Pro Mini sketch. I also found a nice write up on Kalman filtering and might take a crack at constructing one from scratch. I did manage to get the MPU-9150 sketch running on a 5V 16 MHz Arduino Uno but the magnetometer data wasn’t right. Maybe the magnetometer on the MPU-9150 isn’t 5 V logic tolerant? Anyway, I noticed that the filter update speeds roughly doubled, so I take your point that processor speed likely dominates over the details of any one kind of filter.If you succeed in optimizing the Kalman filter I would like to try it.

              • Ok, I am working on it…

                • The latest version of RTIMULib ( now has the RTQF fusion filter available (and it’s now the default). This is a severely stripped-down Kalman - actually it’s now incredibly simplistic. There are some small optimizations that could be made still but the big stuff has been done. So, if you want to try RTQF, let me know how it goes!

  • Thanks for such an easy to use library. Also, the sensor data sheet is easy to understand despite its somewhat perfunctory descriptions. I created a sketch to compute filtered quaternion representations of the sensor frame relative to the fixed Earth frame using open-source Madgwick or Mahony 9DoF sensor fusion filtering and can get filter update rates of between 125 (Madgwick) and 165 (Mahony) Hz using a 3.3 V Pro Mini operating at 8 MHz. This is not too much less than the proprietary Digital Motion Processor on-board the MPU 6050 and MPU-9150. The sketch and (slightly) modified library can be found at I am going to try the sketch with MPU-9150 accelerometer, gyro, and magnetometer DMP outputs to make a more apples-to-apples comparison. I still do not know exactly how to configure the LSM9SD0 registers to latch the gyro and accelerometer data ready interrupts via the DEN_G function. Maybe an e-mail to ST Microelectronics is in order. Lastly, can we get a version of this breakout board with a square footprint with pins on opposite sides? This would be much more convenient for protoboard mounting applications. Thanks again for a great product!

  • Such a breeze to set up! Thank you for the hookup guide and clean design.

    Hey, if anyone’s interested, I think its more fun to see the output graphed than printed to the console, so I modified the “Simple” example that SparkFun provided, to plot the 9 output channels using a processing sketch. Code is here:

  • stacking three of these in parallel with different ranges looks like it would do a pretty good job of balancing the noise from one and getting much larger accurate range.

  • I’ve been working on constructing a full IMU motion-capture suit from these sensors and your arduino coding has been a great help! Do you have any advice on how to convert your code to work with multiple IMUs? I will be using the PCA9509 Level Translator to handle the I2C bus and prevent my Arduino from reading from the same device address. My Arduino will be sending a digital high to connect the I2C bus to a particular IMU while sending a digital low to every other IMU to disconnect them from the main bus. At the moment I’m working on deconstructing the included cpp file and handling everything within the Arduino coding since I’m not sure how to adjust the cpp for multiple devices. I would rather have the Arduino coding alert the cpp file that I want to use a particular address/device, or have the cpp file run for one device, then the next and so forth.

  • I have been studying the library and I think there might be a couple of problems. Where is the twos-complement check (MSbyte > 0x7F) on the raw 16-bit data? Do the scale range algorithms return the correct resolution settings for aRes for +/- 16 g acceleration (10/32768 instead of 16/32768) and for mRes for 2 g scale (0/32768 instead of 2/32768)? Maybe I am mis-interpreting the syntax…

    • Thanks for checking out the library! I’m not sure I see what you’re talking about on the scale algorithms. Is it this line you’re looking at? Those should be dividing the correct numbers in, but the shorthand if could be what’s confusing.

      The two’s complement is taken care of by the variable typing, the bit pattern of the combined low and high bytes should remain the same. It works, but looks lazy. I’ll see about making it more clear.

      • Yes, that’s the line and the corresponding one for the lowest magnetometer resolution setting. Thanks for the wiki pointer; I had never seen that shorthand before, now I get it.

        Are you saying that specifying the signed integer type somehow does the two’s complement conversion automatically? That would be convenient!

  • Thank you Sparkfun for another 9DOF solution for the Arduino! The tutorial and library are very clear and I am looking forward to augmenting the latter for quaternion and compensated roll/pitch/yaw output for various ‘round-the-house projects. I have tried to make use of the MPU6050 but have temporarily given up in frustration. Yes, I bought cheap GY-521 breakout boards, but I keep getting -x-motion interrupts and can’t seem to consistently set the accelerometer and gyro ranges. Plus, there is the entire issue of how to use the DMP. The point is the MPU6050 is poorly documented and Invensense is, shall we say, less than forthcoming for the individual user. I hope to have a more productive experience when my LSM9DS0 arrives in a few days.The gyro has a maximum ODR of 760 Hz, plenty fast for most applications. I expect this board will work fine in a quadcopter. I’ll let you know in a few weeks. In the meantime, I have found a document that sheds some light on the DEN_G function:

  • Any plans on stocking the bare chip? Would be nice for own projects/PCBs.

  • Does anybody know at what frequency the Gyro sensing masses oscillate? I checked the datasheet, but did not find this data. In the past the ST’s gyro were not good for quads and helis due to the low frequency of oscillation so most of the control boards use Invensense sensors that have 27 KHz - 33 KHz oscillation rate for gyros.

    I am curious whether this sensor is applicable to quads and helis.

  • This product looks really cool, but the 9DS0 is not a good starting point for 9-axis. Sparkfun should think about partnering with these guys.

  • Both the InvenSense and ST part have some issues…

    Check out Those AD parts are great - expensive tho:

  • I agree, the fifo interface for accel/gyro/mag is clean.

    What performance specs worse than the 9150 caught your eye xkcd…?

  • Huh. The performance specs on the gyro and accelerometer for the LSM9DS0 aren’t nearly as good as the specs for the MPU-9150. That being said, it looks like ST Mirco made the communication interface much easier to work with than the patchwork job done by InvenSense on the MPU-9150.

Related Products