The effects of AFV on open loop areas

[glens]

Specifically:

If a normal closed loop tune contains open loop cells such as idle and lets say 80 kpa and above will the afv correct the entire afr table or just the cells that are in closed loop.

Actually, idle would usually be included, and the part about "the AFV" has been addressed.  In answer to your direct question "Will the entire table or just marked-as-closed-loop cell[s be affected]?", the answer would be "the entire table".

I can see the ecm adjusting the closed loop cells, but the cells in open loop that the ecm is not collecting o2 data for, I would not I would not expect the afv to change these cells.

Why would you not expect them to be affected?  (or why would you expect them to be not affected?)

The DBW throttle control table only goes to 2500 rpm, does that mean there's no throttle control above that speed, or does it mean that whatever's in that last row gets carried over to the higher speeds?  Obviously, it's the latter. 

Why would it be so hard to envision an "AFV table" which gets treated the same way?  A limited scope of cells which can receive updates, with the outer bounds being carried over to further operational areas which cannot receive their own updates.  That's the way I'd do it and I'd bet that's the way the folks that did it did it.  It's a sensible method

[cts1950]

I am just trying to get a definitive answer, to eliminate any guessing and tie this info down. I have been told that the ecm dose not care about cells in open loop and why should it care in this instance.

[mayor]

If Delphi didn't write in ability to remove fuel as needed in the outlying areas of the fuel tables, and MoCo came along and added the functionality, I'm glad for it.  It's much more sensible that way.

why do you feel it's more sensible?  I would rather err on the side of caution (richer), especially since the change in afr before perceptable difference to the operator for a good running bike is quite broad. 

[blusmbl]

Without being able to read the c code, or attempting to test it, we're all just guessing here.  I know what other manufacturers do (the last adaptive fuel values are extracted up to full load, and can both add and remove), and I can theorize on how our module works, but I'd trust Steve over a Delphi source because I would not be surprised if Steve changes a bunch of things in the base cal and changes the code with each .mt release.

It would be easy enough to check if you had a wideband, just fudge the last couple closed loop-enabled VE columns high by a significant amount, let it adapt, then see if WOT is leaner than when you started.

[whittlebeast]

Without being able to read the c code, or attempting to test it, we're all just guessing here.  I know what other manufacturers do (the last adaptive fuel values are extracted up to full load, and can both add and remove), and I can theorize on how our module works, but I'd trust Steve over a Delphi source because I would not be surprised if Steve changes a bunch of things in the base cal and changes the code with each .mt release.

It would be easy enough to check if you had a wideband, just fudge the last couple closed loop-enabled VE columns high by a significant amount, let it adapt, then see if WOT is leaner than when you started.

Great answer. 

A Power Vision with the wideband option exposes and logs most of this stuff.  In many of the code versions , this stuff can be turned on and off.  I happen to run the Sporty with closed loop on but with adaptive learning turned off.

Beast

[1FSTRK]

If Delphi didn't write in ability to remove fuel as needed in the outlying areas of the fuel tables, and MoCo came along and added the functionality, I'm glad for it.  It's much more sensible that way.

why do you feel it's more sensible?  I would rather err on the side of caution (richer), especially since the change in afr before perceptable difference to the operator for a good running bike is quite broad. 

Mayor
I believe the idea is to not error or to error less. If you have a good tune on both open and closed loop areas and you get a full tank of fuel that requires the closed loop area to be adjusted leaner to be in tune then wouldn’t you expect that same amount of lean offset would be correct when applied to the open loop area. It is after all burning the same fuel.
It comes down to believing the O2s and the ECM can do the job of keeping the tune when conditions change.
I think there is some confusion because we are used to thinking in terms of using this system to reverse engineer the ve tables to create new ones for performance upgrades, when it was design to hold a correct tune in tolerance by making adjustments for changing conditions.

[mayor]

I believe the idea is to not error or to error less. If you have a good tune on both open and closed loop areas and you get a full tank of fuel that requires the closed loop area to be adjusted leaner to be in tune then wouldn't you expect that same amount of lean offset would be correct when applied to the open loop area. It is after all burning the same fuel.

