Virtual Dyno

[JDM SpecB]

Ok thanks.

 

I have uploaded the log now as well.

[JDM SpecB]

<CarMake>Subaru</CarMake>

<CarModel>Legacy</CarModel>

<CarSubModel>Wagon</CarSubModel>

<StartYear>2003</StartYear>

<EndYear>2006</EndYear>

<Weight>3351</Weight>

<TransTypeManual>False</TransTypeManual>

<TransGear3>1.296</TransGear3>

<TransGear4>0.972</TransGear4>

<FinalGearRatio>4.444</FinalGearRatio>

<DragCoefficient>0.32</DragCoefficient>

<FrontalArea>22.20</FrontalArea>

<TireDiameter>25.07</TireDiameter>

[BAC5.2]

Someone send me an automatic log, and I'll see about fixing the problem you guys have.

[JDM SpecB]

mine is posted at the top of this page

[bbarnhill]

if you are referring to the spike you get in an auto transmission log good luck. If there was a way to fix it I would have. There is absolutely ... and I repeat ... ABSOLUTELY no way to compensate for slippage in the drive train. There is no way to accurately do that. If someone will show me a solution (to calculating ... NOT guesstimating), Ill admit I was wrong. Its the same thing as compensating for wheel spin or clutches slipping.

[BAC5.2]

You know engine RPM, and you know vehicle weight, vehicle speed, tire diameter, gear ratios, and time. You can back-calculate non-slip engine RPM and from there calculate horsepower.

 

Work is directly related to acceleration, and horsepower directly to that.

 

I have no idea how you are calculating horsepower, so it might require revision of your whole algorithm. But it can be done, and with a level of accuracy similar to the level of accuracy you'd have otherwise.

 

You can compensate for both wheel spin and slipping clutches. It becomes somewhat complicated, but you can definitely calculate asynchronous power transfer. I know, because I've done it. And a small part of my masters thesis involves similar practice.

[bbarnhill]

I only know vehicle speed based on knowing RPM and calculating vehicle speed. There in lies the problem. Im having to assume no drive train slippage due to not knowing vehicle speed. Not all loggers record vehicle speed.

 

Thank goodness I chose the non-masters route when pursuing my masters in Computer Science which I lack 9 hours in and my Masters in Nursing they didnt require a thesis. I write like a fourth grader.

[BAC5.2]

That's a limitation of the logger, not the program.

 

You can calculate post-torque-converter input shaft speed, and from that calculate the power required to maintain within the laws of physics. That will get rid of what I've been calling the "Automatic Catestrophe". Similar steps can be taken to calculate out wheel spin and clutch slip, with some slight variation on DAQ.

 

I've actually used similar analytical procedures to calculate the power required to motivate a light electric vehicle around a course with elevation changes. The result was accurate to industry specs and commercial systems.

 

It can be done.

[bbarnhill]

enlighten me with only RPM and TPS as to the math involved. I must be slow

[BAC5.2]

Power required to motivate a body through space is not black science.

 

You know physical properties of the vehicle, and you know how quickly it is accelerating (to a relatively high degree of accuracy from the ECU, which can tell time to the ten-thousandths or more, and speed to the hundredth of a MPH).

 

You are merely running a modified form of the algorithm that dyno's use, including the terms for wind and rolling resistance. Since you can calculate, somewhat accurately, wind resistance and rolling resistance, you can calculate power.

 

When I did this for LEV's (and human powered vehicles, as well) as an undergrad, I was doing it with a different goal. My intention was to audit energy consumption of a power-limited electric vehicle on a circuitous route with a varying geographic profile, with the intent of being able to better spec and package power storage devices within the vehicle. The outcome was different, but the concept was the same.

 

My graduate work treads a different path, but a section of my thesis is dedicated to calculation of induced power through an asynchronous system.

 

You don't really even need logs, beyond physical constants, and a plot of speed vs. time. Where the log becomes useful, is so that you can map vehicle power to engine RPM. And since you know speed, gear ratios, and tire sizes, you can back-pedal to get input shaft RPM, and map power to input shaft RPM. Since input shaft RPM is really the governing RPM, that's sufficient to calculate engine power required to motivate the car. And since the torque converter eventually locks up, making the ratio between the input RPM and engine RPM 1:1, you'll see that my method solves the existing problem of the "automatic catestrophe".

 

