Tune drift

[hrdtail78]

Is open end cap +2 suppose to flow the same 12 and a closed?  Is that 3 inch disc or 4 or 5?

I have done a fair amount of ST testing and have not found this to be accurate.   Really depends on the build and cam.  I have tuned  95 that wanted 24 and open.   I have tuned a 124 that wanted 18 and closed.   Give the bike what it wants by the data that bike is showing.   Even custom size holes in the closed end cap help.

[slo-poke 03]

I have been reading this tread for a while, and can't add much except to say, this kept happening to me. It would run good for a while, then start to stutter and miss down low at certain points. I would reload the map and it would be ok for a while, then crap out all over again. Very annoying. Is tune drift real, does it happen, you guys know a lot more about this stuff than me, I can only speak to my experience.

[FLTRI]

...Why 2 discs, open end = 10 discs + 2 for 12 and the open end for more noise...

Open end cap + 2 discs is = to 12 discs which is recommended by Supertrapp on there forum for good overall performance.

Went looking for this recommendation but to no avail. Been tuning Supertrapps for a long time and yet to see or hear of 2 discs + open end cap as a recommended install.
As I mentioned, start with 8-10 open end cap if you want performance and sound.
2 discs are just not enough for the system to work as advertised.
By tuning to 2 discs/open cap you may just be leaving a bit of performance on the table. Why not get best performance with added noise level?
Bob

[glens]

I have been reading this tread for a while, and can't add much except to say, this kept happening to me. It would run good for a while, then start to stutter and miss down low at certain points. I would reload the map and it would be ok for a while, then crap out all over again. Very annoying. Is tune drift real, does it happen, you guys know a lot more about this stuff than me, I can only speak to my experience.

Yes, it can happen.

We're speaking about closed-loop specifically, and how the O2 sensors get bad samples which ultimately drives the system to make improper self-adjustments.

It ("tune drift") can also happen without O2 sensors, but that's a slightly different color horse.

It's imperative that any sensor is getting valid input and giving valid output.  If the input is good but the output ain't, look at the sensor itself.  If the input is bad, the sensor may be either good or bad, but how can you know without a valid touchstone?

Furthermore, a tune generated with sensors that for whatever reason are not providing valid output is going to be problematic from the get-go.

In the big picture, I can see how marketing tuning devices to the general public isn't a real great idea.  The user needs to be able to understand, really understand, what it is they're doing, how engine control systems work, and how to go about addressing issues in order to have consistent success.  Unless they're just plain lucky and/or don't stray from well-worn pathways...

This kept happening to me.

Is it still happening or how did you address the issue?

[rbabos]

Is open end cap +2 suppose to flow the same 12 and a closed?  Is that 3 inch disc or 4 or 5?

I have done a fair amount of ST testing and have not found this to be accurate.   Really depends on the build and cam.  I have tuned  95 that wanted 24 and open.   I have tuned a 124 that wanted 18 and closed.   Give the bike what it wants by the data that bike is showing.   Even custom size holes in the closed end cap help.

His v rod has two fat shots on it. Me, I run 12 per can with closed end. They say (Supertrap) that 8 disc per can equals stock exhaust and stock tune is uneffected. I'd did try it with 8 per can to evaluate that statement, but the dealer demo bike I took out had this setup. Only rode mine 200 kms before winter set in and then swapped over to Fatshots (4") an the PV. My bike full stock and the dealer bike both had that launch hesitation before reaching normal engine temps however. Didn't care much for that.
Ron

[q1svt]

Super Trapp Resource Center / FAQ's

[slo-poke 03]

I have been reading this tread for a while, and can't add much except to say, this kept happening to me. It would run good for a while, then start to stutter and miss down low at certain points. I would reload the map and it would be ok for a while, then crap out all over again. Very annoying. Is tune drift real, does it happen, you guys know a lot more about this stuff than me, I can only speak to my experience.

Yes, it can happen.

We're speaking about closed-loop specifically, and how the O2 sensors get bad samples which ultimately drives the system to make improper self-adjustments.

It ("tune drift") can also happen without O2 sensors, but that's a slightly different color horse.

It's imperative that any sensor is getting valid input and giving valid output.  If the input is good but the output ain't, look at the sensor itself.  If the input is bad, the sensor may be either good or bad, but how can you know without a valid touchstone?

Furthermore, a tune generated with sensors that for whatever reason are not providing valid output is going to be problematic from the get-go.

In the big picture, I can see how marketing tuning devices to the general public isn't a real great idea.  The user needs to be able to understand, really understand, what it is they're doing, how engine control systems work, and how to go about addressing issues in order to have consistent success.  Unless they're just plain lucky and/or don't stray from well-worn pathways...

This kept happening to me.

Is it still happening or how did you address the issue?

I know I will probably draw fire on this, but I got a thundermax and it was problem solved. It (for me anyway) was easy to use, easy to understand and tune. Changes are easy to see, easy to make. I like it very much, and I have tried other tuners and wish I had my money back.

