Forum Rule: Always post complete source code & details to reproduce any issue!
Page 6 of 6 FirstFirst ... 4 5 6
Results 126 to 134 of 134

Thread: MPU-9250 Teensy Library

  1. #126
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    129
    Quote Originally Posted by rpowers View Post
    I ran the scan and it only found 0x68, so I'm going to go with a failure of some sort in the chip. I'll wire up another board and report back. Thanks again for the assistance.

    Edit: Interesting, the new board I am having the same problem with. I read something about pin 1 on the 9250 needing to be connected to VDDIO and there was a breakout board that didn't make this connection, but I haven't seen any complaints about the Sparkfun boards. Maybe I'll contact them and see if anyone else has had this issue.
    That is odd. The Sparkfun documentation mentions that VDDIO is jumpered to VDD, so that should be fine. You might want to try sending 0x80 to register 0x6B in order to clear the MPU-9250 registers first, then set register 0x37 to enable bypass mode, then cycle the power (you'll need some long delays in between these steps). That way you make sure that it isn't some MPU-9250 setting that is preventing the bypass from working.

  2. #127
    Junior Member
    Join Date
    Jul 2017
    Posts
    4
    Quote Originally Posted by brtaylor View Post
    That is odd. The Sparkfun documentation mentions that VDDIO is jumpered to VDD, so that should be fine. You might want to try sending 0x80 to register 0x6B in order to clear the MPU-9250 registers first, then set register 0x37 to enable bypass mode, then cycle the power (you'll need some long delays in between these steps). That way you make sure that it isn't some MPU-9250 setting that is preventing the bypass from working.
    The reset resulted in no change.

    The VDDIO issue I had read about on another board is that pin 1 on the 9250 needs to be connected to VDDIO (separately from the normal VDDIO pin), and one manufacturer didn't do this and it caused intermittent failure depending on whether or not the magnetometer reset correctly by chance. I don't think this is the case, though, since I can talk to the magnetometer directly on the aux I2C pins.

    I've put in a support request with Invensense, but I don't anticipate every hearing anything back from them.

    Thanks for the help, but I think at this point, I'll just use an external bypass (jumper both busses together).

  3. #128
    Junior Member
    Join Date
    Oct 2016
    Posts
    14
    Hi Brian, getting back into another project with a MPU9250 in SPI mode. I don't know if this was in the original code but what is the purpose of the initial register read and CS cycle in the readregisters method for SPI? I don't seem to need it--or I should say it seems to read OK when I exclude that part.

    if(_useSPIHS){
    SPI.beginTransaction(SPISettings(SPI_HS_CLOCK, MSBFIRST, SPI_MODE3));
    }
    else{
    SPI.beginTransaction(SPISettings(SPI_LS_CLOCK, MSBFIRST, SPI_MODE3));
    }
    digitalWriteFast(_csPin,LOW); // select the MPU9250 chip

    SPI.transfer(subAddress | SPI_READ); // specify the starting register address

    digitalWriteFast(_csPin,HIGH); // deselect the MPU9250 chip

    delayMicroseconds(1);
    digitalWriteFast(_csPin,LOW); // select the MPU9250 chip

    SPI.transfer(subAddress | SPI_READ); // specify the starting register address

    for(uint8_t i = 0; i < count; i++){
    dest[i] = SPI.transfer(0x00); // read the data
    }

    digitalWriteFast(_csPin,HIGH); // deselect the MPU9250 chip
    SPI.endTransaction(); // end the transaction
    Thanks again for sharing your code.

  4. #129
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    129
    Quote Originally Posted by EBRAddict View Post
    Hi Brian, getting back into another project with a MPU9250 in SPI mode. I don't know if this was in the original code but what is the purpose of the initial register read and CS cycle in the readregisters method for SPI? I don't seem to need it--or I should say it seems to read OK when I exclude that part.



    Thanks again for sharing your code.
    That's a relatively recent addition. We had multiple, different sensors on the same SPI bus with the MPU-9250 and during de-bugging found that MPU-9250 data with the original code was always one frame old. This addition fixes that issue, so the data that you collect when calling something like getMotion10() is from the current frame. The performance impact is just a 1us increase in the time data collection takes.

  5. #130
    Junior Member
    Join Date
    Oct 2016
    Posts
    14
    Should I ask how you found that issue?

    When you say multiple sensors on the same bus, was that multiple MPU-9250 or just a mix of devices, or both? Do you think it's an issue with a single MPU-9250 device on a dedicated bus?

    Either way I'm glad I asked the question because I was thinking of putting 2+ MPU-9250 on a single bus to get extended precision in the lower ranges and still have the wider range data too.

  6. #131
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    129
    Quote Originally Posted by EBRAddict View Post
    Should I ask how you found that issue?

    When you say multiple sensors on the same bus, was that multiple MPU-9250 or just a mix of devices, or both? Do you think it's an issue with a single MPU-9250 device on a dedicated bus?

    Either way I'm glad I asked the question because I was thinking of putting 2+ MPU-9250 on a single bus to get extended precision in the lower ranges and still have the wider range data too.
    It was a mix of devices, specifically a MPU-9250 and BME-280. We were using the MPU-9250 generated interrupt to drive a data acquisition function which was collecting data from both sensors. We found that we never got data from the MPU-9250 and when we started diving deep into the details, we discovered that even running the MPU-9250 by itself, that the initial frame of data was not valid.

    This was never discovered running multiple MPU-9250's on the same bus. I think this is because the BME-280 ran at a different clock setting.

    Let me be clear that, although the original code worked fine for the MPU-9250 running on its own or multiple MPU-9250's on the same SPI bus, the data was 1 frame delayed. For applications that are latency critical, this wouldn't be great, so I'm glad we found the bug and a fix for it. Especially that the performance impact isn't large.

    Sounds like a neat application! I've thought of similar concepts and have seen it done with pressure transducers for measuring airspeed on aircraft.

  7. #132
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    140
    Quote Originally Posted by EBRAddict View Post
    ... I was thinking of putting 2+ MPU-9250 on a single bus to get extended precision in the lower ranges and still have the wider range data too.
    That caught my eye ... how do you plan to get that "extended precision"? thanks

  8. #133
    Junior Member
    Join Date
    Oct 2016
    Posts
    14
    Quote Originally Posted by ninja2 View Post
    That caught my eye ... how do you plan to get that "extended precision"? thanks
    You get 16 bits of precision on the accelerometer and gyro. On the accelerometer for example, you can set the range to 2g, 4g or 8g. So if you're reading a 2g range with 16 bits the g/(2^bits-1) precision is going to be finer than reading a 8g range with 16 bits. If I set one device to 8g and one device to 2g I will get the full 8g range plus finer increments in the 2g range. Theoretically 4 times more precision in the lower range. I guess I'll find out when I start doing side-by-side comparisons.
    Last edited by EBRAddict; 07-08-2017 at 11:40 PM.

  9. #134
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    140
    ah I see. In my application I'm only reading around 0 - 1.2 g so 2g range is obvious choice. So sadly this idea has no advantage, but I see how it works for you.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •