Post Go back to editing

ADIS16137 温飘异常








  • Thank you for posting this request.  I am sorry that I am not able to communicate in this language, which appears to be Mandarin Chinese. Would it be possible to translate this into English?


  • Hi,we were initially testing ADIS16137(first sample) for a temperature variation test (ranging from -40 to 80 degree celcius) and discovered that the device's degree output data was influenced by the temperature significantly compare to what it claimed standard.

    We also conducted the same test for an ADIS16445 that was soldered on the same PCB board as the ADIS16137 and found out it's temperature variation was less than 16445 and agree with the specs.

    We purchased another ADIS16137 and did a temperature test with a hot air gun set to 80 degree and didn't find such anomaly while the first ADIS16137 had a 0.4°/s deviance at 80 degree after an auto calibration done at 27 degree which was way off the chart considering the spec is 0.00125°/sec/°C.

    We would like to know what kind of factors can cause such data deviance beside the possibility of us got a "bad chip". Is there any quick way to determine if a chip was faulty or not without conducting the temperature test as it was time consuming for a production line.

    The two graphs had the temperature and the degree variation plotted. As you can see in the second graph, the GZ16137 which shows the data variance of the 16137 mems(first sample) had a much larger fluctuation then it suppose to have and 16445 seems to perform as expected. Both devices were soldered on the same PCB and the data were collected simutaneously. 

  • Thank you for providing more detailed information and for translating your needs into English. I am sorry that I do not speak Mandarin Chinese!

    1. I presume that when you say that the devices were "soldered to a PCB," you mean that they were pressed into connectors that were on the same printed circuit board (PCB).  Is that correct?

    2. The specification of 0.00125 deg/sec/degC is a typical specifications, but a fairly conservative one, based on our characterization of these units prior to market release, so your experience is outside of what I would expect. 
    3. We have found that mechanical stress from the attachment method can have an influence on these types of behaviors. While we have not tested this extensively on the ADIS16137, we have seen this on the ADIS1648x family, which has similar opportunities for translating changing force profiles up into the core MEMS elements.  this application note came out of our post-release studies on the ADIS1648x:
      Would you be willing to re-try your experiment, using the mounting methods in this application note, only applied to your ADIS16137?

    4. In some cases, we have seen that the temperature forcing mechanism can make a difference in these measurements as well.  In our calibration chambers, we typically try to duplicate the "most likely" conditions that the device will see in an application.  A top-down heat application is not as typical as a system "self-heating" from co-located devices, so there may be some opportunity for unexplored sensitivity in that area as well.

    While we do not normally offer to do this, we can offer to test your unit in our characterization chamber, using our Failure Analysis process.  If you wanted to take advantage of that, we would need to know where you purchased your device and ask you to make a F/A request through them.  If you ever decide to do this, please let me know and we will provide you with a contact that can help you facilitate this.  

  • Could you provide a bit more detail on the device's configuration, along with your data collection and analysis that is generating?  This information might be helpful:

    1. SMPL_PRD setting
    2. DEC_RATE setting
    3. AVG_CNT setting
    4. MSC_CTRL setting
    5. Data collection synchronous with data ready?
    6. If not, what rate of data collection are you using?
    7. Are you reading only GYRO_OUT or are you also including GYRO_OUT2?
    8. Do these plots reflect any post processing, like averaging?
  • I have found the reason,I run the SELF_TEST,and read the DIAG_STAT,the FLASH_TEST bit is 1.Temperature calibration parameters should be stored in the flash。

    We contacted the sales agents, but they said that the time is too long, no longer provide after-sales support.

    If you can help us, please contact my email

  • Thank you for posting this update.  A flash memory failure could result in loss of (or corruption) of the calibration coefficients, but I am not sure that is the only (or even the most likely) cause.  I will see what I can for you, but could you help us with the following:

    1. Answer the questions from my last post?
    2. Record and present all of the contents of all user-accessible registers, in a response to this post?  
    3. Present comparison data between your good and bad units (first post in English described a unit that did not have this large error). In this same plot, present temperature data from each data collection (one for each unit)?
  • The gyro was install in a robot,so I can't get the new date now,but I can provide the setting in my code(setting reg will be check after write, make sure the setting is write success).

    1. SMPL_PRD setting :0x00(external clock sync)
    2. DEC_RATE setting:0x00
    3. AVG_CNT setting:0x02
    4. MSC_CTRL setting:I think this reg is a command reg,I not read it in my program
    5. Data collection synchronous with data ready?
    6. If not, what rate of data collection are you using?:data is sync by external clock,the sample rate is 100Hz.
    7. Are you reading only GYRO_OUT or are you also including GYRO_OUT2?:yes,I read the GYRO_OUT,GYRO_OUT2,TEMP_OUT in one function,like the burst mode.
    8. Do these plots reflect any post processing, like averaging?:the data is original

    I can express this sensor to you(US or anywhere else),if you need.