What i was doing was taking every .1 second increment and recording that and the RPM. So this way it was as even as possible... Just takes time.. But either way now i can have some sort of tool to help and not have to make 5 hour trips to AMS anymore

I dont have much faith in the AEM forums.. That place is like a ghost town....

 

Jack 1 more question for you... is there a way to make it read up to 9,000RPM??

 

modify your spreadsheet with this information to be accurate. YOu cant just use RPM and time. that is silly. here are facts.

Energy = 0.5 * mass * v * v
Power = Energy / time
Power = RPM * Torque

so you need to add speed into your spreadsheet and use these 3 formulas to be accurate.

 

Lemmonhead,
From RPM, tire diameter and gear ratios we can very accurately calculate the speed. Farrrr more accurately than the Evoscan logging for speed, which sucks lol. All of that is already in there Lemmonhead, you can thank MrFred for doing 95% of the footwork with the math. Take a look at MrFreds origianl thread with his basic spreadsheet to see a majority of the formulas used. It also includes drag coefficient and such as well, he did a good job IMO. You seem to have a strong dislike towards this, any reason? You can try making one yourself if you want, its a piece of cake *rolls eyes*

"You can please some of the people all of the time and all of the people some of the time, but you can't please all of the people all of the time." - Abraham Lincoln




Colt4g63,
I can modify it to go to 9000 RPM but it probably won't be until I make another revision. I was trying to keep the graph scaling to a minimum originally. This tool is great for getting a nice BASE tune so when you DO go to the dyno you aren't wasting your hourly rental on starting from scratch. I DEFINITELY recommend finalizing your tune with a REAL dyno, I do. You can get a LOT accomplished in a 1 hour self-tuning session if you get your tune pretty close before you get strapped down.

 

Ill be watching for your revision for the 9,000RPM limit. VERY good job with this guys!!

 

Ok, so for the next revision I will look into possibly finding another way of compensating for the Mustang Dyno's Eddy Current system vs. Actual vehicle weight and the RPM limit raised to 9000 RPM.

Has anyone found any errors in any of the features so far? I'd be impressed if I didn't mess up any formulas since its literally two seperate simulators in one lol. Lemme know and hopefully I can have the next revision done by the end of this weekend. Thanks guys.

 

Hope you don't mind, but I had to take a look at what was under the hood. Took me about two hours of fiddling around to expose everything. Never knew there were so many ways to hide things and limit interaction. Anyhow, it looks like it should be pretty easy to improve the MD correction factor. I'll think about it tomorrow. Also, it would be nice if the rpm steps were something more like 150 rpm (or at least 200 rpm). There not much that can be smoothed when there are only 25 data points. Also would be good if the first data point were down at 2300-2400 rpm. That's typically where my 100% TPS data starts.

 

You can't go smaller than 250 RPM and cover all the bases of file sizes without errors. Of the NUMEROUS logs I got, the smallest were about 40-60 rows and in that resolution the largest gaps in RPM are between 200-225 RPM usually. Thats why I chose the 250 RPM steps. The RPM min/max is easy enough though. I would prefer to have 2-byte RPM be an option but those DAMN spikes totally make the calculations difficult to compensate for it, even will gobs of smoothing. Same problem Evoscan has with them. I might add a checkbox with the 2-byte option with a much higher resolution set of spreadsheets tat it can switch between. Any way to completely eliminate the 2-byte RPM spikes? Cuz that would make it very easy to improve the accuracy ten fold.

 

Out of curiosity, why did you go with a set RPM range for smoothing and not just an adjustable number of before/after cells for smoothing, like it was? (I haven't looked at what you have done exactly.)

For people with DMA logging or functional 2-byte logging with hundreds of lines per pull, I think the 250 RPM increment is losing too much data.

 

Because the smoothing factor was a NIGHTMARE trying to have it average a 40 row pull vs. a 1800 row pull! If you have a set amount of reference points you can regulate the smoothing MUCH easier. As MrFred can probably back up, if you have a lot of rows with the exact same RPM value, it creates a bunch of zero's in the formula which can be a pain. I'd 'prefer' every 50-100 RPM but on smaller logs it just isn't feasible. I might create 2 simulators built-in with an indicator at a certain row # and have it automatically choose the lower resolution if its below that value and if its above that row # it will automatically use the higher resolution simulator. The user wouldn't even know its doing anything differently though.

I REALLY didn't want to create a program which required a ton of RULES in order for the graph to work correctly (i.e; 2-byte RPM only, log must be more than 200 rows of code,etc...). So I make it work for the 'worst case scenerio' which is a small file when multiple items are being logged or their computer isn't all that fast.

EDIT: What I can do is have it check for the largest RPM gap from one reading to the next and edit the reference points (currently 250 RPM) to accomodate that particular datalog. Hmm, that might be a good way to go.

 

Im just glad i have some type of dyno software that i can use with my AEM since i no longer can use DLL. I think you did a very good job man. But im not much of a nit picker when it comes to this type of stuff anyways.... As long as it works and is consistant then im a happy camper!

Cant wait for your revision so i can see all the way to 9K. I know on AMS's dyno my HP didnt fall off AT ALL even at 8900-9,000RPM. It holds it like a rock!

 

Well I think I might have a nice setup going on right now but I just need to make sure I can make the smoothing work for all file sizes. I basically have it look for the largest deviation in RPM from one cell to the next and that will be the factor which determines how many reference points THAT particular datalog will use. So, if you want better resolution you can just log less items or use 2-byte RPM data (or both), but if you had to datalog many items you can still get decent results even with a small file size. Hopefully it works out. Getting high resolution and accuracy is easy, getting it to work in a wide variety of situations is my goal so its extremely user friendly.

So far though, the averaging at 250 RPM ends up looking almost exactly like anything else I try once the smoothing is applied. Not sure its really worth the hassle for such a basic concept. I'll keep you posted though.

 

Just got a chance to try this out on one of my latest pulls, pretty cool stuff I used the same log and compared a Dynojet log v. a BR MD log. I also showed what that log would look like in DLL. Keep up the good work

VDR Dynojet v BR MD


DLL Reading

 

Has anyone compared this to Data Log Lab's torque/hp calculator?

Duh. Just saw above post!

 

Eh..it's aight I guess..looked pretty simple of a project to me


J/K man..awesome work, glad me and my car could be part of it