Filtering DFCO Cells

[Tordne]

Anyone know of a PID that can be logged that indicates when DFCO is active. I have looked and there doesn't appear to be one... I was hoping there may have been a State PID or something.

Because of the way in progressively comes in and out I am finding it quite had to filter out cells where DFCO is in effect. The effect of DFCO on BEN factors is obviously huge cause it shuts the fuel and the WB pick this as a sever lean condition :)

Can a State PID be created if it doesn't already exist?

Cheers,

[joecar]

Is DFCO indicated by {GM.FTC} == 21 ...?

[Tordne]

DFCO will occur in FT Cell 21, but so will other driving conditions, for example cruising and maintaining 60km/h say. So simply removing FT 21 cells won't do what I want.

I am commanding 15.4:1 AFR in low MAP cells as well, so I'd like to be able to remove the DFCO affected cells and just tune those cells that were actually used in non DFCO conditions.

I have tried a number of things to try and remove DFCO cells, like:
- Removing low TP% cells
- Removing cells with low spark advance (DFCO removes and reintroduces spark as it comes into and out of effect)
- Low Injector Duty Cycles, cause it basically shuts off the injectors
- Filter out high AFR's > than say 17.5

All of these do help to some degree, but there are still enough DFCO affected cells to pollute the BEN factors.

I was hoping that there was going to be a State PID tat I could simply log to e like a Boolean switch for DFCO active/inactive.

[GMPX]

Look at the MAP/RPM value it kicks in and filter the log for any numbers below that, afterall, you don't need to get that area right as the fuel is off!.

Cheers,
Ross

[Tordne]

Thanks Ross,

I still find though that there are cells in the log below the DFCO enable map etc. that are valid and DFCO was not active. I'd like to be able to filter out all cells where DFCO was active or becoming active/inactive.

I can send you a log if you like?

Cheers,

[Tordne]

That makes sense.

Is this overdoing it:
MAP < 20kPa and TPS == 0% and DTC == 21

I have tried that and more, but it is a real prick to get rid of all the cells, without losing ones you still want to retain. That is why it would be good to have a State PID tat is a simply Boolean value.

I can hear people saying "just turn DFCO off", but it has a couple of benefits IMO. One is obviously fuel economy, and at today's fuel prices that is good (just paid NZ$107 to fill with 98 octane - ouch). The second thing I like is the engine breaking effect when the fuel and spark is cut.

[joecar]

Originally Posted by joecar
That makes sense.

