When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
The Dyno RoomA special room dedicated for Dyno tuning products, troubleshooting and results. All Gearheads and Dyno Operators are welcome here as well as the guys that are new to tuning. Please see the special rules for this section before posting.
So putting CLI and AFF and sensor latency and accuracy to good use, what are we looking for or hoping not to see
What are we looking for? FP3 doesn't show CLU/AFF yet, are they worth looking at,
Or are we not ready for examples yet
I think examples of data are fine but I had no idea Dynojet PV was not accurately reporting what the ECM was really doing. That said, we are going to have to be careful going forward to keep in mind how to look at the data because it appears that at least Short and Long term are done different and I have seen data before that showed the exact same RPM for over 12 frames in a row before from DJ PV and we know that is not possible, as the engine never holds dead even.
I want this thread to be able to talk about any brand stuff but understand the Basics of how and why the Delphi ECM does what it does. So at this point I'm open to anyone posting data and asking questions as long as the data is identified so we all can try and keep it straight.
Thanks Steve... and the last thing we want to do here is accuse a product of not doing "A" when it should be doing "B".
That's going to be hard when dealing with several products in this market but maybe we can keep this thread to ECM Tuning Basics and talk very little about actual product performance?
I know you are going out of your way to be product fair and I think we all appreciate that very much.
I would also like to invite any other Product Expert or Manuf Support Tech to join us in this conversation.
It's all good, people just need to understand it is not what it's been made out to be by many internet sellers. There are some hard and fast things that have to be dealt with and there is only so many things that can and do cause changes. If you have a bike with a 4 pin connection (J1850) most tuners log at 2 fps and 6 pin connection (Can) 10 -14 is the normal range. While its not everything TTS has pushed hard to get data rates up when no one else thinks it matters. 4 pin at 5 - 6 fps for fuel data and 14 - 15 for spark data and 6 pin at 30 - 40 depending on ECM. When you have all this extra data to look at, things do appear different, but the higher data rates paints a more accurate picture of what is really going on.
That said you still need to understand the limits and accuracy of the sensors! Everything is based from the sensors so if you know it can and does move around, then seeing that movement becomes easier to understand. What becomes harder is to pick out when the movement is from the sensors or something else.
So Steve,
I'm a little naive here.. What is the importance of getting the frame up on the data collection for the average guy?
I would imagine that if the user us processing this data to tune the motorcycle, it would make the process quicker..
Looking at the sample numbers you posted before, it looks as tho you are trying to shoot for a sample every 4 cycles which means after both cylinders have completed their 4 cycles.. Since the data is being collected and processed, can't you just take data every other 4 cycles or every 4th 4 cycles.
I would imagine it helps to collect data faster when the RPMs are changing but what is not collected right away can be collected later..
From the perspective of a professional, I guess I could see decrease in time to perform a dyno dune..
I'm a little naive here.. What is the importance of getting the frame up on the data collection for the average guy?
I would imagine that if the user us processing this data to tune the motorcycle, it would make the process quicker..
Looking at the sample numbers you posted before, it looks as tho you are trying to shoot for a sample every 4 cycles which means after both cylinders have completed their 4 cycles.. Since the data is being collected and processed, can't you just take data every other 4 cycles or every 4th 4 cycles.
I would imagine it helps to collect data faster when the RPMs are changing but what is not collected right away can be collected later..
From the perspective of a professional, I guess I could see decrease in time to perform a dyno dune..
Any other reasons?
The "average guy" as you call it, is going to be out riding there bike trying to collect data from anything but a steady state engine so speed and accurate data become very important. Since any data logger can only collect what the ECM is sending how do you know how many and where you missed data? So keeping track of it, is not an easy task. Now remember back in my earlier post where I told you all about the speed at which the ECM itself updates, as this now plays into what you see. If the ECM updates one data item every second, odds are the worst you will ever be off is one data frame. Now let's move to something the ECM updates every 0.004 mS if your logging device is only running at 2fps you can become never accurate, as your missing so much, that it is very possible it will never line up properly. Another thing one needs to remember is the ECM sends the data out as packets, NOT all at once. So when you see a frame of data it really contains several packets of data that were sent over time. So if you sample slow the ECM may have update and by the time the packet get sent, it no longer lines up with the first packet of data. This is just why speed is very important!
Now a Dyno operator can hold the engine stable and collect lots of data for the area they are testing and nothing changes, so it is much easier to get down to what data is good and bad then toss the data bad out. Hope this explains it better for you.
Last edited by Steve Cole; Aug 3, 2016 at 01:04 PM.
The "average guy" as you call it, is going to be out riding there bike trying to collect data from anything but a steady state engine so speed and accurate data become very important. Since any data logger can only collect what the ECM is sending how do you know how many and where you missed data? So keeping track of it, is not an easy task. Now remember back in my earlier post where I told you all about the speed at which the ECM itself updates, as this now plays into what you see. If the ECM updates one data item every second, odds are the worst you will ever be off is one data frame. Now let's move to something the ECM updates every 0.004 mS if your logging device is only running at 2fps you can become never accurate, as your missing so much, that it is very possible it will never line up properly. Another thing one needs to remember is the ECM sends the data out as packets, NOT all at once. So when you see a frame of data it really contains several packets of data that were sent over time. So if you sample slow the ECM may have update and by the time the packet get sent, it no longer lines up with the first packet of data. This is just why speed is very important!
Now a Dyno operator can hold the engine stable and collect lots of data for the area they are testing and nothing changes, so it is much easier to get down to what data is good and bad then toss the data bad out. Hope this explains it better for you.
So you are saying the important information can be skewed. Say it sends out RPM in one packet and MAP in another? CLI in a third? Injector PW in a 4th. I could see where that's an issue..
I think examples of data are fine but I had no idea Dynojet PV was not accurately reporting what the ECM was really doing. That said, we are going to have to be careful going forward to keep in mind how to look at the data because it appears that at least Short and Long term are done different and I have seen data before that showed the exact same RPM for over 12 frames in a row before from DJ PV and we know that is not possible, as the engine never holds dead even.
I want this thread to be able to talk about any brand stuff but understand the Basics of how and why the Delphi ECM does what it does. So at this point I'm open to anyone posting data and asking questions as long as the data is identified so we all can try and keep it straight.
Thanks Steve, I was trying to get away from that box vs the other box which while interesting doesn't really help us understand what the signals are trying to tell us, or when they are bad or good.
I was thinking generic pointers and expected observations rather than looking at logs as such. I'm sure the rest of the forum can handle specific questions/issues. But you're driving.
Thanks Steve, I was trying to get away from that box vs the other box which while interesting doesn't really help us understand what the signals are trying to tell us, or when they are bad or good.
I was thinking generic pointers and expected observations rather than looking at logs as such. I'm sure the rest of the forum can handle specific questions/issues. But you're driving.
Thanks Steve, I was trying to get away from that box vs the other box which while interesting doesn't really help us understand what the signals are trying to tell us, or when they are bad or good.
I was thinking generic pointers and expected observations rather than looking at logs as such. I'm sure the rest of the forum can handle specific questions/issues. But you're driving.
I'm trying to answer the questions and teach people the way the ECM works. Beyond that, I have to try and keep politically correct so I cannot use our in house data as a reference point or people get upset and try to say I'm pushing a product. So the data needs to come from the forum members so we can discuss what we see and try to figure out why it is doing it. If members now feel they understand what and why sensors effect the result and that they have to get put into the mix we could move forward to another part of tuning but it all up to the members.
I'm trying to answer the questions and teach people the way the ECM works. Beyond that, I have to try and keep politically correct so I cannot use our in house data as a reference point or people get upset and try to say I'm pushing a product. So the data needs to come from the forum members so we can discuss what we see and try to figure out why it is doing it. If members now feel they understand what and why sensors effect the result and that they have to get put into the mix we could move forward to another part of tuning but it all up to the members.
I wasn't thinking about specific data ...we discussed CLI so, for example - how much would you expect CLI to wobble around at idle?
I've heard +-5% mentioned, is this a real expectation and if it's greater than that does that indicate a problem?
What might it tell us about the general state of our tune? that sort of generic question or is this what you want to come back to later?
...unless that sort of stuff is for another discussion and you want to stick to tuning basics, which is fine too, it's your thread and I certainly appreciate your time and effort giving us an insight into the inner workings of the ECU
7 Surprising Harley-Davidson Products that Are Not Motorcycles
Slideshow: The bar-and-shield logo shows up on far more than motorcycles, some of the company's most unexpected products have nothing to do with riding.
Slideshow: From the troubled AMF years to modern misfires, these bikes earned reputations for reliability issues, questionable engineering, or disappointing performance.
Crazy Bunderbike Build Looks Amazing, But Is It Impossible to Ride?
Slideshow: The Swiss custom shop has taken a Harley Softail and stretched it into something so long and low that it looks closer to a rolling sculpture than a conventional motorcycle.
Engraved Rebellion: Inside Bundnerbike's Glam Rock II
Slideshow: A standard cruiser becomes an intricate metal canvas in the hands of a Swiss custom house known for pushing Harley-Davidson platforms far beyond their factory brief.
Slideshow: Harley-Davidson's challenges aren't abstract; they show up in dropping shipments, shrinking dealer traffic, and strategic decisions that aren't yet translating into growth.