so, let's say that the tune was based on an E10 blended fuel...and you were lucky enough to get some real gas for a tank ride, how much perceptible difference would the operator feel if the AFV's reduce the desired pulsewidth in the open loop areas to account for the less needed fuel to reach the desired afr in those settings?  How much different would the bike run, if the AFV's didn't get applied to the open loop areas   I doubt that the average person could tell the difference.     The window for power generation in regards to afr is broad, but the leaner settings of this window create heat.  Most of the time, richer fuel settings are more to control heat...not necassarily to produce more power. This is why I would prefer to err on the richer side (not rich, but rather richer side of stoich).

It comes down to believing the O2s and the ECM can do the job of keeping the tune when conditions change.

The very nature of the narrow band system does not allow for 100% closed loop operation, so why would anyone want this system to behave that way when the programmer specifically tells the ecm to ignore certain areas (by setting them to open loop)? Another way to look at it is with certain pipes/cam configurations the data obtained by the sensors may be skewed, so the applied AFV's could make the bike run worse than if the data was ignored altogther (like the programmer intended by switching to open loop).  My guess is this is what Wurk is worried about happening. 

I think there is some confusion because we are used to thinking in terms of using this system to reverse engineer the ve tables to create new ones for performance upgrades, when it was design to hold a correct tune in tolerance by making adjustments for changing conditions.

I think the confusion might be on just how minute of change is perceptible to the operator.  Even if the margin of error for reaching the desired afr is broad, the perceptible difference to the operator is broader.  If anyone doubts me on this, just hook an afr meter up to a carb bike and ride around for a while. 

[wurk_truk]

Both the Delphi and the MOCO.

I say invention as opposed to tuner companies saying THEY wrote this, as they did not.  Delphi wrote THE WHOLE code, one as the standard Delphi code and two as a 'project' for MOCO.

I want a definitive answer, too.  FBRR confirmed that OL gets effected by CL AFVS.   The problem for the OP is these OL changes are math derivatives and cannot be matched to the CL portion of AFVs.  The percentages, etc are all different.  Think about it.  OL HAS to be effected, or else when the fuel would dictate...  the OL would/could stay lean unless the AFVs from CL richened them up.

Glens, I'm glad you are back, but now-a-days it looks to us that you have taken over the point in these arguments of Bob.  Used to be you questioned Steve regularly....  Now you don't at all.  A LOT of knowledge has been gained for ALL of us in your absence.

Alcohol plays a BIG factor in all of this.  If tuned with E10, the bike will ALWAYS stay normal or rich in OL regardless of fuel.  But if OL can go leaner than the map, while in OL, then what happens is during the normal swings trying to center up, the OL can go too lean for the engine.  My/our whole point in tuning is to try and exploit little things to make for a better running, richer running, SAFE tune for bikes that have a 'build' going on.  There are those that Fuel Mileage isn't the biggest concern.  The biggest concern is to keep everything within parameters that give built engines the ability to be reliable.  I don't mind that OL would lean back out, with different fuel, to what the map cells are set for, but being able to lean UNDER that?  No way Jose.  It IS cruise that is the worry, too.... on bigger engines.  THAT is THE area one NEEDS to keep nice and cool.  a 400+ mile day, and one could be unaware the bike is leaner than the map...??   That, scares me.  Any throttle movements could be handled by PE settings but having PEs low as 2500 is ridiculous, IMHO.

Lets look at all of the 'failures' of axtell cylinders.  No matter what one thinks, some of these really do have to do with heat being produced during cruise.  I have seen the blue wrist pins, etc myself, first hand.  With our ECM being able to pull timing and stopping ping... cruise is THE danger zone to my way of thinking.  Very easy to overheat this.  Hell a 100% stock bike will overheat this area a LOT.  With higher comp and nonstock cams...  this is NOT a good thing, IMHO.  My stock bike would hit ETMS on the off ramp from a run that was done at 75+ mph for simply two hours.  A 'telling' fact for me is the Ron Dickey, in his personal bike used TTS for the 107 build, but switched to TMax on his 117.  Why?  To keep it rich enough in the cruise areas is why.

A Stage 1 is NOT my concern, what is...  is the ability to keep engines running 100sq and up doing their job, staying cool, and being reliable.  What is left to determine is whether FBRR is correct or Steve.  If it is Steve, I simply wouldn't be able to condone the use of CL in highly modified engines...  And dammit!!!  I've been the lone voice of reason on this issue.

