VEMS has very precise RPM measurement, available in MegaTune logs. It is very easy to calculate dRPM / dt, with some (easy to provide) additional data, engine torque can be calculated.
When doing tuning runs, this makes it very easy to compare the result after changes (like changes in ignadv). It really saves a LOT of time and fuel, and provides real performance data without torturing the engine on a dyno. On a dyno, it is often NOT feasible to supply sufficiently cool intake-air in volume required by high-power engines. Measurement only requires a few seconds around each loadsite to get results suitable for evaluation, less than 1/5 of the time needed on a dyno. Often the dyno is not onsite (most often the case with 4WD), and impossible to duplicate the same ambient conditions as on the track.
Analyzing the logged runs, for each RPM-bin (in a similar way as lambda, VE and ignadvn is tuned) is very helpful. Something like this (this only contains 1 set of example data, see the real examples, or, even better, take and analyze your own logs):
| RPM | 3000 | 3500 | 4000 |
| MAP | 110 | 140 | 170 |
| ignadv | 24 | 25 | 27 |
| EGT(C) | 552 | 603 | 612 |
| lambda | 0.82 | 0.81 | 0.8 |
| torque dRPM/dt | 1600 | 3100 | 3900 |
RPM => power calculation is very simple
Some of the input parameters are often estimated though (a well known such parameter: m=mass, you can measure that too, of course)
- P=F*v
- F=m* (dv/dt + anull) + Fnull
- where anull = g*slopepercent (like g*0.04 for a 4% slope to keep the car climbing without deceleration)
- Fnull = some force to keep the car running without decel even on a 0 slope. Fnull=500N means that 500N * 20m/s = 10kW sounds reasonable below 100km/h (at high speed this climbs as v**2, due to air drag)
- so P=v* (m* (dv/dt+anull) + Fnull)
- v = RPM * const
- where, with audi in gear2: const = 1/2.13/4.11 * wheel_circumference
- wheel_circumference=1.87m (if you measure diameter and calculate 0.6m * pi, you get 1.885m, but remember the tyre is somewhat pressed in)
- so the audi wheelspeed at 7000 RPM and gear2: 7000 / 60 /2.13/4.11 * 1.87 = 24.9 m/s = 89.7 km/h
dRPM/dt => Nm (torque) calculation
So (with the 1600kg audi in gear2) what is the const in the torque=const * dRPM/dt to get the result in Nm ?
- dRPM / dt is given
- as in the upper formula, force on the wheels: F=m* (dv/dt + anull) + Fnull
- wheel torque Mwheel = F * wheelradius
- motor torque Mengine = Mwheel / drivetrain = Mwheel / 2.13/4.11
- v (in m/s) = RPM/60 / 2.13/4.11 * wheel_circumference
- m=1600kg (1400kg + spare tyre + fuel + 2 persons)
- wheelradius = 0.3m
- Fnull = 500N
- the uphill we use for tuning: anull = 0.03 * 9.81 m/ss
- this contributes to less than 10% of the power, at dRPM/dt = 1000 RPM/sec it is like 3.6 + 0.29 for the accel and the climb components
octave snippet:\nÿ1ÿ
Cruising fuel consumption (L/100km) example:\nÿ2ÿ
Using the road-dyno
If you don't have an audi200 (you can always buy one ;-), or you tune in gear3 (not gear2), or use a different slope (aNull), or the mass of the car(with driver and fuel) is different, you can change the parameters in v3gui.cfg. Note that units are metric
- mass is in kg
- wheelRadius is in meter
- fNull is Newton (the force needed to keep the car going horizontally without acceleration, eg. to fight friction and air-drag)
- aNull is m/ss (=> 0 if tuning on a 0 slope. +0.03 * 9.81 means climbing a 3% slope => this might make tuning easier, but higher gear also has similar effect, but in higher gear, at higher speeds, fNull becomes more significant)
- drivetrain=8.6 means the wheels rotate 8.6 times slower than the engine
Note that you can use simple arithmetics, eg. to do unit conversion from nonstandard units. If units are used this way, the unit of engine_torque in the output is Nm (with cheating, it is possible to have output in other unit, not recommended).\n
[sessions/mysessionname/torqueConfig] # value is evaluated: parsed symbols: +,-,*,/,(,) mass=1600 fNull=500 # 0.03 * 9.81 = 0.2943 aNull=0.03 * 9.81 # 2.13 * 4.11 = 8.75 drivetrain=2.13 * 4.11 wheelRadius=0.3
When v3gui.exe is started, the program automatically processes c:\races\*.log and writes result to c:\races.csv output file it does NOT do this any longer (at least not in 2007-08-03, it should at least write output when one chooses "Race analyzer")
- experimental/raceanalyzer test also analyzes c:\races\*.log , but it does not write result to any file. It displays on a grid
Evaluation
[example output csv zipped] TODO: upload new evaluation, this was converted before the filtering.
The gear can be seen very clearly. Torque 200-ish is gear2, and 300+ is gear1 (the calc parameteres were made for gear2 so these that are in fact gear1 are not real numbers. Gear 1 is not suitable for tuning anyway. For some engines, even gear2 revs up too quickly => gear3 needed). Considering the value of (dRPM/dt) / avgMAP, it could be automatically judged (unless the terrain has very tricky slopes)
Notes:
- DONE: even better filtering. An +-80 RPM spike (which is otherwise harmless, eg at 5500 RPM) no longer has significant effect on the end-result (normally, when at least 5..15 samples are available for a given RPM-range)
- TODO: for very same reason, the given run sometimes ends a bit earlier than in real (a small downspike makes the algorithm think the acceleration has ended)
- DONE: better annotation of input files (the time in seconds and which file it was from. This makes it easier to examine the same log in time-based vemslogviewer
- DONE: input files had to be c:\races\*.log and output is always c:\races.csv, the directory can be chosen in recent version
- TODO: make Fnull gear and RPM dependent. Fnull does not change too much in gear 2, from 50 to 90km/h, but in gear 4 (or 5 !), Fnull can be significant as the air-drag climbs according to v squared and becomes the most significant part of Fnull.
- TODO: color the grid-cells inside v3GUI
- TODO: when scrolling, the table headers should stick
- TODO: replace dRPM/dt/MAP with G-data for acceleration. Though if we make user-aided automatic gear-estimation possible in the future, that might be based on the less intuitive dRPM/dt/MAP. The G already depends on the gear (which we don't know). Lower acceleration caused by partial load might be mistaken as higher gear if the MAP is not considered.
- TODO: We can even remove the unfiltered dRPM/dt and the dRPM/dt/MAP
- TODO: correct-spelling of drmp to drpm
- TODO: make it possible to select gear from GUI for each race. This could be a separate widget at the left, filename,second => gear. The main outputgrid must be (partually or fully) be recalculated after each change. The filename,second => gear data might be saved to log (later only basename of files will be considered in a comparison, not the dir, not the extension ).
- TODO (low prio): make the input data (textfields) editable from GUI (for each session)
- TODO (low prio): write conversion help for the unfortunate: USA/British units.
- the app already supports conversion formulas, like "3700 * 0.45"
- for the pound => kg that's all
- if you want to scale the output (either to get lbsfoot instead of Nm or to compensate for drivetrain losses), scale the mass (and the Fnull) proportionally. You can use this to estimate crank-torque, the same way dyno-shops do: they estimate that powertrain losses are 15%, than 85% gets to the wheel: to get crankshaft data from wheel-measured data you just divide mass by 0.85. Note that you need to scale up the Fnull as well (but you don't know Fnull very precisely anyway).
- TODO: make it possible to evaluate cruising (fuel consumption in function of certain conditions like ignadv and lambda). Currently only RPM-climbs are considered (everything else filtered out), while cruising has quasi-steady RPM (filter would be sg like CLT>60C && RPM >2800 && RPM <2500 && MAP > 30kPa && MAP <70 kPa ). Besides the input filter, the output data could be configurable and also written to time-based textfile in tab-separated format for easy plotting by gnuplot