[Vignesh_N/A]

I suppose this should work fine for motorcycles also. Has anyone tried before?
Its not that we dont have dyno facility in Chennai, I am just curious to try.

[graaja]

Originally Posted by Vignesh_N/A

I suppose this should work fine for motorcycles also. Has anyone tried before?
Its not that we dont have dyno facility in Chennai, I am just curious to try.

That is an interesting thought. Not sure how the equations work for a motorbike. You could give it a try though. It would also be good to check their forum for some inputs on this.

[Vignesh_N/A]

From the looks of it, Cd and pitch is where I will probably get stuck.
How does the value in Pitch affect the end result?

[graaja]

Originally Posted by Vignesh_N/A

From the looks of it, Cd and pitch is where I will probably get stuck.
How does the value in Pitch affect the end result?

There is no provision to edit Pitch in the dyno parameters. So, not sure how this would affect the final result. But looking at the effect of Cd.A on the results, pitch should also have very little effect as well. The biggest effect is the weight. So you could just set Cd.A to 0.4 and pitch to 3 (which is middle) and try.

[d3mon]

Originally Posted by graaja

Thanks. I did not know about the weather correction. I will do some more runs with weather correction disabled and share the results.

You can also go into your existing results in the app, and then modify the weather conditions to say somewhere around 14 PSI of atmospheric pressure and 50% humidity. That should get you to a correction factor of close to 1 for your existing runs as well! If not, increase of decrease the atmospheric pressure as needed.

[Harrie]

Originally Posted by graaja

Attachment 1610364

The Polo GT TSi is rated to develop 105bhp of power and 175Nm of torque. Hower the dyno results showed a peak power of about 130 bhp and a torque of 210 Nm. This definitely is not possible. The guy who did the dyno kept insisting that the dyno is accurate and my car was indeed that powerful. As any argument was futile, I left it there. And I also postponed the plan to remap the car.

VAG cars usually quote their "Wheel" horsepower. Others quote "Crank" horsepower.

The spitfire dyno has a provision to calculate transmission losses automatically and the final result gives you the "Crank" horsepower.

Wheel horsepower can be noted down as the dyno is sweeping through the rpm ranges.

[Alfresco]

Originally Posted by Vignesh_N/A

How does the value in Pitch affect the end result?

I guess it has to be something with the softness of the suspension. The suspension shall absorb some of the acceleration and, consequently, the correct force shall not be gauged by the accelerometer of the phone resulting in unusable data points that shall mess with the accuracy of the algorithm.

[Jomz]

Originally Posted by graaja

Power = Force x Velocity

This contradicts Power ( energy)= 0.5* mass* velocity^2. I guess the math is wrong.

Originally Posted by graaja

Power = Mass x Acceleration x Velocity

Mass x Acceleration x Velocity = 0.5 *mass* velocity^2

Cancelling mass and velocity

acceleration = 0.5 * velocity:-)??

Originally Posted by graaja

• The app measures acceleration using the accelerometer in the cell phone. Velocity can be easily calculated using same acceleration data. With these values, the App first calculates horse power.

No. Velocity cannot be calculated from acceleration data without knowing the initial velocity from it accelerates & time for which acceleration exists. However you can calculate velocity from the position data given by GPS.

[graaja]

Originally Posted by Jomz

This contradicts Power ( energy)= 0.5* mass* velocity^2. I guess the math is wrong.
Mass x Acceleration x Velocity = 0.5 *mass* velocity^2
Cancelling mass and velocity
acceleration = 0.5 * velocity:-)??

No. The math is not wrong. You are confusing between Kinetic Energy and Power.

The equation you gave Power(energy) = 0.5 * mass * velocity^2 is for kinetic energy. This is totally different from power.

Energy is the capacity to do work. Energy is power integrated over time. Energy is measured in watt-seconds.
Power is the rate at which work is done. Power is measured in joules/second

This video explains the concept of Energy, Work and Power.

https://www.youtube.com/watch?v=w4QFJb9a8vo

Originally Posted by Jomz

No. Velocity cannot be calculated from acceleration data without knowing the initial velocity from it accelerates & time for which acceleration exists. However you can calculate velocity from the position data given by GPS.

Exactly. Velocity cannot be calculated from acceleration data without knowing the initial velocity. But in this case we know initial velocity is zero. Now if you measure acceleration at various points of time, you can easily calculate velocity, and distance travelled by integrating multiple data points. Read the quote I provided from PerfExpert on how it works. Quoting it again below.