Is this overdoing it:
MAP < 20kPa and TPS == 0% and DTC == 21
I somehow deleted my post (...I'm having a day...).:doh:


(just paid NZ$107 to fill with 98 octane - ouch). Ouch.

Yeah, a state pid or bit would be nice.

[Tordne]

I somehow deleted my post (...I'm having a day...).:doh:

Ouch.

Given that I drive my car that gas will probably last 6-7 days, then ouch again :( The price here is not nearly as bad as in the UK. They are really loaded with taxes.

[joecar]

It's sad that governments have to load people down with high taxes.

Joe

[GMPX]

Worst part is most of the Australian Government cars are Statesman's with LS1's in them!!, who cares when someone else pays!!.

I don't think there is a fuel state PID, I'll take a look anyway.

Cheers,
Ross

[joecar]

Government cars are Statesman's with LS1's in them!!, who cares when someone else pays!!. Yeah, the fat cats make sure to look after themselves at our expense.:bawl::bawl::bawl::bawl:

[TAQuickness]

Until that bit can be located, I would say you need to devise a filter around all the DFCO enable/disable settings in your tune.

[Blacky]

It is my understanding that anytime the PCM is not commanding stoichiometry it is in open loop fuel mode. Have you tried logging open/closed loop mode to see if it corresponds with the frames where you believe DFCO to be active?

Alternatively, there is another flag called "Fuel Learn" which I assume would be off when in DFCO - don't want the PCM adjusting fuel trims based on DFCO cells.

Open/Closed loop and Fuel Learn are both in pid {GM.STATE05}

Regards
Paul

[Tordne]

Thanks Paul, I'll give that a look. When in DFCO the commanded AFR does not change so could not be used as a filter criteria (commaded will still be 14.7 for exacmpe but actualy WB02 will read 19.5+).

I'll check out STATE05 and let ya know :)

Cheers,

[Tordne]

Actually.. I'm running in Open Loop fuel mode all the time so learning will not be occuring at any point, either while DFCO is ative or not :(

I'll still log STATE05 and see if this is infact the case.

Cheers,

[GMPX]

Until that bit can be located, I would say you need to devise a filter around all the DFCO enable/disable settings in your tune.

DFCO state Bit has been located, we will add it in to the next update, it is actually in GM.STATE05 :doh: you just can't see it yet.

Cheers,
Ross

[TAQuickness]

DFCO state Bit has been located, we will add it in to the next update, it is actually in GM.STATE05 :doh: you just can't see it yet.

Cheers,
Ross


Ask and you shall receive. This is great stuff guys! :notacrook:

[joecar]

Rule the world, mate.:cheers:

[Tordne]

DFCO state Bit has been located, we will add it in to the next update, it is actually in GM.STATE05 :doh: you just can't see it yet.

Cheers,
Ross

That is some awesome news!!! :thankyou2:

I'm sure this will let me do exactly what I want :notacrook:

Cheers,

[Tordne]

OK, now I have another question... How do you use part of a STATE PID in a filter?

For example: STATE05 represents a number of different Boolean states and looking in the F9 (Data) tab you can see the STATE PID is expanded into a number of individual values.

How does one use one of those values in a filter? I'm preparing for when the DFCO PID is available.

Cheers,

[Blacky]

EFILive provides the same set of operators as 'C'. (Except for equality in C is ==, in EFIlive it is just = and non-equality in C is !=, in EFILive it is <>). And there is no ?: operator, use the built in function iff() instead.

So create a calcualted PID that returns 0 or 1:
iff({GM.STATE05} & 128,1,0)

Then use that calculated PID in the filter.

Regards
Paul

[Tordne]

EFILive provides the same set of operators as 'C'. (Except for equality in C is ==, in EFIlive it is just = and non-equality in C is !=, in EFILive it is <>). And there is no ?: operator, use the built in function iff() instead.

So create a calcualted PID that returns 0 or 1:
iff({GM.STATE05} & 128,1,0)

Then use that calculated PID in the filter.

Regards
Paul

Thanks mate!!

What is the 128, is that a position marker or something for the binary data? It looks like the DFCO portion of the STATE05 PID is going to be in the first position.

Cheers,

[Blacky]

The bits are listed MSb to LSb (Most Significant bit to Least Significant bit). 128 is the equivalent of 10000000 in binary. It is used to isolate just the DFCO bit in STATE05 that we are interested in.

The & operator will take the value of STATE05, AND it with 10000000 to get a zero or non zero result based on the value of the 7th (MSb) bit.
i.e. if the DFCO bit was set in STATE05 then the value would be 1xxxxxxx, if DFCO was not set then the value would be 0xxxxxxx where the x's are don't care values (i.e. all the other bits in the STATE05 value).

Doing a bitwise AND:
1xxxxxxx
&
10000000
is
10000000
Which is non zero and evaluates to TRUE in the iff() function.

0xxxxxxx
&
10000000
is
00000000
Which is zero and evaluates to FALSE in the iff() function.

Hope that helps.

Paul

[Tordne]

Great explanation Paul :master:. I knew it was going to be something like that, I just wanted to make sure of the logic so that I could isolate the correct bit for DFCO.

Cheers,

[joecar]

Do the other C bitwise operators like >> and << work...?

If I wanted to plot GM.STATE05 bit 7 on a chart,
would I create and plot a calculated pid like either of these:
{GM.STATE05} >> 7 & 1
{GM.STATE05} / 128 & 1

:cheers:

P.S. What is the order of precedence of the operators in EFILive...?

[Tordne]

So create a calcualted PID that returns 0 or 1:
iff({GM.STATE05} & 128,1,0)

Then use that calculated PID in the filter.

Hi Joe,

I think this is what the PID might look like, using the DFCO state as an example.

[Blacky]

I have not implemented >> and << (I guess I should, it would not be difficult).

Use the iff() function and & operator described previously to plot individual bits as either 0 or 1 on the charts.

See attached image of new page just added to the Scan Tool manual.

Paul

[joecar]

I think this is what the PID might look like, using the DFCO state as an example.


Use the iff() function and & operator described previously to plot individual bits as either 0 or 1 on the charts.
Andrew,
Paul,

Hi there; I didn't think about it, but you're right, that would produce the required plot.

Thanks. :wave:

[joecar]

See attached image of new page just added to the Scan Tool manual. :coool:
Thanks, I'm going to print it out and paste it to the inside of my glovebox door...
(programmers always print out precedence charts).

Joe
:cheers:

[Tordne]

:coool:
Thanks, I'm going to print it out and paste it to the inside of my glovebox door...
(programmers always print out precedence charts).

Joe
:cheers:

LOL... You guys are scaring me again :Eyecrazy:

You'll be able to ask yourself when you come to a T junction "should I turn left | right?"

[GMPX]

Do the other C bitwise operators like >> and << work...?


What's all this 'C' crap, real men use things like bcc, bhi, bls.

Cheers,
Ross

[TAQuickness]

LOL... You guys are scaring me again :Eyecrazy:

You'll be able to ask yourself when you come to a T junction "should I turn left | right?"


Shouldn't be hard. All you have to do is look it up in the chart :muahaha:


Thanks for the info. This will make for some very interesting PID's. After I had my revalation about the upcoming B0120 table, I starting thinking to myself, "Self, the narrowbands really suck. Would be nice if I had a conditional calc PID so I could create a BEN factor to lean out certain VE values.

"Crap, do I turn right or left, need to look that up. :muahaha: "

and whalah! it is done.

[Tordne]

Just been out for a couple of quick drives to test this out (we'll cal it lunch time :)). Seems that the DFCO STATE PID never transitions to Active in my logs.

My tune is running Open Loop Speed Density. I can send the log(s) to you (Paul or Ross) if you would like to confirm. There is every possibility that I am the problem somehow :)

[joecar]

You'll be able to ask yourself when you come to a T junction "should I turn left | right?"

Should I << or >> ...?

:muahaha:

[Tordne]

Should I << or >> ...?

:muahaha:

:master: Clearly you develop code of some sort. What sort of stuff do you program for (control systems or application etc.)?

I haven't done any what you would calls serious programming, but have done C, PHP (which I really like), Pascal, Basic (if you can call that a language) and even Cobol :bawl:

[joecar]

What's all this 'C' crap, real men use things like bcc, bhi, bls.

:hihi::hihi::hihi::hihi: Real real men use 1 and 0, solder and wire.

[joecar]

:master: Clearly you develop code of some sort. What sort of stuff do you program for (control systems or application etc.)?

I haven't done any what you would calls serious programming, but have done C, PHP (which I really like), Pascal, Basic (if you can call that a language) and even Cobol :bawl:
At present I write device drivers for fibre channel and iSCSI chips made by the company I work for.
I've previously written embedded code for various companies in storage and for defense (scary thought).
I've done Z80, 6800 and 6809 based hardware also, a long time ago (wire wrapping was fun...);
I've somehow avoided application code (don't know how I managed to);
My favourite microprocessors to program on are: Z80, 68xxx, TMS320xx, i860;
my least favourite are 8080, 8051, iAPX86 (although Pentium's are better if you use flatspace).

Edit: So I would have no clue how to write a Windows application

Cheers
Joe
:cheers:

[joecar]

C, PHP (which I really like), Pascal, Basic (if you can call that a language) and even Cobol :bawl: Andrew,

If you can program in it, then it must be a language;
there are hundreds of programming languages out there,
we only get to see the ones intended for widespread use;
I make up my own using the tools "lex" and "yacc".
Pascal is a good lanaguage;
Basic was okay to get you going in a hurry on short programs;
Cobol :bawl: was very wordy as is Ada, coutesy of DoD.

Edit:
C: I use it alot, but I think it's not a good language (allows mistakes to go unnoticed).
C++: good concepts, but I mostly don't like it (there's just is no abstraction for some things).


Joe :banana:

[joecar]

If it's programmable, then it will certainly have bugs.

Debugging is the practice of trading one bug for one or more other [possibly worse] bugs.

Have we gotten off topic or something... :bash: :cheers:

[joecar]

I haven't done any what you would calls serious programming...
Andrew,
You're much better off that way, just ask Paul... :muahaha:

:banana::banana::banana:

[Tordne]

Andrew,
You're much better off that way, just ask Paul... :muahaha:

I was being a little modest ;). I have written a couple of apps (in C :rockon:) but it goes back a long time. Back in the days when Novell only had a product called NetWare ;). Even a little assembler but I'm not admitting to that and I can't remember any of it anyway (thank god).

