Bad switchpoint for rpm based table switch?

Tuning concepts, methods, tips etc.

Moderators: jsmcortina, muythaibxr

Post Reply
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Bad switchpoint for rpm based table switch?

Post by Dennis_Zx7r »

Hello,
for some weeks now I'm using table switching based on RPM to refine my VE table. My (motorcycle) engine is nowhere as linear as the usual car engine and revs up to 13000rpm, so I guess that makes sense.

This is my current VE table. I'm using ITB, MultiplyMap and IncorporateAFR (AFR dependant on load across the whole rev range).

Image

3 questions.
1) I switch to VE3 above 7200rpm. As there is no extrapolation on the borders of the tables, I figured it would make sense to double the switchpoint and have the same values in it (7200/7201).
For example, if my highest revpoint on VE1 were 7000, and my lowest revpoint on VE3 would be 7400, everything from 7000 to 7200 would be the fixed value of 7000, and everything between 7201 and 7400 would be taken from the 7400 revpoint instead of interpolating between several values as usual. This does make sense, doesn't it?

2) When analyzing the data with VEAnalyze, I get quite different values for 7200 on VE1 and for 7201 for VE3. At the moment, I keep them the same as I want to avoid a discontinuity when the switch happens. I just take the values from 7201 (VE3) and put them into 7200 (VE1), as the upper rev range is more important on this engine. It's just a slight difference anyway, but I'm thinking of averaging 7200/7201 may be better?

3) As you probably already noticed from the colors, there seems to be a huge non-linear behaviour around the switchpoint. I have no idea why that is, peak torque / volumetric efficiency definately isn't there. It's more around 9000. This is my biggest concern, as I have no idea if there's something wrong with the way I do things, or if it's just a coincidence that this peak happens to be at the switch point.
Before using table switching, there was a slight peak there, but barely noticeably compared to the current peak.
Image
My project: Link
kaeman
Master MS/Extra'er
Posts: 643
Joined: Sun Nov 06, 2005 12:31 am
Location: NORTHERN CALIFORNIA

Re: Bad switchpoint for rpm based table switch?

Post by kaeman »

I just used the same bottom row values for ve3 as I had in the top row values of ve1, I was using map as my switch point, but I was running itb's and a 383 cubic inch small block chevy. Regarding the non linear spot in your fuel tables, it may be the change in the ram effect of your itb's or the intake air tract tuning... as long as you are making good power and are seeing safe afr readings then I would just go with it. my fuel table did that also, but it was when the ram air effect of the cowl induction from the hood changed the air pressure entering the engine.
64 el camino, 383 SBC, 11.7 to1 CR, accufab tb/rhs intake, 44lb injectors, trick flow heads, xr292r solid roller cam, belt drive camshaft, dry sump oil system, 2400 stall, turbo 350, spooled 9 inch, strange axles, 3.89 gears, dual wideband, full sequential fuel/cop, MS3x using 1.4.1 code.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Bad switchpoint for rpm based table switch?

Post by Dennis_Zx7r »

The numbers on the switchpoint are definately bad, the switchpoint itself seems to be fine.

Look at these numbers. They result from the same data log. VEAnalyze was closed after the analysis was done and the screenshot was taken, so the table would reset and not change incrementally. The numbers are small because I use as the cell change setting, but you can clearly see that in picture 1, the load point on 36 is leaned, while in picture 2 it is maintained, and richened in picture 3.

ImageImage

They only difference in settings was the minimum RPM. Unfortunately, MLV seems to include ALL Rpm below 7200 for the calculation of the switchpoint, aka lowest point in the selected VE table, therefore completely ignoring the table switching behaviour.
What you see in the first picture is my usual MinRPM of 1100 (alittle below idle). The analysis in picture 2 was done using a MinRPM of 6900. In VE1, the highest point is 7200, which holds the same values as 7201 in VE3. The second highest RPM point is 6900, therefore this number.

So in trying to falsify my hypothesis, I took a log which was merely the engine idling and a few throttle blips (<2000rpm!). Consistent with the previous tests however, VEAnalyze failed to recognize the table switching and therefore used the way too low RPM to recalculate the 7200RPM point in the second table.

Image

As it seems a MinRPM has to be set when analysing VE3 with RPM-based table switch, the question arises which RPM should be set. :?:
The next lower RPM, in this case 6900? The mean of 6900/7200 -> 7050? (see complete VE Table in the first post)

I'll post a more compact summary in the MLV sub forum and ask if this can be automated. Judging from looking into two other tunes of people using table switch, there may be quite few people not aware of this, if this is considered to be a user error.
I guess the same may apply to other table switching methods.
My project: Link
Post Reply