This page is developer discussion on analysing datalogs
Datalogs contain much information. Some of it is valuable, still not easy to extract it. In racing, advanced log analysis can make a very big difference.
This is a new log reader program. Very good usable, fast, and stable. You must check it!
I've found a very good usable log analisys software. Check it out! [PAnalyzer]
- plotting in the time domain is the simplest
- the correlations are mostly hidden
- most useful for PID tuning
- or checking noise or other serious problems
One signal in function of the other, or other 2
- plotting signals (eg. pw/MAP, EGT, knock severity)
- against MAP and RPM is of most significance
The idea is to make
- very simple building blocks
- that can be wired together to bigger networks. Wiring happens via signal names. If the 2nd output of block A is named kkk and the 3d input of block B is also named kkk, you got the idea...
- simple filter (condition can be like CLT > 70C)
- pass input1 towards output1 for N sec after trigger (input2)
- pass input1 towards output1 for every blocks on trigger (input2)
The data traveling between building blocks (on the "wires") is
- a sequence of blocks
- of collection
- of signal data
- Wires (nodes) are named (assign the same name to an output of blockA and input of blockB, rememner?)
- and the signals inside are also named
The data is not copied, when not necessary, only referenced.
Use case - Analysis of InTake/VariableIntake
We want to see the difference of (pw/MAP) plotted in function of (RPM,MAP) between data sampled at appr. 0.5sec, 1sec and 5 sec after the variable intake actuation condition is met. This shows the speed of variable intake, and if the vacuum is "consumed" from the vacuum container too early (because of some leak). pw/MAP is close to real VE because of the incredible EGO correction (that is fast, precise, and active at WOT too).
- input0 (all data from mtx log)
- input0 => warm0 : filter out data, so only warm engine data gets through: CLT > 75C
- warm0 => varint0: filter out data, so only MAP>80 kPa gets through
- varint0 => varint1 : filter out data, so only 1000<RPM and RPM<3000 gets through
- varint1 => varint2: a new signal is added, called since_var_act, which is the time since the start of the given block.
- varint1 can be printed in function of (RPM, MAP). The average, the 20% and 80% points for the distribution (peak values are eliminated for better noise suppression)
- varint2 can be printed for a chosen MAP (say 89..93kPa) in function of (RPM, since_var_act).
We should look around for similar frameworks. I doubt that it's feasible with octave. But some sound editors might have these implemented.
- google: signal "building block" edit graph opensource
- Streamit language
- Streamit graph editor SGE (Swing app, can be started from eclipse)
- GME (developed by XVolgy, Marcell's friend - currently in US East Coast)