[Blacky]

Andrew,
You're much better off that way, just ask Paul... :muahaha:


:exactly:
My computer -> :bash: <- me, and that's on a good day.
Paul

[joecar]

I was being a little modest ;). I have written a couple of apps (in C :rockon:) but it goes back a long time. Back in the days when Novell only had a product called NetWare ;). Even a little assembler but I'm not admitting to that and I can't remember any of it anyway (thank god). One of the things I do is write a Netware driver for any new chip we make (fibre channel or iScsi); Novell isn't really selling many new Netware installations, but they are making a ton of money from supporting existing installations (I was amazed when I heard that); now they're doing Linux.

If you don't remember assembler, then you can use those brain cells for something more usuful.:cheers:

[Tordne]

One of the things I do is write a Netware driver for any new chip we make (fibre channel or iScsi); Novell isn't really selling many new Netware installations, but they are making a ton of money from supporting existing installations (I was amazed when I heard that); now they're doing Linux.

If you don't remember assembler, then you can use those brain cells for something more usuful.:cheers:

Novell back in the day developed UnixWare as well which they later offloaded to SCO when they realised that had no clue what to do with a UNIX. The SCO decided there was no money in selling a UNIX either and start suing Linux customers :bash:.

I think Novell's purchase of Suse was "interesting", and given that they had a pretty well established brand I think that will probably go somewhere for them. They also acquired Ximian who made a packaged Gnome desktop and of course the Evolution collaboration platform.

