NefMoto

Technical => Tuning => Topic started by: masterj on August 16, 2012, 11:30:58 AM



Title: ZTSPEV & TVTSPEV
Post by: masterj on August 16, 2012, 11:30:58 AM
Hey, everyone on this wonderful forum!  :)
I was analyzing RKTI section fr diagrams and found some interesting things like:
Why the hell ZTSPEV is there at all, when in diagram I see that it makes no sense (attached image 1)
val(new) = val(old) + (in - val(old) ) * dZTSPEV / ZTSPEV
Because IV and IN are equal we get same number repeated for whole ZTSPEV time unless B_stend interupts this op.

TEST:
T = 1
val(new) = 90 + (90 - 90) * 0 / 1 = 90
val(new) = 90 + (90 - 90) * 1 / 1 = 90
T = 2
val(new) = 90 + (90 - 90) * 0 / 1 = 90
val(new) = 90 + (90 - 90) * 1 / 2 = 90
val(new) = 90 + (90 - 90) * 2 / 2 = 90
....

Or maybe I don't understand Lowpass function?

Also could someone check TVTSPEV map in their damoses? In my definition file it's axis is wrong...  (image2)

Additionally I have attached my bin maybe someone will be able to find correct axis address. Right now map is @ 1CDDB, AXIS @ 1CDD7

Thank you all


Title: Re: ZTSPEV & TVTSPEV
Post by: masterj on August 16, 2012, 11:40:55 AM
Maybe TVTSPEV has 16bit axis instead of 8b (because I see similar 16b progression, but don't know factor)? Then map values would be at 1CDDF


Title: Re: ZTSPEV & TVTSPEV
Post by: matchew on August 16, 2012, 12:04:05 PM
Does everything = 90? Maybe your maths is wrong.


Title: Re: ZTSPEV & TVTSPEV
Post by: masterj on August 16, 2012, 12:06:10 PM
Does everything = 90? Maybe your maths is wrong.

I just took 90C as example but since evtmod is same in IN and IV according to lowpass formula they should end up being 0 (evtmod - evtmod)


Title: Re: ZTSPEV & TVTSPEV
Post by: masterj on August 16, 2012, 12:33:45 PM
I think I have cracked TVTSPEV. Looks like ori definition was wrong. Correct TVTSPEV address is 1CDE0. Axis is at 1CDD8 and it is 16bit. Now only problem is axis factor...


Title: Re: ZTSPEV & TVTSPEV
Post by: masterj on August 16, 2012, 12:46:59 PM
One more thing I have noticed... We can *fix* fueling based on boost. I haven't completely checked out RKI functions, but will do so soon.

Right now I see that FRLFSDP is always applied (and not only in returnless fuel systems as some people said here). I still have to check STARTINJTIME and INJECTIONTIME but at this moment you can see attached image if interested ;).

Only problem I see is that here BOOST is negative since pu_w (ambient) - ps_w (mani). We need either to edit definition by applying negative factor & mirror map or just ignore it ;)