help with RAFIG

[mr.prick]

i have added
;Desired Airflow In Gear
B4307.ROW=SAE.ECT
B4307.RRR=CALC.RAFIG
to the cal_link.txt
and the first time out it subtracted
so much the the car would die.
i am logging this so far
-40
-18
3
25
46
68
90 -0.219463
111 -0.302195
133 -0.328929
154 -0.282911
176 -0.334647
198 -0.401274
219
241
262
284
without RTACS on.

i went by this
http://forum.efilive.com/showpost.ph...54&postcount=4

the car idles well anyways (except on very cold starts)
maybe i should`nt bother?
but i would like to dial it in with my RR.
thanks

[5.7ute]

Does real time correction work on anything that doesnt use the paste & multiply function. The way I see it is this is a default for real time calibration & will cause the problems you are having.

[mr.prick]

maybe everything is set to multiply.
if so i would like to know how to change that.
seems to me the RR would be useless except
for data that is to be multiplied.

[DrX]

I have played with this as well. Even if you derived a calculated PID that could be applied via paste and multiply, you would have to be able to filter out of all the data that is between the temp labels on the B4307 table. Given the available RTACS filters, this appears to be easier and faster to do by creating the maps, applying successive filters to the same dataset to determine the correction at each label value, and performing the paste and multiply for each of those ECT values.

Now I just have to park the truck outside on a -40* night so I can catch the low end of the table. Presuming that it even fires, up.

[mr.prick]

I have played with this as well. Even if you derived a calculated PID that could be applied via paste and multiply, you would have to be able to filter out of all the data that is between the temp labels on the B4307 table. Given the available RTACS filters, this appears to be easier and faster to do by creating the maps, applying successive filters to the same dataset to determine the correction at each label value, and performing the paste and multiply for each of those ECT values.

Now I just have to park the truck outside on a -40* night so I can catch the low end of the table. Presuming that it even fires, up.

yes,
but it seems like a waste not to use th RR in real time.
i would like to know what dictates the changes made with RTACS.
i always assumed that it was set to the specific pid,
and that pid having it`s own mathematical equation
to adjust the data.
but maybe it is set to multiply all data.
it would be nice to know for certain and how to change/adjust
the way data is applied with RTACS if at all possible.
attention Paul, Ross, or Craig.

[5.7ute]

Yes it would be nice but as DRX pointed out the filter set up makes it too time consuming anyway.

[DrX]

You would need a filter like: "not equal to -4 or -28 or-16 or -4 or 8 or 20 or......." without excluding data colllected at each of those values.

[mr.prick]

yes,
but i would still like to know for certain
how data is applied regarding the RR.
whether or not it is multiplied all the time or
if it depends on the pid for the data application.
as for filtering, i guess i could edit out anything
over idle RPM or TPS and to see how that works.

[mr.prick]

yes,
but it seems like a waste not to use th RR in real time.
i would like to know what dictates the changes made with RTACS.
i always assumed that it was set to the specific pid,
and that pid having it`s own mathematical equation
to adjust the data.
but maybe it is set to multiply all data.
it would be nice to know for certain and how to change/adjust
the way data is applied with RTACS if at all possible.
attention Paul, Ross, or Craig.

maybe i will make a seperate thread for this question.

[Blacky]

Currently all RTACS updates are simple multiplications as per the VE table BEN factor style of update.

I see no reason why RTACS could not also be used to apply other mathematical operators such as addition. I will see if it is a reasonable change to add to the code.

Regards
Paul