First real test drive today, after V8 swap.

[Road Trip]

[Warning: Broken Record Alert]

Connect a friggin' scan tool, find out what the computer wants you to know. If your fuel pressure is low, or you have the wrong injectors, the fuel trims should be screwed-up. If the knock sensor is unhappy, the knock counts will be high. If the TPS, or the CTS or whatever is messed-up, it'll show on the data stream. This engine have an AIR pump? If it doesn't divert to the air cleaner as the engine warms-up, it'll freak-out the O2 sensor.

Make sure the EGR is plumbed and wired correctly. Did you source the correct PCV valve? But if there's a strong vacuum leak, the IAC counts will be off, and maybe the fuel trims too.

This engine is crying out for a scan tool.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

{Warning: TLDR Alert}

Greetings @DeCaff2007,

I've taken an interest in your project for a couple of reasons. First, anyone who refuses
to give up on a project until it is successfully completed is a kindred spirit, and deserves
whatever help I can provide.

Second, your 4.3 > 5.7 upgrade project is complex enough that it would be a perfect case
study for the benefits of a structured Analytic Troubleshooting approach. I was fortunate
enough to spend my entire career troubleshooting, 2/3 hands on, and the remaining 1/3
training others. (lecture/lab civilian, OJT on a military flightline)

If possible, I'd like to help demonstrate to enthusiasts that are new to the hobby of driving
old that a disciplined, analytic troubleshooting approach is a valuable tool that folks should
consider adding to their skill set. (IMHO, this approach will help you nearly everywhere in life...)

****

Troubleshooting stuff you are intimately familiar with requires just getting sync'd up
with the problem du jour in front of you, and pretty much letting your muscle memory
take over. No jawboning, just get elbows deep and make it happen.

This is the show that The Elders put on while they worked, and it was obvious while you watched them
in action. It was as entertaining to see them ply their craft as watching any magician on stage in Vegas.

But for me, troubleshooting in a less familiar arena requires a more formal, more disciplined approach in
order to be successful.** This is because when you are intimately familiar with a machine, you pick up
on subtle cues that others miss, and further know which small handful of cues are truly important,
and also that the majority of operating sounds are literally background noise of no troubleshooting
consequence.

Instead, on 'new to me' machinery I feel like I've lost my hearing, and yet I find myself sitting in the
good seat in front of a highly resolving SOTA audio system...and others want me to pick out
subtle sonic differences between 2 different vacuum tube preamps. :0)

So this is when those around me see me shift gears mentally, and observe me trying to quantify the
quality of the data that we are collecting, or advocating for careful failure data collection, and then
following that data wherever it leads us.

****

Q: So where am I going with all this?

A: Schurkey is well known for advocating that when a new GMT400 owner pops in here and asks for help
(diagnosing a complex powerplant under the computer-controlled Closed Loop) ...after already replacing
a laundry list of parts & no joy...his trademark response is to ask the OP to get a scan tool involved.

Not a code reader, but a live data capable tool that allows us to look inside the Closed Loop data streams
while it is operating. It takes the troubleshooting from a WAG/SWAG level to employing a more formal
Scientific Method.

One complication that you see in this hobby is that a lot of times someone who is a guru on all things
mechanical is not as well versed in analog electricity/electronics. Meanwhile, an older analog guru freezes
up when confronted with control data that's laid out in hexadecimal. And finally, the next generation
computer geeks who love nothing better than to roll around in databases simply haven't had the
opportunity to get much real world 'hands-on' experience with mechanical stuff.

In pre-emissions purely mechanical computer days (think muscle car camshaft + carburetor + distributor)
the better mechanics had no problem making an engine bend to their troubleshooting will. But even
then, while many of the same mechanics wouldn't hesitate to help fix a knocking engine, by the same
token they wouldn't be nearly as keen to jump into a tough electrical issue. (Like the '68 Fury III that will start
if you drive it every day...but if you let it set over a long weekend, there's no joy? WTF? :0)

