Originally Posted by F150Torqued (Post 17563927)

Glad to know I'm not _alone_ in the 'ole fart' corner, and there is someone still alive out there who can relate to toggling hex data into a 24k byte computer with toggle switches on a front panel. ugh. Yes, we've come a long way.


With those MFF_RPM numbers of yours, you sure we got the "/10" at the end of that formula? That would make things look better - 624.9.
Remember, all those items on the bottom two rows (except your new gauges) are 'Freeze Frame' numbers (supposedly grabbed at the time of the last misfire). I 'DO' see that MF_Tot incremented by one on screenshoot 2 with a misfire on #8 - but all other MFF freeze frame items seem to remain the SAME. With an additional misfire, I can't explain no apparent update of freeze frame data. ??? And the "FUNKY" mode 06 misfire count for Cyl No 5 makes NO SENSE. That one _blows me away_.

I DON'T EVEN KNOW HOW 'TORQUE' DID THAT. Cannot be communications - that's 'serial'. The formula G*256+H does not even permit treating EITHER G or H as a "signed" byte!!!!!! All the ECU can do is send the contents of those two bytes serially to Torque. Torque programming grabs byte "G" (the seventh) byte in the Data String, multiplies it (as an unsigned byte) by 256 and adds that to the value of "H" (the eighth byte in the data string). Then displays that in a digital gauge per decimals specified for in the setup for that gauge. ///How can that be minus? Is there a 'minus sign' in the Min/Max fields?/// I don't even see that can be related to my prior observation about memory cells.


But All is not bad. There is more than just a little bit of "+" information in those screens. You have clocked four (4) drive cycles with ZERO post 1000 revolution misfires (MFF_0_Cnt). They have ALL occurred within 1000 revs of startup. In fact, within 15 sec of startup (MFF_RNTM), 20% engine load (MFF_LOAD), NOT in drive (MFF_PNP). To top that off, it had been shut off hot and sat for only 38 minutes (MFF_SOAK) and started up with the intake air plenum air at 120º (MFF_IAT). That's not perfect running conditions when fuel and air flow and rpms and everything is settling down. We used to call that "rode hard, and left out to dry".


Those (pre-1000 rev) misfires are treated very differently (less significant) by the ECU. They are not even accumulated toward a DTC limit.


An interesting related matter on My truck. I have noticed (through THIS Misfire Monitor Screen) that I can 'create' a misfire by turning the ignition on, but not crank for 20-30 seconds, then fire it up. ALMOST every time, I will have 2-3 misfires on Cyl 4, and frequently 1 on Cyl 5. I believe pressurizing the fuel rail - static, I must have an injector on those two cylinders that weeps or makes the mixture overly rich on the delayed startup.

I also notice you have an OBDII "Trip Count" of 1. That means ALL 'seven' of the OBDII Monitor routines have successfully completed once (MFMLRN, MISSTAT, FUELSTAT, EVAPSTAT, CMMSTAT,CATSTAT, and I/M_READY).


THAT actually says 'LOTS OF STUFF' is working right. The first four are self explanatory - the last three, Comprehensive Components Test, Catalyst Tests, and Inferred Mass Air Flow (Cams are accomplishing proper EGR mixed with intake air mass) are even more significant.
I've been working on a Torque Monitor screen to follow / track all those OBDII monitors (especially EVAP) through their progress and soon as I get a few formulas polished up and working right, I plan to post it for everybody.


So, set your CPAP on HIGH, and sleep better. It's better for our grey matter. :)

Originally Posted by pdqford (Post 17565424)

I started out in '64 on a word machine - Autocoder and eventually Cobol.
Just trying to follow along here and learn something from you young'ns.
I'm coming up on the big EIGHT OH!



Maybe I can help. Freeze Frame is snaped when the FIRST DTC is set. Not when the last DTC is set.


Returning to CPAP mode.:-drink

Originally Posted by jwiegele (Post 17566924)

Regarding FF data - since I'm not getting a CEL - no fault codes - would I even have accurate FF data reporting using Torque?

Originally Posted by pdqford (Post 17567325)

