Teensy 3.1 and 9DOF Stick I2C

Status
Not open for further replies.

Sn0MaN

Member
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-Teensy-3-1-amp-freeIMU

Here is a pic of my setup:

9DOF Teensy 3-1 Setup.jpg

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-9dof-ahrs/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:
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.

TeensyRigExample.jpg
 
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.

View attachment 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.
 
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.
 
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-Teensy-3-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.
 
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:
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...

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.

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.
 
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.
 
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.
 
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.
 
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.
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.
"
 
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.
 
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.
 
Status
Not open for further replies.
Back
Top