Acceleration log time delay

Comments

• Matt

  June 2015

  Hi Jon, there are a couple of delays in the system from stationary to motion, or motion to freefall.

  
  

  First, if you are using the accelerometer "Auto Sleep" power saving mode, there may be a several sample delay for the device to wake up when it senses any motion.
  

  
  

  Next in line is a sampling delay at the sensor, which is a delay between when the motion first starts, and when the event detection state machine triggers.  This is largely dependent on the accelerometer sampling rate (faster rate, faster response, lower latency), and the configuration of the state machine.  If the state machine requires 6 samples to identify an event trigger at a 50 Hz sampling rate, you are looking at a 6/50s delay, or 120ms.  The response speed is highly configuration dependent, and can be optimized for quick response, low power, etc.

  
  

  If the event is being directly logged to the on-board flash memory, there is a very short delay due to the timer tick of 750 us on average.

  
  

  If you are streaming directly to the app, then there is a delay between when the event occurs, and when the next radio link is available to send that event to the mobile device.  The event could occur just before or just after a radio communication cycle, so this delay could be as fast as 1ms or as slow as the BLE "Connection Interval".  On iOS the connection interval is 37.5ms.  On Android it can vary by phone model, but is typically 20ms or 37.5ms.  You should expect an average delay of half these values.

  
  

  The final delay will occur between the OS BLE stack and the smartphone application.  In general this delay should be <5ms unless the smartphone is particularly overloaded with active applications.  It may vary slightly more on iOS if the app is not active in the foreground, but I would need to confirm with our iOS expert.

  
  

  If you would like to share your exact accelerometer configuration I can comment on the response latency you can expect and how to improve it.  Do you have a performance goal or target you are trying to hit?
• goonerjon

  June 2015

  Matt,

  
  

  Thank you very much for such a detailed description - I'm sure a lot of people will find this useful.

  We've been able to reduce the measurement error significantly already because of this.  Our performance goal is to measure distance travelled in free-fall or down an incline etc as accurately as possible based on the log data retrievable from the device. I guess we want to know what our realistic error measurement will be.

  Here's the accelerometer settings currently (we will be testing at +/- 2G as, from reading, that appears to be more sensitive to smaller degrees of motion?)

  sampleFrequency: 800.0f;

  highPassFilter = NO;

  fullScaleRange = 8G

  lowNoise = NO

  fastReadMode = NO

  activePowerScheme = HighResolution

  sleepPowerScheme = HighResolution

  autoSleep = NO

  
  

  Many thanks,

  Jon

  
  
• Matt

  June 2015

  Jon,

  
  

  What will underpin the accuracy for this use case is the time resolution of the free fall detector in the accelerometer.  The timing will be used to determine how long the object is falling, which can be used to calculate the distance traveled.

  
  

  Distance would be the second integral of acceleration, which can be assumed equal to gravity for a freefall case.  If the object is at rest (v=0) when freefall starts, then the equation for distance is d=1/2*A*t*t.  For a more detailed derivation, there is an application note from the accelerometer vendor here.  The relevant section is 3.1.  Here is some data from their fall distance table:

  
  

  1 ms 4.91 μm

  10 ms 0.49 mm

  100 ms 4.91 cm

  200 ms 19.6 cm

  300 ms 44.1 cm

  500 ms 1.23m
  

  1s 4.905m

  
  

  With the preset settings in the iOS API you will get a notification of freefall every 100ms.  The logger time base accuracy is 1.5ms.  Interrupt delays are expected to cancel because they will affect the first and last event equally.  Your worst case error will be approximately 101.5ms then.  The average error will be 50.75ms.

  
  

  Because the distance traveled is not linearly related to time, the error in the distance calculation will depend on the total distance traveled.  A quick estimate would be the rate of change (derivative of d) at the total time measured, times the worst case or average time error.  The math looks like:

  
  

  dd/dt = A(t)

  dd = A (t) dt

  
  

  For an example where 500 ms was measured, you have:

  
  

  dd = 9.81m/ss (.5s) (.1015s) = 0.498m -- worst case

  dd = 9.81m/ss (.5s) (.05075s) = 0.249m -- average

  
  

  We are now looking into how we can expose more configuration options for the freefall detector in the iOS API.  Once enabled, you should be able to achieve closer to 5 or 10 ms resolution in the time base, which will get you 10-20x better distance calculations.

  
  

  What distance intervals are you interested in measuring?

  
  

  FYI - The accelerometer manufacturer suggests that 100ms should be the minimum threshold for detecting freefall from noise, which is about 5cm distance traveled.

  
  

  The 2g range is the most sensitive when small forces are involved. It can achieve +/- 2g at 12 bits, which is 2g/2047 or approximately 1 milli-g per bit.
