Help Understanding ITG3205 Temperature Offset

I believe my biggest issue is the temperature offset for the sensor, as the offsets often need to be changed when I turn on the arduino. But I don't understand the datasheet on how to go about implementing the temperature offset. If anybody does understand it, or can puzzle out what the data sheet says, I would be greatful for the help. Datasheet is attached.

Please!

ITG3205.pdf (1.1 MB)

The ITG-3205 is an older sensor.
Perhaps the MPU-6050 or the MPU-9150 are better, but you have to compare the specifications.
I think those newer onces don't even need to be temperature compensated.

A MEMS gyro is not very accurate, and the offset being different every time might also be for other gyro sensors.

Is the ITG-3205 the same as the ITG-3200, but with temperature sensor to compensate (a part of) the offset ?

This is the manufacturer page for the ITG-3200 : http://www.invensense.com/mems/gyro/itg3200.html
But I can't even find the document you found on the website of InvenSense, perhaps they are so ashamed of the sensor, that they removed everything. They ignore the existance of the ITG-3205. Can you take a look at the chip with a magnifer ? It is really a 3205 ?

You can find a lot with: itg3205 temperature offset - Google Search

@Peter_n,

Thanks for the reply. From what I have seen, I believe the ITG3205 and ITG3200 are very similar, but I'll have to wait till I'm off work to verify with a magnifying glass that mine is really the 3205. I bought the IMU off of EBay, labeled as GY-85. It seems to work pretty well all around, and reading the data is not very difficult.

I do believe that the temperature offset is important in this case. Because I am integrating the values from the gyro, the error can accumulate quickly. I know that I can manually change the offset, but this won't do me much good if it's out flying. I have done several searches on google about the temperature offset, but nobody seems to have done more than just read the temperature. I am hoping to find out if someone may have actually implemented the offset into the code?

At this point, maybe it would be a good idea to get a newer (but better?...) IMU, with the MPU9150 or similar. But do you know if it is accurate that some don't need the temperature offset? It would be nice to not have to thrash away at that part of the code.

Yes, buy a better one.

Normally I would advise to buy from Adafruit or Sparkfun, but with the gyro and accelerometer boards, they are somtimes a few years behind. Perhaps that is because they have working libraries for them.

The MPU-9150 is the new kid on the block, but it is not an easy chip, and a good library is a problem, since the i2cdevlib has missing links to the code : MPU-9150 9-axis accelerometer/gyroscope/magnetometer | I2C Device Library
The MPU-6050 is very cheap, but just as complex as the MPU-9150. The raw gyro values are however easy to retrieve: Arduino Playground - MPU-6050
So at least you can buy a MPU-6050 on Ebay for 2.38 dollars and run a few tests to see if you like it.
The 2.38 dollars doesn't mean that it is not as good as a 30 dollar sensor, it is an amazing piece of technical achievement for only 2.38 dollars.

However, any gyro MEMS sensor will have an offset. That is why gyro + accelerometer + magnetometer are combined. That is only way to know the orientation and motion in 3D.

P.S.: I still don't understand the temperature compensation for the ITG-3205. I think there should be an application note for that, but since InvenSense removed everything, I suggest to drop that sensor.

It's just frustrating, because I know that people have gotten it to work. The MultiiWii code, for example, works pretty well with this particular IMU. I guess the last thing to try is maybe to graph the temperature reading versus the raw data for the gyroscopes, maybe using a hair dryer or something, and see if the relationship is linear. But with my luck it wont be.

Thanks again!

I am not convinced that temperature is your problem. The gyro drift changes all the time, you have to deal with that by other means anyway.

Do you mind sharing some of these "other ways?" To try and deal with it, I have written code to calibrate the gyro, specifically just change the offsets, when needed. I have also tried changing the built-in low pass filter, I ignore the two LSB's, and I have implemented a moving average filter. I can generally get stable readings now when its not moving, but if I move it around a lot, the roll axis often ends up settling at a value very far from zero.

That is about all you can do. But please don't remove the lowests bits.
I doubt if that sensor is actually 16-bit, but I think you should use all 16 bits and smoothen it by averaging.

Moving and rolling and returning to the 'home' position will confuse every gyro. However, I did that test with a MPU-6050 and it was a surprise how well the values returned to almost zero. But with some motions, it did not longer return to zero. That is for every MEMS gyro sensor. That is how they behave. You can not buy a MEMS gyro sensor that doesn't do that.