Doctor J

Background:
Elsewhere on this board Z69 (Scott L) posted about his VE3 patch for 8D ECM's.
This is the patch that expands the existing VE table entries from 13 X 13 and
11 X 9. The new tables are effectively 17 X 17 and 17 X 16 arrays, increasing
the range and resolution of fuel control points substantially.

Summary:
I tested both an AUJP and an AXCR patch on my ECM bench. Both worked as
expected, and threw no codes or crashes during extended operation over the
full range of fuel control. After sufficient proof on the bench, an AXCR bin
was prepared for my '91 L98 engine.

The patched bin starts and runs the car with no observed problems or codes.
Note that I made up a revised TDF for this application and used my own VE
values to populate the new VE3 look-ups.

Conclusion:
The VE3 patch expands the VE ranges and works as expected. YMMV.


Discussion:
Significantly extending the VE tables was proposed by Ken C (of HPTuners.com)
a couple of years ago in this thread:
http://forums.corvetteforum.com/show...m_id=82&arch=1

Scott L did the considerable code work to compile a patch that manifests the
table changes outlined above. He was generous enough to send me a copy for
independent verification. He delivered what he set out to do, in style, and was
very professional to work with.


The purpose of extending the VE tables is to increase the precision that is
possible in fuel tuning at moderate and high engine RPMs. This change brings
the fuel control potential in an 8D mask up toward the levels that are available
in LT1 and newer ECMs.

Only low-speed car testing has been completed to date. If there are subsequent
(unexpected) issues with the patched program in normal operation of my engine
I'll post them here.



Illustration and Caveats:
A graphic of the VE table difference between GM tables and VE3 is shown below
for ILLUSTRATION ONLY.

See the original patch text for instructions and information on how to modify bins.

The report above is only for education and discussion purposes and any use of this
information is at the user's sole risk and liability.

Further narrative info can be provided by Scott, and thanks again to him for sharing
a terrific job of code work. Have fun.

DrJ

-=Jeff=-

Very cool..

I cannot wait until it is available for all of us to try out and use

Z69

I posted it a month ago.
Almost zero response to it.

JPrevost

I don't really understand why you would need 3 tables.
I hate having 2 and wish it was just 1.
What is the benifit of going with 3? Seems to be a waste of memory and just more cells to edit. Not that I'm comparing this to the megasquirt but look at how well those fuel controllers work with such a small table... they're obviously not going with the accuracy of .1afr for emissions but aren't the older tables with the "extended patch" a much easier setup to tweak?
Personally I can't stand sitting down and editing the LS1 files by hand. I spend more time pulling or pushing values around than I do spending time tuning
From a patching stand point that's awesome. Awesome work.

-=Jeff=-

If I were editing those tables by hand I would not do it either... I created a program form 1 or 2 tables that will do the work for me.. instead of taking hours to sift through data, it take a couple of minutes.

Now before anyone asks, I would love to post it for people to use it, but I have not been able to build an Application yet as the software I have does not have the feature for that.

Z69

Thanks JP & DrJ
Lots of table space still in 8D.
The 3d l/u routine uses accA which has a 255 limit for the RPM value. This prevents using a single table as is and having adequate resolution.
If your goal is lots of resolution, then you run into this limit and have to use another table/scale to get to the higher rpms.
AFAIK, you have to change the rpm/25 calc to get break points other than 100/200/400. You can't get to 6400 using the 200 scaling, only 5600. So 3 tables.

My original question was about making the "VE1 scaled to 200".
My cam doesn't make full vac at cruise till 2400 so I thought that VE1 should go all the way there too.
Rbob was the only responder and suggested the table scales I put in the public patch. I don't have the tuning experience to have a firm idea of what to use scale wise. So by default.

69 Ghost asked for input on table scaling in the S_AUJP V3 thread.
In hind sight. It was probably not the best thread to ask in.
But he was making an XDF for V3 and wanted to include those tables too. At the time, I didn't know how to make a two table 6400 or greater code.
I've figured more things out since I did that patch now. I can get ve1 out to 2400 now using 4-1600 w/100 breaks and 200 breaks
to 2400. And after wasting 16 hrs on a tangent. Rbob politely pointed to an alternate path. Wish I handled idiot questions as well as he does. I can do the LT1 table scaling now.
No patch done for them yet though.
I posted a version of the patch code that needs the VE tables filled in and assembled on TGO.
Due to the lack of response, I wasn't much interested in doing more. I'll admit to be lacking in patience, but only 3 people have shown interest in actually running the patch and one of them lost their laptop so his progress ground to a halt.

