ADIS16488A Data Ready

I had to lay off the IMU for a while to work on other project, but good news is that I have the ADIS16488A working just about 100%. I am using a Raspberry Pi to communicate with the IMU and have no problems configuring the registers or reading data. The only problem I seem to be having is with the data ready signal; there doesn't seem to be much mention of it in the datasheet, and it is not resetting itself after I sample the data registers. I am only sampling the gyro and accelerometer registers; do I need to sample others to get this pin to reset?

  • This is a new question, so I hope that you don't mind me branching this into a new discussion. I am not sure what to say.   We are in the process of clarifying the data ready operation in the datasheet, but it is pretty simple.  The data ready pulses every time the output register update. The pulse time indicates a "do not read time" so you will want to trigger you acquisition on the second edge of the pulse.  If your data ready is not updating and your unit is responding as expected in all other ways, I would wonder if you accidentally set the unit up to expect an external clock. When this happens and there is no external clock, data does not update so the data ready will not pulse.  Is that possible? 

  • Just one clarification: the data ready does not indicate "new data" until data is read.  It only indicates when the registers are being updated. As I said above, the pulse time is effectively the "do not read time," since that is when the registers are being loaded with a fresh set of data.  Hope that helps.

  • No worries, but we try to keep discussions focused on one question, to keep them from getting unruly in their length. Thank you for posting your code.  For starters, where did you get the following from?

    Assert CS low

    Pull RST low for 15 microseconds

    Set CS high

    Delay for 500 milliseconds

    If you must toggle reset, I would eliminate the CS toggling until the device is up and running. It would be interesting to understand why a reset is necessary.  Assuming the device holds +3.3V during the start-up process, as reset should not be necessary.  If it is, I would investigate why because it might indicate a weak supply that sags when the device initiates itself.  See Figure 29 and 30 to quantify the transient current demand during start-up:

    I will review the rest of your code in a bit. 

  • Sorry for the separate posts, but I want to keep my ideas separate for clarity.  Have you probed data-ready during start-up and verified that it pulses at 2460 Hz?  Can you post a picture of what you see on the data-ready line when you don't do anything to it?

  • A few more comments on the code:

    Assert CS low

    The following commands are sent before pulling CS high again:

    >>I would be concerned that the stall time is not being managed, which requires a minimum of 2us between the completion of one cycle and the start of another. Based on the fact that you can read and write registers, this is probably OK, but I thought I would mention this. Also, sometimes, raising CS between each 16-bit cycle can be helpful in noisy environments. Not required, but it can be helpful.

    0x8003          Activate page 3
    0x8C18          Change sample rate to 98.4 sps

    >> Are you able to see the rate change from 2460 Hz to 98.4 Hz on the data ready signal (scope)?


    0x8608          FNCTIO_CTRL[3:0] = 1000 for DIO1 negative polarity data ready signal


    0x8000          Avtivate page 0 for sampling