The effects of AFV on open loop areas

[whittlebeast]

Is the PV data logging merely repeating the data it receives until it receives new data or is it actually making something up, it would seem very difficult to fill in the blanks with the "Fake" data and even be on the same page with what the ecm is delivering.

It just happens to write a new record about every .025 sec or so with the last date it saw from each channel it is watching,  In the case of the wideband channel the numbers change about every third record.  Other channels change somewhat less often.  Almost every channel gets updated in .200 to .250 ms or so.  It all depends on how much data it is trying to watch.  Fake in this world is like plagiarizer in the book world.  Just there to stir up BS to change the subject.

I have not seen any data that was questionable enough to have any affect the final tune in either system I use.

Beast

[glens]

Now knowing that the afv can mess with open loop sections of a tune I am more convinced not to use any any closed loop in a tune.  I do not want a hidden table that can be diffrent for each base cal offered and no documentation on where the afv cells will be applied.

Elaborate, please, on why AFV factoring in open-loop is "messing with" it?  And which "open loop" area(s) do you have in mind?

There are likely several more "hidden tables that can be different for each base cal" than just where AFVs are stored.  And so far as I understand it, none of the other tuning interfaces/software show you more actual tables than does the TTS stuff

So are you saying PV is intentionally inserting false data? or is it data that has not gone through your filters. Is it because they show the ve new in the data stream and you have chosen to filter that out ,because the end user can't handle that data.
How is removing data not fake.

It's not so much that the spurious data is "false".  It's just spurious.  It appears as though every "channel" buffer only gets a new value whenever a new value comes for it from the ECM and the PV spits it whatever's in the buffer each time it spits data out.

If you have 10 "buffer spits" which all contain some value repeated over again, it's data which weights the average incorrectly, if you're averaging the data.  If you're merely graphing it, instead of a line directly between the two good points you've got a horizontal line, which ain't so bad but ain't so good either.

I'd say removing data isn't faking anything, especially if the data has a high probability of being incorrect as far as matching other data from the same general place and folks try to use it for purposes it isn't so applicable.

What is ve new except for the ecm taking the value in the ve table then using the o2 data and making corrections to deliver the proper amount of fuel to keep the o2s at their switch point.

I'd say it's the resultant calculation of the (what might be current, probably averaged between four cells) VE value against the (unknown-location probably averaged between four cells) AFV.

I suspect you are using the ve new once you have filtered it and using it to populate your 24 afv cells per cylinder.

I suspect the ECM itself populates the AFV cells it's told it has and the VE New is a result of them against the VEs.  But since the VE number isn't usually directly out of the table and the AFV isn't usually directly out of its table, both usually being proportionately averaged.

Andy: it'd be better to increase your displacement by 10% if you want to waste your time on such a test.  BTW, I toyed with one of your log files the other day:

Code Select Expand

Script started on Thu 29 Sep 2011 12:11:48 PM EDT
glen@ace:~/Documents/temp$ ls -l *csv
-rw-r--r-- 1 glen glen 10255595 2011-08-28 10:58 log0048_FreshStockInstall.csv
glen@ace:~/Documents/temp$ time { awk 'BEGIN { FS=","; this=0; } { print $1-this
; this=$1; }' log* >PVdeltas.csv; }

real    0m0.480s
user    0m0.468s
sys     0m0.012s
glen@ace:~/Documents/temp$ ls -l *csv
-rw-r--r-- 1 glen glen   206045 2011-09-29 12:12 PVdeltas.csv
-rw-r--r-- 1 glen glen 10255595 2011-08-28 10:58 log0048_FreshStockInstall.csv
glen@ace:~/Documents/temp$ wc -l *csv
   69160 PVdeltas.csv
   69160 log0048_FreshStockInstall.csv
  138320 total
glen@ace:~/Documents/temp$ exit

Script done on Thu 29 Sep 2011 12:12:31 PM EDT
What that did was separate the "ms" figure out of the log file.  The lines eventually end up being 23.741 ms average by the end of the file.  Here's the result of that console command above (the actual data lines start after the two lines containing "0" following the one with "-28".  Drop it into MLV as is and you'll see the sample times.


[attachment removed after 60 days by system]

[yositime]

Recall from sampling theory 102 that sampling of asynchronous data is different than synchronous data streams. Treating asynchronous data as synchronous in most cases produces poor results, although the synchronous technics are simple and cheap. Andy’s proposed method appears to do this, and may be just plain wrong. But perhaps looking at the end objective and environment, maybe not wrong enough to make a difference anyway.  Maybe wrong enough that other methods are still better but that’s hard to tell.  Claims that this method and tool kit may be the best thing since sliced bread strikes me with some skepticism... but valuable discoveries happen sometimes just playing around.

