Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 20 of 20

Thread: Teensy 3.1 and 9DOF Stick I2C

  1. #1
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7

    Teensy 3.1 and 9DOF Stick I2C

    Hello,

    I have a 9DOF Sensor Stick (SENS-10724) from SparkFun, hooked up to a Teensy 3.1 via I2C. Vcc is connected to the 3.3V on the Teensy.

    I am using the same setup as in this thread: http://forum.pjrc.com/threads/25432-...-1-amp-freeIMU

    Here is a pic of my setup:

    Click image for larger version. 

Name:	9DOF Teensy 3-1 Setup.jpg 
Views:	261 
Size:	120.5 KB 
ID:	2241

    Using the Wire Library I am able to turn on the device and output data to the Serial Monitor. The accelerometer gives reasonable values, but I am not for certain. The gyroscope and magnetometer seem to give maximum values of ~65530, that change when the chip is moving, but return to 65530 when sitting still. I have also tried using the RAZOR_AHRS arduino and processing sketches from this tutorial: https://github.com/ptrbrtz/razor-9do.../wiki/Tutorial

    I am able to get the AHRS sketches loaded and running, the processing sketch finds the serial port just fine, but all the values returned are zeros.

    I am not sure where the problem lies at this point. As best as I can tell, I do not need pullup resistors on the SCL and SDA connections, since the 9DOF Stick has the 4.7K pullup resistors onboard? any help would be greatly appreciated.

    Thank you,

    Sn0MaN
    Last edited by Sn0MaN; 06-20-2014 at 04:45 AM.

  2. #2

    Lightbulb

    Quote Originally Posted by Sn0MaN View Post
    Hello,

    I have a 9DOF Sensor Stick (SENS-10724) from SparkFun, hooked up to a Teensy 3.1 via I2C. Vcc is connected to the 3.3V on the Teensy.
    In the Sparkfun page, there is a comment from one of the Sparkfun employees that the VCC for that part needs to be 3.5V to accomodate the dropout of the LDO.
    Suggestion: try driving from a seperate source - say 3.7V-5V. I typically prototype my Teensy work with an adjustable external supply with current measurement. I have boards pull out the underside pins (like the 2nd I2C pair) to headers (female and male so I have jumper options), have current measurement (the one in the pic does not though) and feed the board from an adjustable supply. Makes for quick assessment of sensors needs and other parts - especially if I do need the underside pins.

    Click image for larger version. 

Name:	TeensyRigExample.jpg 
Views:	154 
Size:	139.1 KB 
ID:	2258

  3. #3
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    Quote Originally Posted by digitalCowboy View Post
    In the Sparkfun page, there is a comment from one of the Sparkfun employees that the VCC for that part needs to be 3.5V to accomodate the dropout of the LDO.
    Suggestion: try driving from a seperate source - say 3.7V-5V.

    Click image for larger version. 