I am/was a huge fan of CL.  I was willing to try CL on my 120r.  I could then argue we tune more CL bikes...  if mine would keep a stable tune.  That kind of tune would call for a small amount of CL that is in play right under cruise, but not IN cruise or idle, or any power making portion of the tune.  One wants it to adapt while riding easy in town and NOT while doing 75+ on the highway.  But, if one cannot minimize the ECM calling out leaner than the map, I am surely ready and willing to go to the dark side and tune everything OL.  Simply tune with 89 E10 and rest assured the bike then can handle any fuel encountered.

[Steve Cole]

Look guys you all need to understand that the AFV's are more than one. Based on the calibration written you can have up to 24 learn cells to store the AFV value in, per cylinder. How those cells are lay'ed out is up to the calibrator. Just because the code takes those values and uses them in open loop is not a bad thing. If the cells within the tables are all 1 then no change is going to occur but if the cell has a stored value of something other than 1 it is going to effect the output for that area of the cell.

In order to run a test you need to first have equipment capable of doing the measurements and then be able to repeat the same test in the same exact conditions. The first thing would be to run in closed loop with the factory O2's fully operational and tune the bike per what the ECM is requesting. You cannot use something outside the ECM as the ECM is going to do what it wants whether you like it or not, so you must first let it settle on what it wants. Once that's done and the correct VE table is generated you need to run for some "X" period of time and record the results. Then reset the AFV's and repeat the test. If the two test come out the same then you have a good base calibration to start the test with. Now take and reduce the VE values across the board 15% and run again "X" time to allow the AFV's to learn. Then repeat the test to make sure these results match the first two test. If they do then the system is adapting as it should. Now reset the AFV's again and run the test with the AFR table dropped from 14.6 to 14.5. This will put it in Open loop and you should see a complete different test result. If you do then things are working as they should.

[1FSTRK]

Mayor

Yes the average person probably would not feel it and it may or may not show up in fuel mileage, but the point I think you may be missing is the AFV when applied to the open loop area in this example will not be causing the bike to run any leaner than the map intended. It will adjust the open loop to hit the originally intended numbers, keeping it from going rich because of the fuel change. Basically what you would have had if you wrote the table using the new fuel to begin with.

Close loop area is held to the engines usable range of the stock narrowband sensors.

This is the stickiest part but I believe the ability to switch from closed loop to open loop is in the program to allow you to add the additional fuel needed to run the AFR richer than the narrow band sensors would allow in the needed areas. I don’t think it was put in as a way to compensate for bad cam/pipe combinations. I do not deny that some people are using it for that purpose, but when you use tools for things other than their original purpose you may loose some functionality. I understand and have experienced this first hand. I have pipes that produce this exact effect, which is why I started this thread. I wanted to clarify how the system actually works so that I may decide how to proceed.
It seems that what we have been doing is turning off closed loop to make up for the fact that we can’t turn off AFV in open loop when we have a motor combination that produces bad affects that AF collects data from in closed loop. 

I feel that it makes as much sense to have AFV cover the entire range on a motor that has a good cam/pipe combo as it does to ask for the ability to turn AFV off because I want to run a combination the has some idiosyncrasies that I am otherwise willing to overlook.   

[glens]