If there are no stored fault (DTC) codes there will be no FF data stored.
...

Originally Posted by F150Torqued (Post 17568621)

Thanks @pdqford. According to my understanding, that is a true FACT. (Probably - even with a grey code before it becomes a Demand code --- ??? :-huh) I have no idea if there a 'time window' involved where another / different code would 'refresh' FF data, but I would actually presume so. Which means I used the term "Freeze Frame" a little TOO casually/loosely.


I would give anything if we could have the source code or programmer's comments. It's a B*@#t*H trying to figure out what the programmer was thinking just by exercising a (complicated) piece of software. It is even double dog difficult with two involved - The ECU + TORQUE.


But there is an exception. I know that many misfires (both pre-1000 rev AND post-1000 rev) do not set a DTC, even grey code. But they are accounted for in an "Exponentially Weighted Moving Average". (EWMA) ->toward an appropriate DTC. I have witnessed through my testing of the Misfire Monitor screen, and reliable documentation, that a number of parameters (like RPM, IAT, VS, etc) are stored at the instant of a misfire. Even a misfire occurring during the 1st 1000 engine revolutions, which are treated very differently (less significant) by the ECU. What I don't know, but suspect, is there any 'time window' involved BETWEEN MISFIRES when those would be 'refreshed', OR are these the same memory locations copied to FF data when a DTC is triggered. So it is improper to refer to these fields as freeze frame data. They are just what their documentation designates them as: "at the time of the last misfire".


Further bringing into focus the stark difference between what I know vs what I don't (Thimble vs Battleship).

Originally Posted by F150Torqued (Post 17662696)

A couple more details will improve the quality of the responses.
Engine?
Miles?
Any (other) phaser issues or noises?
scanner / reader capability you have - (how did you get multiple misfire readings)?
Codes?
Mode 06 data available?
Freeze Frame data available?

Originally Posted by F150Torqued (Post 17664508)

Generally speaking (though not always), light or random misfires can be cured by doing a thorough, meticulous, clean plug job with new boots/springs. These engines demand everything in the ignition system to be near perfect to reliably fire every time. They even use very high voltage and 'multi-strike' ignition coil operation below around 2000 rpm. THUS boots must not be brittle or cracked and 'impedance' of the coils is a VERY BIG factor so the coil can 'recharge' three times in about 1500 micro-seconds. (.001500 sec's, that's not very long). This is the most likely reason the engines are picky about using OEM coils. (You mentioned using 'Motorcraft plugs and cops. If not, rethink that.)

Also - there are more than a FEW cases around here where Motorcraft plugs have been 'bad out of the box' - OR DAMAGED (internally fractured) PUTTING THEM IN if the carbon deposits were not cleaned out of the extended spark plug hole in the head. It is 'MY' belief that this is a MAJOR factor in misfires on these engines. My theory and reasoning on this is detailed in this post: https://www.ford-trucks.com/forums/1...l#post15819897

It sounds as though you have done about everything else needed to make it run / perform good. I would just add that at 167k, you are nearing the reasonable upper end of life for steel timing chains. Eliminate the misfires or the slack in worn chains will slap the hell out of (and smash) the plastic chain guides hastening the necessity of a timing job.


I'm not much of a believer in having to "re-flash" the computer. That is generally a 'cop out' by a dealer that doesn't know what's wrong and looking for a way out short of suggesting a new engine (which they do WAY too often).

Originally Posted by F150Torqued (Post 17666923)

I'm not suggesting not do it. EVERYTHING needs to be perfect on these 5.4's to run right. But, if you had a vacuum leak, I would think you would get lean codes - p0171 &/or P0174 - and flashing CEL long before it would cause random misfires. The PCM is amazingly efficient at compensating for things and will increase fuel trims right away if there's unmetered air getting in.


From the code / mode information given, I'm assuming you have live data monitoring capability. If so, graphing or monitoring short term fuel trims is certainly the best way to check for (or find) vacuum leaks very quickly. If you have a vacuum leak or bad IM gasket it will drive short term fuel trims positive.