Name:	TeensyRigExample.jpg 
Views:	154 
Size:	139.1 KB 
ID:	2258
    According to everything I've read, I should be using the 3.3V power source from the Teensy, using a flexible power source might be OK for testing
    purposes, but that doesn't help for my application in the real world, since it will only be able to get power from the Teensy...

    I think the problem lies in my jumper wires at this point, I am going to try to hook up 22AWG wires to the SCL/SDA connections, possibly hard solder them, and try to avoid using the breadboard, and see if that makes any difference. If not I will try your idea, and use the 5V power source, but then I have to buy extra parts (that I shouldn't need in the first place) and drop the voltage down to 3.3 anyway, which is totally redundant.

  4. #4
    Senior Member MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,278
    You might try adding the 4.7k pullup resistors any way just to see if it works better.

    Another thing is trying the Teensy 3.x specific replacement for the Wire library (note, you would need to modify all of your libraries to use it). It has additional debug statements that can be enabled which might help track down the problem.

  5. #5
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    Problem Solved:

    OK, First of all, thanks to MichaelMeissner and DigitalCowboy for putting forth the effort to help me with this problem (which has been driving me crazy for the past 2 weeks now), but I just figured out the solution.

    I didnt change anything to my setup, it was fine from the start, which I kinda thought anyway, so I'm still using the breadboard, jumper wires, and 3.3V power source, as shown in the picture above. The problem is with the code. The output values are sent as "int" type and needed to be type casted to type "int16_t".
    As stated in this thread here for the FreeIMU Library: http://forum.pjrc.com/threads/25432-...-1-amp-freeIMU

    For the RAZOR_AHRS Firmware located here: https://github.com/ptrbrtz/razor-9dof-ahrs
    I had to go into the Sensors Tab and find the read functions for each sensor: Read_Accel(), Read_Gyro(), and Read_Magn()
    and change the lines of code for the sensor outputs from this:

    // ORIGINAL CODE HERE:
    // accel[0] = (((int) buff[3]) << 8) | buff[2]; // X axis (internal sensor y axis)
    // accel[1] = (((int) buff[1]) << 8) | buff[0]; // Y axis (internal sensor x axis)
    // accel[2] = (((int) buff[5]) << 8) | buff[4]; // Z axis (internal sensor z axis)

    to this:

    // MODIFIED CODE HERE:
    accel[0] = (int16_t)((((int) buff[3]) << 8) | buff[2]); // X axis (internal sensor y axis)
    accel[1] = (int16_t)((((int) buff[1]) << 8) | buff[0]); // Y axis (internal sensor x axis)
    accel[2] = (int16_t)((((int) buff[5]) << 8) | buff[4]); // Z axis (internal sensor z axis)

    I did the same for all three sensors and now I have the RAZOR_AHRS Arduino and Processing Sketches up and running and everything seems to be working as expected. On to Calibrating the Sensor!

    Thanks again, hope this helps anyone else having this same problem getting started.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,800
    Any chance you could send a pull request back to the original repository?

  7. #7
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    That's fine by me, how do I go about doing that?

  8. #8
    Glad you got it working! I went a head and checked the datasheet for that regulator on the 9DOF and it's drop out at max current is just a few mV so not sure why sparkfun recommended 3.5+V...maybe a general guidance thing.

    I was coming back to post asking what library you were using.
    Definately let's get that change merged into the library.

    I'm actually in the process of merging the i2c_t3 library with the PJRC version of FreeIMU as I have time - unless someone has already tackled that?
    I've got a subsystem that uses I2C(0) with master/slave and I2C(1) hardware multiplexed to deal with duplicate I2C addresses over long wire (driven to 12 feet) so eventually I need/want FreeIMU to place nice with the i2c_t3 library
    Last edited by digitalCowboy; 06-24-2014 at 06:03 PM. Reason: clarification...3.5V+ not 3.7V+

  9. #9
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    Quote Originally Posted by digitalCowboy View Post
    Glad you got it working! I went a head and checked the datasheet for that regulator on the 9DOF and it's drop out at max current is just a few mV so not sure why sparkfun recommended 3.5+V...maybe a general guidance thing.
    I'm not sure where you read this, because everything I have been looking at says to use the 3.3V power source, which seems to be working just fine now...

    Quote Originally Posted by digitalCowboy View Post
    I was coming back to post asking what library you were using.
    Definately let's get that change merged into the library.
    Sounds like a worthy addition, I'm not sure what the int16_t does, or why it makes a difference, but I guess this is how you learn. I don't mean to be such a noob.

    Quote Originally Posted by digitalCowboy View Post
    I'm actually in the process of merging the i2c_t3 library with the PJRC version of FreeIMU as I have time - unless someone has already tackled that?
    I've got a subsystem that uses I2C(0) with master/slave and I2C(1) hardware multiplexed to deal with duplicate I2C addresses over long wire (driven to 12 feet) so eventually I need/want FreeIMU to place nice with the i2c_t3 library
    This is definitely the next step in my project, I would like to link 2 of these IMU's together and have then communicate with each other.
    Let me know if there is anything I can do to help in the process.

  10. #10
    Quote Originally Posted by Sn0MaN View Post
    Sounds like a worthy addition, I'm not sure what the int16_t does, or why it makes a difference, but I guess this is how you learn. I don't mean to be such a noob.
    Not sure if the backstory is useful to you (or anyone else reading), but IIRC Paul worked with Fabio Varesano (before Fabio's untimely death early last year - RIP) to rationalize various assumptions and outright changes to make the FreeIMU library work with Teensy but a lot of the discrete sensor libraries/firmware are largely built with 16-bit architecture assumptions where int is like int16_t vs. what a 32 bit ARM device expects.
    I'm likely to try and dig into the i2c_t3/FreeIMU thing the weekend after next and I'll post up on a seperate thread based on progress.

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,800
    Quote Originally Posted by Sn0MaN View Post
    That's fine by me, how do I go about doing that?
    I'm not a git expert. I'm sure there are lots of ways to do this if you know git better (than I do). Here's the simple way I usually do it.

    First, you need a free account on github. On the github website, create a fork of the project to your own account. The use the command line "git" program to create a clone of your copy. The clone URL is on the right hand side of the web page. For example, this command create a clone of Teensyduino's core library:

    Code:
    git clone git@github.com:PaulStoffregen/cores.git
    Of course, you need the free "git" software on your computer, and very basic command line skills to run it.

    There's some sort of setup so git will log into your repository as you (rather than some random person). I don't recall how this is done (I did it only once years ago), but I'm sure there's lots of great tutorial out there. It's important to run git as yourself, so you'll have access to push your changes back to github.

    Then edit and test the code. When you've made changes that you want to store, use "git commit -a". It'll run a text editor to enter a comment about the changes. You can do this for each set of incremental changes you want to document (if working on a big set of changes or fixing multiple bugs), or just once for something simple like this. Then run "git push" to send all your commits back to github.

    On the github site, when your forked copy differs from the original, two little icons will appear in the upper right area where the list of files are shown. They are "Pull Request" and "Compare". Click the Pull Request button, which sends a request back to the original project, asking them to incorporate your edits. A couple screens will ask you to confirm, and give you an opportunity to type a message explaining why they should accept your changes. It will also tell you whether the changes can be merged automatically (all they need to do is click yes). If they can't be automatically merged, something probably changed in the original code while you made your edits, causing a conflict.

  12. #12
    Senior Member MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,278
    Quote Originally Posted by Sn0MaN View Post
    Sounds like a worthy addition, I'm not sure what the int16_t does, or why it makes a difference, but I guess this is how you learn. I don't mean to be such a noob.
    The ISO C/C++ standards allow an implementation to have different sizes for the base types short, int, long, etc. The majority of the Arduino code runs on the ATmel 8-bit AVR processors (ATtiny, ATmega, etc.). On those systems, the GCC maintainers for the AVR port have decided that int is a 16-bit type (i.e. it holds values in the range -65,384 to +65,383). On the 32-bit ARM systems like the Teensy 3.x and Arduino Due, the GCC maintainers have decided that the int type is a 32-bit type. The code in question is building up and tearing down 16-bit integers from two 8-bit parts. In some of the code, if int is 32-bits, you get the wrong values when shift it right (i.e. you will get a large number if the top bit is set instead of a negative number).

    There are a set of typedefs (int8_t, int16_t, int32_t, and int64_t) that give you the appropriate sized signed integer for a type. Similarly there are other typedefs (uint8_t, uint16_t, uint32_t, and uint64_t) that give you unsigned types of a particular size.

    One final note, due to space issues, the AVR GCC changes the type double to be the same as float, which means double types have less precision and take up less space on AVR systems compared to ARM systems.

    When you import code from Arduinos, you should look for int, long, and double types, to see if perhaps you want to change it to use one of the above types.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,800
    Quote Originally Posted by digitalCowboy View Post
    I'm likely to try and dig into the i2c_t3/FreeIMU thing the weekend after next and I'll post up on a seperate thread based on progress.
    If you use FreeIMU, start with this copy.

    https://github.com/PaulStoffregen/FreeIMU

    This 16 bit issue has been fixed in several places (hopefully all of them), and a too-fast started issue for one of the gyro chips has a workaround.

  14. #14
    For accuracy, to correct my earlier statement, per the datasheet the regulator has a dropout of several hundred mV at max current...more than I indicated. So the guidance to 3.5V supply seems sound if you want a regulated 3.3V to the part.
    Quote Originally Posted by Sn0MaN View Post
    I'm not sure where you read this, because everything I have been looking at says to use the 3.3V power source, which seems to be working just fine now...
    I suspect the part will function fine. Still, Sparkfun built the part and they say:
    "MikeGrusin | about 2 years ago 2
    Itís a MIC5205 3.3V. This is an LDO regulator, so VCC only needs to be above 3.5V.
    "

  15. #15
    Quote Originally Posted by PaulStoffregen View Post
    If you use FreeIMU, start with this copy.

    https://github.com/PaulStoffregen/FreeIMU

    This 16 bit issue has been fixed in several places (hopefully all of them), and a too-fast started issue for one of the gyro chips has a workaround.
    Will do. I seem to recall the "too-fast" started issue...I am not planning on this to be a huge endeavor but I'm just spread rather thin right now so pushing it off for a week +

  16. #16
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    Pull request sent to Original RAZOR_AHRS Repository, looks like someone else submitted a similar pull request as well. Hope this helps, thanks for all your help.

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,800
    Thanks. That looks great. Hopefully they'll merge it.

    https://github.com/ptrbrtz/razor-9dof-ahrs/pull/20

    I'll make a note to check back on this in a month. If they aren't accepting it, I'll ask Sparkfun to host a fixed copy.

  18. #18
    Junior Member
    Join Date
    Mar 2014
    Location
    Breckenridge, CO
    Posts
    7
    Quote Originally Posted by PaulStoffregen View Post
    Thanks. That looks great. Hopefully they'll merge it.

    https://github.com/ptrbrtz/razor-9dof-ahrs/pull/20

    I'll make a note to check back on this in a month. If they aren't accepting it, I'll ask Sparkfun to host a fixed copy.
    Sounds great, glad I could help out. Thanks again for all the time and patience.

  19. #19
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    118
    Just finished testing the updated libraries with the Teensy 3.1 and a 10724 with the freeimu. The updated libraries needed additional changes as well as the freeimu.h/.cpp files and the serial sketch s well.

    If all don't mind I will follow the pull request process for the changes I made.

  20. #20

    awesome work

    Quote Originally Posted by PaulStoffregen View Post
    If you use FreeIMU, start with this copy.

    https://github.com/PaulStoffregen/FreeIMU

    This 16 bit issue has been fixed in several places (hopefully all of them), and a too-fast started issue for one of the gyro chips has a workaround.
    can you make one for mpu9250

Posting Permissions

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