...but I digress. To be perfectly candid, it goes without saying that as a grandfather I am all for cleaning up the
HC & NOx emissions as much as possible. But the way that these mandated emission-reduction goals were
implemented in the typical GMT400 engine bay, the successful mechanic has to bring a winning combo of mechanical,
analog, and computer chops to the table. And it was tough enough when these trucks were brand new...but
those that are reading this like a challenge, so here in the GMT400 forum we've added the following to the mix:

* The engine bays in the oldest '88 vehicles are now *36* years old.
* Due to the engine upgrade, this individual combo of engine bay/computer/350 doesn't provide the
troubleshooting jumping off point of a previous moment in time where this all once interoperated 100%?
To me, this moves the troubleshooting effort from a pure 'repair back to original state' to a 'sort out a brand
new creation'? (This means that we must consciously keep all possible combinations of unknowns affecting
other unknowns on the table until otherwise proven good.)
* And instead of working shoulder to shoulder, we insist on collaborating remotely on this problem child while
literally spread out around the world? Talk about yet another layer of communication complexity?

Given the above, in order to be successful, the GMT400-linked mechanic actually needs these *6* skillsets:

* Mechanical
* Analog electric / electronic measurement skills, and able to compare what they measure to what is documented.
* Some Digital chops
* Above average reading for comprehension / writing skills (to enable/support the remote troubleshooting team)
* Ability to compose/take/upload well-lit, sharp photos with enough depth-of-field to show all relevant detail.
* A side order of ambassador skills when the inevitable 'flare ups in the talent pool due to frustration' occur. :0)


And here's a short, incomplete list of items that slow down/block progress:

* Frustration leading to negative emotional reaction. To anything. (Tough to do when you are a human.)

* Not cross-checking/validating failure info to the maximum extent possible before following it
down the garden path.) Examples include running the wrong firmware revision in the scan tool
you are relying upon > wrong cylinders identified for misfires, aged electric oil pressure gauges
lying about hot idle oil pressure, off-brand sensor(s) sending erroneous signals to computer,
wrong computer sourced from Treasure Yard that almost, but doesn't quite match the engine
in the engine bay, etc.

There are a *lot* of individual links in the success chain in this troubleshooting scenario, so you almost
need to invoke a 'chain of custody' mindset when reviewing/analyzing the failure data set. (Chain of Custody)

* Folks more interested in maintaining some perceived pecking order vs actually fixing stuff.
(Thankfully absent here in the GMT400 forum. Other forums? Not so much. :0)

****

So what does all this mean to you?

Schurkey is giving you not just sound, but profound advice.

We've already discussed that you & I are both forced to work under the super frugal rulebook, but
frankly we've just about exhausted what we can sort out using old school pre-emissions troubleshooting
tools & skills.

So however you can achieve the best bang for the buck when it comes to acquiring a live data scan tool,
then this is the next thing that needs to happen. Just like when you are working with piston wrist pins,
if you don't have the right tools on hand, you simply won't end up with a successful outcome.

Tools are how mechanics cheat to win, and can repair vehicles that normal folks can not. If it helps to
take some of the sting out of the scan tool acquisition, buy the tool in such a way that after you have
used it, down the road when the time is right you can turn around and sell it. Do this correctly, and
the all-important 'Price Per Use' metric will end up being a very affordable, easy justifiable number. (!)

For what it's worth. Looking forward to when you (& the combined efforts of all the talent in the GMT400
forum) get this project propelled over the Finish Line.

As The Elders used to tell me, "Nothing Good is Easy."

****

(Troubleshooting Appendix)

**Short story version. I went from entry level parts cannoneer (battle cry: "Fix machine, Get banana!")
to the support ranks after being formally exposed to the Kepner-Tregoe Analytical Troubleshooting training.
(Here and Here) Disclaimer: I don't own stock in K-T, never worked for them, etc. But back in late '87
I was introduced to their method, and it literally changed my professional trajectory for the better.

Truly good stuff, and well worth your consideration.

 

[L31MaxExpress]

^^^^^^^^^^^^^^^^^^^^^^^^^^^

{Warning: TLDR Alert}

Greetings @DeCaff2007,

I've taken an interest in your project for a couple of reasons. First, anyone who refuses
to give up on a project until it is successfully completed is a kindred spirit, and deserves
whatever help I can provide.