PerfExpert relies on the accelerometer of your phone to measure the actual acceleration of your car. This requires that you always take off the car from complete halt (0Mph), which allows the application to compute very accurately the instantaneous speed and distance.

Hope this makes it clear.

[Jomz]

Originally Posted by graaja

Exactly. Velocity cannot be calculated from acceleration data without knowing the initial velocity. But in this case we know initial velocity is zero. Now if you measure acceleration at various points of time, you can easily calculate velocity, and distance travelled by integrating multiple data points. Read the quote I provided from PerfExpert on how it works. Quoting it again below.


.

Only if it were this easy. There are quite a few issues with this approach.

1, The accelerometer is measuring acceleration due to gravity and vibrational accelerations. A frame of reference needs to be established to separate various components of acceleration - which is impossible in case of a hand-held.

2, Typically measurements are directly measured or a differential is used. The issue with an integral measurement is - small errors in measurement get integrated with time to get the current value and there is no way to calibrate out this error. In a matter of seconds the error term will overwhelm the actual measurement.

As I said- Most reputed apps use GPS data to get position and, speed as differential on the position for good results. Maybe some of the inaccuracies reporeted are due to the flaws in the approach.

Some references.

http://www.chrobotics.com/library/ac...ition-velocity

[alpha1]

You know I tried searching for an app of this sort since the beginning of smart phones.
I always wondered why there is no app, when all you require is to measure acceleration at ultra-fast resolution, and then mass, frontal area and drag coefficient is something that you can supply with.

Thanks for the find.

[graaja]

Originally Posted by alpha1

...
I always wondered why there is no app, when all you require is to measure acceleration at ultra-fast resolution, and then mass, frontal area and drag coefficient is something that you can supply with.

Thanks for the find.

Actually, this is not my find. Credit goes to d3mon who brought up this app in Chethan's Jetta thread

The author has developed a wonderful application just based on accelerometer data. And the way he has implemented the calibration to cancel offset and gain errors in the phone's accelerometer is just fantastic!

Originally Posted by Jomz

1, The accelerometer is measuring acceleration due to gravity and vibrational accelerations. A frame of reference needs to be established to separate various components of acceleration - which is impossible in case of a hand-held.

Some of the important conditions PerfExpert insists are:

• Firmly fix the phone on a stable holder without any vibrations (it actually throws an error if it detects unstable mounting of the phone)
• Perform a calibration of the acceleration sensor in the phone
• Before starting the dyno run, keep the car absolutely stable when the App shows "Wait"

Error correction: I have posted a video that explains how the phone has to be calibrated. This calibration involves placing the phone in various positions and letting the App performing calibration of the sensor. There are two errors in any measurement system - the offset error and gain error.

Offset Error: When the phone is placed in various resting positions, 2 of the 3 axes should read zero. However, due to offset error in the sensor, the values would be non-zero. These values can be stored and subtracted from real time measurements to cancel offset error.

Gain Error: As earth's gravity is a known constant, this can be used to compensate gain error in the sensor. For example, in each of the calibration positions, one of the sensors should read 9.8m/s^2 (or -9.8m/s^2). However, say if the sensor reads 9.898 m/s^2, the scale error can be caluclated as 1%. Later during actual measurement, this can be used to correct the real time measurement.

With this two point calibration, the offset error can be made almost, if not zero, and the gain error can be made less than 0.5%. I have not made any measurements on the accelerometer values to verify this. However, from my experience in building precision analog instrumentation systems, I know for sure this will be the case.

Positional inaccuracy can also be easily cancelled. Once the offset and gain errors are stored during calibration process, I believe the App also does another round of calibration before starting the dyno. This is to find the position of the phone from the three axes when the car is still. Once the accelerometer data from the three axes is know when the car is in stand still, once the car starts accelerating, it is very straightforward to extract the accelaration component due to the forward movement of the car.

Originally Posted by Jomz

2, Typically measurements are directly measured or a differential is used. The issue with an integral measurement is - small errors in measurement get integrated with time to get the current value and there is no way to calibrate out this error. In a matter of seconds the error term will overwhelm the actual measurement.

As I said- Most reputed apps use GPS data to get position and, speed as differential on the position for good results. Maybe some of the inaccuracies reporeted are due to the flaws in the approach.

Some references.

http://www.chrobotics.com/library/ac...ition-velocity

