Teensy 3.0 driving 9-DOF accelerometer?

Status
Not open for further replies.
Hi Paul,

I have an related question but I am not starting a new post for this one little question. Does the Teensy 3.0 run on an Arduino IDE. I want to run the MPU9150 on a Teensy 3.0.
 
The output on the serial monitor is also jerky (Arduino IDE serial monitor). Its not smooth and continuous for Accelerometer and Gyroscope output. Baud rate 115200.
 
Hi Paul,

I have an related question but I am not starting a new post for this one little question. Does the Teensy 3.0 run on an Arduino IDE. I want to run the MPU9150 on a Teensy 3.0.

When you install the newer versions of the Teensy software, you need to have installed a version of the Arduino IDE. For example, I just installed Teensy 1.14 on top of an Arduino 1.0.5 installation. I don't believe 1.5.x is supported at this time. I believe in the past, I have use the teensy IDE to program a real Arduino UNO.

Now, whether the MPU 9150 library from sparkfun (or elsewhere) has assembly language that prevents it from running on the Teeny 3.0, I don't know.
 
I just downloaded Sparkfun's example code, put it in Arduino 1.0.5's library directory and compiled the "MPU9150_raw" example with Teensy 3.0 selected from Tools > Boards. Of course, without the actual Sparkfun breakout board, I can't know if it actually works, but it definitely does compile.
 
I also took a quick look inside their code. It's based on Jeff Rowberg's original code (like FreeIMU and many others). The "getMotion" functions correctly use int16_t pointers. Earlier versions had trouble on 32 bit boards because they assumed "int" was 16 bits. This looks like it was based on the newer, fixed version.

Code:
        void getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz);
        void getMotion6(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz);
 
I can confirm the "MPU9150_raw" sketch works fine on a Teensy 3.0 with the Sparkfun breakout board. I'm using a variation of it with my current project and have it running at ~600 Hz (excluding the magnetometer).

I'm still working on a good way to read the magnetometer without the 20 ms delay.
 
Teensy 3.0 works with MPU 9150

I just tested a Teensy 3.0 with an MPU 9150 with my own code which is derived from Jeff Rowberg's original code. I am able to sample at 13 milliseconds from accelerometer, gyroscope and magnetometer. It running smoothly on the serial monitor. Is there any way I can make it go any faster. Please let me know.

I also took a quick look inside their code. It's based on Jeff Rowberg's original code (like FreeIMU and many others). The "getMotion" functions correctly use int16_t pointers. Earlier versions had trouble on 32 bit boards because they assumed "int" was 16 bits. This looks like it was based on the newer, fixed version.

Code:
        void getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz);
        void getMotion6(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz);
 
How did you get it to run at a 13ms spacing? Jeff's example code includes a hard 20 ms delay to prevent getting incorrect data from the magnetometer. Without the delay, it returns gyroscope data (for some odd reason).

I'm running mine at ~1.7ms per sample (~600 Hz), but only by skipping the magnetometer. It's hard to say what the problem is without seeing how you modified the code.
 
Thank you

Jeff's code has some issues. So I modified it. I am not too happy with Jeff's AK8975 mag code either. I think the problem lies there. I need help in improving his cpp and h files for AK8975. That will allow us to get a faster response from the mag. Even if I get it below 10 ms, it will help me.

Or I have to look for a faster processor. Something in the tune of 100 MHz.


How did you get it to run at a 13ms spacing? Jeff's example code includes a hard 20 ms delay to prevent getting incorrect data from the magnetometer. Without the delay, it returns gyroscope data (for some odd reason).

I'm running mine at ~1.7ms per sample (~600 Hz), but only by skipping the magnetometer. It's hard to say what the problem is without seeing how you modified the code.
 
Download the whole library at https://github.com/jrowberg/i2cdevlib/tree/master/Arduino
There is one folder for AK8975, in the file AK8975.cpp, in the function AK8975::getHeading you will see a delay of 10 millisecond. You should be able to go down to 8ms. Lower it should not work or the sensor will give you twice the same value before updating, I haven't tried.

I am not aware of a "fast" magnetometer on the market. Probably you should first try to calibrate the device (I failed here) to output reasonable values regarding its position in space.
 