Believe me. You can calculate power output of a vehicle when you know physical properties of the vehicle.

 

Auto manufacturers don't just guess at how much power they want to have. They use performance metrics as a design constraint, then design a power plant to accomplish the metric.

 

The hardest thing to discover is Cd. It's occasionally published, but not always. Wet frontal area isn't too difficult. Photoshop can get you 90% of the way there by giving you a plot of the outline of a front-on picture. A CAD program that lets you import vector drawings will spit out frontal area once you scale the drawing.

[bmx045]

you are an animal BAC, what kind of coffee do you drink this early in the morning?

[BAC5.2]

Meh, I was designing a turbo exhaust manifold this morning, and wanted a break before starting the work I actually have to do.

 

Also, it's not type but quantity. The answer is, therefore, "a lot".

[BAC5.2]

Ooo I just thought of something! You can actually auto-populate much of the equations necessary for this method by logging a "slow-down" event.

 

If your road is perfectly flat and sufficiently long, you can do your pull, then push in the clutch and coast down to just below your starting speed before stopping the log. Then, in Excel or wherever, you can calculate combined rolling and wind resistance from the coast-down numbers.

 

That cuts down the information you need to know significantly, and improves your accuracy.

 

I bet, if you really thought about it and were careful with planning and testing, you could bring your accuracy to within +/- 2% of "real".

[bbarnhill]

Again ... Speed isnt recorded by all loggers. RPM is so I have to start my calculations at the other end of the drive train ... on the other side of the drive train from where speed is figured. Since Tires (tire size) is on one side of the drive train and the recorded RPM is on the other, I have to assume there is no slipping. If every logger recorded MPH or KPH it would be great, but a lot of them do not log speed.

[bmx045]

Well subaru loggers can do speed, so lets check it out

[bbarnhill]

I know CAN loggers can do speed but for some reason they dont. It would have helped GREATLY and cut down on calculations to record speed. Speed is also only recorded to the whole mph or kph which sort of cuts down on accuracy.

 

I also try to keep the program where it works the same for all loggers and dont add special cases per logger. That way everyone gets the same attention and same support. It also does not become a support nightmare for this one man development army.

[BAC5.2]

The Accessport logs record speed to the hundredths place. Same with time.

 

You can still account for drivetrain slip, working from engine RPM only, but the results will very quickly lose accuracy. Again, ask me how I know. It can be done more easily when you have designed the entire drivetrain, but since you didn't it's almost impossible to be accurate with slip.

 

If I had the programming background you have, I'd consider adding an option. For people using loggers that record actual vehicle speed, do it the way I described. For people using loggers that only do RPM, then they can do it the existing way.

 

In reality, all you need is accurate speed and time to calculate power. A good GPS logging program would be sufficient to be able to calculate power. Commercial grade GPS has a spatial resolution of around 3m or so when static, but when moving that resolution tightens by a factor of two or so. Differential GPS can give spatial accuracy down to the centimeter. Speeds calculated via commercial GPS can be accurate to the hundredths, and times to the millisecond.

 

If you could log vehicle data and GPS data, you could even account for tire balloon ratio, and factor that into your calculations as well to improve accuracy.

 

It might not be easy, but it most certainly can be done.

[thefultonhow]

the "automatic catestrophe"

 

...is unsolvable without getting rid of automatics.

[BAC5.2]

I see nothing wrong with that statement.

[JDM SpecB]

Waht the?

 

Few questions...how do I give you my car details since under Subaru there is only option of

05-09 legacy 2.5GT

07 SE

08-09 2.5GT

 

Mine is a 2.0ltr twin scroll so im not sure how accurate it will be?

 

Update on this new pull.

Seems to be some wild variations in the romraider dyno and virtual dyno?

romraiderlog_20110916_122204.csv

[bbarnhill]

you did notice you were showing kW and nM in romraider and ftlbs and hp in VD?

[JDM SpecB]

Not too worried out that.

 

Do graphs seem right?

[bmx045]

You're knocking like a boss. Aren't you not tuned yet?

[JDM SpecB]

You're knocking like a boss. Aren't you not tuned yet?

Nice english

 

 

Lol ,yes Rev02 now.

 

Does the HP and torque seem right?

[bmx045]

I chose that wording on purpose. A little less than 250hp/tq seems right. But if you're not done being tuned, why are you even doing this? You're beating your car and it's knocking because of it.