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.
just following Steve's thread, members are questioning these significant issues that have been highlighted and now looking for feed back on them (as outlined in the first post the discussion is relevant to all tuning devices)
the data Gordon posted is at idle, see pg19 for more info
Gordon, were you able to recreate the circumstances that created the event and verify that The PV AT did indeed correct it? As you know, the devil is in the details. The Delphi ION sensing system does occasionally create or report a non-event as an event. Nature of the beast.
Short answer, I think so ...see the PV auto spark tuning or Mytunes? for further info see ...here...
can you feel or hear the abnormalities that Steve pointed out in your log? Is this just a data log or is your tuner in AT at the time?
This was an example of a normal-notinautotunemode log covering a period of idling from initial start to EITMS kicking in. Can I hear the anomalies Steve pointed out? ...possibly, but I'll take that to a new thread on idling and the timing that hardtail noticed
Originally Posted by Fat11Lo
I was under the impression that when using an "auto tune" type of device that changes should be checked by running a data log after changes are made.
Not all tuners can capture logs so maybe the general idea is to do your tuning, and verify with any other tools you may have, if any. The pro's have wideband and narrowband sensors they can compare for example. The DIY types can certainly use logs to get an idea how close the tune seems to be, but as discussed above, the question of sample rate and how such logs are created may raise a touch of doubt in what "exactly" they mean/show.
This was an example of a normal-notinautotunemode log covering a period of idling from initial start to EITMS kicking in. Can I hear the anomalies Steve pointed out? ...possibly, but I'll take that to a new thread on idling and the timing that hardtail noticed.
The reason I ask is, I have read threads on here before where people have stated "the bike seems to be running fine" or "the bike has never run better, but I noticed when reviewing my last log ........"
Originally Posted by Gordon61
Not all tuners can capture logs so maybe the general idea is to do your tuning, and verify with any other tools you may have, if any. The pro's have wideband and narrowband sensors they can compare for example. The DIY types can certainly use logs to get an idea how close the tune seems to be, but as discussed above, the question of sample rate and how such logs are created may raise a touch of doubt in what "exactly" they mean/show.
I understand this, and I'm fully aware that $500 bucks for a little orange box or a gadget to mount on the handlebars a few cables and a computer program could never replace thousands of dollars worth of professional equipment. I also subscribe to the school of thought that the most important part of the equation is the Tuner(the person) not the device. I'm just trying to learn as much about the process as possible.
Are they issues? This is a PV log off a tuned bike. Does PV filter out this data? Does PV use this data? How are their filters set up? How is it set up in their auto tune to address this? Sounds like questions for DJ, because I can't see Steve caring. Why would he want to fix their stuff? This thread is a DH/Delphi Tuning Basic thread about basics. Not a particular tuning device.
So to better understand the data it's best to understand how a particular device collects that data and processes it? This will help to determine weather the data in question is a bad sample or something is malfunctioning causing the data to be skewed?
People wanted to see skewed data, and how that data looks. BAM, there it is, and thank you Gordon for putting it up.
Even though it is OT. I can tell you what I would do. First I would see if the PW match's what the O2's are seeing. Then I would sample with widebands while sampling with the narrow bands to see if I can verify the narrow bands. Then I would take the data I collected with the WB's and hand create a VE table in this area. Compare my hand VE's to AT VE's, and test again. That's right. I wouldn't use the AT that got me here in the first place, because doing the same thing will get me the same result. If my hand VE's were better. I have a choice. Leave them with hand created VE's and run that area in open loop or try and get the sampling better with the narrow bands.
Basic tuning 101
Basically you are using two sources to verify the data. Sounds like the same approach I use when troubleshooting a piece of equipment, I use the laptop to see what the ECM is reading and then use pressure gauges to verify what the sensor is telling the ECM
So to better understand the data it's best to understand how a particular device collects that data and processes it? This will help to determine weather the data in question is a bad sample or something is malfunctioning causing the data to be skewed?
I don't know how DJ processes their data, but using tuners on other things besides motorcycles. I have learned that these things need to be set up in order to take out the junk data. Some tuners give you nothing and let you figure out all the PID's.
For example in Gordons log. O2 drops out but there really isn't an indication that it is going that lean. So, you filter out the data that does go that lean. All HD flash base tuners do this. Ever collect NB data and you are trying to hold a cell and O2's never come on line in some areas but you get data in the others? Wash that log through and some of the VE is changed and some isn't. Blend the cells that didn't get changed by the cells that did get changed so they are close and run again. Then all cells are getting hits. They just don't let things run wild. If they did there would be no reason to throw codes associated w/ O2 sensors.
Does all this need to be understood to tune a bike with these devices. 90% of the time. I would say no. But when things aren't going as planned. The better understanding of what is all going on will never hurt.
The reason I ask is, I have read threads on here before where people have stated "the bike seems to be running fine" or "the bike has never run better, but I noticed when reviewing my last log ........"
I'm dead chuffed with how mine is running in general but I have one small thingy left that (because I'm a really fussy and pedantic sod) I'd like to fix or at least know why it does it ...THAT is the only reason I'm still playing and running a few logs.
For me, logs are an analysis tool, rather than a reporting tool ...if that makes sense
Last edited by Gordon61; Aug 17, 2016 at 07:10 PM.
just following Steve's thread, members are questioning these significant issues that have been highlighted and now looking for feed back on them (as outlined in the first post the discussion is relevant to all tuning devices)
the data Gordon posted is at idle, see pg19 for more info
Maybe, just maybe if you came here to contribute something you could learn something, but it seems your only reason for being in this thread is to try and start something. I've reviewed each of your post in this thread and none of them ask me to post something for you, regardless of what you have claimed. So unless you go back and edit a post to change it, your full of it. I do not ask anyone to post for me so you can drop all that as well. If you've got something to say spit it out otherwise go elsewhere as this is my last response to you.
I'm dead chuffed with how mine is running in general but I have one small thingy left that (because I'm a really fussy and pedantic sod) I'd like to fix or at least know why it does it ...THAT is the only reason I'm still playing and running a few logs.
For me, logs are an analysis tool, rather than a reporting tool ...if that makes sense
Gordon
Here is a little data that I recorded on a 2016 CVO with a 117 kit installed. One log is cold start and about 10 minutes of continuous idle. As you will see in the data it never went into EITMS as its a water cooled bike. This data runs about 18 fps. I then stopped the data and switch to a data collection that runs about 28 fps and got about 10 minutes more data. You can compare these two logs and see the differences between recording at different speeds and how the data appears to be different, yet it is the same data on the same bike. As for the bike I never turned it off, only switched the data and data rate between the two recordings. The two recording are recording different data but they both contain O2 sensor readings for you to compare as well as other things.
Harley-Davidson Fat Boy Becomes a Dark, Decepticon-Inspired Custom
Slideshow: Killer Custom's latest build relies on styling changes rather than performance upgrades, giving the cruiser an entirely different personality.
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.