MPU-9250 – first impressions

A more careful glance at the MPU-9250 suggests actually most of the MPU-6050 code works fine; most of the new function is in new registers or unused bits in existing registers.

However, there are some changes for which I need to work out how to update the code:

  • my main processing loop frequency has dropped to 300Hz from the 800Hz I’ve achieved with the MPU-6050.  The spec does describe changes in this area, but it’s not at all clear. UPDATE: The problem actually lies with the new device tree mechanism added to the Raspberry Pi distribution in 2015/1/31.  To get the bus speed up to 400kbps, you need to add into /boot/config.txt:
    dtparam=i2c_arm_buadrate=4000000
  • the offset / gains provided for the MPU-6050 to map between the 16 bit temperature sensor reading have changed, and the spec does not provide a revised version; as an example it thinks it’s 40ºC in my house instead of the 22ºC my thermometer says.  An initial analysis (offset, gain) of ~(55,200) whereas the MPU-6050 values are (36.53, 340):
     ºC = sensor * gain + offset

I can find the offset and gain values for the temperature mapping through experimentation; I’m a lot more worried about the processing speed – I think I’m going to have to read that section a lot more carefully. Luckily, the local shop had printer paper in stock!

2 thoughts on “MPU-9250 – first impressions

  1. I am also trying to get the MPU-9250 to work correctly. I am using a C program together with the pigpio library. I have set the sensor to use the FIFO to store the accelerometer values. I then read the FIFO in a loop every 200ms. Everything works correctly for about 30 seconds and then I get corrupted data. The oscilloscope shows that the register number in the read command is incorrect. It seems the driver has an error and is sending incorrect data.
    Have you got the MPU-9250 to work correctly?

    • I have got the MPU-9250 working, but I don’t use the FIFO – I use the raw data registers along with the “raw data ready” interrupt . I haven’t used an oscilloscope to check the i2c signal – you have a lot more experience here than I.

      I do get corrupted data, but I’ve put it down to timing between the data ready interrupt and how quickly I can read the registers. Luckily the errors are easy to spot (0xFFFF for one or more of the sensor values), so I’ve just wrapped the i2c in code that retries if I start getting bad reads. I don’t think this is the problem you are seeing though – it’s more because I’m pushing python to its performance limits.

      If I were you, I’d probably go to the Raspberry Pi forums and post this there – there has been a lot of talk there recently on i2c driver problems, so you stand a better change of chatting to someone who knows i2C well – also the writer of the pigpio library, “jean” hangs out there a lot and is always extremely helpful.

      Last thing – is you Raspian image fairly recent (Febrruary 2015 or later)? Problems were introduced in the Christmas release which were fixed in February.

      Hope you find some useful help from the forums.

      Good luck!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.