Narrow Band Then Wide Band Tuning -Dynojet Power Vision

[glens]

Try asking Steve how the VE New was developed.

I'm not seeking the information for myself.  I want to see if you know what the stuff you're using really represents.  Obviously you don't.

Look back up in this thread at the pseudo-table I created.  If you've got a "VE" figure in one of your graphs that doesn't seem to correspond to anything in the applicable VE table, you'll know why.

I would like to know how DJ derives their "AFF Channel".  You said you'd ask them for me, like as you were on familiar terms with them.  Have you done this yet?  If not, why not; and why did you say you would in either case?

I have noticed that if you take

VE Front * (Front AFF/100) * (Front CLI/100) you get real close to VE New Front

How close?  Coin-toss close?  ( I couldn't resist )

In PowerVision you can turn on and off AFF and CLI

Without knowing what they are or what they do?

How would I know....  Try calling Delphi and see if they will give you the underlying math.  I just  try to make sense of the data as I comes out of the port.

Again, I'm not looking for the underlying math.  I'm looking to see if you even have a clue what the stuff is.

You can tell which values were used to derive the "VE" value you see at any point in a log.  They would be the four surrounding values in the table.  When you see a "VE New" in the log, you don't know if it's a result of four surrounding Adaptive Fuel Values or one from smack dab in the middle of a particular table cell.  You don't know where those cells are nor what they contain.  Just because a "VE New" value is declared at some point in the log does not mean that it would actually be suitable for use to replace any VE table value.

Your problems in your "Coin Toss Tuning Method" are so multi-faceted that if you could even get your noodle wrapped half way around them you'd cease dicking with this stuff like you are.

Changing VE values in the calibration based solely on what you've derived from data in the logs is more a waste of time than a dog chasing his tail.  Why don't you keep careful track of the changes you make over time and graph those?  I'd bet it'll plot a nearly perfect circle, given enough tosses of the coin.

[whittlebeast]

When you are driving thru the mountains and see a 5% grade, do you get out a digital level to point out at the location of the sign, the grade was 4.8% so you write the state to fix the sign or do you just accept that a hill is in your future?

Beast

[glens]

Andy, it really escapes me why you asked that of me.  The way I see it, you're the one with the level stopped at the sign.  I'm the one riding right up the hill like it's not even there.

For what it's worth, I have a very good idea of what you're actually trying to accomplish with your presence here, and believe me when I tell you this: it's backfiring on you.  You're firmly cementing the notions many have long held.  You could start to turn that around if you'd enter into some meaningful dialogue.

[Sporty 48]

Great humor and I think some of you know what you are talking about.
A lot of the confusion here comes from the points of view(s). I think there might be some government types used to dictating from on high. Some are enthusiasts, some engineer types, some are very technically minded. I get confused but am happy that the dialog is civil and engaging.
Good that we agree, at least, that the hill is up and tuning is good fun.

[Coyote]

Some interesting input here:

Tossing coins is not a good analogy for tuning. I've spent my life in the controls, closed loop, digital sampling industry. Once you lose data, you cannot recover it from averaging. There is a reason that you must sample data much faster than than the data itself. A nice theorem to look up is the Nyquist  theorem. It explains the minimum sampling rate for analog signals

I agree in the context of tuning, or trying to reconstruct the analog signal, but noone is trying to do that, are they? I fail to understand what Nyquist has to do with it, unless you are trying to reconstruct the analog signal and playing it on your stereo equipment. There are lots of other theorems much more relevant in this context, taken from statistical sampling of discrete data, not from signal theory of analog signals. What this is about is finding and filtering representative data from an undersampled dataset. (Which is what the tuning software do.)
My question is just about a peculiarity in a simple test for randomness:
Why are the data skewed? As they are skewed, we can agree that we don't have a random sampling situation. That is what I am wondering about, what is the explanation for this nonrandom effect?

I think that you do not understand closed loop systems. The closed loop fuel injection system, like all others, consists of an item to control (in this case fuel) a feed back sampling method (in this case O2 sensors), a low pass filter (in this case the filter is done digitally but that doesn't matter), a comparison with a reference (in this case a fuel target table, That comparison creates an error value). For a closed loop system to operate properly, the error value response time (set by the low pass filter) must be fast enough to meet the system requirements for error correction. The sampling rate for the feedback signal must be considerably faster than that to allow the sampling frequency to be removed (by the low pass filter). If it is not substantially removed, it will case artifacts in the feedback signal. This is why Nyquist applies. This is also why you can't just loose the data. Just as the closed loop won't respond correctly, your calculated measurements won't be correct either.

[hpulven]

I think that you do not understand closed loop systems.

You are assuming wrong, but let that be as it is.
I am assuming nothing about you from what you write about Nykvist, but it is in fact not relevant to the question I asked about the feedback from the O2 sensors.
I was told the ECM reads a discrete, single measurement every time the gases are escaping from the cylinder, and will be happy and satisfied with that. What the sensor voltage is between those discrete, time-separated measurements is of no interest to neither the ECM, you or me, so Nykvist is of no interest either, as noone is interested in reconstructing the complete analogue signal from the sensors between those separated measurements in time. (Other sensorsignals are a different matter.)

I think Glens made the final conclusion to my question:

I'm afraid that to get that answer you're probably going to have to get hold of either a Delphi or an H-D engineer.  Someone who's actually worked on the code and is willing to discuss it with you.

Fair enough, I will have to live with that. (My bet is on the sensors being more busy at certain stages in the feedback cycles, but it is only my hypothesis until som more info comes along.)

On the toin-coss discussion, I have to point out that we could indeed make a stochastic model with a binomial 50/50 distribution as the population we are sampling from.
A random sample would by the laws of statistics give the average (clb bias), but we agree that it does not, so the sample is not random and that is why I asked the question. (Why is there a systematic skew?) It does not, however, change the fact that we can look at it as a sampling from a binomial distribution.

(To be taken seriously I suppose I have to say something about myself:
I am not an expert on tuning, but my knowledge of mathematics, statistics and feedback control systems is quite extensive, believe it or not. It should be unneccessary to say things like this, we should be able to ask questions, answer questions when we can and discuss these things without making suggestions of other participants' eventual lack of knowledge, we all stand or fall by our logic and arguments, so let us consentrate on that.)

[yositime]

(Why is there a systematic skew?) It does not, however, change the fact that we can look at it as a sampling from a binomial distribution.

Sorry I'm a little thick here, not much of a theoretical mathematician, but why do you think there is a skew? Could the samples we have access to just look skewed or that the sampling technique is coloring the observations?
If we see all the samples, would the story would be much different, how can we tell?

[Sporty 48]

And to think this started over a question if the addition of a wide band sensor to a narrow band tuning device would enable the tuner to increase power or make the power smoother. Did anyone ever answer that question???
We are getting a little warm sunshine today, more snow is melting, not too much water in the roads.
Going to fire up the trusty Sportster and go do some throttle twisting on the roads, no NyQuil theorems or skewed ECU data readings, no closed loop dilemma, just a little fun.

[hpulven]

Sorry I'm a little thick here, not much of a theoretical mathematician, but why do you think there is a skew? Could the samples we have access to just look skewed or that the sampling technique is coloring the observations?
If we see all the samples, would the story would be much different, how can we tell?

You are right, and we are in agreement. There is a skew because it looks like a skew and the reason is as you say that the sampling technique is coloring the observations. The sampling is done by the ECM by what it decides to put on the bus. If we could see all the samples we would see what was really going on. I was only wondering if anyone could explain the system behind what the ECM is reporting and what it is not reporting. Thank you for asking, I probably should have put it like this earlier on, English is not my first language, so it doesn't always come out the way I want it to.
(It is a pity though, as we are not able to check the health of the O2 sensors by seing the regular, nearly symmetrical switching every second like when I log the sensors in my car.)

[Steve Cole]

The Data Bus was never setup for doing what we are doing with it. So with that in mind the simple truth is that you cannot take what is coming out in a PV log as anything close to what is really happening. I points this out to Andy with one of his own personal captures from his own bike. He was supposed to get answers to the questions that Glens posted but he has never done so or if he has he never posted those answers. With out those answers we are all just guessing at what they are doing with the raw data to get the results they areputting into the log. Going from memory I believe the data was off by about 12:1 ratio and finding which data goes with what is one issue that no one has answered. We are all assuming and at this point and that is not going to help get to the bottom of it.

[whittlebeast]

He was supposed to get answers to the questions that Glens posted but he has never done so or if he has he never posted those answers.

Feel free to post the answer. 

[glens]

Andy, this ain't a personal attack, it's just a question.  Are you really that dense?  You are the first "he" in that sentence.  I guess maybe either you or I could be taken as any of the later "he"s in it.

Let me boil this down for you:

You made like you were peas in a pod with the DJ guys.

I asked you to ask them how they're deriving their "AFF Channel".

You said you would.

We're still waiting.

Once you post that information you'll have come through with your end of it, and I won't need to post anything because you already will have done so.

[Steve Cole]

He was supposed to get answers to the questions that Glens posted but he has never done so or if he has he never posted those answers.

Feel free to post the answer.

I already did that before but also stated I had to assume what they were doing. It perfectly clear that what they are doing is incorrect from your logs. To try and get to the bottom of it you really need to know, with out assuming. Your response was that you would get the information and post the answers as to how they were getting data that is not there and how to sort the PVrecords so you could get down to the real data. Then for Glen you also said you would get the answers to his questions. You take the PV data and make assumtions to make your plots look like you think they should, this is why you have to use forumla to change the data. So you start with fake, bad or corrupt data and try to filter it you still end up with fake, bad or corrupt data. All you need to do is get the answers you said you could get. Then everyone can make use of it.

[whittlebeast]

So do we need to assume every piece of data out the port is fake date from PW to timing... You name it.  It is all fake and BS?

Beast

[Steve Cole]

Never said that at all, how you coming on those answers?

[whittlebeast]

This is looking more and more like the only way that the only can tune one of these bikes with data you can believe is using a PowerVision to log the RPM, MAP and TPS off the data port and then use the wideband option to log the AFR.  Cool Steve for straightening all of this out for us.

Beast

[14Frisco]

Good day! Axe-handles.

[Tsani]

This is looking mere and more like the only way that the only can tune one of these bikes with data you can believe is using a PowerVision to log the RPM, MAP and TPS off the data port and then use the wideband option to log the AFR.  Cool Steve for straightening all of this out for us.

Beast

No Andy, it just simply looks like only you can tune one of those bikes with data you believe in using PowerVision. Don't know what the problem is, I have several sporty's here in the garage tuned with TTS and doing just fine.  If you have a method that helps DIY's, then back it up Andy. That seems like something you don't care to do. Your like that Govenor in The Best Little Whore House IN Texas who just keeps doing his side dances.  IMHO, it seems to me that your "method" is simply a glorified scattergraph version of Colortune using a lot of hit or miss guesstamates of 3% changes while pushing the PV as your proof that it all works. That you have a axe to grind with Steve is clear. This just isn't the place for it. And if I were the Folks at PV, I would ask ya to back off on pushing the product. Your lousy at selling it. Ain't no way I would consider it now. Any good salesman would be willing to prove the product works. And BTW Andy, I ride above 2500 RPM and use more than 15% Throttle, at least two hours a day even. Yeah, Like I said, I read. Even at the XLForum, which I have been poking around at before you got here. And no, I won't send you my data logs.  Now I know I ain't no brainiac, nor a well known and proven tuner, nor do I claim to be. But I will say that your posts have caused me to look at tuning in a different way say so to speak. But the more you spout, without proof, the more it looks like I made the right choice. I started reading your posts back in 2005, and peeked in here and there. Seems to me you been chased out of a few forums for the same crap you are pulling here. Looks like it's time to "Potty mouth" or git off da pot my man.

[glens]

Well, Andy, at least it seems you're trying to actively enter into some actual dialogue.  Too bad the only place it makes any sense is in the Andy world...

Let's look at what's currently going on here.  You use data taken from a device that oversamples an undersampled data set.  The device replicates all last-known values at the oversampled rate until such time as a new value is obtained, then resumes the process.  The various data therefore often doesn't correspond with the other data currently being replicated since not all of the items get updated at the same time.  You then take this faux data stream and mathematically manipulate it until it looks better to you, and "tune" (and "retune" and "retune" and "retune") engine systems with it.

This device also derives various data with no explanation, which it also replicates the way it does the real data, and which you also use in your manipulation.

You are repeatedly advised that the information itself, even if/when properly gathered and collated, still isn't very suitable for doing what you're trying to do with it.

You "participate" in several forums, constantly requesting folks send you datalogs from this system and from the TTS system, the longer the better, like as if you'll be able to plot some Rorshasch images with the information and discover secrets or something therein.

You come here trying to bait folks with intimate knowledge of the Delphi system into divulging some hidden secret you imagine must be there, and want to know, which you think they might know, only so you can use it against them in an attempt to prove them either liars or idiots.  Does that fairly sum it up?

I believe you have had to by now gotten the common notion regarding you firmly cemented into place, Andy.  Congratulations!

On a personal note, I've about reached the limit of what I can do to try to actually communicate with you.  It brings to mind the definition of some state/activity being "doing the exact same thing over and over again, expecting a different outcome".

Good luck.

[glens]

Andy ... git off da pot...

You know, you might just be on to something there!  That would explain a lot. 

[Jeffd]

You "participate" in several forums, constantly requesting folks send you datalogs from this system and from the TTS system, the longer the better, like as if you'll be able to plot some Rorshasch images with the information and discover secrets or something therein.

You come here trying to bait folks with intimate knowledge of the Delphi system into divulging some hidden secret you imagine must be there, and want to know, which you think they might know, only so you can use it against them in an attempt to prove them either liars or idiots.  Does that fairly sum it up?

bingo

[glens]

This is looking mere and more like the only way that the only can tune one of these bikes with data you can believe is using a PowerVision to log the RPM, MAP and TPS off the data port and then use the wideband option to log the AFR.

One more attempt, I guess.

Andy, you can save a lot of money in the long run by getting a TwinScanII+ kit.  With it you can log all the data, in conjunction with a set of broadband sensors, without lugging a laptop along, and later go back to your desk and use the included software to generate valid VE and spark tables.  And you can so generate calibrations for any number of bikes with it, without incurring further cost for the kit beyond the initial acquisition.  Naturally, it'll require some type of other device with which to write the calibration to each ECM, there's no getting around that.

This option has been available for at least 4 years that I'm aware of.

The only really new things brought to the table by the PowerVision so far is the combination of touch screen and faux data acquisition.

[wurk_truk]

 

+1 on the Twin Scan Plus Kit.

[Steve Cole]

This is looking more and more like the only way that the only can tune one of these bikes with data you can believe is using a PowerVision to log the RPM, MAP and TPS off the data port and then use the wideband option to log the AFR.  Cool Steve for straightening all of this out for us.

Beast

This is looking more and more like the only way that anyone can get an answer to a question from you is to not ask one. You stated that you were working with DynoJet Engineers and that you would get answer to some very basic questions that have been asked, why now is it that after several weeks you are still dodging what you already said you would do? For the record the PV is not a pile it just has some issues that are causing it to put out wrong data.

How you can take that to its the only way to tune is beyond me. You want to take data that is wrong, massage it until you think it looks good and then say it good data. Sorry but that just does not work and anyone who understands basic data acquisition knows better.

There are lots of ways to properly tune but what your doing just isn't one of them.

[Sporty 48]

So a wide band sensor is useful at full throttle, high rpm runs.
But the response time is slower than the narrow bands.
How does the wide band sensor assist tuning during those WFO runs?