Looking for MBT with Virtual Dyno
Jan 4, 2011, 07:35 AM
#16
I've never been able to acheive the same repeatability on the road that I can on a dynojet. This is with the same stretch of road with ideal conditions. I can still effectively tune on the road, but the resolution is a bit lower than on a dynojet.
Last edited by mrfred; Jan 4, 2011 at 07:39 AM.
Jan 5, 2011, 05:12 AM
#23
If there are questions about Virtual Dyno I am the developer so just shoot me a message or something and Ill be glad to help.
I understand that you like using a dyno ... but everyone doesnt have access to one whenever they want or in their garage so thats where Virtual Dyno comes in. If the math and physics are correct then it will be correct.
I understand that you like using a dyno ... but everyone doesnt have access to one whenever they want or in their garage so thats where Virtual Dyno comes in. If the math and physics are correct then it will be correct.
Jan 5, 2011, 10:06 AM
#24
The same rules that apply to proper dyno testing apply to "virtual dynos" and this is where most make mistakes. Consistency in data is created through consistent process of testing.
My personal method is all due to the fact that I have found a testing area that works well. I have found a section of road that is plenty long for a 3rd gear pull with ample braking room. At the end of the road, I can pull off in an industrial complex to evaluate the data and to avoid being noticed by any unwanted individuals. I then drive back down the road opposite the way I do the pulls so I can verify nobody is around before making a pull going back the other direction. This is important because it takes you mind off things like crossing paths with somebody else and let's you focus on getting the data as consistent as possible.
I have consistency in my testing in that I watch the log before starting a pull for a couple things. Coolant temp and IATs within a few degrees, stabilize RPM before beginning pull, start at the same point on the road every time, run the car to the rev limiter every time.
Beyond that, I use the scientific approach, one variable at a time. I tune AFR and timing completely separately, never changing both at the same time. I usually will only change a small RPM range at a time too, so that the data should show consistent before and after the change to verify a good pull. On one hand, it time consuming. However, I find doing this, and having a basic knowledge of what the car likes, I can tune the car in far less pulls overall. Instead of doing pull after pull, I just make each pull count and the data is consistent enough that this works well.
Doing this, I've been able to show very small changes and I've been able to tune MBT on 91 octane up until about 320WHP, which is about 18-19 PSI peak on my car and about 14 psi at redline. Above that boost level, I can no longer reach MBT before detonation sets in. It is HP limited in my case as it is the point where the turbo starts getting very high shaft speeds. Anything over about 340WHP I have to start dumping fuel on it to keep it happy. Can't wait to see what E85 does.
My personal method is all due to the fact that I have found a testing area that works well. I have found a section of road that is plenty long for a 3rd gear pull with ample braking room. At the end of the road, I can pull off in an industrial complex to evaluate the data and to avoid being noticed by any unwanted individuals. I then drive back down the road opposite the way I do the pulls so I can verify nobody is around before making a pull going back the other direction. This is important because it takes you mind off things like crossing paths with somebody else and let's you focus on getting the data as consistent as possible.
I have consistency in my testing in that I watch the log before starting a pull for a couple things. Coolant temp and IATs within a few degrees, stabilize RPM before beginning pull, start at the same point on the road every time, run the car to the rev limiter every time.
Beyond that, I use the scientific approach, one variable at a time. I tune AFR and timing completely separately, never changing both at the same time. I usually will only change a small RPM range at a time too, so that the data should show consistent before and after the change to verify a good pull. On one hand, it time consuming. However, I find doing this, and having a basic knowledge of what the car likes, I can tune the car in far less pulls overall. Instead of doing pull after pull, I just make each pull count and the data is consistent enough that this works well.
Doing this, I've been able to show very small changes and I've been able to tune MBT on 91 octane up until about 320WHP, which is about 18-19 PSI peak on my car and about 14 psi at redline. Above that boost level, I can no longer reach MBT before detonation sets in. It is HP limited in my case as it is the point where the turbo starts getting very high shaft speeds. Anything over about 340WHP I have to start dumping fuel on it to keep it happy. Can't wait to see what E85 does.
Jan 5, 2011, 12:02 PM
#25
Virtual dynos are useful, but like mrfred had stated, not as precise as a real dyno.
It's not the calculations the spreadsheets and VD programs use that's the problem...t's the data that we log from the ECU. Many of the key parameters have large data jumps, like the normal 1 byte RPM most people log. 2-byte RPM will help improve precision, for example. Also, logging speed is a very big factor as well. You don't want your timestamp and your data too far off. Using DMA will be better than MUT, for example.
All of these limitations add up and factor into the lack of precision and consistencies that we get from logging. That being said though, the VD tools are very useful and if you know what you're doing and understand what's going on, then they can be used to tune quite effectively and see very small changes. Whether that's good enough to tune for a 1* timing resolution, I guess that's all up to your data and acquisition.
It's not the calculations the spreadsheets and VD programs use that's the problem...t's the data that we log from the ECU. Many of the key parameters have large data jumps, like the normal 1 byte RPM most people log. 2-byte RPM will help improve precision, for example. Also, logging speed is a very big factor as well. You don't want your timestamp and your data too far off. Using DMA will be better than MUT, for example.
All of these limitations add up and factor into the lack of precision and consistencies that we get from logging. That being said though, the VD tools are very useful and if you know what you're doing and understand what's going on, then they can be used to tune quite effectively and see very small changes. Whether that's good enough to tune for a 1* timing resolution, I guess that's all up to your data and acquisition.
Jan 5, 2011, 01:33 PM
#26
There is some consistency in the data rate though, provided you always log the same things. Keep the number of items to a minimum though.
I've noticed that when tuning and logging multiple channels, I'll usually end up with about 5% higher readings then when I do a pull "for bragging rights" where I only log TPS and 2-byte RPM. Logging only those two channels, I get a reasonable data rate of like 30Hz. Not great, but good enough that I trust the results to be fairly close to a real dyno. Within 5% or so anyway.
I've noticed that when tuning and logging multiple channels, I'll usually end up with about 5% higher readings then when I do a pull "for bragging rights" where I only log TPS and 2-byte RPM. Logging only those two channels, I get a reasonable data rate of like 30Hz. Not great, but good enough that I trust the results to be fairly close to a real dyno. Within 5% or so anyway.
Jan 5, 2011, 02:58 PM
#27
^^ thats pretty good... i dont get those speeds from evoscan (Even when logging tps, rpm)
saying that i normally use DMA, i havent tried VD with it yet, but i know using VDR it will give a very inflated power number compared to if i used evoscan to log. i put it down to the fact i was using 1byte rpm and the sample rate was too high. (i normally get 30-40 hz... and i have full ign,boost,wideband etc values available.
saying that i normally use DMA, i havent tried VD with it yet, but i know using VDR it will give a very inflated power number compared to if i used evoscan to log. i put it down to the fact i was using 1byte rpm and the sample rate was too high. (i normally get 30-40 hz... and i have full ign,boost,wideband etc values available.
Jan 5, 2011, 03:45 PM
#28
I've got the baud rate up at 63,500 or what ever it is. 30Hz may be a bit higher then reality actually, probably closer to 25 Hz. It is considerably higher then normal though and the data is more then 2X as long on a given pull compared to my tuning setup where I grab about 7-8 channels of data.