If I am understanding this correctly, we are to interpret these scatter graphs as something based on the number of measurements of a certain value over a fixed time period. If the number of times a certain value shows up is skewed due to sampling error (like repeating a value as if its a new value or loosing a real but same value in the noise) then the interpretation is suspect? How close does it need to be to make any difference. I dunno but I just don't get excited about sorting through noisy data.

After the fact, it is somewhat difficult determining if the sample is a repeat or an actual new valid but same value. Missing a good repeated value is almost as significant as repeating the same. Maybe a human with superior pattern recognition can sort it out. I wonder if the PV has the horsepower to use a more sophisticated and accurate sampling method than the cheap and simple poling scheme it appears to use. Of course then we would be discussing the value the ECU is reporting and if it is any more useful for this method.  Maybe more sophistication is a waste of energy..  maybe not.   

So with all these sampling issues, not that any data is fake..  data is data.. , I'm not convinced that this method would provide better results on the street or strip than the alternatives. How can that be proven? I guess I’m skeptical if its worth the extra effort until the effect of poor sampling can be determined.

Later....

[FBRR]

 "If Harley used the same "scheme" we use, we allowed the "LEARNED" values to modify OPEN LOOP (P.E.) ONLY if the "learned values" were ADDING fuel!"


You will NOTE! I said IF!! Harley used the same scheme!! Steve has indicated they did not! And I too think it an error to allow ANY closed loop AFV to remove fuel in OPEN LOOP! If that is what HARLEY allows, it's not very smart!! ( running a little too rich is far safer than running a "little" lean in open loop! And allowing the AFVs correction in OPEN LOOP to subtract as well as add fuel risks a "little"lean to occur! That is the whole idea behind ONLY allowing "FUEL ADD" from AFV in open loop.)

And that danger MAY !! NOTE MAY be magnified based on the cell (AFV cells)definition boundaries as they relate to the VE table break points.


I try to stay out of the fray as it seems not to add anything and only gets twisted. 
But you need to remember VE is only a model based INPUT to the MASS AIR PREDICTION. And AFV are corrections based on closed loop control! Those are two seperate functions!
VE is an INPUT!
AFVs are a  LEARNED "correction" value from closed loop fuel control!

[glens]

Here are two screenshots of datalogs.  One the file I attached earlier, and one of a TTS "DBW" log that was probably about 15 minutes (also probably with a not-so-well-made data port to interface connection).

[attachment removed after 60 days by system]

[whittlebeast]

Post the raw dm3 file and let's see what you have.

Beast

[glens]

To what purpose?  I exported it, culled all but the "Frame Time" deltas (with a command just like shown above), and opened the result in MLV, just like the file I attached earlier, which I also MLV'd.

The delta seconds is much higher in the TTS log but the variance is much less than in the PV log.  Note that in that the bulk of the hits are about 17 ms but they're all over the place quite often.

I still say I like that the HD Delphi implementation will both push and pull fuel open-loop.  If the VE tables are correct then that's what you'd want.

[whittlebeast]

To what purpose? 

I find it interesting to see how other people are doing with their tune.  You would be amazed what you can learn by looking at tunes.

Beast

[glens]

No, I wouldn't be amazed.  That log file was the second half of the trip bringing the bike home from a stage-one plus cam install, running on a base calibration.  It isn't interesting in the least.

[Tsani]

FBRR.... :up:Yay!!!! 

I purposely tried to drag you in here.  I know the 'ifs', and KNOW you stated if, etc.... but Steve says he has PROOF that the ECM pulls fuel from the OL portion of the tune.  I see no problem with the AFVs going richer AND leaner in OL, as long as the AFVs can NOT pull leaner than the map settings.

In a couple of months, I have dyno time set up to test what HD actually does.  I truly wish Steve would share on this one small issue, as it is important to me, and just maybe me?  I simply cannot see how this would be 'proprietary' to TTS, or any other tuner on the market, as it would involve the code from the MOCO.

Wurk_Turk,
Steve did give you an answer and also stated why he will not specifically say exactly what and where.

Let me answer a few things here

1. I know where each and every AFV cell is set in all TTS based calibrations.
2. I'm the one that set them up, but NO I will not tell, there is already to many companies trying to copy what we've done so certain things will only be talked about in general.

