decipha wrote:
will do lito thanks for the heads up
attempted to adjust some things on the speed density ecu today and couldn't get anywhere with it
88 thunderbird with DE ecu suppose to be the LUXO strategy but it doesn't want to communicate with it using the tweecer
checked out the def and theres no qhorse support in the def so that needs to be addressed
pulled the stock binary from the ecu using the tweecer though got the original DE bin file if anyone wants it
It's going to be interesting to see if you can debunk the Ford "Tooner" opinion that the only thing to do with a SD vehicle is fit an A9L ECU.
Tuning the VE table IS harder than tuning a MAF transfer function, simply because the VE table is the height of a 2 dimensional surface, and the MAF transfer function is the height of a 1 dimensional line. So in the MAF transfer function, and air mass value comes only from a single input voltage, but in the VE table, that same mass value can come from many N/MAP combinations.
I've never tuned a GM car, but I have done a SD truck. I imagine the histograms BobCat refers to are the same kind of tools I had to fabricate with spreadsheets. So here's some random tips from me. The pros are welcome to comment on the principles involved, but don't bother telling us all that it's better to use an HPT or other commercial program. I'm sure it is if you want to pay for it.
A Every cell you adjust adjusts the height of a surface. That surface should be smooth and not rippled as you
cross it in any direction.
B Every time I made a correction I would plot the VE table in a spreadsheet as a set of 8 lines (for Ford's
8 MAPOPE levels) versus RPM. These lines should all be smooth, should all be higher in the middle than
at the ends, ideally don't touch each other, although they sometimes do, and, (I believe) should NOT cross
each other.
C The corrections come from the same places as you get them when MAF tuning, basically measured WB
LAMBDA over commanded Lambda.
D However the Ford SD bins may have significant fuel contributions thatare not counted in the commanded
Lambda that you log. These are usually transient compensations, AE fuel and manifold wetting. If you have
a load absorbing dyno and are careful in finding steady state, these may not bother you. It was impractical
to put my 14,000# vehicle on a dyno (and any hill is a dyno :-)) and for me steady state turned out to be
an impossible thing to find. MY VE corrections never homed in on a solution, and this was the problem.
I'd suggest at least logging AE and EFTR fuel and computing them as a percentage of base fuel (the fuel
that does go to commanded Lambda) and discarding any sample in which they are too high. I ended up both
doing that and also removing their contributions to fueling.
E If you have a load absorbing dyno, you'll probably be able to use the VE table cells as steady state points
if you're careful. If you're tuning on the street, that will be impractical, and in that case, you'll need to invent
some method of combining the samples from the log that you do have, into contributors to a particular cell.
I used my spreadsheet to divide my log up into rpm bands and MAPOPE bands around the cells and averaged.
Probably the pro tools have their way of dealing with this. I'm sure it's better if you have it.
F If you're tuning an automatic transmission, with the converter unlocking, there will be places in the table that
can't be reached, so don't waste time looking for them. (these are the high load, low rpm cells)
Even with a manual, there will be cells that you won't reach, or won't stay in for long, probably the high RPM,
low load ones.
G When you get to enabling KAMs, remember that the VE table and the KAM table may have different
Y axis functions (if you decide to map the KAM corrections back in to the VE table.
Your DE.bin isn't the same strategy as a DA1.bin (which I gather is a LUX0 bin) It's similar, so many of the payload
addresses are the same, but not all. The VE table IS at the same address, so making changes to it should have made a difference. Have fun with it.