Second, your 4.3 > 5.7 upgrade project is complex enough that it would be a perfect case
study for the benefits of a structured Analytic Troubleshooting approach. I was fortunate
enough to spend my entire career troubleshooting, 2/3 hands on, and the remaining 1/3
training others. (lecture/lab civilian, OJT on a military flightline)

If possible, I'd like to help demonstrate to enthusiasts that are new to the hobby of driving
old that a disciplined, analytic troubleshooting approach is a valuable tool that folks should
consider adding to their skill set. (IMHO, this approach will help you nearly everywhere in life...)

****

Troubleshooting stuff you are intimately familiar with requires just getting sync'd up
with the problem du jour in front of you, and pretty much letting your muscle memory
take over. No jawboning, just get elbows deep and make it happen.

This is the show that The Elders put on while they worked, and it was obvious while you watched them
in action. It was as entertaining to see them ply their craft as watching any magician on stage in Vegas.

But for me, troubleshooting in a less familiar arena requires a more formal, more strict approach in
order to be successful.** This is because when you are intimately familiar with a machine, you pick up
on subtle cues that others miss, and further know which small handful of cues are truly important,
and also that the majority of operating sounds are literally background noise of no troubleshooting
consequence.

Instead, on 'new to me' machinery I feel like I've lost my hearing, and yet I find myself sitting in the
good seat in front of a highly resolving SOTA audio system...and others want me to pick out
subtle sonic differences between 2 different vacuum tube preamps. :0)

So this is when those around me see me shift gears mentally, and start to see me try to quantify the
quality of the data that we are collecting, or advocating for careful data collection, and then following
that data wherever it leads us.

****

Q: So where am I going with all this?

A: Schurkey is well known for advocating that when a mechanic (who's diagnosing a complex mechanical
engine bay under computer-controlled Closed Loop operation) hits an impasse after replacing a laundry
list of parts...he consistently asks to get a scan tool involved.

Not a code reader, but a live data capable tool that allows us to look inside the Closed Loop data streams
while it is operating. It takes the troubleshooting from a WAG/SWAG level to employing a more formal
Scientific Method.

One complication that you see in this hobby is that a lot of times someone who is a guru on all things
mechanical is not as well versed in analog electricity/electronics. Meanwhile, an older analog guru freezes
up when confronted with control data that's laid out in hexadecimal. And finally, the next generation
computer geeks who love nothing better than to roll around in databases simply haven't had the
opportunity to get much real world 'hands-on' experience with mechanical stuff.

In pre-emission purely mechanical computer days (think muscle car camshaft + carburetor + distributor)
the better mechanics had no problem making an engine bend to their troubleshooting will. But even
then, while many of the same mechanics wouldn't hesitate to help fix a knocking engine, by the same
token they wouldn't be nearly as keen to jump into a tough electrical issue. (Like the '68 Fury III that will start
if you drive it every day...but if you let it set over a long weekend, there's no joy? WTF? :0)

...but I digress. To be perfectly candid, it goes without saying that as a grandfather I am all for cleaning up the
HC & NOx emissions as much as possible. But the way that these mandated emission-reduction goals were
implemented in the typical GMT400 engine bay, the successful mechanic has to bring a combo of mechanical,
analog, and computer chops to the table. And it was tough enough when these trucks were brand new...but
those that are reading this like a challenge, so they add the following to the mix:

* The engine bays in the oldest '88 vehicles are now *36* years old.
* Due to the engine upgrade, this individual combo of engine bay/computer/350 doesn't provide the
troubleshooting jumping off point of a previous moment in time where this all once interoperated 100%?
To me, this moves the troubleshooting effort from a pure 'repair back to original state' to a 'sort out a brand
new creation'? (This means that we must consciously keep all possible combinations of unknowns affecting
other unknowns on the table until otherwise proven good.)
* And instead of working shoulder to shoulder, we insist on collaborating remotely on this problem child while
literally spread out around the world? Talk about yet another layer of communication complexity?

Given the above, in order to be successful, the GMT400-linked mechanic actually needs these *6* skillsets:

