NefMoto

Been doing a lot of logging lately with some friends working on a similar project to see if we can find MBT and optimize timing curves etc etc. They are smarter than I with the goals of the project.

We seem to hit a stumbling block with the data the ME7 logger is giving us.

It appears as though the Time Stamps aren't the actual time the data is from.

Say 25samples a second which is .04 seconds a per data point. Well when you plot the acceleration of the vehicle you get a lot of noise in the data, which leads us to believe that .04s isn't actually what is happening but when the ECU is being requested to give that data. Thus based on the number of points being measured >1 the data comes from some time point after .04s based on the I/O capabilities of the ECU.

Has anyone else seen something like this?

You can see the oscillation in the data, I'd guess the car doesn't have that kind of fluctuation in acceleration.
(http://i101.photobucket.com/albums/m56/ejgsjeep/Noisydata_zpse8b1d467.jpg) (http://s101.photobucket.com/user/ejgsjeep/media/Noisydata_zpse8b1d467.jpg.html)



Or does anyone know a good way to smooth out the outliers? I tried using 2 std dev's of the data and well all points are within.

Why exactly is it important if it is 0.04s before or after?

ECUxPlot has a lot of filtering because of the jitter... and there is a lot of it.

both jitter and quant noise...

To get an accurate model for acceleration.

Vf - Vi / Tf - Ti = a

Fitting an equation to that data will allow me to work on building a tq model.

It is what it is. Internal update rate of specific variable you're logging is difference than your logging rate. Unless you tune yourself to that frequency (20ms? prj would probably know), you will always have jitter. If it is indeed 20ms, you'd have to log with 50 samples a second and see if you get more consistent readouts, you should. I don't know if I/O interface can go that fast and if it wouldn't cause ECU to run out of processing time to do normal stuff == ECU crash.