mrfred

iTrader: (50)

I had intended to use DLL to calc HP/TQ from my EvoScan logs, but after getting nowhere with the definition file to read my EvoScan logs, I decided to create my own Excel spreadsheet to calc HP/TQ. It uses the same principle as DLL to calc HP/TQ from rpm and time. I've got it setup to calc HP/TQ from either 3rd gear or 4th gear runs. If you're any good with Excel and all you want is HP/TQ, this will work for you.

Here are some tips for best results:

1) Update the spreadsheet for the weight of your vehicle with you in it.

2) The spreadsheet is setup for a 6 speed. There are minor differences in gear ratios between the various Evos that could make a few percent difference in the result if your car is not a 6 speed. For best accuracy, update the spreadsheet using the rpm/mph values using the files in the link below.

3) If your car has an unusual wheel size, update the spreadsheet for your tire size

4) If you want the most accurate HP/TQ values, you'll want to adjust your EvoScan Data.xml file to log rpm directly or almost directly after logging LogEntrySeconds.

5) Disable any unnecessary data logging in EvoScan to get the maximum logging speed. I am for at least 70 lines of 100% TPS data in EvoScan for a 2200-7200 rpm WOT run.

6) Only paste in data corresponding to 100% TPS.

EDIT: I added my Data.xml file that corresponds to the logging order in the spreadsheet.

EDIT: Fixed up the Excel spreadsheet to include boost and afr on the HP/TQ graphs.

EDIT: Fixed up the Excel spreadsheet to include knock sum in the HP/TQ graphs. Also, below is a link to post that has Excel and PDF files showing the gear ratios for the USDM Evo 8/9.

https://www.evolutionm.net/forums/ec...t-control.html

chmodlf

iTrader: (19)

I have found that the key to the DLL app is matching the DataItemID to the right ID. I had all kinds of problems with the 2byte load rendering correctly. That is not to say that it will solve your problems but food for thought.

Nice macro BTW

tephra

iTrader: (6)

nice work mrfred, how does it compare to DLL or evoscan?

mrfred

iTrader: (50)

I never got DLL up and working, and I haven't tried it in EvoScan. With that said, there's only one simple way to calculate HP/TQ from time and rpm. Power = F*v where F = m*a. I'm sure that everyone is using the same formula. I found that the key to getting a non-jagged curve is lots of data stream averaging, much more than what I initially thought would be necessary.

juyanith

iTrader: (7)

Thanks mrfred. I have a very similar log analysis spreadsheet I've been using, based in part off the charts you had already posted. I basically took your calculation methods and put them in my spreadsheet and everything seems to be working fine. I had played around with doing hp/torque before but I wasn't sure about the results because of the smoothing. The main difference seems to be that you are also smoothing time and rpm which I wasn't. There was a post around somewhere about SAE correction values which I may try to add if I get time.

To answer your question tephra, these calculations seem to be slightly less than DLL even after I adjusted the formulas to match the values DLL uses (Cd, Area, etc.) and my VIII's gearing. My thinking is that these numbers compare pretty well to previous DD dyno results except that the dyno spools slightly later (maybe 200-250 RPM).

Thoe99

iTrader: (25)

What's DLL?

juyanith

iTrader: (7)

Er, sorry. Data Log Lab. It's a program you can use to make graphs from your log files.

mrfred

iTrader: (50)

Yeah, lots of averaging! You're right, I did not include a weather correction or SAE correction. Do people select those options regularly on DLL?

juyanith

iTrader: (7)

I have used the SAE correction values in DLL regularly. But the actual correction factor hasn't varied significantly over the last couple of weeks, ranging from 0.98 to 1.03 and tending to be pretty close to 1.0.

I just played around with DLL and could get the correction factor to vary from 0.91 to 1.11 by changing temp, humidity and pressure (32*-100* F, 0%-100% humidity, 98-102 kPa pressure). This caused graphed hp to vary from about 280 to 340, but I think these are extreme values. More than likely most testing will be done in conditions that have SAE corrections within 0.96-1.05. It may not really be worth the effort to worry about it.

nj1266

iTrader: (6)

The attached file works with the latest version of Evoscan. I tested it and all the variables you see in the picture can be logged. There is other crap in it that needs to be cleaned up, but that is up to the end user to do. My advice, leave the crap in there so you will not mess something else up. You can display all the needed variables with this file.

spdracerut

iTrader: (2)

I made own spreadsheet a while back because I was bored. I also found that you had to do a lot of averaging. Also, I went through the data set I was using and got rid of 'bad' data, such as the rpms dropping or remaining constant.

I think I left out the drag factor because I got busy and had other things to do; maybe one of these free weekends like 2 months from now, I'll get around to messing with it more.

EvoBroMA

i got the best results by using a moving average filter on RPM with a filter width of n=5. if i remember correctly this is the same as using a centered moving average with 11 samples.

it gave the same results as DLL's smoothing=5.

edit: for power runs, you really only need RPM and Time. the timestamp is only temporally close to the first MUT request, so logging a bunch of requests only exacerbates the issue.

another major issue is the innacuracy of the RPM MUT Request, this can be solved eventually by hacking the rom image to not truncate the RPM bytes. but we can get away with filtering it. it comes close enough.

as for the timestamp issue - I was trying to work on a logging system that takes timestamp per request, and then interpolates this data to a more discrete timeline. we use these types of real time systems in the Power Co, to log real time transmission data.

Pd1

iTrader: (38)

Stupid question: Why doesn't evo4mad use this calculation in EvoScan? I assume it's different than what he's doing since the numbers in v.99 seem to be wildly inaccurate..

Which leads to the question of whether we can modify EvoScan (XML file?) to use this calculation method instead of the one that's being used.

mrfred

iTrader: (50)

I thought about doing a 2-byte RPM mod, but after seeing how well the 1-byte data turned out, I'm wondering if the 2-byte will be any better. 2-byte will require making two requests which adds its own inaccuracy.

Pd1, If the EvoScan HP/TQ data bounce all around but are in the right ballpark, then he just needs to do more averaging. If the numbers are way off, e.g. 400 whp on a stock Evo, then he can look up my formula in the spreadsheet and use it.

EvoBroMA

honestly - filtering/smoothing the rpm signal gets it close enough to make some pretty good graphs. 2-byte RPM does not seem worth it to me.

i noticed DLL has a flaw when using alot of samples close together, at a high datarate. this is because the dv/dt term gets really volatile - the closer the samples are temporally the more error/distortion is introduced. I'm assuming its from the resolution of the time stamps. it gets to the point where any hickup in between samples will cause dv/dt to spike/or dip wildly - all because he is only using 2 samples at a time to calculate dv/dt. smoothing out dv/dt over several samples would easily fix DLL's issue with high sample rates causing erratic power graphs.