I saw a timing diagram showing the sensor sample order in a thread about the 16448.
Is a similar diagram for the ADIS16488A available?
Thank you for offering that information. As it turns out, this appears to be simpler to determine and explain, than I had originally anticipated. As luck would have it, I ran into the original architect for this product family in the hallway. He was kind enough to share some helpful insights as he passed by. Here is a summary of what he offered:
I hope that this helps!
The ADIS16488A leverages separate ADC channels to produce data simultaneously, so this type of diagram may not be necessary. What level of precision do you need to understand the timing to? Are you planning to use an external clock in your application or are you just trying to determine what the step or impulse response would be?
We are using an external clock, plus we have an externally generated time-tag. So, we are trying to understand the delays between the external clock and the data samples which include the timing of the burst of 4 9840Hz samples into the 4x ave/dec stage relative to the external clock. So the questions I am trying to answer are:
1. Does the external clock gate the samples with the 9840Hz clock running asynchronously to the external trigger, or is there an underlying faster clock that is enabled by the external source?
2. Is there some other delay between the external clock and the first 9840 sample?
3. Are there relative delays between the x, y, z axes samples? and
4. Are there relative delays between the gyros and accelerometers?
Also, how would one have to sequence the part so that the first input to the Average/Decimation stage (the one controlled by DEC_RATE) is guaranteed to be from the first external clock edge? Our current design assUme-s that the count into that stage resets when the external clock option is enabled in the FNCTIO_CTRL register.
Thank you for the more detailed request, but I was sort of hoping to better understand how this impacts your application. When I get back in the office early next week, I'll do a little research and see what I can find out for you.
Just to clarify my previous reply, the driver in asking for this timing info is to ensure that the time-tag on the gyro and acceleration IMU measurements is accurate. The initial source for the time-tag is a timer that also drives a 2kHz external clock to the IMU. I need to account for all delays from A/D sampling to output register read. Even if these are average values. I am beginning to think that the difference between the external clock and actual A/D sampling is less of a contributor to variation in the time-line than software running in the IMU. So if I read the data sheet correctly, the average delay from external clock to data available in the output registers is 490 us plus the time it takes to bring data ready high.
All that being said, I think I need to better understand max/min delay through the part and whether or not running the FIR filter affects the average time. I already understand the delay caused by the FIR process, but I don't know whether or not the increased software load further slows the output.
I am going to move the last question in the original post to its own thread.
We are buried right now but will get to this. Again, for the level of detail that you are implying, I am afraid that I might need to understand this better. Of course I am going to do all I can to help you, but what can I use to convince a design engineer, who is already tasked with other high-pressure and high visibility demands, to stop what they are doing to quantify this to the level of detail that you need? It really helps to have a justifiable level of sensitivity that we can understand. If you feel like you need an accuracy of 10us or 10ns, that is fine, explaining why might help us get there quicker. Believe me, I am on your side, but the nature of our business is making it much harder to support "as good as possible" requests on very detailed attributes of these products. Regardless of what you can provide, I am going to do my best to help you, but I did want you to be aware of what might help. Thanks again for your your interest in using these products in your program.
My accuracy requirement hasn't been easy to nail down, but it is not as tight as 10us. For this application I am trying to get the time-tag to be within +/-200 us. Our current software design uses the data ready to generate the time-tag. I am not sure that is adequate.
Sorry I wasn't more explicit in the last post.
That helps a great deal.
Retrieving data ...