• Matt

  June 2015

  It should also be noted, that the way the interrupt triggers -- there is a freefall debounce period before it activates -- will cause you to always measure less than the actual time.  That is, the error will always add more time to the fall or distance.  The average is the same as described above.
• goonerjon

  July 2015 edited July 2015

  Many thanks again Matt for your reply.

  Ideally I'd like to be able to measure distance dropped from no more than 3 metres with an error of 1 or 2 cm at most.

  So from what I've read we need to optimise the settings to enable:

  1. The data should be read locally by the device, not the App.

  2. Only when there is freefall START and END should the timestamps be sent to the device.

  3. We can then correct for delays and calculate from there. 

  we've been getting csv data with very detailed acceleration measurements, sometimes more than one acceleration value per mS. Presumably we are therefore using the device to record acceleration. If you graph the acceleration (RMS method rather than eliminating X and Y axes from calculations) then eyeballing the data to obtain a sensible timestamp for freefall start and end gives reasonable accuracy but not what I'm after. Also, using the mean acceleration observed in test conditions, as opposed to 9.81 appears to give better results, but I'm not convinced as the observed acceleration is presumably more susceptible to small rotations/tilts than for there to be a significantly measurable effect from air resistance (on average my acceleration data is returning an average during fall of 0.9G). Ideally I want the device to send me the two most accurate timestamps without us having to write an algorithm based on the graphical data, which doesn't appear particularly accurate.  Really I'd like the inherent delays to be part of the calculation already as well so we can simply concentrate on the kinematic equations. It seems getting these timestamp values out is quite complicated!

  
  

  
  

  
  

  
  

  
  
• goonerjon

  July 2015

  so...we are logging everything on the device and transferring the data over to the app once the freefall has been completed. We obtain a csv of time and acceleration data. The difference in time from one reading to the next is often 1mS, it can have the same time (to the nearest mS) presumably because of the rapid streaming which is being captured by the accelerometer. Therefore, using this method, all of the delays you've mentioned above are not relevant? Even the 100ms mentioned as we are not relying on freefall being detected? Do I even need to add any delay at all? Looking at the resultant graph and using 9.81 I seem to be 10 cm or so out usually.
• Matt

  July 2015

  Lets first roughly estimate the time resolution you need to distinguish 1cm differences at 3m.  The equations above work well for an estimate.

  
  

  First the time it takes to travel 3m in freefall.

  
  

  d = A/2 * t * t

  t = sqrt(d / [A/2])

  t = sqrt(3m / [9.81m/ss / 2])

  t = 0.782s

  
  

  The time delta from 1cm distance at the 3m point:

  
  

  dd/dt = A(t)

  dt = dd / [A (t)]

  dt = (0.01m) / [9.81m/ss (0.782s)]

  dt = 0.0013s = 1.3ms
  

  
  

  That comes out to about 769Hz, which is just under the max 800Hz the accelerometer supports.  The freefall function built in to the accelerometer is not this fast though, so you would need to develop a custom algorithm to analyze the data for the best accuracy.

  
  

  I agree with your points 1, 2, and 3.  Point 2 will be difficult to achieve though, as there will be no easy way to determine the stop time in the device.

  
  

  You are occasionally seeing two samples at one point in time, because the timer tick is approximately 1.5ms, which is just slower than the accelerometer tick at 800Hz which is 1.25ms.

  
  

  For the most accuracy, I would try using the freefall trigger to capture raw accelerometer data at 800Hz.  Then download that data from the log and analyze it in the phone.

  
  

  If you want to identify start and stop points, you could try using the "Threshold" filter in the data processing module.  When the RMS of accelerometer output falls below some threshold, likely around 0.3 to 0.4g you would be entering freefall.  Another threshold once gravity returns around 0.8 to 0.9g could be your stop condition.  It may be a challenge to get clean start and stop points this way.

  
  

  In all cases, you will want to log these outputs and then download them.  This will give you time stamps from the logger's time base, which is the most precise option you have.  Also, when using the logger time base you can ignore all of the delays previously mentioned. The biggest problem which is radio delay is removed.  Delays from the sensor itself will affect all data points nearly equally, so they cancel each other out and can be ignored.

  
  
• Matt

  July 2015

  In response to your last comment, yes, you can effectively ignore the delays when using the logger as your time base.

  
  

  All data points coming from the accelerometer will be affected by roughly equivalent delays before hitting the logger. You are measuring the time between two accelerometer points, so the delays cancel out. e.g.:

  
  

  Tstartlogged = Tdelay + Tstart

  Tstoplogged = Tdelay + Tstop

  Tfall = Tstoplogged - Tstartlogged

  Tfall = Tdelay + Tstop - Tdelay - Tstart

  Tfall = Tstop - Tstart
• goonerjon

  July 2015

  Many thanks Matt, it seems we are approaching it in the correct way: essentially to develop an algorithm to extract start and stop times from the raw data. Will let you know how we get on!
  Cheers,
  Jon