* Mechanical
* Analog electric / electronic measurement skills, and able to compare what they measure to what is documented.
* Some Digital chops
* Above average reading for comprehension / writing skills (to enable/support the remote troubleshooting team)
* Ability to compose/take/upload well-lit, sharp photos with enough depth-of-field to show all relevant detail.
* A side order of ambassador skills when the inevitable 'flare ups in the talent pool due to frustration' occur. :0)


And here's a short, incomplete list of items that slow down/block progress:

* Frustration leading to emotional reaction. To anything. (Tough to do when you are a human.)

* Not cross-checking/validating failure info to the maximum extent possible before following it
down the garden path.) Examples include running the wrong firmware revision in the scan tool
you are relying upon, aged electric oil pressure gauges lying about hot idle oil pressure, off-brand
sensor(s) sending erroneous signals to computer, wrong computer sourced from Treasure Yard that
almost, but doesn't quite match the engine in the engine bay, etc.

There are a lot of moving parts in this troubleshooting scenario, so you almost need to invoke a
'chain of custody' mindset when reviewing/analyzing the failure data set. (Chain of Custody)

* Folks more interesting in maintaining some perceived pecking order vs actually fixing stuff.
(Thankfully absent here in the GMT400 forum. Other forums? Not so much. :0)

****

So what does all this mean to you?

Schurkey is giving you not just sound, but profound advice.

We've already discussed that you & I are both forced to work under the super frugal rulebook, but
frankly we've just about exhausted what we can sort out using old school pre-emissions troubleshooting
tools & skills.

So however you can achieve the best bang for the buck when it comes to acquiring a live data scan tool,
then this is the next thing that needs to happen. Just like when you are working with piston wrist pins,
if you don't have the right tools on hand, you simply won't end up with a solo successful outcome.

Tools are how mechanics cheat to win, and can repair vehicles that normal folks can not. If it helps to
take some of the sting out of acquisition, buy the tool in such a way that after you have used it, down
the road when the time is right you can turn around and sell it. Do this right, and the all-important
'Price Per Use' metric will eventually be a very advantagous number. (!)

For what it's worth. Looking forward to when this project is propelled over the Finish Line.

****

(Troubleshooting Appendix)

**Short story version. I went from entry level parts cannoneer (battle cry: "Fix machine, Get banana!")
to the support ranks after being formally exposed to the Kepner-Tregoe Analytical Troubleshooting training.
(Here and Here) Disclaimer: I don't own stock in K-T, never worked for them, etc. But back in late '87
I was introduced to their method, and it literally changed my professional trajectory for the better.

Truly good stuff, and well worth your consideration.

Then you also have to add in the aspect that the engine is not stock. Not only will it need troubleshooting, it needs actual tuning. The timing and fuel delivery tables are probably not even close to what the engine wants now that the TBI heads are off the engine. The fuel system needs to deliver adequate fuel to the engine near the pulsewidth it was calibrated to run at from the factory and the timing advance curve will need more timing to compensate for the slower burn of the non-swirl port intake port equipped heads. Swirl port head only needs about 26* total timing where a non swirl port head will need more than 30 and perhaps as much as 36-38*. The ECM will also need adjustments to acceleration fuel pump shot to compensate for the increased plenum area and wall surface area of the larger 4bbl manifold and higher airflow though the engine. Crank up the fuel pressure to feed it at WOT and the engine will over-fuel with the throttle plates closed at idle or just off-idle when the volumetric efficiency is near stock because of the minimal airflow flowing through the throttle plates.

 

[L31MaxExpress]

BoostedNW has taken over with a similar product line to what Craig Moates offered. I do not know how well his products function, because I have never used them. Unless you can find used Moates stuff like an Autoprom or Ostriche or even a Burn1 and a datalogging cable, BoostedNW is the only source I know of still in the OBD1 GM ball game.

GM TBI/TPI OBD1 Tuning Starter Kit

boostednw.com

In the right hands, TunerProRT with the correct definition files for both editing and capturing data from your specific ECM operating system are the most powerful tools you can have. Far better than the same money tied up in an antiquated scanner setup that can only read the datastream.

 

[Orpedcrow]