So it would appear that while the MOCO had written the ECM code ( and I am willing to bet that it is possible that Steve, as well as others, had a hand in that since TTS also developed the SERT module and software, No?) TTS has changed where the code looks for the AFV data and that would require the code to be changed. So to some degree, yes, that could be considered 'proprietary' information and I for one can understand why Steve would hesitate to share that info since TTS feels this is one of the things that makes it's software stand out and function better.

So can you truely blame him for not explicitly sharing that information with us?

[glens]

Also having a stable tune is an issue.  MY idea of a stable tune would be one that does NOT allow the ECM to command LESS fuel to the bike while in OL.  I really think, if it all works correctly, that Closed loop is the way to go for touring....  but if the code allows too lean of an operation, then??

I agree, a stable tune is important, but I disagree with your line of thought when it comes to pulling fuel if deemed necessary while in open-loop operation.

If you've got your VEs set correctly this should be a non-issue in terms of concern and a strong positive issue in terms of maintaining a stable tune.  Say you'd tuned with E10 and are on a trip using your second tank now of pure straight gasoline.  If your E10 tune was correct in all respects I'm pretty sure you'd see, if you could see, AFVs all very close in value, pulling several percent fuel now.  If it's correct to do this while closed-loop, and I'm sure you'd agree it is, please explain succinctly why you wouldn't want the same proportion of fuel also pulled anywhere running open-loop?  It would be correct to do so and if it did not occur, your tune would not fit your criteria of being stable!  How is it you disagree with this notion?

[wurk_truk]

I have advocated tuning with E10, so that it would be RICHER with regular gas.  But, now the flip...  the bike will run lean when tuning with gas and running E10.

I have my answer.  This ALL goes back to Ron Dickey seeing excessive heat on closed loop tunes.  I am NOT talking about Stg1 103's BTW.  It now appears to me that closed loop can be detrimental after a certain amount of 'building' on an engine.  Where that line may fall?  I don't know, nor will I further worry about it.

Open loop it is.

[rbabos]

I have advocated tuning with E10, so that it would be RICHER with regular gas.  But, now the flip...  the bike will run lean when tuning with gas and running E10.

I have my answer.

Open loop it is.

Never thought I'd see the day. With all the +/- of each, my choice in the end as well. Not slamming closed loop since I ran the 113 most of the season with it. In the end I just can't trust an 02 sensor to protect a rather expensive engine. No way of knowing if a lean condition will sneak in over time with a degrading or failing sensor. By the time it becomes obvious damage might have happened. I've heard all the arguments for both, tried both and in the end I will feel warm and fuzzy in (open) going down the road, especially in Canada where fuel quality is not an issue.
Ron

[glens]

I'm not talking stage one 103s either.

Ron, the beauty of it is the stock (type) sensors, when they start to go south, invariably indicate falsely lean.

I don't plan on ever building an engine, much less one I'd "tour" with, that would make closed-loop problematic.  Closed-loop all the way for me.  I want a stable tune in the face of different fuels and differing operational characteristics the kind of which just happen over time, like injector response and fuel pressure.

[rbabos]

I'm not talking stage one 103s either.

Ron, the beauty of it is the stock (type) sensors, when they start to go south, invariably indicate falsely lean.

I don't plan on ever building an engine, much less one I'd "tour" with, that would make closed-loop problematic.  Closed-loop all the way for me.  I want a stable tune in the face of different fuels and differing operational characteristics the kind of which just happen over time, like injector response and fuel pressure.

I think the faulse lean part needs some explanation. Does this not translate to a leaner mixture in the end? If faulse, how can you decifer the data to know where you stand?
Ron

[glens]

I have advocated tuning with E10, so that it would be RICHER with regular gas.  But, now the flip...  the bike will run lean when tuning with gas and running E10.

Exactly.  When you're running open-loop all the time.  Closed-loop and it doesn't matter which of the two fuels you use, whenever, because your tune will wind up the same everywhere (in terms of fueling).  If you're not on the ragged edge anywhere for either fuel or spark it'll be stable all the time.

I'll quit harping on it (for) now...

[glens]

Ron, false lean is when the voltage output is lower than it should be.  It's rather like a battery with the voltage produced being greater as the difference between O2 levels increases either side of the element.  If it's so rich that it's getting sooty it'll indicate lean (low voltage output), driving even more fuel...

As the "battery" gets tired, the voltage produced becomes less, normally indicative of a "lean" mixture.

