What could cause this ?
05-31-2003, 07:00 PM
#1
TECH Resident
Thread Starter
Join Date: Jan 2002
Location: USA
Posts: 754
Likes: 0
Received 0 Likes
on
0 Posts
What could cause this ? Check this PCM data out,
you see out of the blue the right injectors pulse width of 549 mSecs and left is 158 mSecs and then goes right back to normal.
None of the other parameters such as MAP, MAF, etc show any large changes as RPMS and speed also the same, so what could cause this random problem to blip like this when the PCM has no DTC errors ?
you see out of the blue the right injectors pulse width of 549 mSecs and left is 158 mSecs and then goes right back to normal.
None of the other parameters such as MAP, MAF, etc show any large changes as RPMS and speed also the same, so what could cause this random problem to blip like this when the PCM has no DTC errors ?
05-31-2003, 09:54 PM
#3
TECH Resident
Thread Starter
Join Date: Jan 2002
Location: USA
Posts: 754
Likes: 0
Received 0 Likes
on
0 Posts
Re: What could cause this ? I measured the resistance of both wires to all 8 injectors and they all had the same resistance.
Also measured resistance of interal coil of injectors and they all matched.
Also weird is any decent lifting of TPS and LTFTs go right to +12 to +21 but STFTs stay close to zero and all On load trims cells avg +1.
Also notice the delivered torque doubles it's value even though speed, engine load and RPM were the same.
Something has to tell the PCM to command 100 times normal of what the pulse width should be, yet all the functions like MAP, MAF and TPS are reporting valid values.
Cruising up hill has better trim cell avgs then when going downhill ( less load) meaning high lean shows up much more going downhill.
These weird issues are so short in time that PCM does not even flag a pending DTC and being STFTs stay below +5 ( far within STFT window) but yet LTFTs go super lean but when that happens inj pulse width are below 2 mSecs.
Then out of the blue about 5 PCM cycles in a row report unreal pulse widths and is seen only once in about 40 mile drive.
Also measured resistance of interal coil of injectors and they all matched.
Also weird is any decent lifting of TPS and LTFTs go right to +12 to +21 but STFTs stay close to zero and all On load trims cells avg +1.
Also notice the delivered torque doubles it's value even though speed, engine load and RPM were the same.
Something has to tell the PCM to command 100 times normal of what the pulse width should be, yet all the functions like MAP, MAF and TPS are reporting valid values.
Cruising up hill has better trim cell avgs then when going downhill ( less load) meaning high lean shows up much more going downhill.
These weird issues are so short in time that PCM does not even flag a pending DTC and being STFTs stay below +5 ( far within STFT window) but yet LTFTs go super lean but when that happens inj pulse width are below 2 mSecs.
Then out of the blue about 5 PCM cycles in a row report unreal pulse widths and is seen only once in about 40 mile drive.
06-01-2003, 01:22 AM
#4
Restricted User
iTrader: (2)
Join Date: Dec 2001
Location: New Zealand
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
Re: What could cause this ? Hi John,
I'll have a stab at explaining the data - it's just a theory...
Based on the byte values and the number of bytes involved it looks like the scan tool has extracted data from the wrong dynamic packet.
Dynamic packets can carry up to 6 bytes and scan tools will try to pack all 6 bytes with data. Some PIDs are 8 bit values, some PIDs are 16 bit values meaning they take 1 and 2 bytes respectively to store in a dynamic packet.
It is commnon to store 3 x 16 bit PIDs in one packet.
I am assuming that the scan tool requested the PCM to pack: DELTQ, PWB1 and PWB2 into a single dynamic packet. That explains the first issue of why did those three PIDs' values all change at the same time - the link beteween those three PIDs, I believe, is that they are all transmitted in the same dynamic packet.
Secondly, what about their values? Given that I can't see the whole data stream I will only do the math for a single PID (BPW1) - here's what I beleive:
Another dynamic packet, which was packed with (among other PIDs) LTFT1 and LTFT2 was interpreted by the scan tool as the dynamic packet containing DELTQ, PWB1 and PWB2.
In the flash30-2.xls data you can see the following:
PWB2 is displayed as 549, to cause the scan tool to display PWB2 as 549, the raw data value must have been transmitted as the 16 bit value: $8C8A.
Look also at the LTFT1 and LTFT2 values:
LTFT1: 9.4, to cause the scan tool to display the LTFT1 as 9.4, the raw data value must have been transmitted as the 8 bit value: $8C.
LTFT2: 98.6, to cause the scan tool to display the LTFT2 as 8.6, the raw data value must have been transmitted as the 8 bit value: $8A.
Assuming the LTFT1 and LTFT2 were packed into a dynamic packet as two adjacent bytes (a reasonable assumption) then the resulting 16 bit value would have been $8C8A which is EXACTLY the value that I believe is being incorrectly used to calculate and display PWB2.
I would also assume that the other two PIDs: DELTQ and PWB1 can be explained the same way. I hope that made sense - if not let me know, I'll try to explain it more clearly.
Assuming that explanation is true (and it's just a theory), I guess the question really is: did the PCM pack the wrong values into the dynamic packet or did the scan tool mix up two dynamic packets? Without the raw data log we'll never know.
Regards
Paul
I'll have a stab at explaining the data - it's just a theory...
Based on the byte values and the number of bytes involved it looks like the scan tool has extracted data from the wrong dynamic packet.
Dynamic packets can carry up to 6 bytes and scan tools will try to pack all 6 bytes with data. Some PIDs are 8 bit values, some PIDs are 16 bit values meaning they take 1 and 2 bytes respectively to store in a dynamic packet.
It is commnon to store 3 x 16 bit PIDs in one packet.
I am assuming that the scan tool requested the PCM to pack: DELTQ, PWB1 and PWB2 into a single dynamic packet. That explains the first issue of why did those three PIDs' values all change at the same time - the link beteween those three PIDs, I believe, is that they are all transmitted in the same dynamic packet.
Secondly, what about their values? Given that I can't see the whole data stream I will only do the math for a single PID (BPW1) - here's what I beleive:
Another dynamic packet, which was packed with (among other PIDs) LTFT1 and LTFT2 was interpreted by the scan tool as the dynamic packet containing DELTQ, PWB1 and PWB2.
In the flash30-2.xls data you can see the following:
PWB2 is displayed as 549, to cause the scan tool to display PWB2 as 549, the raw data value must have been transmitted as the 16 bit value: $8C8A.
Look also at the LTFT1 and LTFT2 values:
LTFT1: 9.4, to cause the scan tool to display the LTFT1 as 9.4, the raw data value must have been transmitted as the 8 bit value: $8C.
LTFT2: 98.6, to cause the scan tool to display the LTFT2 as 8.6, the raw data value must have been transmitted as the 8 bit value: $8A.
Assuming the LTFT1 and LTFT2 were packed into a dynamic packet as two adjacent bytes (a reasonable assumption) then the resulting 16 bit value would have been $8C8A which is EXACTLY the value that I believe is being incorrectly used to calculate and display PWB2.
I would also assume that the other two PIDs: DELTQ and PWB1 can be explained the same way. I hope that made sense - if not let me know, I'll try to explain it more clearly.
Assuming that explanation is true (and it's just a theory), I guess the question really is: did the PCM pack the wrong values into the dynamic packet or did the scan tool mix up two dynamic packets? Without the raw data log we'll never know.
Regards
Paul
06-01-2003, 10:10 AM
#5
wrencher
iTrader: (2)
Join Date: Aug 2002
Location: Chicagoland
Posts: 4,762
Likes: 0
Received 0 Likes
on
0 Posts
Re: What could cause this ? EFIliveV5 is right cause Tech-2's do this also & GM tech's are pre-warned of this condition. The sugestion I have is, if you suspect a problem double check it with a digital storage ocilliscope/DSO. There is no data stream communications there just dead on/real time readings.
06-01-2003, 10:47 AM
#6
TECH Resident
Thread Starter
Join Date: Jan 2002
Location: USA
Posts: 754
Likes: 0
Received 0 Likes
on
0 Posts
Re: What could cause this ? dynamic packet theory does not work out as the problem.
1. This has been seen out of the blue on a car that never showed this before using the same PCM scanners.
2. the 2 slices shown above are from different days and PCM flashes, if it was a packet issue then other PIDs could also showup with incorrect values but in capturing this several times it is always injector PW and always B2 having the higher value.
3. The car clearly shows a problem since surging and bucking occurs.
4. Two different OBD-II scanners were used and both show the same high pulse widths.
5. LTFTs when in cells 2 and 6 average from +12 to +25 when all other cells are around +5 or less so its a repeatable problem that is ocurring at the same conditions which says its not a packet issue.
1. This has been seen out of the blue on a car that never showed this before using the same PCM scanners.
2. the 2 slices shown above are from different days and PCM flashes, if it was a packet issue then other PIDs could also showup with incorrect values but in capturing this several times it is always injector PW and always B2 having the higher value.
3. The car clearly shows a problem since surging and bucking occurs.
4. Two different OBD-II scanners were used and both show the same high pulse widths.
5. LTFTs when in cells 2 and 6 average from +12 to +25 when all other cells are around +5 or less so its a repeatable problem that is ocurring at the same conditions which says its not a packet issue.