.CSV log file
14 July 2010, 03:46 PM
#2
Scooby Regular
Join Date: Jan 2006
Posts: 3,695
Likes: 0
Received 0 Likes
on
0 Posts
Unless something's really badly wrong, we probably won't be able to give you a definitive yes/no answer as to whether your data's good, more a general indication, or a suggestion of things to look at in more detail.
You can post the file here by saving it to some personal webspace or a file sharing site and dropping in a link.
You can post the file here by saving it to some personal webspace or a file sharing site and dropping in a link.
14 July 2010, 04:10 PM
#3
Here is the link. TBH i would not know if there is anything seriously wrong.
http://rapidshare.com/files/40693230..._14h15m59s.csv
http://rapidshare.com/files/40693230..._14h15m59s.csv
14 July 2010, 04:43 PM
#4
Scooby Regular
Join Date: Jan 2006
Posts: 3,695
Likes: 0
Received 0 Likes
on
0 Posts
Nice one. As above, there's nothing obvious I can say regarding whether there's anything "wrong" there or not. There's nothing that immediately sticks out like a sore thumb.
The big problem one has when analysing a log like this is because I wasn't in the driver (or passenger) seat when it was recorded, one has no context or understanding of what the car should have been doing at the time. For example, the coolant temperature is a little on the high side throughout. Without knowing whether you were parked up for a while immediately before starting the recording, or indeed without knowing what the ambient temperature was on the day, this could either be normal or a sign that your cooling system is a little less optimal than it could or should be.
The other problem with your log is that it looks like you're logging every single possible data parameter. This results in a very low (c. 500 millisecond by the look of it) refresh rate which makes it very easy to miss transient problems. You don't need all those binary switches when you're logging performance, for example, they're irrelevant. Turn them off and your refresh rate will improve. Similarly you don't need to know what the idle control valve position is most of the time, either.
The less data you get, the faster you can log it so think carefully about what you're trying to find out. If you're checking the health of the airflow meter under hard acceleration, for example, all you really need is engine speed, throttle position, airflow meter voltage, manifold relative (or absolute) pressure.
The big problem one has when analysing a log like this is because I wasn't in the driver (or passenger) seat when it was recorded, one has no context or understanding of what the car should have been doing at the time. For example, the coolant temperature is a little on the high side throughout. Without knowing whether you were parked up for a while immediately before starting the recording, or indeed without knowing what the ambient temperature was on the day, this could either be normal or a sign that your cooling system is a little less optimal than it could or should be.
The other problem with your log is that it looks like you're logging every single possible data parameter. This results in a very low (c. 500 millisecond by the look of it) refresh rate which makes it very easy to miss transient problems. You don't need all those binary switches when you're logging performance, for example, they're irrelevant. Turn them off and your refresh rate will improve. Similarly you don't need to know what the idle control valve position is most of the time, either.
The less data you get, the faster you can log it so think carefully about what you're trying to find out. If you're checking the health of the airflow meter under hard acceleration, for example, all you really need is engine speed, throttle position, airflow meter voltage, manifold relative (or absolute) pressure.
Thread
Thread Starter
Forum
Replies
Last Post
ossett2k2
Engine Management and ECU Remapping
15
23 September 2015 09:11 AM
