Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Coyote.]

Interesting. Are the two lines due to corrections from reading the o2's switching around the set point?

[whittlebeast]

That is correct.  This is the root cause of the hunting that plagues every stock Sporty.  Sporty's can't run in closed loop when in gear.

Andy

[Steve Cole]

Are you sure?
 
How about all the data that the ECM is using that does NOT get sent out on the buss to be captured.
The best you can do on a Sportster is to get about 4 frames per second of data and since the engine is truely running at 8.33 HZ at an idle speed 1000 RPM per cylinder you are NOT seeing over 50% of the data in your scatter graphs at idle alone.

Then, as engine speed increases your scatter graphs show less and less of what is really going on due to the buss issue.
At 6000 RPM you are getting 4 out of 50 or only 8% of the real data the ECM is using!
That's 92% you are NOT seeing!
That is going to leave a huge hole in your plots

You have to start with the basic understand of the system before you can jump to conclusions like you are.

[Coyote.]

I'm not sure I get why you can't run (a sporty, this bike) in closed loop but the rest makes sense to me. I guess I would expect a graph like that for any HD running closed loop. The system has an inherent error around the sensor switch point.

[FLTRI]

I'm not sure I get why you can't run (a sporty, this bike) in closed loop but the rest makes sense to me. I guess I would expect a graph like that for any HD running closed loop. The system has an inherent error around the sensor switch point.

What's the inherent error?? Does it happen with all closed loop NBO2 systems?
Bob

[sam280z]

Steve,
How does the output buss work? Is the output just what is available at the time that an update is required?
If not, and there is some characteristic of the data that drives what is output, I agree with you.

But, if the fact that a data "frame" is output only depends on time, then with enough log time and enough data, there won't be any "holes" in the scatter plot. There may be some "error" (really a lower correlation between variables) if the buss speed is slow enough that conditions have changed significantly between the output of one variable and the output of the next. But if the output algorithm just grabs a snapshot of all variables and then outputs them, then a scatterplot is perfect for looking at it - as long as you have lots of data.

Sam

[joe_lyons50023]

I would agree with the fact that no matter how slow the data stream if you have enough data collected it should be ok but yes with a higher rate of data collection less ride time is needed.  What kind of speeds of data collection are you getting with the 614 cals Steve?   Also why would harley choose TP based VE tables over MAP based VE tables?  Im guessing that there is a MAP vs. VE table in the ecm somewhere but just not used.

Andy how long were most of these recordings that you have.  They look huge.

[whittlebeast]

I typically get about an hours worth of data.  I have a couple of loops I ride that gets lots of different types of data.  I also can open several rides at the same time to get plenty of data.  When I am looking at faster data rate systems, I often look at a half million samples at one time.

[whittlebeast]

Are you sure?
 
How about all the data that the ECM is using that does NOT get sent out on the buss to be captured.
The best you can do on a Sportster is to get about 4 frames per second of data and since the engine is truely running at 8.33 HZ at an idle speed 1000 RPM per cylinder you are NOT seeing over 50% of the data in your scatter graphs at idle alone.

Then, as engine speed increases your scatter graphs show less and less of what is really going on due to the buss issue.
At 6000 RPM you are getting 4 out of 50 or only 8% of the real data the ECM is using!
That's 92% you are NOT seeing!
That is going to leave a huge hole in your plots

You have to start with the basic understand of the system before you can jump to conclusions like you are.

Yes I am sure.

You have to start with the basic understand of statistics before you can jump to conclusions like you are.

This screen shot clearly demonstrates that plenty of data and applying filters as required does wonders.  



Sure there are a few breaks in the data but in EFI tuning, getting a great tune has everything to do with averages.  Scatter graphs do the averaging for you in living color.  

Andy

[whittlebeast]

Here is an example of AE Testing taken off one of my motors.  This happens to be a jetski sitting at slightly over idle.  I stab the throttle.  You can clearly see the Pulse Width jump up faster than the MAP and then settles in.  That is the AE hitting.  Notice how the AFR is fairly stable.  The motor peaks out at close to 40000 RPM/sec for a short period of time as the motor jumps from 2300 RPM to 7000 RPM in .274 sec.  That works out to a little over 17000 RPM per sec average.  That was all sorted out looking at scatter plots.

I am looking for the motor to jump in RPM as soon at you see the throttle jump.  You will also see the MAP jump up with the throttle.  I never want to see the RPM drop with a throttle stab.  This motor happens to be a 275 Hp 1500 cc motor.



Have fun tuning

Andy

[Steve Cole]

Steve,
How does the output buss work? Is the output just what is available at the time that an update is required?
If not, and there is some characteristic of the data that drives what is output, I agree with you.

But, if the fact that a data "frame" is output only depends on time, then with enough log time and enough data, there won't be any "holes" in the scatter plot. There may be some "error" (really a lower correlation between variables) if the buss speed is slow enough that conditions have changed significantly between the output of one variable and the output of the next. But if the output algorithm just grabs a snapshot of all variables and then outputs them, then a scatterplot is perfect for looking at it - as long as you have lots of data.

Sam

Sam

The HD Buss does NOT allow for a data frame to be collected at one time. It comes out in small packets and those are all stagger in time. Different packets get updated at different rates and at different times. This is how all automotive data buss's send out data and why Andy just cannot understand what he is plotting contains the artifacts of this issue. Until he learns that the artifact needs to be removed he is making nothing other than pretty pictures, as he clearly has no idea what goes with what. Add to that the amount of missing data (up to 92% missing) and it becomes clear why the pretty pictures look like they do, it jumps right out at you.

Let's say for sake of discussion that one data frame contains 20 packets. Each packet gets it's own data updated at various rates. So now you have 20 packets collected at a fixed rate that are staggered in time, with packets that contain data that has been updated at different times. The higher the engine speed the more the data collection update rate and staggering in time becomes an issue. That should give you the basic understanding of what's going on.


Andy

No matter how much you try, until you learn how to understand the raw data IMHO your just making pretty pictures.

[Buckeye_Tuning]

And... for once... lets keep this civil.  Maybe we can start to have some real discussions instead of this devolving into tit-for-tat, like that other site always does.

Lets discuss more about how ANY program sucks the data packets out of the bus.

[sam280z]

Steve,
I see your point, but I see two potential  issues with your argument against usefulness of the data that comes out of this system.
1) The buss refresh rate is about 1 per .12 seconds. So new data comes out once every 12th of a second (8.33Hz). I'm assuming that the data being inserted into a packet is associated with a maximum time interval of .12 secs. i.e the maximum amount of time between two pieces of information reported together in one packet is .12 seconds.  This can be less than some of the lags created by the physical configuration of the motor (input tract length, injector placement, exhaust distance to UEGO sensor, etc...) and computational times of the controller algorithms. What is changing so fast in the engine that this matters, especially for steady state tuning?

2) Let's say it does matter.
    a) If we know something about how the data is related in time, we can address the lags in the scatter plots by plotting the value of one variable from one record/packet against the value of a different variable in an earlier/later record.
    b) If we do not know how the data is related in time, or the timing differences are smaller than the difference between records, we can throw up our hands and give up, or accept that this difference will be the minimum error we can possibly have. We can measure the error in the tune and break it into tune error and measurement error. The buss timing issue would fall into measurement/random error along with things like sensor calibrations. All we can do to minimize the total error is adjust the on the tune to minimize he tune error. Once we get to a point where attempts to reduce error actually increase it, you are done.

Sam

[Steve Cole]

Steve,
I see your point, but I see two potential  issues with your argument against usefulness of the data that comes out of this system.
1) The buss refresh rate is about 1 per .12 seconds. So new data comes out once every 12th of a second (8.33Hz). I'm assuming that the data being inserted into a packet is associated with a maximum time interval of .12 secs. i.e the maximum amount of time between two pieces of information reported together in one packet is .12 seconds.  This can be less than some of the lags created by the physical configuration of the motor (input tract length, injector placement, exhaust distance to UEGO sensor, etc...) and computational times of the controller algorithms. What is changing so fast in the engine that this matters, especially for steady state tuning?

