Master Thesis Code
by Simon Moser
Loading...
Searching...
No Matches
jumpCorrectData.m File Reference

this function corrects several timing issues which occur because of the way the data is stored on the JUMP Sensor. More...

Go to the source code of this file.

Functions

function jumpCorrectData (in tt, in options)
 

Detailed Description

this function corrects several timing issues which occur because of the way the data is stored on the JUMP Sensor.

Note
This function works only as a part of jumpReadData
Parameters
tt- timetable of the JUMP sensor data, properly formatted
options.plot- plot the results (default: false)
Return values
corrected- timetable of the JUMP sensor data with corrected timing

As Patrick (renn@.nosp@m.zhaw.nosp@m..ch) found when investigating the firmware is that the samples are not stored equidistantly. The saving of the samples is done as following:

  • whenever a sample is taken on the MPU, the MPU interrupts the uC which the incremets a counter.
  • whenever the counter reaches 20, the uC reads the FIFO of the MPU. Also, it stores the time at that 20th interrupt.
  • Now, the uC stores the 20 samples as follows:
    • the last sample is stored with the time of the 20th interrupt (t_i).
    • the second last sample are is with the time of the 20th interrupt minus 1/ts (ts is the sampling rate of the MPU, in the case of 100 Hz this is 5 ms [actually 5.00488.. ms or 164 / 2^15]).
    • the third last sample is stored with t_i - 2/ts and so on.
  • the first sample is stored with the time of the 20th interrupt minus 19/ts, and here's the problem: since the time between the interrupts is not stored the time difference from the last sample of the previous block to the first sample of the next block is jittering. Therefore the time difference between those two samples is between 0.8/ts and 1.2/ts.

Also, Patrick found that the the pressure and temperature samples are not sampled at the same time but alternating. But in the data the uC stores, they are stored at the same time.

Also, Patrick found, that the sync signal does a hard sync, i.e. all jitter from e.g. the BLE stack or other timing issues directly affect the synced time. This leads to a jitter occuring in the sync interval (1s).

Also, the data is interpolated on the uC with the last valid value.

Therefore, the following function does the following:

  • correct the time at the end of a block to be equidistant
  • correct the time between samples to be equidistant during a block and to the block before.
  • removes interpolated samples
  • corrects the time of the pressure samples
  • resamples to match exactly an integer sampling rate
Note
Some actual samples of temperature or pressure are removed by this function since they are identical to the previous sample. This is not intended. But since the firmware of the uC doesn't even manage to store these samples equidistantly, I cannot apply a better algorithm to remove interpolated samples (at least not with sensible effort).

Definition in file jumpCorrectData.m.

Function Documentation

◆ jumpCorrectData()

function jumpCorrectData ( in tt,
in options )