I suspected that the component id
byte you added was not being recognized
by standard.

Until Ian allows a way to extract the desired
byte from multiple responses you are
stuck just like the TFT situation I mentioned
before.

I remember Ian added mode 6 to the pid
editor to let users extract DPF data for the
dashboard display so I’m hoping he will
add the Rx capability for multiple responses.

Sounds correct to me… the MSB of the
Component ID would indicate a min or max
test value comparison. (PWM).

To correctly interpret the test values (beyond
PASS/FAIL) you would need OEM documentation
to determine the multipliers like you described.

Except that test limit equals…

3D00 = 15616 (0.23424%) not 61.

Since the test value is less than test limit (max)
it would PASS.

(As I am left handed … might be off
in Right field).

Hey.
I have written to you in the mail.

Thanks for sending. I’m currently working on both the short term manual scan as well as the Torque Scan plugin fix…..will update when I have some good news to report.

Steve

Doesn’t the 0x need to be removed from the
pid field first?

Aren’t these listed in the Ford OBD Summary
manual for last/current drive cycle? (Mode 06 –
CAN specific).

OP mentioned his vehicle uses J1850.

I have spent the last few days teaching myself Java and learning everything I could about IDE’s, Java JDK, JRE, Android SDKs, etc……..painful.

The short of that adventure was that I was able to successfully update and build the [OLD] sample Torque Scan plugin and replace the current faulty Torque Scan plugin. With this in hand, I was able to complete a scan and obtain the results. The scan took a few hours to complete.

I did a quick analysis of the Mode 22 Torque Scan results:

Number of successful Mode 22 responses: 166
Responses with a byte count of 10 (including header): 87

I assume that the Mode 22 J1850 cylinder specific commands (if they exist) will be in sequential order in a group of 8, or at a minimum, in two groups of four and produce a result with a length of 10 bytes—10 bytes including the header is consistent with all other Ford misfire results. I have copied the results into a spreadsheet to aid in the analysis ( https://drive.google.com/open?id=0B7kQiBSEfjaETFYtZlhnQllEbFk ).

I tried a few PIDs on the vehicle late last night but am not convinced I am on the trail yet. Maybe today will be the day…..

Steve

Not trying to be a smart ass, but rather hoping to cut off rabbit trail paths (of which I have traveled MANY times). In your spreadsheet – isn’t your Byte Count actually nibbles?

BTW, I went through it comparing to all the data I have collected trying to identify / sort out all the PIDs that ‘responded’ to Torque Scan on my 2004 5.4L. I thank you for it. Your spreadsheet assisted my filling a couple of the blanks by knowing what kind of vehicle it came from.

I did notice several things of INTEREST in your data… you might want to check out. ASSUMING my documentation is correct – and it is all collected from various research sources that I considered credible and much tested against my vehicle where possible. In your spreadsheet:

1.) PID 162E (bit 4)(a bit mapped byte) has the bit set that indicates (according to my documentation) “Service engine Soon Light (MIL) output fault detected” ie: open / short in the Service Engine or MIL indicator light or PCM is otherwise unable to operate the MIL. I could easily suspect my documentation, but PID 21 indicates “Miles driven with MIL ON” = Zero. And PID 1103 bit 5 “MIL indicator Light Control” is NOT on. (you do not have an MIL) confirming my suspicion.

2.) PID 1688 (bit 1) (a bit mapped byte) has the bit set that indicates (according to my documentation) “Cylinder Head Temperature indicator Lamp Fault”). Again – my docs could be wrong. I do note CHT-normalized (PID 1624) is reading 203.89 which is likely about right.

JUST some thoughts.

———————

54371019

I understand the different ISO standard, but in spite of the frustration of differences between like years & models, thank god, so far I have not encountered differences where SAME/LIKE PIDs seem to be assigned different meanings. (THAT would be disastrous). It has always been merely that different vehicles just DO NOT respond to the other vehicles PID #. I notice their are many PIDs in your list that correspond to mine, applying formulas and comparing the data to mine seems reasonable. Even most of the Misfire PIDS I am using in my misfire dashboard are populated in your data.

I only mentioned 162E because it responded on your scan with Hex ’10’ – and all bits in that byte are assigned to some type ‘Fault’. The whole byte should be zero. Here are the assignments from my documentation (which acknowledged could be flawed) – but here’s the whole batch in case ANY are applicable to your truck.

162E b0 IAC_FO IAC output fault (open circuit or short to ground)
162E b1 IAC_FS IAC output fault (Shorted to load or VPWR)
162E b2 EGR_FO EVR output driver fault – open circuit fault
162E b3 EGR_FS EVR output driver fault – short circuit to ground
162E b4 MIL_F Service Engine Soon light (MIL)output fault indicated
162E b5 WACF WOT A/C Primary Circuit Fault
162E b6 FPF Fuel Pump Output Fault
162E b7 X?unk X?unk

It also appears that my misfire PIDs are being populated with reasonable data on yours.

