People, I need your experienced help, cause I'm about to give up.
Bought C4, 88, L98 a couple month ago from a guy, who rebuilt engine, put there upgraded cams (and probably something else, he didn't mention what exactly). Additionally, he gave me custom chipped ECM (Motorvation, custom build 7777), but didn't install it and didn't tell what is inside of it, so car currently is on stock ECU.

Since the beginning. car was idling rough hot and cold. And after some travel (about 5 mins) - engine starts chocking a bit and then Code 33 appears. After that car starts to drive
very badly and rough.
I changed IAC - no difference. Then I bough OBD1 from reddevilriver, but scanner didn't show anything bad, except that coolant temp sensor is showing pretty low temp (100F ECU and 160F gauge) and the car is not switching to closed loop even after 20 mins drive.
Then I changed TPS. Coolant temp sensor and both MAF relays - car started idling and driving better when cold, temp now is way more accurate, but still same problems when hot.
I bought Service manual and made a test steps from the diagram - it showed that seems like MAF is broken.
Finally, I replaced the MAF today. After short warm up to check if everything working and restarting the engine - it showed code 36 one time, but since then - never showed again. It became idling and driving perfectly when cold and hot during my 15 min test drive. I was almost happy. BUT !!! On one of the intersections - engine bacame chocking and SES (code 33) appeared again, and car behavior became waay worse.

I don't know what to think now - I changed everything to the new and still having this issue. Could it be the problem with ECU vs upgraded cams? Almost giving up :/


Driving

O2 at the beginning

 

In your log file, check the maf while the throttle position is in the vicinity of 1.10 volts (or less) with rpm < 2200. Flow > 45 gm/sec under these conditions will set code 33. Do you have an aftermarket throttle body?

 

The throttle body is stock. I didn't connect scanner during last drive because I found that immediately when I connect scanner when engine is running - idle increases from 800 to 1000. If I disconnect it - it drops from 1000 to 800 stable. Looks like scanner affects somehow the measurement. But let me try again

 

Scanning at 160 baud will set the idle to 1000 rpm. This is normal, but annoying.

 

Checked yesterday and logged the error (graph below). It happened during the red light stop - SES Code 33 appeared (still not logged in ALDLdroid for some reasons, but logged with paperclip). In the graph - it is in the center. Doesn't seem like anything wrong metrics for MAF there (?), but I didn't get, why IAC started to increase itself (data point 823-841), without TPS change and without affecting RPM, when I was just standing and idling. Could that be related to this issue? (I changed IAC last month to the new one).

Also, one additional symptom appeared, but it was a single time only as for now - when I came back and was idling in the driveway - the engine started chocking and stalled. I cranked, it stated and then immediately stalled. I checked fuel pressure during this choke and it was dropping from 40 to 5-0 almost immediately. I cranked it again in 10 mins - started perfectly without hesitation and pressure was 35-40.

Those car gremlins are annoying :/

 

At 160 baud you will miss much of what's going on due to the slow sample rate. You're welcome to try one of my old 8192 baud adx files with ALDLdroid (attached to the link below):

https://www.corvetteforum.com/forums...post1600929509

You want to look at the unlimited airflow signal since the regular maf signal is limited with respect to rpm and may mask the issue if it should occur below 1200 rpm.

The IAC is attempting to control the idle to 1,000 rpm between 823 and 841. You just can't see what the rpm is really doing between the samples. It is likely dipping below 1000 rpm which is causing the IAC to increase in order to compensate for the control error.

Regarding error codes: check the corresponding *.csv file. Not sure if ALDLdroid can display bitmask labels (rather than numerical values) directly when viewing data logs within the app. You may need to edit the adx file in order to display 1 or zero instead of the text labels. Alternatively, you could use TunerPro to view the corresponding *. xdl file.

 

Ok, so some updates here (unfortunately, without solution yet). Thanks to @tequilaboy 's adx file - I got better picture (graph + metrics), which finally tracks error and closed\open loop.
1. I cleaned all grounds (literally, walked across the whole ground diagram to find them)
2. I cleaned all connectors in ECU, around ECU and sensors.
3. I replaced ECU to the one, which previous owner ordered from Motorvation (they shared with me what he ordered - it is custom chip with modification Cam (Comp Cams) 206-210-112 24 lb/hr inj 160* thermostat). Car started terribly and stalled many times during idling - there was a lot of exhaust smoke and even there was a steam coming from right engine header. Hence, I replaced ECU back to the original.
4. I replaced both MAF relays
5. I replaced MAF, O2 sensor, IAC, TPS and coolant sensor (which goes to ECU).
With each fix car drove better, but only before error appears.
I noticed that each time error pattern is the same - starting car, idling for 1 min, driving few mins perfectly, then immediately I feel loss of power for a few seconds, and then error 33 appears. After that car drives terrible - kicks from red light start, kicks when releasing throttle, and in general the ride is rough.
If I restart the engine - everything appears in the same way - rides few mins perfectly, and then loss of power, error 33.

Diagram and metrics has the same pattern - the MAF increases drastically for a second or two till 48 with engine at 1650 revs, and then drops -> error 33 appears. I really doubt that this is a bad electrical contact, since the pattern and the location of the issue the same each time.
Also, now after car restart - error 36 appears, but I replaced all relays.

Need some help :/

Here is the example of the issue (diagram + metrics + attaching the csv file) - time - 270-280 sec

 

Here is your issue (shown graphically from your csv file):

https://datazap.me/u/tequilaboy/code...2142-2093-2103

Note the 3 yellow markers.

The first marker is when the maf first exceeds the 45 gm/sec error threshold (for tps < 14.8% ~1.1 volts) which starts the error detection process.

The second marker (1.3 seconds later) is when the actual maf signal is replaced by the default airflow calculation due to detection of the error. Note the significant drop. You can also see the deviation develop between the maf and unlimited airflow signals here and that the unlimited airflow signal is frozen after this point which serves as an obvious failure indication. The third marker is where the error code 33 is finally transmitted.

Once the maf signal drops (to the default airflow calculation) as the error is detected, the car runs very lean as indicated by the O2 sensor voltage. This is what causes the rough running. It remains lean despite the increasing fuel trim values. See BLM and Integrator signals following the error.

My conclusion is that your car has an unusually large appetite for air flow with respect to the tps. The default air flow calculation is not perfect, but it should be pretty close to the actual maf signal under normal conditions (subject to modifications). The default air flow calculation (model) is generated by the tps load axis, rpm and IAC position plus a 4 gm/sec offset that represents the closed throttle airflow, it is then limited by the normal max maf vs rpm table.

You have some options:

1. Investigate why the car needs so much air for a given tps voltage. Tps voltage/throttle position/throttle body are all suspect.
2. Raise the 45 gm/sec error threshold in the tune so it won't be likely to set without an actual (open circuit) failure.
3. Tune the default airflow calculation to more closely resemble the actual maf signal so that it will still run acceptably if the failure is set.

 

Wow, thanks for the analysis! Really appreciate!

I have that tuned ECU with Motorvation chip, which I can potentially erase and replace with factory settings, but change the MAF error threshold, which you recommended (just don't know yet where to find default\factory firmware (settings) which I can use as a base for that chip)

Regarding unusually large appetite for air flow - I started to think that this could be due to modified Cam (Comp Cams) 206-210-112, which previous owner installed -> maybe it has bigger intake valve lift to get more air (?). Previous owner also gave me Comp Cams valve springs, which he didn't install before selling. Maybe stock springs have valve closing lag which also can cause additional air coming to the cylinder (just guessing?).

Need to try both - chip and springs change.

 

Are you sure that you don't have any dead cylinders or extremely high accessory load? Sure its not a stroker or a large displacement small block? Any holes in the throttle blades? A few over-adjusted valves (always open) could cause huge pumping losses without contributing to power production. Retarded or advanced timing? Incorrect cam timing? Maybe try running it without the belt temporarily to eliminate the accessory load.

Just throwing out some ideas that could cause the excessive air (and fuel) flow.

Check the manifold vacuum and ignition timing at idle. This should provide some clues. 20°/20 inches (hg) of vacuum expected with EST connected. 6° and reduced vacuum with EST disconnected.

There should be a direct but inverse correlation between the manifold vacuum and maf (or more accurately load). I suspect that you will find that the manifold vacuum at idle is less than 10 inches. The cam alone is not big enough to explain this. There is something else going on.

 

Here you can see the IAC position and (4 gm/sec) offset contribution to the default air flow calculation in isolation (independent of rpm) following ignition off during the IAC reset routine:

https://datazap.me/u/tequilaboy/code...4407-4415-4398

Kinda cool to see this effect.

 

@tequilaboy , trying to adjust the MAF code 33 threshold. Do you have by any chance the proper .xdf file which will be compatible with '88? (your .adx worked perfectly, so I was thinking that you have similar .xdf).
Also, what will be the proper key for this parameter in parameter tree?

Also attaching the bin file
I loaded the $6E and $1F from TunerPro site, and in both xdf I see this stock of Maximum AirFlow vs RPM parameters, which for me looks odd:

 

You need to use a $32B xdf file for both 87 and 88 bin files.

• $1F for 85 only
• $32 for 86 only
• $32B for 87-88
• $6E for 89 only

 

Now I'm a bit confused. Stock bin started to show proper value in TunerPro with $32B, but ANZA.bin and ARAP.bin (which I planned to use) started to show odd values (but showed good, when I used $F6 with them).
Does it mean that I can't use ANZA.bin or ARAP.bin with '88 ?

 

Your stock $32B bin is ACKY, but it looks a bit strange.

The working bin file should only be 16kb. The file that you uploaded is 64kb and is actually comprised of (4) 16kb files stacked on top of each other. I split the 64kb file into (4) 16kb files, but they still show some differences (39 bytes) with respect to the ACKY file that I have, so it appears that some editing has already been done to your stock file.

The 165 ecm can run $32, $32B and $6E (and even a few more) masked bin files. However, when working with a particular file, you must use the appropriate xdf file or the data and addresses wont line up properly. You can't mix and match bins and xdf files, but you can run different bins in the ecm itself.

I would suggest that you stick with $32B and get used to working with mild variations of your original bin file, before jumping to a different mask and bin altogether like $6E. What complicates things a bit is the fact that your stock bin looks a bit screwy at the moment. Double check your programmer address settings and eprom. Is your original eprom a 27C128, 27C256 or something else? Trying to understand how you ended up with a 64 kb file.

Are you using ALDLdroid to read the chip? If so, I have not had good results reading and programming with ALDLdroid. It seems that the start and end addresses always get screwed up somehow.

I attached one of the split bins and will add acky, but looks like that file needs to be split as well

 

Thanks for the details!

I'm using BoostedNW for read and write, and TunerPro RT for adjustment.
My chip is 27C128, and I read it initially as 27SF512 (which is probably my mistake, but it was readable in $32B which you shared originally). Now I changed it to 27C128 in BoostedNW. The Bin now is 16kb (I attached it to this message), but it is not readable with $32B - values are constant across most of the tables.

 

I see that something has gone wrong reading the "proper_stock.bin". The 27C128 eprom is a 16kb eprom. The 16kb bin file should reside between 0000 and 3FFF. Check the start/end and buffer addresses in the programming utility.

PM sent

 

Ok,so seems I fixed it! Kudos to @tequilaboy for tremendous help and education!
So the reason for code 33 in my case was high air appetite in the engine, probably due to modifications done by previous owner (cams, fuel rails, etc). I increased the threshold for MAF sensor from 45g\l to 100g\l and now there is enough threshold gap to avoid triggering of the error and dropping settings to the default due to high engine air appetite. Worth to mention that I replaced all sensors before diving deep into the chip tuning - MAF, IAC, Coolant temp, TPS, both MAF Relays, cleaned all grounds and connectors -> that improved car behavior, but didn't fix the main issue.

Lesson learned:
-Proper OBD1 reader and Service Manual is a must for proper debugging. Without it - it would be very hard to identify the high air flow to the engine in medium revs range
- Memcal needs to be attached in my case with the chip. Without memcal - ECU can start the engine in any .bin, but it runs terrible and throwing "code 41" related to the cylinders count issue
-My stock Chip (shitsplit4.bin) was not actually stock, but instead it was Hypertech Street Runner 128881 Stage 1 tune (I found lebel which fell of initially). It is 3-11% (AFR - 13:1) leaner than stock in power enrichment mode.

I tested both .BINs - shitsplit4.bin (hypertech stage1) and "ACKY 88 vette 5.7TPI 700r4 with 3.07 or 2.73 gears split1.bin" (stock ACKY) with changed MAF threshold in different modes (idle, acceleration and different rev ranges).
I feel that hypertech stage 1 is more aggressive and has a better acceleration on high speeds, but ACKY works way smoother. Probably will change them back and forth, depends on the mood

I attached ADLDroid graphs for both .bin just for the reference.

Thanks again!

Hypertech stage1

ACKY stock

 

ACKY log data: https://datazap.me/u/tequilaboy/ailv...2-12&mark=2262

Note: The original csv file was split into two log files due to datazap limitations. Both logs are included above and can be viewed individually.

Looks like a threshold of about 75 gm/sec would work. The 100 gm/sec threshold that was tested should provide plenty of safety margin and still protect for an open circuit failure. I would like to see some WOT data to see if you're running into MAF and/or injector limitations, but be careful, since it may lean out if that is the case.

 

Houston, we have a problem: https://datazap.me/u/tequilaboy/ailv...25-670-662-638

Your maf is already being limited by the max maf vs rpm table causing it to run lean at part throttle.