I'm open to suggestions or discussion.

Doctor J

It's all about how to plot CURVES in the ECM/PCM.

1. If you look closely at the VE tables in an ECM program, you will notice they
generally have a 'curved' surface. The shape is characteristic of operating
curves from a compressor using modulated inlet pressure, measured at various
crank speeds.

In SD, the VE map is the empirical determination of how much air flows through
the system at various operating conditions. GM calculates engine airflow in
order to accurately estimate(control) the fuel required to realize a target
combustion AFR.

2. If you read the program description in "How 3D Tables Work" you will note GM
uses linear interpolation to approximate VE values that fall between KNOWN
data points in the VE 'look up' tables. What that means is, the ECM is using
straight lines to approximate the 'curved' (air flow) map that it's trying to
follow, in order to derive its fuel metering.

3. The new VE3 tables use a larger array of KNOWN data points than the
original tables to represent the engine's operating curves. Mathematically,
that means the ECM can use 'shorter' straight lines to interpolate between fixed
points on the airflow map. In other words, because the data points are closer
together the ECM does less approximation between known points.

4. Where the interpolations are smaller, less error is introduced into the resultant
fuel calculation - at any rate for the parts of the compressor map that are 'least
linear'. In terms of process control, a look up table with a larger number of
known values is a more accurate representation of an irregular shape.

That's an entirely excellent observation : Having 'more cells to edit' is in fact
the POINT of the whole exercise.

That concern about 'wasting memory' is a valid one. However the new VE3 table
values simply replace binary 'zeroes' in the stock ROM space. These 'zeroes' are
not wasted - they are collected and excess supplies will be sold on eBay.
No binary numbers were harmed in the making of this patch.

Whether accurate fuel modeling/control has any practical benefit is entirely up
to the user.


Some further discussion of engine maps and fuel control can be found here:
http://www.hptuners.com/forum/YaBB.p...num=1101917527

HTH

JPrevost

Doctor J, You still haven't convinced me that this patch is needed. That thread linked to HP Tuners forum is rather confusing. They're talking about burst knock caused by the VE table not being smooth... not sure if I can agree with them on their observations. They don't talk about emissions, maybe because Australia is new to the whole emissions thing? Seriously, the calibrations engineers are sitting on a dyno trying to do what they're saying they do. The whole "getting commanded to match actual" was done before it ever got on a dyno, this is now to make sure the emissions and power are balanced. Having it go rich or lean in an area because the routines for AE, open loop modes have been simplified is what they're doing with the bumpy VE table.
A real VE map of an engine IS smooth. Even with the resonance tuning being all miss matched a true VE map is curvatious meaning a VE table that isn't "smooth" is trying to compensate for something else. In that case it makes perfect sense to have some higher resolution.
For proof I'd like to see a difference in A) Fuel economy, B) Power, C) Ease of tuning. With the 8D the code is very good for port injections of all types so it's hard for me to believe that you have decreased the "error from interpolation" to the point of making a significant difference in the engine's fuel calculations. I still think there is more error on the programmers part that giving them MORE cells to edit is only going to make it harder to tune. The straight line interpolation is still very good, the eorror is very little. Besides, with closed loop cruisng you're subjected to the PID routines for fuel economy and those usually just shadow over your VE errors meaning idle and WOT are really the places this patch SHOULD shine... but does it? How much more control do you have over the actual AFR/fuel in the real world. I know theoretically it's increased but going back to my whole programmers error I think it might be pointless.
I do however love the patch and will try running it when it gets released.
I bet this sounds like I'm fighting the patch but I'm not. This is not me being a "ski-down-it" in the MAF debates. I'm just trying to find proof that there is a benifit that offsets the hassle of having to edit more cells. Got a program that does all the editing, awesome, but I still want to see the errors compared.

edit: It just came to me. I bet having this resolution would be a benifit to somebody with VERY large injectors.

vernw

iTrader: (2)

Hmmm..... I should probably keep my mouth shut and just stay out of this with my newbie's knowledge level, but what the hay, no on ever called me smart...

I understand DrJ's reasoning on the interpolation errors, and how finer grained tables will decrease that. I also understand the line of reasoning that it may be too small a decrease to ever notice. Being an engineer by degree, it all boils down to signifigant precision.

