curious effects in datalog

[garz]

hi

i had some old data logs from 3rd gear pulls in my car - starting at around 30mph / 3000rpm and finishing in the region of 85mph/8500rpm
(on a closed road of course)

out of interest i loaded them into the "Virtual Dyno" software to see how well they would agree with the real world dyno it was tuned on
(K20A with SC + CC )

but virtual dyno gave numbers over well over 600bhp - which was a bit odd

on further inspection it seems virtual dyno is only taking vehicle weight, tyre diameter and rpm data - calculating vehicle acceleration from that and working back to torque and then horsepower

so in other words the only thing is really needs from the log is good RPM data - and the rest is user entered as fixed variables.

digging a bit more i found that the "dyno chart" that the virtual dyno software makes is heavily damped - and yet it still looks pretty erratic ( if you turn all damping off - it looks even more erratic)

virtual dyno 3 runs.JPG

so digging deeper - and looking at the RPM data in the log (since this erratic curve can only really be driven by the input data - and all input data is fixed except for the RPM values) - i found that the rpm data in the log was a little odd.

essentially the hondata log can go up to 0.4 seconds between recorded data points - and it looks like this is causing a lack of resolution in the rpm data - relative to a 3-4 second run in 3rd gear - and this is what's causing the lumpy graph in Virtual dyno

i found this a bit surprising as i was under the impression that the hondata would log at around 10hz ( 10 times a second ) - but this seems to suggest its much slower - and at variable intervals ......

so my question is - is this normal behaviour for a Kpro - or is there some kind of issue ?

this time vs rpm chart shows the large gaps in rpm samples - but this can be verified in the log also

rpm vs time chart.png

the full log file here

poss 3 runs.kdl

[garz]

the car is accelerating at around 1000rpm per second in 3rd gear

so 0.4 seconds is equivalent to around 400rpm between data log points in 3rd gear - and the gaps could be even wider in 2nd gear

i would hope the ECU is actually updating fuel and spark in time increments much smaller than this when the car is in ide open throttle use

but it would be good to know for certain

can anyone from hondata Jump in ??

[garz]

to clarify - this is a question about the Hondata Kpro - rather than Virtual Dyno - which is just being used to visualise the data from the Hondata Log

the car is accelerating at around 1000rpm per second in 3rd gear

so 0.4 seconds is equivalent to around 400rpm between data log points in 3rd gear - and the gaps could be even wider in 2nd gear

i would hope the ECU is actually updating fuel and spark in time increments much smaller than this when the car is in ide open throttle use

but it would be good to know for certain

can anyone from hondata Jump in ??

[garz]

anyone ?

key questions
1, is 400ms gaps between log entries normal - or does this indicate a problem with the Hondata ECU
2, if its normal behaviour can hondata confirm the ECU is actually adjusting fuel / spark in finer increments than this 0.4s gap in the log

[Spunkster]

Post the datalog in question

[garz]

Thanks.

Its in the first post.

I think the time plot i gave the snapshot of is the first pull

[Spunkster]

When you make a datalog, close all other windows in Kmanager and see if you get more frames per second.

[garz]

To my knowledge. When i ran that datalog the only window open was the display window

I.e the one that displays rpm speed etc as a dashboard.

Is the ecu adjusting fuel and spark much quicker than the log - or refreshing at the same rate?

[Spunkster]

The ECU operation has nothing to do with datalogging speed. close the display window when datalogging and you will get more frames per second.

[garz]

OK - thanks for clarifying

[Arno]

I guess to avoid such variation from the link to the PC a workaround would be to use the on-board datalogging on a Kpro3 or higher for such power-test runs where you want the most consistent samples.

That is of course under the assumption(!!) that the onboard datalogging is a real-time function of the Kpro daughterboard microcontroller and thus should be very consistent in it's sampling intervals with little variation or skew in the resulting data files.

Bye, Arno.