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.

That might help, however this is what I have been experiencing. I configured the IMU to use a negative pulse on DIO1 (as outlined in the datasheet), however probing DIO1 shows long periods of low assertion broken up by regular positive pulses on the order of 10 microseconds long. Is this what you would expect with a positive pulse configuration?

Also, I don't think it is expecting an internal clock because the data is changing. The issue is that the Raspberry Pi does not support interrupts, so I have my code polling the data ready pin and, if it is low, to sample from each of the accelerometer and gyroscope registers. Because of this, it will read the registers several times before they update. Other attempts to prevent this (for example, sitting and waiting for the signal to go high before exiting the if statement) have resulted in receiving no data, perhaps because the Pi isn't polling fast enough to detect the short positive pulses I am seeing. Let me know if you need more information.

Edit: Also I don't mind at all branching this in a new discussion; should I have moved this to a new topic?

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:

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?

>>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 30x8C18 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)?

The issue is that the Raspberry Pi does not support interrupts, so I have my code polling the data ready pin and, if it is low, to sample from each of the accelerometer and gyroscope registers. Because of this, it will read the registers several times before they update. Other attempts to prevent this (for example, sitting and waiting for the signal to go high before exiting the if statement) have resulted in receiving no data, perhaps because the Pi isn't polling fast enough to detect the short positive pulses I am seeing. Let me know if you need more information.

>> I just purchased my first Raspberry Pi to start learning this platform but I have not started that process yet. I was not aware that it would not support edge-triggered interrupts. That is an unfortunate limitation that would be an issue for most of our customers, as they cannot typically afford to allocate processor resources to polling a data ready pin. Regardless, your polling of this pin should not change its behavior. I wonder if the sequential reads are violating the stall time and causing a delay in the ADIS16488's internal firmware loop, which services changes in the output pin states. I will keep thinking about this but hope that this gives you something to start with.

The reset came from an experience I had with getting another IMU to work with the Pi. Initializing the SPI interface on the Pi caused some toggling to occur that interfered with the IMU, which required a reset before I could obtain any data from the IMU. Since I started from scratch for the ADIS with the Pi, I coded it with the reset and it worked, so I left it. (Also, for your future reference, this toggling issue occurs when I am using the bcm2835 libraries found on airspayce.com, which has helped significantly in coding for the Pi)

As for scoping the data ready line, no I have not scoped it. I have only looked at it with an inexpensive logic analyzer; I'll need to get back to you on that after the holiday.

I'll play around with adding some delays between reads to see if that helps, but the way you are talking about the data ready signal makes me wonder if I am thinking about it's operation wrong. The other IMU I have been working with has a data ready signal that indicates that "new" data is in the registers. Once each of the registers have been read (that is, each register flagged in a configuration register, so the accelerometer and gyro data), this signal goes low until more data is loaded into the registers, thus allowing a polling approach to be implemented fairly simply. Am I wrong in thinking I will be able to use the ADIS like this? Sorry if this seems like an unnecessary question, but I want to make sure we are on the same page and not trying to debug something that I am just using incorrectly.

Please do not hesitate to ask if something is not clear. With respect to the data ready, no, it will not support this function in the manner you describe. Our older IMUs have new data bits but those functions were embedded into the registers themselves. Data ready is different; it tells you that the data has been updated in the registers, it does not provide a flag whose purpose is to say, "new, un-read data is still available in the output registers." After thinking about your description a little bit more, I think that you said that you had to read something multiple times to actually get real data. Am I interpreting this correctly? That should never be the case. One read should produce one set of data as long as you're not conflicting with the very small data ready polls, which I described above, identifies the time that the output registers are actually being updated. Even if you were to conflict with this time, in a large majority of the cases you will still get valid data.

With respect to the chip select/reset discussion, I like to borrow what others have done as well but I tend to strip away what is unnecessary and if I can't understand what something is doing, I try to experiment with removing it to see if it really is necessary. I can't tell you how many times I've worked with others who have had things like that, which were unnecessary for supporting normal operation, cause them problems. Unfortunately, I've seen many people trick themselves into thinking that gimmicks like toggling chip select or reset are necessary, when they actually have a problem with their power supply or somewhere else in their system. The gimmick ends up changing their operation just enough to support normal operation and meet their needs at the moment, then they post their code and move on to something else.

The bottom line is that there is a lot of value in leveraging the work of others to get started, but it is dangerous to assume that they know everything there is to know about a particular product or that they have taken the time to fully understand the consequences of their approaches in their code. in fact, some of the boldest people

I only offer this because I've been through this myself. I probably would've done the same thing that you've done if I were in your situation, so I thought I would share this perspective to help you as you move forward and optimize your code.

With respect to probing the data ready line with a logic analyzer or a scope, either one should work just fine. My primary question was related to verifying that the data ready was doing what we expect. After you do all of your configuration, what do you see in the logic analyzer when you are not reading any data or doing any other activity on the serial port? Does that change when you start polling the port?