I just returned from vacation today. The parts are here and I will put it together tomorrow. I know replacing the IAC is a long shot but cleaning the throttle body and putting in new gaskets will not hurt. If the IAC was stuck open it could explain the incorrect MAP sensor readings? We will see, something is causing an incorrect reading!

 

No it did not solve the problem! I now have a rebuilt throttle body. However I am closer to the problem I guess? The MAP sensor is still the key. I disconnected the temp sensor forcing open loop. The car did not run better. I disconnect the MAP and the car runs great. Even with the AC on, no stumbling! What is going on? I am buying a new truck and this car is up for being traded. I hate to give up but I am getting too old and frustrated! I am not a mechanic!

Rich harris

 

MAP sensor disconnect is the key to the repair. The car runs very well with the MAP disconnected. This happens immediately! Only the MAP sensor causes this positive response, no other sensor makes any difference. There are several great mechanics out there and this is an electrical problem not a mechanical problem. When I get a chance I will again test the MAP sensor signal. I am ticking off miles with the MAP sensor disconnected and I am enjoying the performance. I try to avoid looking at the check engine light!

 

maybe tps ?

 

I have not used or even downloaded EEhack. Does EEhack do datalogs? Can you post up a CSV datalog? Is EEhack what you're using to verify the volts/kPAs/hg etc? Computer's are stupid...garbage in garbage out. Have you put a vacuum gauge on the engine and compared that to what EEhack is spitting out?

 

TPS was switch out with no change in performance. I have run real time data on the engine and I am reviewing it presently.

 

I am back to trying to solve this acceleration problem. I am using the car almost everyday. With the MAP sensor disconnected I can drive the car and it runs great. The problem is the check engine light is on all the time because the MAP is disconnected. As soon as I reconnect the MAP sensor the acceleration problems begin. I have driven over 5000 miles with the car and it runs very well but I would like to fix it! I am toying with removing the intake, inspecting it and re setting it over the winter. However I plan to drive the car all winter and would hate to take it off the road! Why does the MAP sensor voltage go down as the car accelerates?

 

That would be pointless. There's nothing wrong with the vacuum in the intake - you've already verified that - and it would take a monstrous leak to make it a problem.

When you open the throttle and the car is in gear, the absolute pressure in the intake goes higher and stays higher (i.e. it gets closer to atmospheric, or the "vacuum pressure" is reduced) for a bit as you accelerate. If you leave the car in 1st gear and went up to redline, it would probably return to near idle vacuum (i.e. manifold pressure would go down well below atmospheric again) because the load on the engine is reduced. But if you upshift and keep flooring the throttle the vacuum will stay pretty low (i.e. absolute pressure stays close to atmospheric). Think of it this way:

• Any time the throttle blade is preventing the engine from running faster, it's creating vacuum in the intake and the MAP is lower than atmospheric. That's because the engine (which is a positive-displacement air pump) is trying to such in air and the throttle blade is restricting it.
• If you open the throttle wide open so it stops being a restriction, and the only thing restricting RPMs is the load on the engine, then MAP can raise up pretty close to atmospheric.
• When you have the car in neutral (minimal load on the engine) and you snap open the throttle, MAP may momentarily rise as the engine is slightly loaded by its own reciprocating mass and the flywheel or torque converter, but as soon as the RPMs rise it will once again be restricted by the throttle blade (we hope!) and the MAP goes way down again.

 

Thank you for the response. I was looking for an excuse to not remove the intake and now I have one. I agree. I am thinking I could plug the MAP sensor back in. Disconnect the sensor wire only. Run that wire into the car an attach a volt meter to it. Take the car out and run it and record the readings.There is some reason the PCM is restricting fuel on acceleration when the map sensor is connected but does not when it is disconnected? Until than I will enjoy the ride!

 

Yes it does, by default as soon as you connect, it's logging. If you use the 'save' function it will save a proprietary format you can load into a copy of the program, though if you like you can go to the 'Main' tab and click 'Export CSV' on the right side to export a CSV. However, the proprietary EEDATA format is far more useful.

I don't know what OP is using for logging, but if they don't mind sharing a log, I'd love to take a look at it.

During default operation on a 94-96, the MAP sensor is not actually used for operating the engine. It is used for a few interpolation tasks, but the MAF sensor is what's actually used for the measurement of air into the engine during normal operation. The only time the MAP sensor is used for operation is if the MAF sensor circuit fails (either by unplugging it or setting it to disabled in the code). Then the PCM will drop back to speed density mode and rely on the MAP sensor and IAT sensor for measuring air into the intake.

That said, there is one single operation that the car relies on the MAP sensor for regardless of what operation mode it's in, and that's for reading the barometric pressure the moment you turn the key. Since the engine is not running, it takes a reading from the MAP sensor to see what the current barometric pressure is, then remembers that while the engine is running. If you unplug the MAP sensor, the PCM has no way to detect the barometric pressure, so it will probably use some default value instead.

If there are any datalogs you wouldn't mind sharing, they'd probably help a lot. Like, one of the car running with the MAP sensor plugged in, and one with it unplugged? If the problem is a sensor, it should be insanely obvious in the datalog.

 

I knew about the speed-density fall-back mode if the MAF fails, but I thought the PCM used MAP data all the time to help determine the load on the engine and set the spark advance. So that's not true? And if it's not, how does a 94-96 LT engine determine load? For clarity, I'm not arguing here but rather asking.

The OP did post a data file in a different thread. It's a really long thread. To my recollection it was logged via EEhack. Maybe that file will give you something to help him?

 

