- Joined
- Oct 25, 2014
- Threads
- 226
- Messages
- 2,801
- Reaction score
- 950
- Location
- Dearborn Heights, Michigan
- Website
- www.livernoismotorsports.com
- First Name
- S550 HQ
- Vehicle(s)
- 2016 Mustang GT (TVS 2650) (6R80)
There are no additional charges for us to update your tuning remotely. We are using all of your build data, mods, octane and environmental information to build your tuning. So there is no more perfect information to use.
Anyone taking the native values and recalculating them into something else that gives a chance for things to be miscalculated. This is the biggest issues we see with data logging or tune monitoring.If someone looks at AFR on a monitoring device, that value is already calculated. But the issue is what conversion are they using? 14.64? 14.08? something else? Now, what about what is in your tank. If they are assuming e10, and you have something more like e6, that instantly makes the applied conversion incorrect. Then, what if they aren't grabbing the right data point from the ECM to log it? What if they are grabbing one with an offset already added in? or a delay? or a commanded VS actual average?
You can see where one simple item like "AFR" is all of a sudden riddled with chances of incorrect data being displayed and/or gathered. Now, we haven't even started talking about boost, or any other myriad of items that could be logged. You see, the Data points that almost all dataloggers use are SAE. Now, SAE standards are nice, BUT they are not designed for someone to do calibration from. They are for repair shops to help diagnose issues with vehicles. So, the level of precision, and refresh rate is not what's needed to do proper calibration development. If you are using a data point with a 200ms refresh rate, but the actual value in the ECM refreshes every 8ms, then the ECM is updating 50x more frequently then what you are watching. Again, you start to see where the issues happen and it's easier to understand why we do not treat the EcoBoost like any other engine before it. Can someone get lucky and eventually end up with a tune that works by looking at the wrong data? Absolutely. Can they repeat those results over and over again without starting from scratch each time? Usually not. And it all stems from having the right knowledge, and data in the first place.
No where does the computer spit out A/F data. Yet the data logger you're using is providing your tuner with this inaccurate A/F data. This is why we data log our own vehicles in house, to ensure it's the correct format and information required. What good does inaccurate data do anyone? That is how people end up with engine failures. Making tune adjustments from this incorrect data. When there is an option that allows remote, accurate, seamless data logging available, we wouldn't reject this, and is something we are working on developing, but again, it's not needed at all due to our procedures we have in place today.
To make it a little easier to picture for most people. If Ford, GM, Chrysler, or any auto manufacturer could spend $30-50 on hardware to datalog and do calibration, why don't they? The answer is simple, you can't, it takes 10's of Thousands of dollars to have the right hardware just for the process to begin.
Anyone taking the native values and recalculating them into something else that gives a chance for things to be miscalculated. This is the biggest issues we see with data logging or tune monitoring.If someone looks at AFR on a monitoring device, that value is already calculated. But the issue is what conversion are they using? 14.64? 14.08? something else? Now, what about what is in your tank. If they are assuming e10, and you have something more like e6, that instantly makes the applied conversion incorrect. Then, what if they aren't grabbing the right data point from the ECM to log it? What if they are grabbing one with an offset already added in? or a delay? or a commanded VS actual average?
You can see where one simple item like "AFR" is all of a sudden riddled with chances of incorrect data being displayed and/or gathered. Now, we haven't even started talking about boost, or any other myriad of items that could be logged. You see, the Data points that almost all dataloggers use are SAE. Now, SAE standards are nice, BUT they are not designed for someone to do calibration from. They are for repair shops to help diagnose issues with vehicles. So, the level of precision, and refresh rate is not what's needed to do proper calibration development. If you are using a data point with a 200ms refresh rate, but the actual value in the ECM refreshes every 8ms, then the ECM is updating 50x more frequently then what you are watching. Again, you start to see where the issues happen and it's easier to understand why we do not treat the EcoBoost like any other engine before it. Can someone get lucky and eventually end up with a tune that works by looking at the wrong data? Absolutely. Can they repeat those results over and over again without starting from scratch each time? Usually not. And it all stems from having the right knowledge, and data in the first place.
No where does the computer spit out A/F data. Yet the data logger you're using is providing your tuner with this inaccurate A/F data. This is why we data log our own vehicles in house, to ensure it's the correct format and information required. What good does inaccurate data do anyone? That is how people end up with engine failures. Making tune adjustments from this incorrect data. When there is an option that allows remote, accurate, seamless data logging available, we wouldn't reject this, and is something we are working on developing, but again, it's not needed at all due to our procedures we have in place today.
To make it a little easier to picture for most people. If Ford, GM, Chrysler, or any auto manufacturer could spend $30-50 on hardware to datalog and do calibration, why don't they? The answer is simple, you can't, it takes 10's of Thousands of dollars to have the right hardware just for the process to begin.
Sponsored