Last edited:
Thank you

Thank you. In the AK8975 .cpp file the get heading delay appears four times. Do I have to change them all. Please let me know. Once the device starts sampling at a higher rate I will start the calibration process. I guess the calibration is going to be challenging too.
Download the whole library at https://github.com/jrowberg/i2cdevlib/tree/master/Arduino
There is one folder for AK8975, in the file AK8975.cpp, in the function AK8975::getHeading you will see a delay of 10 millisecond. You should be able to go down to 8ms. Lower it should not work or the sensor will give you twice the same value before updating, I haven't tried.

I am not aware of a "fast" magnetometer on the market. Probably you should first try to calibrate the device (I failed here) to output reasonable values regarding its position in space.
 
The function AK8975::getHeading(... uses delay(10) only one time. If you call X, Y, and Z separately you will need a delay for each call. Study and try the examples and you will see.
 
Thank you

I am able to sample when the delay is set at 3 millisecond in the .cpp file for AK8975. But the output data rate is now 6 millisecond for the Acc, Gyro and Mag combined. The data does not get repeated in the mag output. But what is the actual output data rate for the Mag AK8975. I could not find it in the data sheet for AK8975. Please could you look into it. I did study Jeff Rowbergs examples. Did not find anything useful. Am I missing something. Please help.
The function AK8975::getHeading(... uses delay(10) only one time. If you call X, Y, and Z separately you will need a delay for each call. Study and try the examples and you will see.
 
Thank you for your post. I am still trying to optimize all the parameters. I will be happy to share the code once everything starts working. I am not using Jeff's code because it has bugs. The Acc and Gyro alone sample at 600 Hz. Jeff's code needs improvement and bug fixes. There is no standardized calibration protocol for the MPU9150. One small step at a time.
 
Thank you

I am able to sample when the delay is set at 3 millisecond in the .cpp file for AK8975. But the output data rate is now 6 millisecond for the Acc, Gyro and Mag combined. The data does not get repeated in the mag output. But what is the actual output data rate for the Mag AK8975. I could not find it in the data sheet for AK8975. Please could you look into it. I did study Jeff Rowbergs examples. Did not find anything useful. Am I missing something. I was also wondering if the .cpp files for the MPU6050 also need improvement. Because the .cpp files for MPU6050 work along with .cpp files for AK8975 when I run the MPU9150. I think Jeff Rowberg's code needs a little more optimisation to enable users to get the MPU9150 to work at its fullest potential.
 
Teensy 3.0 problems

Hi Paul,

I am facing two problems with Teensy 3.0. The first one being, once I load a sketch to read data from the MPU9150 everything works fine the first time. But when I disconnect the USB and try to reconnect it once again and try to read data from MPU9150 using the Teensy 3.0. I only get zeros on the serial monitor. Why does it happen.

The second problem is how do I save data from the Teensy 3.0 onto an Open log. I connected the Tx from open log to the Rx on the Teensy 3.0 and the Rx from the open log to the Tx on the Teensy 3.0. The open log is also powered from the Teensy for power as well. It does try to save the data. A file gets created on the open log and it does not contain any data. Is there any other alternative where I can connect a microSD card to save the data from the Teensy 3.0. This is a critical requirement I am looking for.

The link for open log wiki is as follows

https://github.com/sparkfun/OpenLog/wiki/datasheet

I also took a quick look inside their code. It's based on Jeff Rowberg's original code (like FreeIMU and many others). The "getMotion" functions correctly use int16_t pointers. Earlier versions had trouble on 32 bit boards because they assumed "int" was 16 bits. This looks like it was based on the newer, fixed version.

Code:
        void getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz);
        void getMotion6(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz);
 
Teensy 3.0 problems

Hi Paul,

When I disconnect the Teensy 3.0 from the computer and reconnect it back then why do the programmes stop running. I do not get any reading on the serial monitor. Even when I press the reset button I still do not get any reading on the serial monitor except zeros. Moreover when I press the reset button then COM port is no longer visible on the Arduino IDE. Please help me resolve these problems.
 
When I disconnect the Teensy 3.0 from the computer and reconnect it back then why do the programmes stop running.

Can you see how incomplete this question is, without details of how your board gets its power?

I do not get any reading on the serial monitor. Even when I press the reset button I still do not get any reading on the serial monitor except zeros. Moreover when I press the reset button then COM port is no longer visible on the Arduino IDE. Please help me resolve these problems.

Presumably you're using Windows? That matters, because Microsoft's drivers have a bug where unplugging the USB while a program has the port open can result in leftover junk left in the Windows Registry. The driver's bugs cause it to not recognize the device again when it's reconnected. Sometimes plugging into another port solve the problem. Rebooting usually fixes it too. This is a special problem on Windows. Mac and Linux have much higher quality drivers.

But even without the Windows bug, if you leave the serial monitor window open, it keeps that instance of the serial port in use. None of the 3 operating systems is designed to reconnect the same USB device to an already-open session. It would be nice if things worked that way, but that's simply not the way it works. When you disconnect (or reprogram the board, which is the same as disconnecting the cable as far as the software is concerned), the serial monitor can no longer communicate with the device. You have to quit the serial monitor, reconnect the device, and then open it again. On Linux, if a program has the old device open, a new name gets assigned, so you also may need to find and select the port again in the Tools > Serial Port menu.

Of course, on Windows there is the extra problem that the driver may not recognize the device when its reconnected if junk got left over in the Windows Registry. That extra problem is unique to Windows. There are only 2 solutions.... #1: be careful to close whatever if accessing the port before you reprogram (in Arduino, the serial monitor automatically closes when you click Upload, but not when you press the pushbutton), or #2: use Mac or Linux.
 
My board gets power through USB. I was hoping you would assume it as I did not mention any other source of power. But thank you for the detailed explanation. I have a mac I will try it out. Please could you answer the second part of my question regarding saving data to a micro sd card using open log or any other alternative method.
Can you see how incomplete this question is, without details of how your board gets its power?



Presumably you're using Windows? That matters, because Microsoft's drivers have a bug where unplugging the USB while a program has the port open can result in leftover junk left in the Windows Registry. The driver's bugs cause it to not recognize the device again when it's reconnected. Sometimes plugging into another port solve the problem. Rebooting usually fixes it too. This is a special problem on Windows. Mac and Linux have much higher quality drivers.

But even without the Windows bug, if you leave the serial monitor window open, it keeps that instance of the serial port in use. None of the 3 operating systems is designed to reconnect the same USB device to an already-open session. It would be nice if things worked that way, but that's simply not the way it works. When you disconnect (or reprogram the board, which is the same as disconnecting the cable as far as the software is concerned), the serial monitor can no longer communicate with the device. You have to quit the serial monitor, reconnect the device, and then open it again. On Linux, if a program has the old device open, a new name gets assigned, so you also may need to find and select the port again in the Tools > Serial Port menu.

Of course, on Windows there is the extra problem that the driver may not recognize the device when its reconnected if junk got left over in the Windows Registry. That extra problem is unique to Windows. There are only 2 solutions.... #1: be careful to close whatever if accessing the port before you reprogram (in Arduino, the serial monitor automatically closes when you click Upload, but not when you press the pushbutton), or #2: use Mac or Linux.
 
I use a 32gb microsd card with it. I'm pretty sure it'll support 64gb. It might mention it in the README file.

Good idea to use what others have used that have good write speeds. Typically class 10 is what you want. But brand-to-brand may vary.
 
Hi Linuxgeek, Thank you for the quick update. That is very useful. Does the microSD adaptor work straight out of the box just like the open log. In case of open log I have to just set the baud rate before I connect it to Arduino. Then it simply saves the data. I set the abud rate in the open log by entering the value of the baud rate in the config text file. How does it work in case of microSD adaptor.
I use a 32gb microsd card with it. I'm pretty sure it'll support 64gb. It might mention it in the README file.

Good idea to use what others have used that have good write speeds. Typically class 10 is what you want. But brand-to-brand may vary.
 
Look at the example sketches (like I said there's a lot). You can just copy/paste what you need out of there.
I'm sure there's a logging example. I use mine for storing binary data as fast as possible.
 
Status
Not open for further replies.
Back
Top