CL MAF CAL

[joey]

Hey Steve,

I got a quick question...

Can I do a maf cal in CL, recording commanded and actual lambda and then do x3 logs and then enter those details into the maf cal calculation excel sheet like the same way we do OL maf cal?

[skiptownmcat]

Download attachment and read chapter 4

http://www.mazdaspeedforums.org/forum/f ... obs-83959/

[Steve @ VersaTune]

You will need to do Both CL and OL logs to do the entire MAF range.

Ignore the trims for the OL cal, as they are not applied.

[joey]

I know Abilor's guide. Its next to my Bible hahahahaha *joke

I was just wondering if I could do the CL Maf cal same way as the OL Maf cal... I slept on it and realized that I can't do that as I need the LTFT to build and the commanded and actual lambda in CL is realtime.

Anyways, thanks guys!

[mituc]

I'm not very comfortable to run a high load map with the default MAF CAL at temps around freezing. Since I have a few gigs (literally, 17GB more precisely) of logs captured with my Dashdaq at a very high resolution (over 60 readings per second) in a lot of weather and driving conditions, I was wondering if I could use those to get my MAF re-calibrated roughly before I get on the road for fine tuning.
The logs I have now, among other PID's, also have the MAF g/s, MAF voltage and LTFT's in there, so I could even apply small corrections to the values I have to match the current weather conditions as the last logs have the LTFT's a bit off by 1-3%.

Should this work? Is the versatuner logging in a different manner or just the raw PID values just like my dashdaq does?

[manselainen]

For CL MAF cal you should probably have the data needed in your existing logs. On the other hand, I can't see risk in running CL MAF cal runs in cold weather. Those are run with very small engine load anyway.

I would be more concerned about OL MAF cal. I would make just one WOT run and analyse it, make corrections, and then run other WOT runs. I have been modifying my OL MAF cal settings so many times... but almost every time in the same direction, richer.

But you might have also OL MAF cal data in your logs, if you have happened to log desired AND actual lambda (or AFR) and MAF g/s OR MAF voltage.

[Steve @ VersaTune]

Was the car running a stock tune when you took those logs? If not, then the logs are not useful.
How many concurrent PIDs were you logging when you got 60 samples per second with the DashDAQ?

[mituc]

No, the car was using the Hypertech tune. Shouldn't the MAF g/s and voltage relationship still apply no matter what the tune was? If it doesn't apply then can you please tell me what's altering it and these should be actual measurements of the amount of air coming into the engine and not something that can be changed programatically (and even if it was so the ECU would learn the differences and log FT values different than 0).
I apologize if this sounds stupid or newbish but... this is what I am

manselainen, I log the actual AFR and desired AFR as well.

I'm currently logging 25 PID's (I can log even more than that) and 7 of them are actually calculated results (by example Boost is calculated as MAP-BARO, the RPM is multiplied by 0.001 just to have a RPM gauge just like the one on the car dashboard, AFR is lambda * 14.64, Commanded AFR also is multiplied by 14.64, FRP is multiplied by 0.145038 to get the result in PSI rather than BAR, and there are also 2 PID's for the HP and torque which I'm not sure how well are calculated but they are using a pre-defined value of the car weight and a few other signals to do the actual calculation).

I upload all the resulted CSV files into a local database on my computer to be able to search everything easier so here are some counts per second (one line contains the values of all logged PID's):

dashdaq=> select count(*) from logis77mtc0374 where timestamp between '2011-12-03 16:44:28.000+02'::timestamptz and '2011-12-03 16:44:29.000+02'::timestamptz;
count
-------
67
(1 row)

dashdaq=> select count(*) from logis77mtc0374 where timestamp between '2011-12-03 16:44:38.000+02'::timestamptz and '2011-12-03 16:44:39.000+02'::timestamptz;
count
-------
64
(1 row)

dashdaq=> select count(*) from logis77mtc0374 where timestamp between '2011-12-03 16:45:48.000+02'::timestamptz and '2011-12-03 16:45:49.000+02'::timestamptz;
count
-------
68
(1 row)

..and so on, sometimes I get even 70-72 readings/sec but they are consistently above 55-60 every time, so these are not values stored in an internal buffer and flushed all later at about the same timestamp.
Basically anything above 20 readings/sec would satisfy me, but if it's 2 or 3 times more than that it's even better

[Steve @ VersaTune]

So, you are logging 25 discrete PIDs at once, and getting 60+ pids/sec? If these are all generic SAE/ISO standard pids, then it makes sense. If they are manufacturer specific pids, then they have some magic to get that data rate. The logging throughput is limited to about 50 - 70 messages/sec by the low priority of the CAN message ID of log requests. That is so that a log request does not prevent an airbag deployment or some other much more important message from going through.

SAE/ISO standard messages can be requested in batches, manufacturer specific can not. This is all spelled out by the SAE/ISO standard.

We are working on high speed logging.

Do you know whether the HT tune used the stock MAF table values? If so, then those logs are useful.

[mituc]

So, you are logging 25 discrete PIDs at once, and getting 60+ pids/sec? If these are all generic SAE/ISO standard pids, then it makes sense. If they are manufacturer specific pids, then they have some magic to get that data rate. The logging throughput is limited to about 50 - 70 messages/sec by the low priority of the CAN message ID of log requests. That is so that a log request does not prevent an airbag deployment or some other much more important message from going through.

Some of the PID's are ford specific (just a few of them actually because I figured I get more accurate readings with the generic ones) and some of them are standard PIDs.
Also, you already have a pretty well documented process for logging and data processing so whatever the logging speed is now with the versatuner I guess it's fine, since it's getting far more logging than a dashhawk.

So I'm not trying to replace the MAF CAL process as described in the VT docs/forum, just trying to get a bit ahead and have the MAF CAL a bit closer to the reality (so not trying to make a perfect one) than the existing MAF CAL in the high load map before I go on the road with this new tune and start gathering data for a proper MAF CAL.

Do you know whether the HT tune used the stock MAF table values? If so, then those logs are useful.

Nope... I was using the Cobb SRI MAF CAL... as this is what I have for some time now on my car (like one year and 8-9 months, and since about 13-14 months ago I also have it with the CorkSport CAI BOX).

But if, say, right now I get something like (all in CL):
30.43g/s at 1.936V, 32.23 at 1.972V, 20.84g/s at 1.748V, 21.87 at 1.764 and so on, ignoring the LTFT's for now as they are within -/+2 or so (but usually within -/+ 0.7%) and puth these numbers into the existing MAF CAL and smooth it a bit shouldn't this give me about the same MAF cal I have now, and after the ECU relearns everything even get about the same LTFT's?