[edit: It's almost impossible (at least quite unlikely) to get a false "rich" reading (excess voltage being produced), which would remove fuel from where things were programmed.  Also, as the sensors age they become sluggish, but this only serves to cause (and may in fact be the main reason for) a lower average voltage being produced.  Under usual circumstances error would most always results in things richening up instead of the other direction. 

I'm trying to think of a scenario which would cause excess voltage to be produced such that fuel would get incorrectly pulled...  I'll let you know if I come up with one.]

[Jeffd]

Ron, false lean is when the voltage output is lower than it should be.  It's rather like a battery with the voltage produced being greater as the difference between O2 levels increases either side of the element.  If it's so rich that it's getting sooty it'll indicate lean (low voltage output), driving even more fuel...

As the "battery" gets tired, the voltage produced becomes less, normally indicative of a "lean" mixture.

[edit: It's almost impossible (at least quite unlikely) to get a false "rich" reading (excess voltage being produced), which would remove fuel from where things were programmed.  Also, as the sensors age they become sluggish, but this only serves to cause (and may in fact be the main reason for) a lower average voltage being produced.  Under usual circumstances error would most always results in things richening up instead of the other direction. 

I'm trying to think of a scenario which would cause excess voltage to be produced such that fuel would get incorrectly pulled...  I'll let you know if I come up with one.]

that's easy..getting struck by lightening as you are riding along LOL.

[Steve Cole]

I have advocated tuning with E10, so that it would be RICHER with regular gas.  But, now the flip...  the bike will run lean when tuning with gas and running E10.

I have my answer.  This ALL goes back to Ron Dickey seeing excessive heat on closed loop tunes.  I am NOT talking about Stg1 103's BTW.  It now appears to me that closed loop can be detrimental after a certain amount of 'building' on an engine.  Where that line may fall?  I don't know, nor will I further worry about it.

Open loop it is.

You had better go back and talk with Ron Dickey again as he see's the same thing on some carburated rigs that were tuned on a dyno by a so called expert tuner! 

You can take things to an extreme on either end and not like the results so I guess you should not do anything, or Rip the fuel injection back off the bike, throw a carb. on it and then call it a day. That way you will only get what the carb let's out so it will be rich in some areas lean in others and when you get various fuels your screwed. Then make sure you only ride around your area because if you go up in altitude your screwed again.

Now does that make any sense? Fuel injection with closed loop control is much better and controls the mixtures more precisely. How is this and issue?

[rbabos]

  
Ron

[wurk_truk]

I will do my own tests and dyno runs and decide for myself.  Since the answer to my question is/ was not forthcoming, Steve.  You know damn well i like EFI.   AND... Closed loop.

[Steve Cole]

Just make sure you compare apples to apples.

[wurk_truk]

I think I can do a test myself without a dyno.

Tune the bike CL and let it build up AFVs for a bit after tuning with 93.  Then throw in some 89 corn.  See what happens to the desired AFRs in the OL areas.  Should desire a richer AFR.

The switch it... tune with 89 corn, and see what the desired AFR is after installing 93.  Hopefully stays the same.

Same bike, pipe, etc.  Simple Apple Pie to me!   I will need to weld in a couple 12mm bungs on my Bosscat.

[blusmbl]

Now does that make any sense? Fuel injection with closed loop control is much better and controls the mixtures more precisely. How is this and issue?

It's not like O2 sensors have been in use for 30+ years or anything.  I'm sure it'll be awhile before the technology and closed loop strategy is ready for prime time. 

Note: this post may contain sarcasm.

[glens]

Tune the bike CL and let it build up AFVs for a bit after tuning with 93.  Then throw in some 89 corn.  See what happens to the desired AFRs in the OL areas.  Should desire a richer AFR.

You don't need to waste the time letting it "build up AFVs" first, just drain the tank after tuning and put in the corn.  It'll be the corn that brings about the change, not the octane, so why not use 93 corn?  Why introduce a different change when all you want to do is derive the AFRs?

The[n] switch it... tune with 89 corn, and see what the desired AFR is after installing 93.  Hopefully stays the same.

Where, oh where did you get the notion that you'd want the same AFR as corn after changing over from the corn?  It'll be relatively richer then!  Think in terms of only lambda instead of "AFR" and it should be clear to you.  If you've got the OL lambda at 0.86, that means you want 0.86 no matter which fuel you're using.  If the AFVs don't correct it for you, after tuning with corn and changing to non-corn, it'll be too low without the corn -- not what you wanted there.  It'll be for you an unstable tune. 

I ask you yet again: please, please explain why you want it to be too rich OL in a situation like that when it can be just right instead?