That part I'm not honestly sure. The developer for EEHack suggests it's not, and some others suggest it is. I haven't actually disassembled the code and looked at all the places where the MAP is involved, so I personally cannot say what it is used for during normal operation other than it being used to read barometric pressure on startup and "it's used somehow during engine operation sometimes." That latter statement is why when tuning these cars for MAF operation, you first disable the MAF and tune the VE tables instead. Then once everything's good in Speed Density land, flip the MAF back on and tune the MAF table. Additionally, there are plenty of cars on the road that use exclusively MAF for air metering and have no MAP sensor whatsoever. They seem to get by, so I can't imagine ours wouldn't.

Anyway, lemme grab that data file and see if I can figure anything out.

EDIT: Had a look at the CSV. A little less immediately useful than the EEDATA file since I have to graph it all manually, but it did have some oddities. Unfortunately due to how old this data is, I can't be sure that it's relevant to the current situation, and additionally, I can't be sure that those oddities aren't a result of EEHack momentarily glitching since I also don't know which version of the program it is (earlier versions had some issues with allowing junk data into the datalogs during momentary communication stalls when talking to Corvettes). So with that disclaimer, it's actually the MAF that looks weird in this dataset. It has random spikes to improbable flow values with no associated change in throttle position. The MAP on the other hand, at least in this data, appears to follow throttle changes reasonably closely.

I also had a peek at the O2 sensors, and found that on initial startup they go pretty much dead lean (almost no voltage at all). Once closed loop kicks in, however, they do oscillate as expected. However, when the spreadsheet is loaded into Trimalyzer for fueling analysis, it shows knock all over the place (which would have associated knock retard) and recommends large amounts of fuel be added across the board (up to 10% at higher load cells, and at least 5% just about everywhere else). It makes me wonder if knock retard is what's causing the acceleration. For example, around data point 3586, you can see him hit the throttle, but then knock is detected and his 26 degree spark advance plummets to around 19 degrees, with 8 degrees of knock retard. This then increases to a maximum of 13 degrees of knock retard, resulting in an awful 10 degrees of spark advance.

I'd want a newer datalog, in EEDATA format if possible, one with the MAP plugged in and one with it unplugged. From this older log, all I can see is that there appears to be a major fueling issue that's causing the computer to request more fuel flow from the injectors across the board, and which is resulting in knock on acceleration that's causing the computer to pull timing.

 

Okay. I've read through most, but not all, of the suggestions for crappy idle and acceleration in "closed loop".
Please pardon any redundancies.

TEST ONE:
Attach your fuel pressure gauge to you know where:
Turn your key to "On"
If fuel pressure reads 43.5 psi with the key "On" great.
Now, turn the key "Off" and check for leak down.
If you're losing fuel pressure quickly, its probably a bad check valve in the fuel pump.
If you're losing fuel pressure slowly, its probably a leaking injector(s).
If you're not losing pressure at all, STOP!
It's not a fuel issue.

TEST TWO:
If leak down DID occur, do the following:
Turn your key to "On"
Safely (yet firmly) clamp the "rubber feed line hose" coming from the fuel tank (the double-clamped hose closest to hatch window)
Turn your key to "Off"
Observe fuel pressure. If you lost fuel pressure in TEST ONE and NONE NOW, its the fuel pump check valve.
If you lost fuel pressure and STILL ARE, its the Fuel Pressure Regulator or Injectors.
Also, check your vacuum line from the fuel pressure regulator for fuel.

My '96 had similar problems and I isolated the problem to be the Fuel Pressure Regulator. Easy Fix.
Hope this helps!

 

Thank you for taking the time to work with me on this! I hear that I have some tests to rerun on the car. I will try to post newer information from the ehack program both with MAP connected and disconnected. I will also do another fuel pressure test and relay results.

 

Yeah, you make a good point on the CATs. If nothing else shows up, the CATs should be on the test/verify list. (Been there...done that too!).

 

Replaced both Cats this summer.

 

Interesting today........ Connected the MAP and hooked up the ehack program and went for a ride. The check engine light went off as expected but the ARS service light came on. The thing that was interesting is that the car ran very well. No stumbling even in closed loop. I went to the post office and shut down the car. I starting up again and the ARS service light went out, no lights on. The car did start to stumble. Went for another ride this afternoon and the service ARS came on again, the car ran well again with little stumbling. What needs to be done to service the ARS system?

 

Connecting any logging tool, whether it's EEHack or a Tech 2, will disable the ABS/ASR due to how ALDL communication works. The short version is that there's no dedicated transmit and receive pin, and so every computer in the car talks all at once. When you connect a scan tool, it tells everyone to shut up, and so this causes the various computers to lose signal and malfunction. Thus the ABS and ASR will be disabled as long as the computer is connected, and your digital climate control (if equipped) will temporarily stop working and the LED will blink. It is expected operation.

If you have EEHack logs (preferably the EEDATA format ones) from runs where it was stumbling, I'd be more than happy to check them out to see if anything jumps out.

 

That does explain the ARS service light. I will try again tomorrow with the ehack program disconnected. What would explain computer connected runs fine. Without computer connected stumbles? I am having trouble getting the data to upload. Thanks for offering to analyze it! I will keep trying.

 

Put the EEDATA file into a ZIP folder before trying to attach to the forum. On Windows, this can be done by right-clicking the file(s) and then going to "Send To -> Compressed (Zipped) Folder."

The computer does not change anything about engine operation while connected. Connecting it only affects ancilliary systems such as the ABS, ASR and C68 Auto Climate Control. So at least in terms of the computer itself doing anything, that should not be the case as it is a passive device. However, if instead the question is, What would explain the car stumbling whenever ABS and ASR are active, that would be a more peculiar question. Technically ASR does have the ability to control engine timing up to a point, but if it were doing so you should see an "ASR Active" light come on in the DIC. If this light is not on, ASR should not be messing with timing.