2) Let's say it does matter.
    a) If we know something about how the data is related in time, we can address the lags in the scatter plots by plotting the value of one variable from one record/packet against the value of a different variable in an earlier/later record.
    b) If we do not know how the data is related in time, or the timing differences are smaller than the difference between records, we can throw up our hands and give up, or accept that this difference will be the minimum error we can possibly have. We can measure the error in the tune and break it into tune error and measurement error. The buss timing issue would fall into measurement/random error along with things like sensor calibrations. All we can do to minimize the total error is adjust the on the tune to minimize he tune error. Once we get to a point where attempts to reduce error actually increase it, you are done.

Sam

Sam

I agree with some of what you said. We have to know............ and since you do not know, there lies the problem. While I have a very good handle on it, just taking data from an unknown source then claiming this is the answer doesn't fly here. Andy is taking data collected by another program, so he starts at a lose because he has no way to know where/how any of it fits together.

Again, I want to make sure that you and everyone understands that scatter plots have there place but you must know and understand the pitfalls of them too. Same goes for many of the sensors being used to collect data from, they all have there specifications and you need to know those to be able to weed out the areas that can be at issue due to those tolerances. Using steady state information goes a long way to getting those errors averaged out but that is NOT what Andy has said nor shown.

The last time he did this and posted the raw collected data he used, it was proven to be bad data but he himself never figured it out. So all those pretty charts were just that! This is were I see issue with it and telling people, this is the answer, is a problem to me. This is what I do for a living and I can only share so much but in Andy's case I have to say with reason for saying it is , buyer/reader beware.

[North Georgia Hawg]

Frankly, most of this stuff is flying 40,000 feet over my head. I have read it and re-read it multiple times, and it just doesn't seem worth all of the trouble to me. All of these scatter plots give me a headache after a few moments of looking at them and attempting to SEE what Andy says they show.

As a 30-year software guy, I know that analysis can be done perfectly fine using mathematical calculations, and I don't understand why all of the scatter plots are even necessary along the way. If the data is there and it's good data - a well-written computer algorithm is far more efficient at analyzing it, eliminating anomalies, performing complex statistical analyses, and identifying trends - and producing good results - than is a human looking at charts. There are many software products on the market - and I've used several - that can perform extremely complex analyses on what we call "big data"... literally trillions of rows of data... and the only time they ever create charts is when the results of these complex analyses need to be seen by a human. The charts are used merely to present the results to a human... not to determine how to do the next analysis, nor how to apply the results of the analyses to the end product.

As a user, I just want a tuning device that figures out all of this stuff using the real-world data I have collected during rides, updates my tune, and lets me then enjoy riding the bike more. I think that's what most riders really want. I really couldn't care less about the last 2% of power to be gained, if it means exerting 10 or more times the effort to get it. It's the law of diminishing returns. I'll be more than happy with the first 98%, or even the first 95%, and I am confident that the TTS gives me all that I need and will ever be able to use.

If I were a pro tuner like some of the folks here, then it might all be more interesting and relevant to me... not to mention more understandable. And believe me, I've tried hard to understand. But frankly I can't see how all of this is worth the effort unless you're tuning top fuel dragsters, NASCAR engines, or race bikes - and winning is everything.

I guess my question is: Why is all of this NECESSARY for tuning Harley big twins... especially big hulking 900 lb Touring bikes? The Twin Cam isn't exactly a modern, state-of-the-art racing engine. When is a tune "good enough", and do devices such as the TTS provide a "good enough "tune? Will most riders ever notice an extra ft-lb or two of torque, or 2 extra HP? I may be completely ignorant about this level of tuning... but if Steve Cole doesn't get it either, then it's clearly far above my level of understanding, and way more than I will ever need.

I'll bow out of this thread now, but I'll continue watching it from time to time. It clearly isn't aimed at people like me.

Ken