I apologize if this info exists, but I couldn't find it.
If I set the data rate to 200 Hz how accurate is that and what spread over many devices?
I'm sorry that there is no clock frequency deviation charactrization data for ADXL346. But it should be similar with ADXL362 (figure 29, on page 12 of ADXL362 datasheet). You can find that +/- 8% from ideal should can cover +/-3 sigma. Hope this can help.
Would you kindly let me know your application with ADXL346. Why this parameter is important to you.
This is important because I am numerically integrating acceleration to get velocity over about a one second event. The exact time between points is required for accurate results.
I can do one of two things I believe: Use an external clock/interrupt to grab the data at regular intervals or determine the accelerometer clock by timing the data ready interrupt.
Does this sound reasonable?
Thanks for the reply. It explains the deviation we've been seeing in our product. I think you should include this spec for all your devices. Just a suggestion.
Thanks for sharing and the suggestion. We are keep on trying to offer more info for different requirement / applications.
Refer to the two things that you are going to do, they are all reasonable. Using polling mode to read the data may be the most easy way if your MCU timer is more accurate.
I just would like to share more insight:
1. ADXL362 support external clock and also support synchronized acceleration sampling to an external trigger. If clock deviation is the key to you. You can also consider to use ADXL362 and using the external clock.
2. If you want to do the integrating to get the velocity, I think the error caused by noise and tilt variation (tilt and acceleration due to motion are indistinguishable by the accelerometer) over the integration period is more than the error caused by the clock deviation.
Thanks for the reply.
Our test is brief and all initial conditions due to tilt and gravity are zeroed out before each test. Also I do noise filtering. Our velocity results are very good as shown by a free fall velocity test from different heights. This testing pointed out that some units were high and some low which resulted in my clock question.
I have since incorporated a small routine which detects the rate of Data Ready interrupts and computes the correct delta t for each device. This resulted in correcting readings that were off by about 6% to being essentially right on.
I will check out the ADXL362.
Thanks for your update. Let's discuss further if you have any questions on ADXL362.
Retrieving data ...