We're evaluating the ADIS16465-2B with an STM32 platform. We're able to get burst data in successfully at 2Khz, or all 32 bit for gyro, accelerometers and delta angles at 200Hz.
We've noticed that the nominal frequency of 2000Hz is a bit off, currently at about 2010Hz or so. When sampling at 2Khz, using the burst function, we use the microcontroller to calculate the delta angle for each axis, and the time between samples is calculated by an internal micro timer. The datasheet states that 16 bit is the best resolution available at that frequency.
At 200Hz we're able to read in all 32 bits for gyro, accelerometer and delta angles. If we compare the delta angle from the IMU, which is calculated using this formula:
against the delta that we obtain between each gyro rate sample at ~200Hz using a similar formula as above, there's a difference of about 15% in the result.
Is it more accurate to use a sampling rate of 2Khz at 16 bit (burst) and do the angle calculations in the microcontroller, or using 200Hz at 32 bit and let the IMU do the calculations?
At 200 Hz, is it better to use 32 bit data or 16 bit data? Results on both are slightly different.
Would you recommend using an external clock instead of the internal one to improve accuracy? If so, which mode would be better, 2Khz at 16 bits or 200Hz at 32 bits?
Hi A. Fahrenkrog,
Thank you for your post!
Having different results could depend on the truncation/quantization since the 32-bit data could represent more values in between each step compared to the 16-bit.
Your sampling rate could be based from your type of application. Hope this helps! Best regards,John
thanks for your reply. Quoting from the datasheet:
The decimation filter  and Bartlett window filter  have direct influence over the total number of bits in the output data registers, which contain relevant information. When using the factory default settings (DEC_RATE = 0x0000, FILT_CTRL = 0x0000) for these filters, the data width for the gyroscope data width is 16 bits, which means that application processors can acquire all relevant information through the X_GYRO_OUT, Y_GYRO_OUT, and Z_GYRO_OUT registers.
Should I understand this that all the useful information is at 16bit / 2KHz? I'm not changing the decimation rate or the filter control registers.
Having access to a microcontroller, would you recommend doing decimation and filtering after reading 16 bit data on a burst read, or use the IMU's decimation and filter registers? I'm trying to understand which way would give me more accurate readings.
Hi A. Fahrenkrog,Sorry for taking too long.
For your question: "Should I understand this that all the useful information is at 16bit / 2KHz? I'm not changing the decimation rate or the filter control registers."
Well, the answer is yes. Fundamentally, the ADIS16465 is a 16-bit sensor.
"Having access to a microcontroller, would you recommend doing decimation and filtering after reading 16 bit data on a burst read, or use the IMU's decimation and filter registers? I'm trying to understand which way would give me more accurate readings."Well, this shouldn't matter. As long as you don't miss a sample and you employ the same equations for decimation and filtering. The advantage of using the IMU's decimation and filter registers is that you would be sure that all samples are accounted for in its computation.
As an addition, for your sampling rate, you may look at the FFT at 2kHz and at 200 Hz and look if you are not averaging any samples. If there are energy bins that are averaged out, it is possible that there is time-based error.
Hope this helps!Best regards,John
thanks for your help so far, I would like to trouble you yet again if possible.
- We're reading X axis data only for gyro rates and delta using sequential reads.
- We're reading data at 2 KHz using the internal clock. The data length is 5 minutes.
- The IMU ADIS16465-2B is sitting on a granite table, no one touched or moved it at all.
From the 5 minutes of data:
- Gyro rate X axis average is 0.016 degrees / sec. I've seen these results before, and I think that is ok.
I'm plotting the delta angle for the X-axis from the IMU, and I'm calculating the delta angle from our rates information using the below formula again:
Fs is 2KHz nominal.
If you look at the plot above, blue is data from the IMU (delta as calculated by IMU), and red is delta calculated using a script with the formula above.
As you can see, the envelope follows very well, there's no samples missing, however, there are still differences between delta from the IMU and delta from the raw rates.
Are we missing some filtering in between?
Can you help explain the difference please?
At this stage we're trying to confirm that we only need the burst read at 2KHz and perform some basic averaging and filtering post-processing with the 16 bit burst data.
I just came across your post and I am facing the same problems.
What is the status of your tests, have you reached a conclusion on which approach is better?
Which microcontroller are you using in your application?
We're using an STM32F3 microcontroller, it works really well with SPI, the limiting factor being the ADIS low SPI data rate.
We took two approaches:
- Sample the whole 32-bit data at 2 KHz doing reads for rates and delta (no acceleration), and we noticed that even though the datasheet states 16 bit, the delta values are calculated in the IMU using 32-bits, in which case our delta and rate integration/sum give same results.
- We decided to sample at 200 Hz, downsampling by a factor 10. We're reading the whole 32 bits of all data. At this stage, we believe it's the best approach. Letting the IMU sit idle for hours on a granite table on concrete floor, we get results similar to what the datasheet states. We are using the delta values from the IMU. If we compare at 200Hz delta values from the IMU with values calculated from the rates, we still get small differences. We assume there's some filtering going on inside the IMU.
Last, we started using an external sync signal into the IMU (2KHz), which yields more consistent results and much better timing.
Hope that helps!