X2 with the boost referenced regulator.
Printable View
X2 with the boost referenced regulator.
I don't know if that MAP sensor is suitable...
aem 35-8460 wideband with gage...Quote:
Originally Posted by joecar
drivers manifold is stock...passenger manifold is trick performance stainless cast manifold (turbo mounted on it)with NO o2 spot....the passeger o2 is in the down pipe...the wideband is in the down pipe...both are 18-30'' from turbo...Quote:
Originally Posted by joecar
yes i have..:D im not new to turbo charging, supercharging, fast programs, or holley fuel injection...but efilive is new to me...i know the numbers to shoot for, just now how to setup the program up to get there.....Quote:
Originally Posted by 5.7ute
the wideband is off.....im trying to figure out how to adjust...ive had a hard time callculation my injector data...
80 lb sure fire injectors based on 43 psi
fuel pressure is 70 psi..not sure why...i think my pump is too big for stock lines
i will connect the stock pressure regulator...ive read wherte a stock 99 silverado one will work with boost.
thanks
is there one thats better, or a good one i can install? just was lazy, choose one that was plug and play...Quote:
Originally Posted by joecar
Does it have a serial comms port (is this how it talks to the gauge)...?Quote:
Originally Posted by garyk1970
EFILive hints:Quote:
Originally Posted by garyk1970
- set VE units to g*K/kPa,
- set fueling units to EQR,
- set PE sufficiently rich to be safe (and make sure it will enable),
- log GM.EQIVRATIO,
- use wideband Lambda for correcting VE and/or MAF tables (might need a calc pid for it),
- disable MAF and trims, correct VE table;
- disable VE and trims, correct MAF table;
More info, see posts #2, #4, #29, #38 in this thread: Summary Notes
Quote:
Originally Posted by joecar
hello Joe;
im using the 5v out of wb and a ground connected to A1 input on the bottom of the v2...
There is a thread on how to correct maf and calculate ve. Inside the thread shows how to setup calc pids to use analog signal and use it with eqr and lambda. I think
Can post the AEM user manual pdf here...Quote:
Originally Posted by garyk1970
Here is what 400ss is referring to (see post #1): Calc.MAFT thread
This is also helpful (both Calc.VET and Calc.MAFT thread refer to this also): Calc.VET Summary Notes
Has anyone opened a log to see what's there?
Still waiting for you to post one up.Quote:
Originally Posted by garyk1970
Sorry for being unclear... Has anyone figured out why when I save a autove map, then reopen that table shows invalid numbers?
No one else is having that problem, hence why we need you to post your log file to have a look.
I would be extremely confident that the problem is in your map settings, ie you are logging the wrong pids. Once we see your logs raw data we will be able to sort you out.
If your BEN_PLX map shows 10.7 (see post #37 above), then when you paste-multiply you will very likely exceed the VE cell max range.
Post log file, and the tune file that the log was taken from.
Post #20 is my pid file.....and you guys need a ve log...coming up in a couple hours when I'm at work.
Thanks again...
What I'm not understanding is the numbers are .7 to 1.2.....those are normal numbers? Then I copy with labels and paste and multiply....everything works as should?Quote:
Originally Posted by joecar
But if I simply save the log and come back, the numbers are different (10s)....sometimes I cant copy and paste right away (log on my way to work 37 mile trip)
a log file and current tune file....
There is definitely something strange going on there. The EXT.AD1 voltage pid values are getting corrupted when you save the log. (I am sure your V2 would be dead if it saw 70 volts)
I would first try doing a complete reinstall of efilive.
OK, I'm gonna do this now.
Also let us know what build number of Efilive you are using.
Last time I down loaded the lastest version on this forum.
https://forum.efilive.com/showthread...pdate-Feb-2015
ok, i now have;
v8 8.2.2 build 270
7.5 7.5.7 build 276
boot 2.07.07 2/7/14
firmware 2.07.77
No worries. Now you will need to do another log, save & see if the EXTAD1 voltage still get corrupted. If it does we will have to kick it up the chain to get a fix.
OK...driving 40 minutes home , I'm going to log the trip....I'll report later.
Gary:
- is your FlashScan a V1 or a V2...?
- which wideband do you have...?
- did you connect a ground/return to the AD1- pin...?
I have the v2Quote:
Originally Posted by joecar
Aem....model # in past post (I don't remember model#)
Yes , 5v on positive, gage ground on negative
I logged another drive and nothing has changed...after save be screen has different numbers saved than logged..
I also noticed the 70+ volts on the wide band....I'll double check everything....my gage never fluctuates.
You do mean in the logged data after it has been saved???Quote:
Originally Posted by garyk1970
Yes...before I save, on the data log map...I see numbers ranging .07-1.3....those I assume are "normal" numbers?
Then after i save the log, that same map shows 10.8 on all cells.
Before I saved, I saw 70v on the wideband log also...not sure what's going on....I'm an automotive electrical field engineer by trade....I'll monitor the v2 input....I'm sure its not 70v in...
Try just logging the EXT.AD1 pid on its own. Then check the values before & after saving.
Looks like a bug with the way EXT.AD1 is being stored i the log file. Both EXT.AD1 and GM.AFR are being stored at the same byte offset in the frame. That means they will both be using the same raw value to compute their actual display value. One of them will be wrong, in this case the EXT.AD1 value will be wrong.
If you adjust the charts in V7 so that the EXT.AD1 PID is plotted with a vertical axis of 0..100 (instead of 0..5) you will see that the EXT.AD1 data is exactly the same as the GM.AFR PID's data.
I'll get a fix available for it asap.
Regards
Paul
Paul, would a work around be to use the EXT.AD2 slot instead?
Probably not, I expect all EXT.* PIDs are being handled (incorrectly) as calculated PIDs and no data is being stored in the log file for the EXT.* PIDs. That means when the Scan Tool software tried to extract the EXT.* data from the log file it pulls the data from the first real PID in the log file. In this case its the GM.AFR PID.Quote:
Originally Posted by 5.7ute
Unfortunately I can't think of a workaround right now.
Regards
Paul
Logging the voltage through the EGR system like we do with the fuel pressure sender & making a calc pid should work.