I've long held and stated the opinion that it'd sure be nice to know the layout of the AFV "tables" in any particular calibration (or is it in ECM code that burning a calibration doesn't touch?).  Especially so, perhaps, if it's a fixed table format.  If you're concerned about operation in the bottom and the right of the fuel tables (or does the scheme follow the VE tables instead?) ever going leaner than some figure you think you've got, then merely "strand" the last column and row of the AFV "tables" by dropping them out from closed-loop maintainability.

Likewise, it'd sure be nice to know if the tables dynamically follow the edges of closed-loop coverage and will never "strand" any "AFV cells" in the way envisioned just above.

Also, if you've got a trouble spot where you just can't (or don't otherwise want to) prevent some obnoxious airflow condition without messing up a larger, more desirable area of operation, it sure would be nice to know whether you could or could not isolate that spot from closed-loop, thus prevent that AFV from changing.  Or something like that...

I say invention as opposed to tuner companies saying THEY wrote this, as they did not.  Delphi wrote THE WHOLE code, one as the standard Delphi code and two as a 'project' for MOCO.

It's a can of worms I don't want to open here, but many folks who write software, both for a living and for a hobby, feel that putting different combinations of code together does not truly fall under the classification of "invention".  Creating a new programming language, maybe, but merely using an existing one, even in novel ways?  Nope.  It'd be akin to applying for (much less getting) a patent on striking a nail with the side of a hammer head.  Anyway...

The problem for the OP is these OL changes are math derivatives and cannot be matched to the CL portion of AFVs.  The percentages, etc are all different.

I don't know if we're agreeing or not here.  If your VEs are proper everywhere, why wouldn't a 4% change on the border of where the AFVs get generated translate accurately on out the rest of the way?  Either direction?

Glens, I'm glad you are back, but now-a-days it looks to us that you have taken over the point in these arguments of Bob.  Used to be you questioned Steve regularly....  Now you don't at all.  A LOT of knowledge has been gained for ALL of us in your absence.

If Bob and I hold similar opinions then either it's pure luck on one of our parts or we at least come to the same conclusions based on processing the information similarly.  I highly doubt Bob molds his opinions based on what I have/had might say, and I know it doesn't happen the other direction either.  At least not blindly at any rate.

I have largely quit asking Steve some kinds of questions because he has either answered them already or I surmise it would be pointless.  Steve knows a lot, likely more than any non-MoCo_code_writing Delphi engineer, but some things either he can't know for sure or sure can't say here.

"A LOT of knowledge has been gained for ALL of us in your absence."  Whew!  I'm glad you didn't say from or by my absence! 

Alcohol plays a BIG factor in all of this.  If tuned with E10, the bike will ALWAYS stay normal or rich in OL regardless of fuel.  But if OL can go leaner than the map, while in OL, then what happens is during the normal swings trying to center up, the OL can go too lean for the engine.

I guess that would depend on factors relating to the strategy and how it's implemented.  Does the scheme go ahead and throw preliminary corrections at all the AFVs after confirmation "at the mouth of two or three witnesses" (so to speak) immediately after a significant-enough rise in the fuel level?  (Might be wise to do.)  How rapidly at any give time does the system update the AFVs?  Are there situations looked-for which either speed up (example already contemplated) or slow down the process?  Where are the damn things?  There are a lot of questions which, as I speculated, either Steve can't say for sure or, really, can't say.  And don't neglect the notion that trying to "crack the code" can run one afoul of the Fed as often as not anymore.

Does the average Joe need to concern himself with these intricacies?  Hell no.  But there are some of us who get off on just such kind of information; and maybe will or maybe won't actually go ahead and make use of it on our or others' bikes for good or otherwise.

I dearly hope you do ferret out just exactly what's going on (in a '12 Touring ECM, for sure!) in this matter; and that you share the information with at least me

[Steve Cole]

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.
3. Are they all the same for each application from HD, NO.
4. Can the AFV's by themselves be switched off and on, NOT IN ALL SOFTWARE
5. If Whittlebeast did a little real testing he would have figure this out by now, as it cannot be switched in a Sportster calibration.
6. Does it really matter where they are setup, I believe so.
7. AFV's are what they are and they work if you let them.
8. Closed loop and AFV are not one in the same but one needs the other to work.
9. AFV's can only be updated when running in closed loop operation.
10. AFV's can be used in both Open and Closed loop for corrections only.

That about covers it. You need to stop worrying about thinking out as AFR is everything. NONE of the meters measure AFR, they measure the difference in O2 level in the exhaust versus what in the surrounding air, that's it! So the Closed loop system is all about keeping that ratio as close to the same as possible and it does it nicely when setup properly to start with.

All I can say is our 120R test program gets checked roughly every 1500 miles, we are 8000 miles in an it produces the same power and torque now as it did when it came off the dyno. The  AFR measurement are the same within the accuracy of the measuring equipment. So it can be done and it does work with what I would call a big engine and cam combination with a pretty open exhaust 2:1 system on it. It should be back soon for the 10,000 mile check out.

[1FSTRK]

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.
3. Are they all the same for each application from HD, NO.
4. Can the AFV's by themselves be switched off and on, NOT IN ALL SOFTWARE
5. If Whittlebeast did a little real testing he would have figure this out by now, as it cannot be switched in a Sportster calibration.
6. Does it really matter where they are setup, I believe so.
7. AFV's are what they are and they work if you let them.
8. Closed loop and AFV are not one in the same but one needs the other to work.
9. AFV's can only be updated when running in closed loop operation.
10. AFV's can be used in both Open and Closed loop for corrections only.

That about covers it. You need to stop worrying about thinking out as AFR is everything. NONE of the meters measure AFR, they measure the difference in O2 level in the exhaust versus what in the surrounding air, that's it! So the Closed loop system is all about keeping that ratio as close to the same as possible and it does it nicely when setup properly to start with.

All I can say is our 120R test program gets checked roughly every 1500 miles, we are 8000 miles in an it produces the same power and torque now as it did when it came off the dyno. The  AFR measurement are the same within the accuracy of the measuring equipment. So it can be done and it does work with what I would call a big engine and cam combination with a pretty open exhaust 2:1 system on it. It should be back soon for the 10,000 mile check out.

Steve
Thanks again for posting here and trying to help us get some understanding of this AFV thing. I think with the help from this thread I have some handle on how to make it work for me now.

I will be doing some testing and tuning with different exhaust changes over the winter to solve some of my incompatibility issues.

My Question to you is this:
Do the AFV differ enough from base cal to base cal that I should be testing different base cals to find the one that works with my combination?

[whittlebeast]

This is the Sporty calibration I have been running for several years opened up in PowerVision.

http://www.ncs-stl.com/PVTune/PVLimitsAndSwitches.jpg

Beast

[Steve Cole]

whittlebeast

Andy that's just my point. Just because you see it, you believe it and that is the problem. The same as you believed the PV was reading more data from the ECM, just BS. There are things that are not what they seem and YOU need to test them prior to claiming what you do. Once you start doing some real testing maybe you can begin to understand how these things really work.

1FSTRK

Trying various base calibrations is always a good thing when you do not have a match to your parts as there is much more in a base calibration that may match what you have besides AFV's.

[whittlebeast]

Early in testing the capabilities of the PowerVision, I was testing on the bike with the tune I had been running for a couple of years.  For the last 1000 miles or so, I had o2 eliminators on the bike.  The field named VENewFrontPctPV is a "Manipulated" field that is

100*[VE New Front]/[VE Front]

The field names Front AFF is coming from the PowerVision data stream.  I would have to say the correlation is strong.

http://www.ncs-stl.com/PVTune/AdaptiveFueling.jpg

The same data but zoomed in tighter

http://www.ncs-stl.com/PVTune/AdaptiveFuelingTight.jpg

Note that my bike is only in closed loop at very low power output.  Essentially the bike is only in closed loop when coasting or idling.

Beast

[cts1950]

It sure looks like everything above 3000 and 50 kpa is near a multiplier of 100. It must be adding a little fuel above idle to 2200.

[glens]

Have the PowerVision guys got back to you yet with how they're deriving "AFF"?

A quick glance would seem to indicate that by shrinking the closed-loop coverage you're able to hang AFV cells out to dry.  Assuming the data is valid-enough to draw such conclusions.

[whittlebeast]

Have the PowerVision guys got back to you yet with how they're deriving "AFF"?

A quick glance would seem to indicate that by shrinking the closed-loop coverage you're able to hang AFV cells out to dry.  Assuming the data is valid-enough to draw such conclusions.

I have not asked about the AFFs as we normally talk about far more interesting issues and features in the pipeline.

I have not seen any issues in the data feeds that lead me to question it's validity.  Sure there is a bit of data here or there but we never come to conclusions based on random data.  We are always looking for patterns in the majority of the data.

In this trace, would you worry about the few random yellow dots or would you concentrate your effort on the blue blob?

https://idisk.mac.com/ryser//Public/PowerVision/Geeksters2-1_wb_man_3.png

Beast

[cts1950]

It is rather obvious that the rear at 2250-2500 and 40-60 kpa needs more fuel.

[Steve Cole]

Have the PowerVision guys got back to you yet with how they're deriving "AFF"?

A quick glance would seem to indicate that by shrinking the closed-loop coverage you're able to hang AFV cells out to dry.  Assuming the data is valid-enough to draw such conclusions.

I have not asked about the AFFs as we normally talk about far more interesting issues and features in the pipeline.

I have not seen any issues in the data feeds that lead me to question it's validity. Sure there is a bit of data here or there but we never come to conclusions based on random data.  We are always looking for patterns in the majority of the data.

In this trace, would you worry about the few random yellow dots or would you concentrate your effort on the blue blob?

https://idisk.mac.com/ryser//Public/PowerVision/Geeksters2-1_wb_man_3.png

Beast

Did you bother to read what everyone has pointed out to you with your own PV data logs? Did you get it explained to you why they FAKE data and add it to the logs at a ratio of about 10:1? If you cannot see anything wrong in the data logs you've posted the rest of it is really quite meaningless. This is NOT random data as your trying to brush it off as it's a 10:1 ratio and that is clear as a bell when you look at the data files as supplied by you!

So if you could strip out all the FAKE data the resulting graphs would look completely different by a ratio of about 10:1 and that is NOT random data, That is HUGE. There is a very old computer saying, CRAP IN CRAP OUT and that just what all of this is. Until you solve the base data issue the rest is just more .............

[cts1950]

"Look guys you all need to understand that the AFV's are more than one. Based on the calibration written you can have up to 24 learn cells to store the AFV value in, per cylinder. How those cells are lay'ed out is up to the calibrator. Just because the code takes those values and uses them in open loop is not a bad thing. If the cells within the tables are all 1 then no change is going to occur but if the cell has a stored value of something other than 1 it is going to effect the output for that area of the cell."

"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.
3. Are they all the same for each application from HD, NO.
4. Can the AFV's by themselves be switched off and on, NOT IN ALL SOFTWARE"


How is this not different from the Harley Hidden Tables  Whittlebeast has been asking for for years. He just did not know the name of the tables He should have been asking for the TTS hidden tables. 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. That is kind of like the Microsoft sales person saying that is not a bug that is a Feature.

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.
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 suspect you are using the ve new once you have filtered it and using it to populate your 24 afv cells per cylinder.

[Steve Cole]

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.
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 suspect you are using the ve new once you have filtered it and using it to populate your 24 afv cells per cylinder.

Cannot say if they have done it on purpose or not but the simple fact is they are inserting data where it does not belong. I am not commenting on anything other than the fact that the PV logs as posted by whittlebeast are loaded about 10:1 with fake data. Whether or not the data in any column is accurate or not is a different discussion and could only be tested by side by side testing. The HD ECM will only send a small packet of data about every 25ms. That packet will contain as few as 2 items to a max of 6 items. To get a frame of data you must get multiple packets and you cannot just fill in what you want when you want too and expect things to work correctly. So some simple math shows the problem in the datalogs as posted by whittlebeast.

So if they are not showing/displaying the data correctly who know what goes where? One would need to know how they are doing it, to take the fake data back out of the logs to see what is really going on. Then you could work with whats left.

[whittlebeast]

So has anyone here actually done a test?

try this...

Tune your bike with all AFR targets from 15-80 kpa to 14.6 or Lambda 1.00 just like a vtune.  Once tuning is done, do several WOT runs and get a good feel for the PW that the ECU is sending to the injectors as the motor passes thru the higher revs.

Now set your VEs in the 15-80 kpa range to 95% of what you use on that fully tuned  bike.   Ride the bike for a few long rides.  This should convince your ECU that the motor is running 5% lean for some reason, so it should run most of your AFFs up to 105.  If you have a PowerVision, turn on Front AFF and Rear AFF on the display and you can watch all of this stuff happening on the fly.

Now if all this stuff is working as people claim and you have a code with Adaptive fueling turned on, you should get 5% more fuel at WOT.  Keep in mind that the first ms or so of commanded PW does not count so the change in PW should be right at 104.5% of the first test +/- a little.  If the WOT PW is the same, then the trims do not have an effect on the top end.  Hopefully the weather is close in the two tests.  You can always toss the original map back in the bike and clear the trims and get better back to back testing.

Have fun tuning

Beast

[BVHOG]

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.