Table switching / VEA RPM limit

Questions specific to Megalogviewer

Moderator: LT401Vette

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

Table switching / VEA RPM limit

Post by Dennis_Zx7r »

When using RPM based table switching, you're using VE1 and VE3. I use 7200 as a switchpoint (MaxRpm 12800) and use the same values on 7200 (VE1) that are generated for 7201 (VE3) so there's no discontinuity when the table is being switched. Below you can see my tables from a few weeks ago.
Image

The values around the switchpoint were conspicuous to me, and I now am quite sure that the values generated be VEAnalyze at this point make no sense. By now, I know why VEA generates these wrong values, and it's because I did not set a MinRPM limit when analysing VE3. Turns out that VEA doesn't recognize the table switching and therefore assumes every RPM below 7201 has to be handled by this datapoint. For example, when loading a data log where the engine just idles (around 1200rpm), all the hits are attributed to the lowest point in VE3, if MinRPM isn't set high enough.

:arrow: A MinRPM clearly has to be selected when working on VE3.
Question is: Which RPM should be chosen? The RPM of the nearest lower column, in this case 6900? Or the mean of 6900 and 7200, which would be 7050? How does VEA handle this for other adjacent columns in the same table?
Maybe this could even be automated? I think this may apply to TPS or kpa switched tables too.

---
EDIT:
I think there may be another problem with this approach. If you want to avoid discontinuity by keeping 7200 and 7201 at the same values, VEA would have to look at VE1 and VE3 combined in the analysis. In the approach described above, the blending betweend 6900 and 7200/7201 would be neglected otherwise, as every RPM below 7201 would be weighted as 100% 7201 if I understand this correctly.

The other option would be to look at 7200 and 7201 seperately, with a MaxRPM for 7200 and a MinRPM for 7201. This would mean that theres a sudden change in VE numbers when the RPM changes from 7200 to 7201, however. I don't think this is good, either.

EDIT2:
I just thought of a compromise, which I think might be a good solution. Analyse VE1 with MaxRPM 7200. Analyse VE3 with MinRPM 7201. Blend the calculated values (for 7200/7201) together and use this compromise on VE1 and VE3.

Is there any official recommendation on how to handle this?
My project: Link
LT401Vette
Super MS/Extra'er
Posts: 12731
Joined: Sat Jul 16, 2005 8:07 am
Location: Moorseville, NC
Contact:

Re: Table switching / VEA RPM limit

Post by LT401Vette »

What firmware are you using..

The best way to deal with it is likely to add a custom filter based on the table switch status. That way rather than guess what table it is on, the ECU can tell it.
That is how TS's VEAL handles it.
Phil Tobin
EFI Analytics, helping to simplify EFI
Next Generation tuning software.
Supporting all MegaSquirt versions and firmwares.
http://www.TunerStudio.com
http://www.efiAnalytics.com/MegaLogViewer/
Support the firmware running your engine:
http://www.msextra.com/doc/donations.html
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Table switching / VEA RPM limit

Post by Dennis_Zx7r »

I'm running Ms2Extra, current version.
My project: Link
LT401Vette
Super MS/Extra'er
Posts: 12731
Joined: Sat Jul 16, 2005 8:07 am
Location: Moorseville, NC
Contact:

Re: Table switching / VEA RPM limit

Post by LT401Vette »

For VE Table 1 use the custom filter:
status1 & 32

For Table 3:
!(status1 &32)
Phil Tobin
EFI Analytics, helping to simplify EFI
Next Generation tuning software.
Supporting all MegaSquirt versions and firmwares.
http://www.TunerStudio.com
http://www.efiAnalytics.com/MegaLogViewer/
Support the firmware running your engine:
http://www.msextra.com/doc/donations.html
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Table switching / VEA RPM limit

Post by Dennis_Zx7r »

Alright, this seems to work fine. Thanks!
The filters need additional brackets to work, if anyone else reads this.

([status1] & 32) for VE1 and
!([status1] &32) for VE3

I guess merging the switchpoint data and having the same VE values on both sides (7200/7201 in this case) to get a smooth transition still makes sense?
My project: Link
Post Reply