As for the suspected 1688 fault—-not sure how I would even go about ‘testing’ it.

Yeah… that’s a big problem. There are MANY bit oriented ‘fault’ PIDs that can/could be tremendously helpful if they can be sorted out. But they are _ALL_ hard to VERIFY. I’ve unplugged the Evap Purge valve – drove with gas cap off – ran with MAF, CMPs, Oil Temp Sensor, (certain) O2 sensors, and all sorts of stuff ‘unplugged’ to see what happens!. But even as eccentric as I am, I wouldn’t pull the IM to screw with the CHT sensor just to see what happens.

ADDITIONALLY, there are probably fifteen ‘FMEM” (Failure Mode Engine Management) mode indicator flags that would be MOST helpful for diagnosis if they can be verified / identified / trusted. The OBDII design is intended to /keep the vehicle running even if in a limited mode. I think many loss of power or performance complaints could be attributed to one of these things. ie: TOFMEM – Transmission over Temperature FMEM, EGRFM – EGR System in MFEM, TCCFM – Torque Converter Clutch unlocked (FMEM) due to excessive slip, and several other useful ones. ///MANY of these are in PIDs 1105, 1106, and 1107/// Then the engineers stuck ‘shift solenoids 1,2,3 in PID 1105 amongst them to confuse things. I notice your in your linked spreadsheet – Shift Solenoid 1 Control – SS1 (1105 b4) is on – but all the Others are zero. So these PIDs are applicable to your vehicle – and none of the mentioned problem flags exist in your scan run.

If you were to create a custom PID 06A20B or 06A20C (Cylinder 1 Misfire Events for CAN) and press the “TEST” button on the custom PID

I have done this. As best as I can tell – the program design concept of Torque is to send individual requests in a continuous loop. This is, to some degree, contrary to the ‘design intent’ of Mode 06, which (I believe) is to send One -test result – response stream per request. As a result (I believe), Torque seems to end up stepping on its shoe strings and stumbling. The session disconnects and the vehicle icon starts flashing. After a moment, it (vehicle icon) will reconnect and go steady again. —– Of course nothing changes on my screen (basically because my truck does not suffer ANY misfires). It will routinely go 40,50 or even 70 drive cycles without a single (post 1000 rev) misfire.

Since your vehicle ‘responds’ AT ALL to PID # 160[1-8], I think the PIDs ‘WORK’ on your version of PCM software. IDK, but likely the ‘current drive cycle and only for ‘post 1000 rev misfires’.

But I would re-emphasize (NO malice intended), that I think your concerns about dynamic misfire monitoring are misplaced. The Mode 6 report and the PIDs reporting ‘conditions present’ at the time of the last misfire (detailed in my post of 03/03/2017 on page 2 above) are likely more helpful in resolving misfire issues than are dynamic monitoring of misfires – when they occur. As for ‘why’ they occur, isn’t it more what else is going on at the time that’s more important than ‘simply when they occur’? Could this be WHY 160[1-8] is removed from my model PCM software? There are ‘plenty’ of other great live data PIDs available for live data monitoring that can be causing misfires. Just MHO.

But I DO have healthy respect for your curious, inquisitive nature. Check your private email.

—————

54371019

I don’t believe Mode 06 uses the CID for
requests. When a TID has additional CID
data, in your case individual cylinders,
your ECU will respond with all that apply
with that TID.

The standard does provide data rate
capability for certain services… maybe you
accidentally sent a form of one of the
requests which activated the additional
responses.

Or maybe other modules are responding
to the same pid.

I really believe Ian is sending a single request
looking for a single response except in
cases of functional addressing where multiple
modules could respond or using a global type
header requesting all modules with the pid
to respond.

As always… my understanding could be wrong.

Did you guys ever come to a conclusion as to whether we could access this information?

I actually started Googling this because I had an idea how to get which cylinder was misfiring using the misfire counter and crank position sensor? From what I gathered reading this thread up to now is that this wouldn’t be possible because there is a pretty serious delay between when a misfire is detected and when it is reported? 500 milliseconds if I recall correctly?

If there is no way to get this info from the pcm I’d bet I could MacGyver something up with an accelerometer a knock sensor and an Arduino. Though I’d still need to read that crank position sensor data at the very least.

Anyway thank you guys for the work you’ve put in to this point. It was a very interesting read even if I’m more of a tinkerer and nowhere near the coder either of you obviously are.