2216d3 MFF RPM Engine RPM at time of Misfire RPM
2216d4 MFF LOAD Engine Load at time of Misfire %
2216d5 MFF VS Vehicle Speed at time of Misfire kph-mph
2216d6 MFF IAT Intake Air Temp at time of Misfire Deg. C
2216d7 MFF SOAK Engine-Off Soak Time at time of Misfire Minutes
2216d8 MFF RNTM Engine Running Time at time of Misfire Secs.
2216d9 MFF EGR EGR DFPE Sensor at time of Misfire Volts
2216da MFF TP Throttle Position at time of Misfire Volts
2216db …….X?unk X?unk
2216dc MFF 0 CNT Number Drive Cycles SINCE DTC CLR or Misfire (after at least 1000 Revs) Cnt
2216dd b0 MPLRN Misfire Wheel Profile Learned in KAM Yes/No
2216dd b1 MFF PNP In Drive at time of MisFire Yes/No
2216dd b? FF_LRN Strategy has finished learning the inferred alcohol content of the fuel YES/NO

—————–

EDIT: 9/3/201 11:45 Originally typed (1688) incorrect PID for the 8 fault flag bits which should have been and are corrected to #162E.

Sorry for any confusion.
—————————
54371019

Yes the prior flags are PID # 162E . I incorrectly typed 1688 for their PID#. I have ‘EDITED’ the prior post to reflect the correct PID # for those flag assignments. In your PID SCAN bit 4 is set in the response to 162E.

1688 b1 is another ‘fault’ flag bit and it was mentioned because the response to 1688 in your scan is hex 02. It is also a ‘fault’ indication, but I am less confident in assignments of this PID. Some, I have never been able to check or verify against my truck, any members data, or research. You might shed some light on it (you got a bit set in that byte). I did note that your normalized CHT (PID #1624) reading seemed sensible. I calculated it wrong in the previous post – it’s 191.9, but that’s still reasonable & the CHT sensor is working – we just do not know if the ‘LIGHT’ is. Curious thing is that the two ‘faults’ we have spoken about / suspected are related to the instrument cluster……. ?????

1688 b0 CHTIL Cylinder Head Temperature Indicator Lamp
1688 b1 CHTILF Cylinder Head Temperature Indicator Lamp Fault
1688 b? DPI Dual Plug Ignition System (secondary spark plugs enabled)
1688 b? FPHI High speed desired for 2 speed fuel pump
1688 b4 SAIRB Secondary Air Bypass commanded on
1688 b? SAIRD Secondary Air Diverter commanded on
1688 b? X?unk X?unk
1688 b? X?unk X?unk

** AS TO MISFIRE PIDs
**YOU do realize, that (at least on my 2004), Ford treats misfires in TWO DISTINCT different ways. (Misfires within the 1st 1000 engine revs are NOT CONSIDERED/COUNTED in the EWMA (Exponentially Weighted Moving Average) toward the percentage misfire rate for setting DTC or catalyst damage DTC Flashing. They _ARE_ however included in the MFtot PID 1616. But they DO NOT reset MFF_0_CNT, the Number of Misfire Free drive cycles – PID # 16DC. PID 1616 will reflect misfires occurring during the first 1000 revolutions, but those will NOT reset the drive count in 16DC. Ones occurring AFTER 1000 revolutions are ALSO accumulated in 1616, and DO reset MFF_0_CNT, and DO count toward DTC, flashing CEL (> factory set Catalyst damaging %) ect. I SUSPECT – but IDK – that they would NOT SHOW UP in 1601-1608 unless they are ‘post’ 1000 revolutions.

ALSO, you CANNOT cause a Misfire to increment those counters by ‘unplugging’ a COP while running. ((Do not ask how I know this)). The PCM sees an electrical fault (open COP primary ckt) and the smart little ‘sum-bitch’ knows it can’t fire the plug if it wanted to. So it just conveniently refuses to fire that fuel injector either, increases fuel trim on the other three cylinders on that bank, tweaks idle settings slightly – and keeps on running – surprisingly well.

I _might_ tell you how I know this via a private message sometime – but I’m not exposing ALL my ignorance right here publicly !!! LOL

—————–

54371019

@F-150Torqued

Sorry, one more question—-if you were to issue commands for PIDs 06A20B and 06A20C (cylinder 1 misfire events), how many hex digits of data (or bytes if you prefer that measurement) are returned for your vehicle? 2 hex digits (one byte), 4 hex digits (two bytes), other?

An example of your results would be very helpful, even if all zeroes. I am still looking at identifying other possible Mode 22 PIDs given my latest observation of not being able to correlate 2216[01-08] to 221616 (MF Total).

@capp777:

I have some questions on how Torque and OBD works—-when I create a Dashboard object linked to a custom PID (e.g., 221601), is Torque requesting an update at some predefined interval? Or, does the OBD bus already have this information on it, and Torque is essentially monitoring the bus for the proper PID, and extracting/updating the info every time it sees it published on the bus? Is this different for Mode 22 vs Mode 06?

I am just trying to figure out if my Dashboard objects could have “missed” the individual misfires (I expect these to be reported every 200 revolutions).

Thanks,
Steve