[FLTRI]

Super Trapp Resource Center / FAQ's

So your recommendation?

[hrdtail78]

"About" can mean different things on different combinations. 

[FLTRI]

Good point Jason. I guess I've never used just 2 discs on any Supertrapp but I'm willing to try it.
Bob

[q1svt]

Super Trapp Resource Center / FAQ's

So your recommendation?

That his information as to the relationship between open/closed end caps...

[/quote]

Bike is a 14 DX, standard air filter and supertrapp fatshots, open end caps with 2 discs and a PV1

Open end cap + 2 discs is = to 12 discs which is recommended by Supertrapp on there forum for good overall performance.
I have no problem with the performance when the tune is good, I only want to fix the drift.

"About" can mean different things on different combinations. 

His bike is pretty stock and running equivalent to 12 discs, and if he's happy with the tune* then adding discs isn't going to fix the OP 'Tune Driff'

* and we all know that performance displayed on a dyno [WOT pulls] doesn't directly transfer to the track or the street...

[rbabos]

What baffles me is , lets say the tune was derived from using the O2 senors to a condition where the bike runs good . In that case the tune should hold since all the sensors do is follow that from then on, right?  Something else is going on. Poor sampling was used to create the tune where it runs good so there's no reason the tune should change after the fact with the same poor sampling. Excuse my logic.
Not being able to get the bike to run right during autotuning, then I can buy the sampling theory.

Ron

[whittlebeast]

Was there ever a log posted on this bike?

[joe_lyons]

It would be interesting to see the CLI and Adaptive values as the temps changed.

[upnorthbiker]

Hi, I've never posted a log, I can do a log at the weekend,
What would channels would you like me to log ?
Jeff

[rbabos]

It would be interesting to see the CLI and Adaptive values as the temps changed.

Ron

[whittlebeast]

Hi, I've never posted a log, I can do a log at the weekend,
What would channels would you like me to log ?
Jeff

This is the list of fields I tend to log.

Acel Enr
Advance F
Advance R
Decl Enl
ET
Front AFF
Front CLI
Front Fast Retard
Front O2 V
Gear (The first one)
Idle Set
INJ PW F
INJ PW R
IONQ1
IONQ2
MAP
Rear AFF
Rear CLI
Rear Fast Retard
Rear O2 V
RPM
Set AFR
TP
VE Front
VE New Front
VE New Rear
VE Rear
VSS
Warm-up AFR

[glens]

That's a nice comprehensive list, but the trouble is the data rate is going to be dismal.  Maybe better to break it up into smaller chunks and gather several logs.

Ron, I'm in agreement with you.  If the sensors themselves are used to generate the tune and it subsequently changes, it pretty much has to be temperature related somewhere somehow.  Or the tune-generation steps don't include (or allow) really real-world conditions.

My suggestion is to use the most-final calibration as the basis for a day-long logging session from which to generate a new calibration and see what the software comes up with.  I forget but assume this is a PV we're discussing.  Can you do that with the PV or does it limit one to specially-crafted calibrations (stuff like CLBs @450, lambda=1, etc.) for that purpose?  If that's the case (specially-crafted only), then that may be the basis for the problem.

I know I'd be aggravated by such an ongoing situation...  Time to think outside the box a little.

[joe_lyons]

That's a nice comprehensive list, but the trouble is the data rate is going to be dismal.  Maybe better to break it up into smaller chunks and gather several logs.

Ron, I'm in agreement with you.  If the sensors themselves are used to generate the tune and it subsequently changes, it pretty much has to be temperature related somewhere somehow.  Or the tune-generation steps don't include (or allow) really real-world conditions.

My suggestion is to use the most-final calibration as the basis for a day-long logging session from which to generate a new calibration and see what the software comes up with.  I forget but assume this is a PV we're discussing.  Can you do that with the PV or does it limit one to specially-crafted calibrations (stuff like CLBs @450, lambda=1, etc.) for that purpose?  If that's the case (specially-crafted only), then that may be the basis for the problem.

I know I'd be aggravated by such an ongoing situation...  Time to think outside the box a little.

I believe the sample rate is the same it's just the size of the file gets bigger faster with the more fields you log.

[hrdtail78]

Data is going to be read at same speed.  Just takes longer to come around again. 

I'd say that the overall sample rate would be the same, but for the individual channel it would slow down.

[glens]

Data is going to be read at same speed.  Just takes longer to come around again.

That's pretty much what I was getting at.  The rate the data comes is the same but since there's so much of it requested, each "channel" effectively slows down.  Would want to miss as little as possible in this case, thus the suggestion to decrease the requested information, effectively increasing the data rate.

[Steve Cole]

That's a nice comprehensive list, but the trouble is the data rate is going to be dismal.  Maybe better to break it up into smaller chunks and gather several logs.