I haven’t looked personally but I’m willing to bet the FSM has values listed for all the sensors and step by step procedure for verifying their operational range with a simple volt-ohm-meter.

You’ll also need some t-pins or even just sewing needles work for back probing live connectors. Alligator clips help.

Of course it takes more time than just connecting a scan tool and watching live data but it is a good skill set to look into for the frugal diy mechanic.

 

[termite]

Depening on willingness to dive in and learn, tunerprort and an aldl cable could be an option as well.

 

[Road Trip]

I haven’t looked personally but I’m willing to bet the FSM has values listed for all the sensors and step by step procedure for verifying their operational range with a simple volt-ohm-meter.

You’ll also need some t-pins or even just sewing needles work for back probing live connectors. Alligator clips help.

Of course it takes more time than just connecting a scan tool and watching live data but it is a good skill set to look into for the frugal diy mechanic.

I share your mindset about gaining access to live signals when working on a stubborn
problem that's resisted all previous attempts to repair. Of course when you mention
this in polite company this really seems to raise the eyebrows. Or raise the hackles
of seasoned mechanics who have worked through tough intermittents that were
eventually traced back to 'looks good on the outside, corroded wires on the inside'
engine bay harnesses.

But since I'm no longer held to a strict aerospace rulebook, for all the vehicles I work
on currently I'm actually moving from backprobing to piercing. But instead of
leaving behind entry points for corrosion here in the rust/corrosion belt, each and every
piercing is treated to either liquid electrical tape (LIQUID ELECTRICAL TAPE) ...or in
a pinch, clear nail polish.

And here's a good article discussing the pros & cons of backprobing vs piercing.
(Real world underhood data collection)

Based upon the situation you find yourself in, sometimes you have no choice but
to gather the data any way you can. But it *can* be done without leaving behind
an unreliable, unsupportable mess.

 

[Orpedcrow]

And here's a good article discussing the pros & cons of backprobing vs piercing.
(Real world underhood data collection)

That was a good read.
I wasn’t aware that the probing vs piercing was a controversial topic Makes sense that it would be though, like crimping vs soldering.

I have one of those yellow twist on piercing deals, it works great. Much better than trying to stab a probe into a wire, the probe rolling off of said wire and stabbing the …. out of the wire supporting finger tip behind it.

 

[Schurkey]

OK, if we're going there...

If you have to do it the hard way--with a multimeter, or better yet a graphing voltmeter/oscilloscope--do it near the computer, inside the cab--no road splash behind the glovebox. The wires haven't been exposed to engine heat, so the insulation is probably in better condition to begin with.

As a further benefit, you're testing most or all of the associated wire harness connecting the sensor to the computer.

You will have to be careful to choose the correct wires to pierce or back-probe, depending on which sensor(s) you're testing.

Expect it to take ten-plus times as long to do this compared to using a scan tool. And it doesn't confirm that the computer is receiving and processing this data, which you'd get with the scan tool.

But it should catch "most" sensor problems.

 

[DeCaff2007]

Ok wow... I'm about to just bolt the FACTORY HEADS back on! I don't have patience nor knowledge to go measuring this or back probing that, especially when the wiring in this Heap is a joke to begin with.

I'm going to try ONE more thing before the stock heads find their way back on this engine. It's been suggested that I bump the timing up a few degrees and see what difference that makes.

Sorry, but I'm not getting into ECM tuning.

 

[Schurkey]

Ok wow... I'm about to just bolt the FACTORY HEADS back on!

I expect you'll have an engine that runs just as bad, has cost more in additional gaskets, supplies, etc, and weighs more.

Zero benefit. Wasted time, money, effort, and enthusiasm.

I don't have patience nor knowledge to go measuring this or back probing that, especially when the wiring in this Heap is a joke to begin with.

If you're not willing to diagnose, take it to someone who can.

It's been suggested that I bump the timing up a few degrees and see what difference that makes.

Worth a shot.

Sorry, but I'm not getting into ECM tuning.

Screw "tuning" at least for now.

Find someone to figure out why the engine runs bad. "Tuning" may be part of that, but it's almost certainly not the whole story. Something is WRONG, and you're putting your head in the sand.