I've never had to smooth to anywhere near that many frames. About 90% of the datalogs I'm able to nail with 8-16 frames of smoothing. I've got a 3 step smoothing algorithm ;)Gernby wrote:I'm glad you mentioned the occasional drop in RPM in the datalog. I hadn't noticed that. However, since I'm smoothing across 80 frames for each datapoint on the torque plot, implimenting the fix that you suggested made for a very minor reduction in the noise.
Datalog resolution
I'm not sure I can agree that it's even possible to just smooth by that few frames in my case. There are surprisingly long spans of time where the frames have duplicated RPM values. I'm also seeing anywhere from 30 - 50 frames for each 100 RPM's with varrying time durations between frames. Some frames are only .004 seconds apart, and others are separated by as much as .011 seconds. I wonder if it would help to reduce the sample rate a tick.
'06 NFR S2000
Very possible... It's all about how you extract the data from the CSV. Mind you I'm not using a spreadsheet to generate my graphs, but a full blown application that I've written. Depending on the resolution of the datalog after initial parse there's only say... 6-10 frames for the smoothing function per 100 rpm's. For instance, your 2400-2500 range would only spit out 8 frames since I'm only using the first RPM value detect for each frame when the "trim" function is enabled. I leave the choice up to the person running the app.
Yes I know. I have an optional function in my graphing app that cleans up the resolution on noisy road torque graphs.Hondata wrote:Datalog using the FlashPro, not the laptop, and your datalog rate is much faster.
I haven't ever used a laptop to datalog. I've only used the FlashPro by clicking the datalog button.
I'm a VB.NET developer by profession, so I've used several aproaches (code or formulas) to do whatever I can to find the "best" algorithm. It sounds like you and I are doing our algorithms in a different order. I do my smoothing across the original datalog (all frames), then I select my datapoints for the graph (1 point every 100 RPMs). This seems like the best way to ONLY filter out noise without filtering out the "real" humps and dips.
My current results after several hours today are pretty good. I'm using a spreadsheet with a graph and 3 scroll bar controls to adjust the characteristics of the graphs (slope adjustment due to aerodynamic drag, correction to compare 2 different runs, and a RPM/Second to FT-LBS conversion). If I could figure out how to do a screen print fron Windows 7, I'd post a picture now. :(
I'm a VB.NET developer by profession, so I've used several aproaches (code or formulas) to do whatever I can to find the "best" algorithm. It sounds like you and I are doing our algorithms in a different order. I do my smoothing across the original datalog (all frames), then I select my datapoints for the graph (1 point every 100 RPMs). This seems like the best way to ONLY filter out noise without filtering out the "real" humps and dips.
My current results after several hours today are pretty good. I'm using a spreadsheet with a graph and 3 scroll bar controls to adjust the characteristics of the graphs (slope adjustment due to aerodynamic drag, correction to compare 2 different runs, and a RPM/Second to FT-LBS conversion). If I could figure out how to do a screen print fron Windows 7, I'd post a picture now. :(
'06 NFR S2000
Print Screen button and followed by a paste into word ;)
The logic behind doing it the way I am is I don't want all the little bumps in the road showing up because I might not start at the exact same point even using the same road. So far using this method I've been able to produce very accurate results, back to back pulls that overlap, so I'm satisfied :)
The logic behind doing it the way I am is I don't want all the little bumps in the road showing up because I might not start at the exact same point even using the same road. So far using this method I've been able to produce very accurate results, back to back pulls that overlap, so I'm satisfied :)