Jeff Rowberg

Member Since: October 17, 2010

Country: United States

  • For anyone using the MPU-6050 or MPU-9150 with I2Cdevlib, there is an official support forum for those devices when used with that library now available here:


    It's a little easier to work with an endless comment threads here, and more open than the InvenSense forums (no draconian "no reverse-engineering allowed" terms of service). There are already answers up there to some of the questions here.

  • Is it going back and forth between 0 and 6, or is it happening only at first? There is a ~8-second calibration routine that happens first when the DMP is enabled the first time. This is expected behavior and inherent in the DMP algorithm. There is also an issue with yaw/pitch/roll in my code (at the moment) where pitch and roll don't go above +/- 90 degrees when they should.

  • Hi Manuel,

    To be honest, I haven't worked much with the Leonardo yet, and I suspect the issue you are seeing has to do with that. I am not sure how to help at this point. Perhaps other have been able to work with it though, and may chime in here.

  • Wow, I really need to set up a forum on i2cdevlib. :-)

    Typically you don't want to change any of the #defined values, but instead effect different behavior with class methods and different parameters. The _ACCEL_FS_2 is the value which represents +/- 2g, correct. The _AFS_SEL_BIT is the bitfield position in the config register. Changing this will have undesirable results. The _AFS_SEL_LENGTH is the number of bits which the _AFS_SEL field takes. The register map from InvenSense says this field is 2 bits wide, hence the value 2. Changing this will also have undesirable results. You are probably really looking for the "setFullScaleAccelRange()" method. However, the power-on value of the module is already +/- 2g, so this is probably unnecessary.

    Incidentally, the data from the DMP is calculated internally on the module, and I'm not sure that setting the full scale accel range even has an effect on how it works. If you're using the DMP6 example sketch, the 2-decimal-place rounding is due to the AVR's handling (or possibly the Serial.print() function's handling) of float variables. The original data from the DMP is coming across as four quaternion elements, represented as signed ints in the range of [-16384, 16384] and then scaled to floats in the range of [-1.0, 1.0]. These values are computed into angles (no idea exactly how, I just found some code that worked). Any precision loss is going to happen there, if at all.

    I hope this helps!

  • As far as I can tell, the Baby Orangutan uses the same ATmega328P chip that the regular Arduino Uno uses. In this case, the I2C lines are fixed to A4/A5. There is no way to reassign them unless you move away from the hardware I2C/TWI bus, which is not usually a good idea. On the 328P, there is only one choice.

    Functionally speaking, this part of the communication is handled in the Wire library, or one of a few custom TWI implementations like the I2C Master Library or Fastwire. I2Cdev only has Wire support for now, but I really need to add Fastwire.

  • Yes indeed:

  • I think they may have changed their page structure a bit. However, the WT12 page says this:

    • Up to 14 supported Bluetooth profiles in iWRAP firmware

    ...which links to this page. The profiles supported out of the box by the iWRAP5 firmware running on the WT12 are these:

    • Serial Port Profile (SPP): DevA and DevB
    • Bluetooth Health Device Profile (HDP): Sink and source modes
    • Dial-up Networking Profile (DUN): Terminal emulation
    • Object Push Profile (OPP): OPP server and client
    • File Transfer Profile (FTP): FTP client
    • Human Interface Device (HID): HID device
    • Hands-Free Profile (HFP) v1.6: HPF mode
    • Headset Profile v1.2 (HSP): HSP mode
    • Phone Book Access Profile (PBAP): PBAP client
    • Message Access Profile (MAP): Client
    • Device Identification Profile (DI)

    The WT32 (not WT12) additionally supports these:

    • Advanced Audio Distribution Profile (A2DP): Sink and source modes
    • A/V Remote Control Profile (AVRCP): AVRCP controller and target
    • Hands-Free Profile (HFP) v1.6: HFP-AG (audio gateway) mode
    • Headset Profile v1.2 (HSP): HSP-AG (audio gateway) mode

    ...and all WT* modules can support the Apple iAP profile with special firmware available free upon providing proof of MFI program membership. It isn't the cheapest module out there, admittedly, but you'll be hard-pressed to find one that can do as much.

  • Hi! The problem is most likely a missing VIO connection. This is not obvious if you don't know it's required. Here are the typical connections for the SparkFun breakout, including the interrupt pin to work with the DMP example sketch:

    VDD - Arduino 3.3v
    GND - Arduino GND
    INT - Arduino digital pin 2
    FSYNC - leave unconnected
    SCL - Arduino SCL (dedicated pin or Analog 5)
    SDA - Arduino SDA (dedicated pin or Analog 4)
    VIO - Arduino 3.3v
    CLK - leave unconnected
    ASCL - leave unconnected
    ASDA - leave unconnected
  • Glad to help! And yes, reading raw sensor data as opposed to using the DMP can be very fast indeed.

    Do you know if you have an early engineering sample version of the chip? This would be indicated by "MPU6050ES" on the chip. It doesn't necessarily mean it's incapable of faster speeds, but it might be related at least. Also, what's the single letter on the bottom right corner of the chip? I think any of C, D, or E (if they have E yet) should be fine. If it's B, it might be an issue, especially if it's also an engineering sample.

  • That sounds like your code can't read and process the data fast enough (especially the FIFO overflow indicates this). Do you have a lot of interrupts going on, or slow serial output?

    I need to double-check that code, actually. The DMP6 example as-is may not be efficient enough on a typical Arduino even at 400kHz I2C, due to the way it detects and then waits for DMP packets. A modification I made to a separate project reduces the overhead involved, and that may have been necessary to get 100Hz to work.