Ron, I'm in agreement with you.  If the sensors themselves are used to generate the tune and it subsequently changes, it pretty much has to be temperature related somewhere somehow.  Or the tune-generation steps don't include (or allow) really real-world conditions.

My suggestion is to use the most-final calibration as the basis for a day-long logging session from which to generate a new calibration and see what the software comes up with.  I forget but assume this is a PV we're discussing.  Can you do that with the PV or does it limit one to specially-crafted calibrations (stuff like CLBs @450, lambda=1, etc.) for that purpose?  If that's the case (specially-crafted only), then that may be the basis for the problem.

I know I'd be aggravated by such an ongoing situation...  Time to think outside the box a little.

I believe the sample rate is the same it's just the size of the file gets bigger faster with the more fields you log.

Just to make sure you guys understand this as I have said it many many times.

YOU cannot change SAMPLE RATE. The bikes with a 4 pin connector on the DTC connector which is what HD used prior to switching to HDLAN/CAN (6 pin) is slightly less than 4 data frames per second with anything other than a TTS Unit. Since we write our own code and change things in this area we can and do speed that up where we can. That said, you still have to do it correctly or your going to get data like Rabos has posted with clear errors in it. The data comes out only so fast and the more you ask for the longer between it takes.

So YES, it does matter how much you ask for and how it's done. Remember that at idle 1000 RPM you are firing the spark plug ~8 times a second and at 6000 RPM your doing 50 times per second! With data limited to 4 times per second you can clearly see how much you have to miss to start with!

[joe_lyons]

That's why bigger logs help with getting the averages as that's what we have to deal with.  Just like you said, firing events are not the same time after time but we have to play to the averages.  It's the oddities and trends that we look at and say "why are you there".

I still haven't had a good chance to view Ron's log with Power Core or MLVHD.  At what point did you guys find the anomalies.

[rbabos]

That's why bigger logs help with getting the averages as that's what we have to deal with.  Just like you said, firing events are not the same time after time but we have to play to the averages.  It's the oddities and trends that we look at and say "why are you there".

I still haven't had a good chance to view Ron's log with Power Core or MLVHD.  At what point did you guys find the anomalies.

I'm sure each of our anomalies are slightly different. Chris for example ran my latest edited cal with adative off on a trip. At first it ran fine but then it started misbehaving from 4500 on down. I've never had issues below 3750, usually 2750-3500 at most. He currently is supplied with 3 more cals to try. One with the +4 to the whole ve tables other then the idle and 1500 which are only +2. Above 5k was not changed as they were done with AT100 anyway. This time all switches off. Adaptive disabled, closed loop disabled and heated sensors disabled. Second cal with lowered afr to 13.8 in light load and  14.0 to 4500 rpm. Last cal is the one that ran great for a while on the trip then changed. On that one only change was to turn off all switches.  All of these cals are open loop. The object is to determine if temp or baro compensation to the cal is causing it, since nothing else should influence it now.

Now, my situation. I'm closed loop, tuned nicely and no adaptive. I cannot make it miss anywhere in any condition.  If I turn the switch to 1 for adaptive the cal instantly leans. The miss re-occurs in the 3200 area when temp is under 200 as in 180-190ish. The miss clears up over 200 but the exhaust remains poppy under light load. Same effect of me pulling 6-10 ve points in that area, base on knowing what it took me to get rid of the miss in the first place.
I'd not worry about reading the logs I sent.
What I can do is supply you with the good current closed loop cal, one log run with adaptive off and
one log with the same cal but with adaptive enabled if you wish. Let me know.
Oh, and thanks for sucking me back into this . I'm only doing this to find a reason and possible solution to this drifting. I'm fine with how my bike runs as would any serious critic however it would be nice to find out if it's software related somehow. I'm sure you have plenty of v rod MTE's also if code is the issue? Then it would be a work around situation, that I've adopted for my tune and no point going further.
Ron

[hrdtail78]

That's why bigger logs help with getting the averages as that's what we have to deal with.  Just like you said, firing events are not the same time after time but we have to play to the averages.  It's the oddities and trends that we look at and say "why are you there".

I still haven't had a good chance to view Ron's log with Power Core or MLVHD.  At what point did you guys find the anomalies.

I have found it is better to get logs that have 30-50 hits in each cell over a log that has 200-300 hits in some cells and 10-15 in some.  A 15-20 minute log that hits every cell with in reach, over a 3 hour log that is just collecting data in the same cells.  Quality of data over quantity. 

A vrod MTE is going to tell us nothing about a vision tune.  An MTE that is pull out of an ECM that has a vision calibration?  Yes, but I believe that bridge is burned.  I am no longer interested in assisting.  Just keep throwing VE corrections at it in big chunks with no rhyme or reason.  I'm sure you'll get it.  IME open exhaust and reversion, or bad sensor placement doesn't run a bike lean.  It indicates lean which in turn.  The ECM fattens it up, but I am not there to hear it.