Want to make the patch REALLY GOOD? Why not take the 3 tables memory space and make it ONE CONTIGUOUS TABLE? Seems like that would be the easier one to work with (if it's even possible to do that). And the extra precision can be there for those that want it. Those that don't can do their own extrapolation between the extra data points like they do now in the existing tables, they'll just do it over more points.

Then follow that up with a TP ecu/xdf/adl file so it can be monitored and modified easily.

Oh, and make the patch for both an auto BIN (like Super-AUJP) as well as a manual BIN like AXYC.

D@MN, I must be management material. Sounds like I'm getting awfully good at coming up with stuff for other folks to do that I can't do myself.....

branz28

Hrm, I looked up the post where the original patch was posted, is there an updated version before i put this into my bin? I figure what the heck, if it'll help it'll be just as much learning experience i have.

JP86SS

iTrader: (1)

More resolution is never a bad thing, except as JP put.. Filling them in.
The increased resolution "should" have much better results for people who suffer from surging at critical points where traversing VE cells at the point where the engine is waking up. I've only had slight run ins with this problem and have to admit I should try the patch. (Reminds me, gotta quit smoking too!)
Anyway, The adjustability is what all the patches and other code adders are giving us. To some who don't feel the need, fine. But there are other who have the NEED to be that accurrate and get it as close to perfect as is possible. As for the next step, maybe getting the spark tables to match resolution and possibly having more BLM cells to aid in setting them up???.
I too am good for that Vern But, without creative ideas it may never happen. I play with code a bit but still don't feel I can make any significant changes yet without full understanding of the outputs. Simulation works ok, but I really should build a bench to see the results.

JPrevost

JP, GM didn't feel the "NEED" to be that accurate . I really have a hard time believing that it would solve any surging issues. Like I said before, yes resolution helps but programmers error is overwhelmingly (and 98% of the time) the overshadowing error. I don't dislike the patch but I feel it's necessity is very low. If you've gotten to the point where you feel and measure a difference in overall operations of the engine then you've gotten VERY far along in your tuning. I'll admit that the dry flow is a lot easier to get up and running so maybe this is the case.
I can see this patch helping owners of large injectors. When the pulse widths get small the resolution might be warrented. But at normal cruising, WOT, and decell is there really any data that proves that there is a need for more granularity?
Again, do NOT mistake my criticism for stubbornness. I'm excited about this patch but at the same time I don't want some newer guys coming into this and feeling overwhelmed. Newbie's and big tables never mesh well .

89 Iroc Z

Is this the same patch that is in Super AUJP V3?

JP86SS

iTrader: (1)

I see the point and do agree.
There are many things better left until knowledge of operation is obtained.
I don't feel I've peaked my tuning ability by any means but have seen a point where my converter threshold gives me troubles at different loadings at the same rpm. My car doesn't hardly run below 2K rpm and depending on my footspeed, the loadings can vary. I do get a little surging when cruising at the "threshold" as I'll call it. I was just thinking the resolution would enable me to get closer to the mark in that small area and help with that problem. My timing is a little on the aggressive side which doesn't help there either. But it runs pretty good. That discussion is for another day, just giving you some reasoning.
Others have had issues with surge when traversing cells as well.
Like you said, is it required, NO, is it another tool in the box, YES.
I don't believe I need that resolution everywhere, only where I want it

Edited out the dumb comment

Z69

Nice to see some discussion on this finally. JPrevost-keep it coming. Can't learn much if we all agree from the outset.
Apparently the other more experienced tuners are ignoring this thread.

The only P4 hardware consideration I made was clock cycles.
My patch is probably 2-4 cycles faster than the stock code since it's shorter. Plenty of space left on the eprom.

As far as GM goes, the stock LT1 tables do have more resolution.
All 5 kpa breaks and 200 rpm up to 4k. And based on just what I've seen here, they need it in some situations. And apparently the LS1 has bigger tables also. If this was only for emmissions, you'd think they would have only expanded the tables in the "low ve" table. (btw, I've seen some megasquirt posts poking fun at the expanded table idea) To each his own. From what I can tell, the bigger the cam in relation to CID. The more you could use better resolution in specific areas of the table. I wanted my patch to fit in the original VE l/u area. So that put constraints on how much scale manipulation could go on. Depending on the app. You could have the scaling change at or near your torque peak. That could be aggravating. Or not, that's why I wanted input on the scaling. For a stock setup, all I see is maybe better mpg. Start lowering the cam LSA and making the power have more of a peak to it. And more resolution might help.

The patch in V3 is the one that RBob put out over a year ago.
"All" it does is extend the VE2 out to 6400 rpm using the original scaling. My patch changes the map and rpm scales of Rbobs' patch. Which required a 3rd table due to my code knowledge level. Which I have since figured out how to make fit into 2 tables with slightly different scaling.
The code needed seems to work fine on the bench. But it's still a 3 table patch and goes to 7500 rpm. I haven't written a 2 table patch yet.
But I'd prefer to have that specific code tested on a running car first. Mine doesn't run yet. I posted the info needed on how to come up with this code too (RPM/25). Rbob showed me the way. I just posted the hac info with better comments and some snipping since it's hard to follow straight out of the hac. I did this so that if people were interested, they could make there own patch with more or less resolution. You could start with a low res table to rough in the tune and then expand it for the fine stuff. Smoothing software is already out. I have an excel file I did for the table cut/paste into the patch files or TP.

Vern, one would have to write another 3d l/u routine or modify the current one to make the VE tables fit all in one. To me, this is more of a convience than a necessity. Although, the 3 table Ve really does look messed up in graph form. Bruce has a bin with VE1 having 600-2k w/200 breaks and 2k-4.8k w/400 breaks.
And VE2 is 4.8-6.4 w/400.

That's why I don't post bins. DOS seems to stop most of the newb's for some reason. And I posted the actual S19 file too.
Not hard to find.

vernw

iTrader: (2)

I ended up fiuring out it was a space problem, as in not enough contiguous space for a single table. I'd like to try your patch in a couple of weeks. Want to work on my tune a bit more first at the current resolution, and then see it the patch helps or not. FWIW, I'm runnung a 730 and $8D.

Z69

I fit 3 tables in. Plenty of space. Just not enough experience.
Might want to have a look at Rbobs patch or mine. They are very similar in the table area.

3.8TransAM

I personally hate the blank part of the VE table in the 1600 to 2000rpm jump range.

U do start lsoing resolution and it shows. This was brought up in the original post when the idea was first brought up.

No matter what u do, when u get to the 400rpm jumps you cant get your fueling dead nuts on 128 and sometimes have some wierd flutters or strange numbers. That has bugged me since I started tuning on anything and makes things annoying.

I never figured out why the resolution gets worse where the majority of cars spend their rpm's at when on the highway?

GM has steadily added to the resolution of the tables in every succedding ecm/prom/engine combo and I'm betting that emissions and driveablilty are the only reasons driving it. they would not waste the time or $$ if it did not impact one of those two issues.

My two cents :-) Once I get the 383 here a little happier, I'm going to play with patching the VE tables and making a TC file to use along with it. Prolly gonna take me a while I have trouble making a ready to go patch work :-)

later
Jeremy

PLANT PROTECTION

iTrader: (6)

I finally got some time to test this out. I had a problem with the ECM losing connection with my lap while datalogging, random blips of extremely inaccurate data, and twice the engine cut out for a split second then resumed. It may all be the same problem, may be two or three different ones. Either way, going back the original tables and most likely won't investigate further.

69 Ghost

iTrader: (1)

Not to say I am an expert in this area but I worked with Z69 to get a second table to 6400 with 5kPa resolution while using the stock lower table. It served multiple purposes one being it kept the VE table definitions in Super_8dm simple without causing too much confusion as well as keeping something stupid from happening especially for the newbies. While I am not a programmer nor do I have a bench I am persistent and have done testing for quite a while now. The original VE work was with 3 tables that Z69 and I discussed. It got to a point of analysis paralysis especially when tuning the tables. First off I was used to using VEMaster to tune along with DataMaster. That went out the window with WBO2 patches, etc. Moates and Mansur were working on some kind of Datamaster/VEMaster program of sorts for TP but since there are not 36hour days I am afraid we will never see anything from them. I am not planning on spending any more effort on getting more resolution into the VE tables unless there is some kind of VEMaster setup for the patches and it works with TP since I am stuck in the manual edit mode now anyway. EFI live has a AFR tuner that takes the datalog and then tunes the bin from the datalog. I posted this but got no real response:

https://www.thirdgen.org/forums/diy-...-autotune.htmla

Interesting thing here is it is bin definition independent and it tunes multple tables at one time. For me I see 2 directions. First is to remove the limitation on SAUJP and go independent to get what should be in the bin. Second develop a program that is similiar the EFI Live's to tune the bin based on a TP datalog. If that was accomplished then you could add all the tables you wanted and still tune as long as the 'Tuner' program could handle changes. I guess we all lose site of what we are really after. Personally I have never had a problem with the 8d original tables. I still say that 6400 is all you need even if you are going above that because you will be at WOT and PE mode will be in effect so the differences will be minor especially since you probably are not going to be there for very long in the first place.