MMCd New Features

[Multiades]

Originally Posted by cbatters

The speed sensor outputs a pulse every 1.5' which provides adequate resolution for doing all kinds of slick things related to distance/time.)

By my calculations, a pulse (four pulses per speedo rev, right?) should come every 1.2675 feet with 810 rev/mile tires (average mfr. spec) and a 2G speedo gear.

Did you calculate tire circumference from diameter or did you roll the car down the street to take your measurement? I'd like to measure actual rolling average, but I haven't yet.

Assuming 810 rev/mile tires (6.5185ft/rev) and a speedo gear that turns 1.2857 times per front diff revolution (2G speedo), you should see a speedo pulse every 1.2675 feet, NOT every 1.5'; that would be some pretty significant error -- like 18% error!

810 rev/mile becomes 6.5185 feet/rev (1/810 * 5280 ft/mile).

6.5185 ft/rev multiplied by the 2G speedometer gear ratio (28/36) becomes 5.070 feet/sender_rev.

Divide 5.070 feet/sender_rev by 4 pulses/sender_rev.

End up with 1.2675 feet/pulse

With the same tires and a 1G speedo gear (27/36), one pulse should come every 1.2222 feet.

Can anyone find a problem with my calculations? That should land you the most accurate speedometer information possible. Perhaps having a text box to input the tire rev/mile info would be a nice feature.

-Chris

[cbatters]

Originally Posted by Multiades

By my calculations, a pulse (four pulses per speedo rev, right?) should come every 1.2675 feet with 810 rev/mile tires (average mfr. spec) and a 2G speedo gear.

Did you calculate tire circumference from diameter or did you roll the car down the street to take your measurement? I'd like to measure actual rolling average, but I haven't yet.

Assuming 810 rev/mile tires (6.5185ft/rev) and a speedo gear that turns 1.2857 times per front diff revolution (2G speedo), you should see a speedo pulse every 1.2675 feet, NOT every 1.5'; that would be some pretty significant error -- like 18% error!

810 rev/mile becomes 6.5185 feet/rev (1/810 * 5280 ft/mile).

6.5185 ft/rev multiplied by the 2G speedometer gear ratio (28/36) becomes 5.070 feet/sender_rev.

Divide 5.070 feet/sender_rev by 4 pulses/sender_rev.

End up with 1.2675 feet/pulse

With the same tires and a 1G speedo gear (27/36), one pulse should come every 1.2222 feet.

Can anyone find a problem with my calculations? That should land you the most accurate speedometer information possible. Perhaps having a text box to input the tire rev/mile info would be a nice feature.

-Chris

1.5' was an approximation for sake of friendly discussion, not a scaling constant from the code.

UI will provide speedo gear + tire data input and/or measured mile which is by far the most accurate. (1/16" tire wear could create a 300' error - the length of a football field. Also not sure how much tire pressure affects the outdide diameter of the tire but the measured mile would null out this error as well.)

How about helping out with some calculations for acceleration / HP and drag calculations?

The interface processes a speed interrupt every 1.5' (approximately) and I have uS timing resolution so we have the option of very accurate/high resolution HP/acceleration numbers.


Clint

[skunkworks]

This is sounding very interesting - Theoreticly you could the graph hp along with everything else. Awsome. I would think You would need to take into account the weight of the car in hp calculations then. In its basic form 1 hp = 550 ft*lbs/sec. Sorry though my physics is a little rusty.

sam

[cbatters]

Originally Posted by samco

This is sounding very interesting - Theoreticly you could the graph hp along with everything else. Awsome. I would think You would need to take into account the weight of the car in hp calculations then. In its basic form 1 hp = 550 ft*lbs/sec. Sorry though my physics is a little rusty.

sam

Correct. Pretty sure these calcs are fresh in Multiades mind. Otherwise I will need to dig out an old physics book to make sure I get the formulas right for accelaration and HP calculations.

Note: In additon to gross vehicle weight, we may also want to compensate for drag by measuring the time it takes for the car to slow from 60 to 30 MPH. Pretty sure GTECH includes this as part of their setup/calibration.


Clint

[skunkworks]

here is a far out idea. Our ecs struts some how adjust for body role and stuff don't they? Is the esc computer reading some sort of feed back from the struts? Think that could be used for a weight measurment - feedback from all four struts for a on the fly weight calculation? For that heavy passenger

I know I am probably dreaming but that would be neet.

sam

Originally Posted by cbatters

Correct. Pretty sure these calcs are fresh in Multiades mind. Otherwise I will need to dig out an old physics book to make sure I get the formulas right for accelaration and HP calculations.

Note: In additon to gross vehicle weight, we may also want to compensate for drag by measuring the time it takes for the car to slow from 60 to 30 MPH. Pretty sure GTECH includes this as part of their setup/calibration.


Clint

[cbatters]

Originally Posted by samco

here is a far out idea. Our ecs struts some how adjust for body role and stuff don't they? Is the esc computer reading some sort of feed back from the struts? Think that could be used for a weight measurment - feedback from all four struts for a on the fly weight calculation? For that heavy passenger

I know I am probably dreaming but that would be neet.

sam

No such magic. ECS has no idea how much the car weighs.

Car weight is well documented and unless you lie about the weight you see on your bathroom scale, the HP calcs should be pretty close.



Clint

[cbatters]

Found my nemesis. Subtle interaction between the vehicle speed and ECU interrupt service routines. Had to build some timing circuits to make the problem repeatable enough to isolate the code sequence. (Could not see any problems using debugger / simulation.) It took a week to find but only one line of code to solve.

Everything in the expansion interface is interrupt driven which is why I am able to simultaneously communicate with with Palm @ 56K baud, extract data from the ECU @ 1953 baud, update vehicle speed 4 times per tire revolution and scan each one of the analog inputs more than 500 times per second. Pretty slick piece of code.



Some 3SI Firsts:

1. First time a Sony Clie SJ33 has EVER logged 1G car data (Expansion communication interface works with ANY Palm compatible device. Could also be used with Pocketlogger / Mirage with minor changes to support higher baud rates.)

2. First time logging/displaying new sensors along with existing ECU data

3. First digital speedometer display using Large Digit mode - you could even set an alarm at 55 MPH to warn that you are speeding - NOT!

4. First logging of fuel pressure - (Unfortunately I forgot to enable the signal for this log - I was so busy screwing around with the MPH signal.)

After lunch I will post another 3SI FIRST - Real time MPG calculation based on INJD (injector duty cycle) and MPH speed sensor. (Tonight I will run some wires so I can begin logging fuel pump voltage.)

Time to get out the bits/bytes/interrupts of the expansion code and make a few changes to the MMCd code.

In the next day or two I will create a new thread to gage overall interest in the expansion interface. Based on the level of interest I will get a sense of how many PCB / parts to purchase for the first build.



Clint

[WARdriver]

holy shnikes...this is a big deal to say the least. Great work!

[skunkworks]

Nice Work!!! I can't wait to see HP graphed.

sam

[wraith]

The active aero "knows" what speed the car is going and there are G-sensors that you might be able to utilize for lateral acceleration calcs. Just a few random thoughts I thought I would add. Also, my AVCr boost controller tracks speed very well using a stock speed sensor tap from the ECU.

Sam