In integration, only the offset error gets integrated over time. Gain error does not integrate. It remains the same even after integration over infinite time. As the calibration would make the offset and gain errors very small, and as the complete dyno run lasts less than 20 seconds, the error in the final result should be within acceptable limits.

I am not trying to prove that this is the best way to implement this application, nor am I saying that this approach does not have any flaws. All the clarifications I have provided are based on how I would have solved various errors in the system.

Yes, the author could have used GPS for getting velocity or used an OBD adapter to get RPM (instead of reverse calculating through gear ratios). But my guess is that he may have his reasons for implementing this system this particular way and would have done some home work regarding the errors that this system would produce and how to compensate these errors.

I always believe that if a problem is given to 10 engineers, they would solve the same problem in 10 different ways. Each solutions will have its advantages and disadvantages, but still each of them would have solved the problem.

I think I have explained everything I know. If you have any more questions, maybe other experts in Physics and instrumentation could answer your questions. Or you could discuss this in PerfExpert forums and share your learnings.

Cheers!

[Jomz]

Originally Posted by graaja

Offset Error: When the phone is placed in various resting positions, 2 of the 3 axes should read zero. However, due to offset error in the sensor, the values would be non-zero. These values can be stored and subtracted from real time measurements to cancel offset error.

Nope. 2 axes would read zero only if the software compensates for direction of 3 axes. The the accelerometer axes are tilted there should be still a reading which is valid. For example if the axes are tilted by 45 deg there would still be the component of g in each axes. This cannot be used to delete the gain error.

Again on gain , which is a multiplier on sensor output- 2 reliable noise free values need to be taken to establish the gain constant. Your approach shows only one point on the gain curve.

There is always sensor noise which needs to be accounted for. Unless your phone has really high quality sensor and expensive hardware filters- this noise is going to get integrated and that will kill the integral measurement over time.

some more references

http://stackoverflow.com/questions/1...-accelerometer

https://www.codeproject.com/Question...-accelerometer


But if it is done , Great job. Should publish a paper on how he did it

[graaja]

Originally Posted by Jomz

Nope. 2 axes would read zero only if the software compensates for direction of 3 axes. The the accelerometer axes are tilted there should be still a reading which is valid. For example if the axes are tilted by 45 deg there would still be the component of g in each axes. This cannot be used to delete the gain error.

I believe the software does compensate for the direction of the three axes. Below is the raw accelerometer output from my cellphones sensor, in three positions - lying flat, portrait and landscape. If the software knows the position of the phone and the sensor readings relative to that position, it can easily compensate for all errors. In fact, the calibration involves placing the phone in 6 different directions. That is enough data points to calibrate the sensors.



Is this going to provide aerospace or military grade accuracy? No, definitely not. Even the angle of the floor of my house and the wall, and how I hold the phone during calibration are going to introduce errors in the final results.

Originally Posted by Jomz

Again on gain , which is a multiplier on sensor output- 2 reliable noise free values need to be taken to establish the gain constant. Your approach shows only one point on the gain curve.

Yes. You need two noise free points to calibrate gain. Zero can be one of them. And in this case where readings are taken with the phone in 6 positions, there are enough data points to compensate the gain error.

Originally Posted by Jomz

There is always sensor noise which needs to be accounted for. Unless your phone has really high quality sensor and expensive hardware filters- this noise is going to get integrated and that will kill the integral measurement over time.

Actually you do not require very high expensive sensors to get accurate readings. With calibration and some digital processing, even low cost sensors can give pretty accurate readings. Again "accurate" is a relative term here. With the low cost sensor in a cell phone is it possible to achieve an accuracy of 3%, 2% or even a best case 1%? I believe it is possible.

Is it possible to achieve an accuracy of 0.1%? No, that is not possible. For that you would need very expensive sensors and advanced signal processing circuits and techniques.

As we are talking about an app that costs INR650, and an application where a user is not going to bother if the torque reads 320Nm or 310Nm (that is a 3.12% error), I guess it solves the purpose.

Originally Posted by Jomz

But if it is done , Great job. Should publish a paper on how he did it

Absolutely. This is a great job indeed. But I doubt if the author is going to publish a paper on this exposing his trade secrets

[Sutripta]

How does this compare with Dynolicious? Anyone using both?

The biggest problem with these systems is trying to work out how much the vehicle will squat under acceleration.

Regards
Sutripta