If you are writing device drivers and things like that (and developing your own languages) that is some serious shit!!!

[Tordne]

Anyway... Back on topic....

I tried putting the car back into Closed Loop fuelling mode and the DFCO STATE PID still doesn't change at all from "Inactive". Basically the same as running full Open Loop. :bawl:

My OS is 01290003 V3 custom if that is of any significance?

Cheers,

[TAQuickness]

Until the state pid gets worked out, log one of your injector pulse widths, and filter any value less than 1 ;)

[Tordne]

Until the state pid gets worked out, log one of your injector pulse widths, and filter any value less than 1 ;)

There is no reliable way I have found (and I have tried lots of different criteria) to filter the DFCO affected cells. Will just wait patiently for the DFCO STATE PID to be sorted :)

[joecar]

Anyway... Back on topic....

I tried putting the car back into Closed Loop fuelling mode and the DFCO STATE PID still doesn't change at all from "Inactive". Basically the same as running full Open Loop. :bawl:

My OS is 01290003 V3 custom if that is of any significance?

Cheers,
Andrew,

See this: showthread.php?p=20368&posted=1#post20368 (http://forum.efilive.com/showthread.php?p=20368&posted=1#post20368)

It could be that you need to apply the RAW() function to {GM.STATE05} first.

Joe
:cheers:

[joecar]

iff(raw({GM.STATE05}) & 128, 1, 0)

or

raw({GM.STATE05}) / 128 & 1

[Tordne]

iff(raw({GM.STATE05}) & 128, 1, 0)

or

raw({GM.STATE05}) / 128 & 1

Thanks Joe... The problem with the DFCO STATE PID at the moment is that it actually doesn't toggle between Active and Inactive states for me. So the formula, even though perhaps now correct will still always report a 0 value :(

Cheers,

[bK]

I'm guessing the update to show the state of DFCO hasn't been released just yet?

[Tordne]

I'm guessing the update to show the state of DFCO hasn't been released just yet?

It is there to tease you but doesn't seem to toggle based on DFCO state. Mine always shows as Inactive.

[bK]

It is there to tease you but doesn't seem to toggle based on DFCO state. Mine always shows as Inactive.

Just logged mine and the same thing.... I know DFCO is activating.

Can you log the raw output data from GM.STATE05 and see if anything is coming out? I can run a Boolean expression over it and put the pieces together.

[Tordne]

Just logged mine and the same thing.... I know DFCO is activating.

Can you log the raw output data from GM.STATE05 and see if anything is coming out? I can run a Boolean expression over it and put the pieces together.

Right now it is literally on the whiteboard to be looked at. But until it reaches the top it is no point trying to get the DFCO "bit" cause it isn't set when DFCO activates.

[kbracing96]

Ok, I'm bringing this back form the dead. I wanting to setup a filter for when DFCO is on, so the MPG pid a set up will work correctly. DFCO really skews the MPG number higher, but when it is turned off, they seem ok. I tried to setup a calculated pid for it like shown by Blacky, but it wouldn't work. Can some one help me here? Thanks.

[Blacky]

Turns out the DFCO PID data {GM.STATE05} is probably only supported on the later model PCMs (1Mb) but not the early ones (512K).
I don't think there is any accurate way to calculate the DFCO state from other PID values.

Regards
Paul

[Tordne]

Bummer.. It is really hard to get rid of DFCO affected cells. The best I have been able to do is filter for:

TP = 0 AND
Injector PW < ~-.70 AND
Spark decreasing less than something

[kbracing96]

Turns out the DFCO PID data {GM.STATE05} is probably only supported on the later model PCMs (1Mb) but not the early ones (512K).
I don't think there is any accurate way to calculate the DFCO state from other PID values.

Regards
Paul

Humm... so does anyone have any good ideas on how I could filter out DFCO out of a log, so can get an accurate MPG reading?

[TAQuickness]

Actually, you're MPG reading should be pretty accurate unfiltered. I've run several test by recording my average (un-filtered) MPG from a tanks worth of logs and comparing it to the miles/gallons and they are usually within 0 - 0.5.

Otherwise, I've had good luck by filtering out low IPW's and low Spark values

[mr.prick]

i know this thread is old but i think it`s better to turn DFCO off because,
you might only hit some cells during DFCO thus not getting any unskewed data.


just my opinion.

[SSpdDmon]

Just filter out spark less than 10 degrees. It'll go away then.

If your WBO2 lags behind a tad like mine does, I also filter out cells where the WB is greater than 15.6:1. I shouldn't have any spot in my tune where that's a 'normal' AFR.