AnsweredAssumed Answered

ADIS16375 - Unexplained behaviour

Question asked by Jannibal on Aug 24, 2012
Latest reply on Oct 8, 2012 by NevadaMark

I'm currently working on a research project at the Department of Computer Science at Linköping University, Sweden that is utilizing an IMU ADIS16375. We have had some weird behavior from the sensor and I hope that you will be able to help us out a bit.

 

We have the ADIS16375 and the evaluation board for it (the ADIS16375/PCBZ that is) and we have connected it to a stable PSU and it communicates through SPI to a micro-controller.

 

This setup has been working fine for us for a couple of weeks, right until recently when the sensor stopped updating the output registers. When the sensor stops updating the registers (it does still respond to requests of PROD_ID, X_GYRO_LOW etc, but it does not update the values anymore) the power consumption increases from ~170mA to ~220mA. It does, however respond correctly on writing to PAGE_ID. So we can turn page and read all of the registers everywhere in the sensor, they just won't update. (Note: seems that PAGE_ID is the only register that actually behaves correctly when writing to it when the sensor is in the more power hungry state)

 

The sensor enters this state in a seemingly random pattern and can stay in that state for a random amount of time. Right out of the blue the sensor can return to a "sane" state and start responding to read requests for the output registers and they update fine.

 

Do you have any suggestion why this occurs? Is there some setting in a configuration register that can trigger this behavior? I'm asking because the micro-controller we're using has been connected to the sensor during development of he MCU firmware. During the development phase then micro-controller can have been sending random SPI-data to the sensor and perhaps inadvertently configured something wrongly?

 

We've tried running the "Restoring Factory Calibration" command (both in the faulty state and in the normal state) with no good result (the sensor doesn't actually reset the FILTER_SELx registers for us, or anything else).

 

Information for our particular sensor:

LOT_ID1 - 0x0103

LOT_ID2 - 0x0619

LOT_ID3 - 0x0011

PROD_ID - 0x0177

 

Hope you can shed some light on the situation.

Thanks in advance!

//Janne

Outcomes