Opinions on High Frequency data capture for miniature dyno.

Archiver

I have been researching what would be needed to accurately capture
the RPM's of a flywheel and timing each rotation down to microseconds.

The flywheel would rotate up to a maximum of about 12000 rpm or about
200 revs per second. I need to time each rotation to capture the
acceleration and speed at intervals to calculate the horspower and
torque.

I am looking into using a hall sensor or an optical encoder to
capture each rotation of the flywheel and am also looking at a BASIC
stamp to coordinate the timing and marshalling of data to a PC for
graphing, printing, and analysis. There have been a number of
messages in here for accurate timing but I'm not sure of what would
be the right way to go about this project.

Ultimately I would like to have PC software that would provide a
countdown to the operator of the dyno and when signal goes 'green'
the engine is revved up as the datalogging captures the RPM's and
acceleration under a known load and gear ratio etc. Each revolution
would be timed in subsecond units (resolution greater than 200 per
second) and sent down an RS232 serial port to the PC.

The questions I have are:

1. Would an optical encoder capture and pulse quick and accuratly
enough or would a hall sensor be better for this?

2. What would be able to take the pulses from the sensor and the
elapsed time between each revolution and store/send it down a serial
link to the PC for analysis and computation of Horspower,torque,
acceleration?

One more piece of information...I am just learning about BASIC stamps
and electonics, circuits etc. My background is in software
development in the corporate world and not so much at lower hardware
levels. I have done serial comm though.

By all means if someone out there already has a package that can do
this type of thing at the accuracy level I 'think' I need then that
would be great. I still would want to learn how anyway.

Thanks for any advice one can give.

Darren Ford

Archiver

Darren,

I used to work at a place that built test systems (including dynos) for
electric motors. Here is how we did it.

We used a quality quadrature encoder that cost in the neighborhood of
$600-1000. It was interfaced directly to a PIC that sampled on the AC
zero crossings, 60 hz.

Data was xmitted serially at 115,200 baud to a VB/VC++ app on a PC.

Sampling at 60 hz required that the data be sent real-time and not stored
in the PIC.

For encoders, you might wish to check out automationdirect.com -- never
used their brand, but they look promising. (and inexpensive compared to
what we used)

I really question if a Stamp will be fast enough to do what you need.
Especially if you try to read the encoders directly with no external
circuitry or interface chip. There are some nifty interface chips
available to read quadrature encoders; try googling for them.

Regards,
amg

On Mon, 25 Aug 2003 03:48:18 -0000 "darylmer" <darylmer@y...>
writes:
> I have been researching what would be needed to accurately capture
> the RPM's of a flywheel and timing each rotation down to
> microseconds.
>
> The flywheel would rotate up to a maximum of about 12000 rpm or
> about
> 200 revs per second. I need to time each rotation to capture the
> acceleration and speed at intervals to calculate the horspower and
> torque.
>
> I am looking into using a hall sensor or an optical encoder to
> capture each rotation of the flywheel and am also looking at a BASIC
>
> stamp to coordinate the timing and marshalling of data to a PC for
> graphing, printing, and analysis. There have been a number of
> messages in here for accurate timing but I'm not sure of what would
>
> be the right way to go about this project.
>
> Ultimately I would like to have PC software that would provide a
> countdown to the operator of the dyno and when signal goes 'green'
> the engine is revved up as the datalogging captures the RPM's and
> acceleration under a known load and gear ratio etc. Each revolution
>
> would be timed in subsecond units (resolution greater than 200 per
> second) and sent down an RS232 serial port to the PC.
>
> The questions I have are:
>
> 1. Would an optical encoder capture and pulse quick and accuratly
> enough or would a hall sensor be better for this?
>
> 2. What would be able to take the pulses from the sensor and the
> elapsed time between each revolution and store/send it down a serial
>
> link to the PC for analysis and computation of Horspower,torque,
> acceleration?
>
> One more piece of information...I am just learning about BASIC
> stamps
> and electonics, circuits etc. My background is in software
> development in the corporate world and not so much at lower hardware
>
> levels. I have done serial comm though.
>
> By all means if someone out there already has a package that can do
> this type of thing at the accuracy level I 'think' I need then that
>
> would be great. I still would want to learn how anyway.
>
> Thanks for any advice one can give.
>
> Darren Ford

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!

Archiver

Try US Digital for encoders and IC's that can do the sampling for
you. Stamp may be too slow to get the data you need. Maybe the BS2p40
but even with that you only going to get maybe 30 to 40 samples a
second depending how efficient your code is and how much pre
processing you need.

Jason



--- In basicstamps@yahoogroups.com, amg amg <controlsdude2000@j...>
wrote:
> Darren,
>
> I used to work at a place that built test systems (including dynos)
for
> electric motors. Here is how we did it.
>
> We used a quality quadrature encoder that cost in the neighborhood
of
> $600-1000. It was interfaced directly to a PIC that sampled on the
AC
> zero crossings, 60 hz.
>
> Data was xmitted serially at 115,200 baud to a VB/VC++ app on a PC.
>
> Sampling at 60 hz required that the data be sent real-time and not
stored
> in the PIC.
>
> For encoders, you might wish to check out automationdirect.com --
never
> used their brand, but they look promising. (and inexpensive
compared to
> what we used)
>
> I really question if a Stamp will be fast enough to do what you
need.
> Especially if you try to read the encoders directly with no external
> circuitry or interface chip. There are some nifty interface chips
> available to read quadrature encoders; try googling for them.
>
> Regards,
> amg
>
> On Mon, 25 Aug 2003 03:48:18 -0000 "darylmer" <darylmer@y...>
> writes:
> > I have been researching what would be needed to accurately
capture
> > the RPM's of a flywheel and timing each rotation down to
> > microseconds.
> >
> > The flywheel would rotate up to a maximum of about 12000 rpm or
> > about
> > 200 revs per second. I need to time each rotation to capture the
> > acceleration and speed at intervals to calculate the horspower
and
> > torque.
> >
> > I am looking into using a hall sensor or an optical encoder to
> > capture each rotation of the flywheel and am also looking at a
BASIC
> >
> > stamp to coordinate the timing and marshalling of data to a PC
for
> > graphing, printing, and analysis. There have been a number of
> > messages in here for accurate timing but I'm not sure of what
would
> >
> > be the right way to go about this project.
> >
> > Ultimately I would like to have PC software that would provide a
> > countdown to the operator of the dyno and when signal
goes 'green'
> > the engine is revved up as the datalogging captures the RPM's and
> > acceleration under a known load and gear ratio etc. Each
revolution
> >
> > would be timed in subsecond units (resolution greater than 200
per
> > second) and sent down an RS232 serial port to the PC.
> >
> > The questions I have are:
> >
> > 1. Would an optical encoder capture and pulse quick and
accuratly
> > enough or would a hall sensor be better for this?
> >
> > 2. What would be able to take the pulses from the sensor and the
> > elapsed time between each revolution and store/send it down a
serial
> >
> > link to the PC for analysis and computation of Horspower,torque,
> > acceleration?
> >
> > One more piece of information...I am just learning about BASIC
> > stamps
> > and electonics, circuits etc. My background is in software
> > development in the corporate world and not so much at lower
hardware
> >
> > levels. I have done serial comm though.
> >
> > By all means if someone out there already has a package that can
do
> > this type of thing at the accuracy level I 'think' I need then
that
> >
> > would be great. I still would want to learn how anyway.
> >
> > Thanks for any advice one can give.
> >
> > Darren Ford
>
> ________________________________________________________________
> The best thing to hit the internet in years - Juno SpeedBand!
> Surf the web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!

Archiver

I had thought about a similar use for tachometer or anemometer using an IR
emitter/detector pair and a disk with X equally spaced holes. (X pulses per rev)
Even if you have 100 pulses/rev at 200 rev/sec that's only 20,000 Hz. Seems the
BS2p should be able to handle that using the Count command with the Period using
fraction of a second with the remaining fraction available for computation.
Being I am new at this, any holes in this logic other than that the error will
be dependant on how fast the disk accelerates? To me this seems easier than
timing a pulse as you don't have to wait, you're just taking a sample.

Archiver

I read through this thread, hoping it would answer questions I have
regarding a similar appplication. I am hoping to implement a dyno
that I can install on a motorcycle. The dyno simply consists of a
gear tooth speed sensor (Cherry part #GS101202 or similar) that
watches the rear sprocket of the motorcycle. If I know the number of
teeth on the sprocket, the circumference of the rear tire, and the
weight of the rider and bike, I can calculate the rear wheel RPM,
Torque, and therefore horsepower. This is a little better than the
original application because the rates are much more reasonable. For
instance, at 100mph wou would only see about 1000 Hz on the gear
tooth counter. Of course I could only do this in one gear, but that
shoudln;t be an issue for now.

I was planning on using PULSIN or COUNT to do the actual speed
sensing. Using either method, each result is stored and made
available to download later and play with on Excel or a similar
spreadsheet application.

Here are my questions:
How can I keep track of time so that I know when the counts are
done? If I use COUNT, for instance, the code would simply loop thru
a count and a write command. I would know exactly how long the COUNT
period would be, but can I count on WRITE taking eactly one clock
tick? If not, how will I know how long it was from one COUNT period
to the next when the program loops?

Is there a better way than using EEPROM space to store this? I get
approximately 100,000 writes on my BS2sx. While I sincerely doubt I
would ever do 100,000 runs, I would rather not wear out the EEPROM.
If I used a seperate EEPROM and communicated to it with SPI or I2C,
can I count on the same speed of execution for the write command?

I would want the data storage to start on a BUTTON, which is simple.
Should I simply have it end when the EEPROM space for that section of
the program is full, or is there a better way of implementing this
such that it only takes up a fixed amount of memory space?

Thanks
Kevin

--- In basicstamps@yahoogroups.com, "darylmer" <darylmer@y...> wrote:
> I have been researching what would be needed to accurately capture
> the RPM's of a flywheel and timing each rotation down to
microseconds.
>
> The flywheel would rotate up to a maximum of about 12000 rpm or
about
> 200 revs per second. I need to time each rotation to capture the
> acceleration and speed at intervals to calculate the horspower and
> torque.
>
> I am looking into using a hall sensor or an optical encoder to
> capture each rotation of the flywheel and am also looking at a
BASIC
> stamp to coordinate the timing and marshalling of data to a PC for
> graphing, printing, and analysis. There have been a number of
> messages in here for accurate timing but I'm not sure of what would
> be the right way to go about this project.
>
> Ultimately I would like to have PC software that would provide a
> countdown to the operator of the dyno and when signal goes 'green'
> the engine is revved up as the datalogging captures the RPM's and
> acceleration under a known load and gear ratio etc. Each
revolution
> would be timed in subsecond units (resolution greater than 200 per
> second) and sent down an RS232 serial port to the PC.
>
> The questions I have are:
>
> 1. Would an optical encoder capture and pulse quick and accuratly
> enough or would a hall sensor be better for this?
>
> 2. What would be able to take the pulses from the sensor and the
> elapsed time between each revolution and store/send it down a
serial
> link to the PC for analysis and computation of Horspower,torque,
> acceleration?
>
> One more piece of information...I am just learning about BASIC
stamps
> and electonics, circuits etc. My background is in software
> development in the corporate world and not so much at lower
hardware
> levels. I have done serial comm though.
>
> By all means if someone out there already has a package that can do
> this type of thing at the accuracy level I 'think' I need then that
> would be great. I still would want to learn how anyway.
>
> Thanks for any advice one can give.
>
> Darren Ford

Archiver

External SRAM? With the address generated by an external counter and
clocked by the Stamp you'd use a couple pins, plus the pins needed for
the data, and a serial to parallel latch. Or if you've got the pins a
byte-wide bus.

Kevin R. Walsh wrote:

> Is there a better way than using EEPROM space to store this? I get
> approximately 100,000 writes on my BS2sx. While I sincerely doubt I
> would ever do 100,000 runs, I would rather not wear out the EEPROM.
> If I used a seperate EEPROM and communicated to it with SPI or I2C,
> can I count on the same speed of execution for the write command?
>

Archiver

Just curious - Why does it matter what gear you're in?

Jack

Kevin R. Walsh wrote:
> ... Of course I could only do this in one gear, but that
> shoudln;t be an issue for now.

Archiver

Forgive me, Kevin, but I do not see how you can calculate torque "the
number of
teeth on the sprocket, the circumference of the rear tire, and the
weight of the rider and bike." Can you tell me how you intend to do
this?

On Friday, September 19, 2003, at 01:43 PM, Kevin R. Walsh wrote:

> I read through this thread, hoping it would answer questions I have
> regarding a similar appplication. I am hoping to implement a dyno
> that I can install on a motorcycle. The dyno simply consists of a
> gear tooth speed sensor (Cherry part #GS101202 or similar) that
> watches the rear sprocket of the motorcycle. If I know the number of
> teeth on the sprocket, the circumference of the rear tire, and the
> weight of the rider and bike, I can calculate the rear wheel RPM,
> Torque, and therefore horsepower. This is a little better than the
> original application because the rates are much more reasonable. For
> instance, at 100mph wou would only see about 1000 Hz on the gear
> tooth counter. Of course I could only do this in one gear, but that
> shoudln;t be an issue for now.
>
> I was planning on using PULSIN or COUNT to do the actual speed
> sensing. Using either method, each result is stored and made
> available to download later and play with on Excel or a similar
> spreadsheet application.
>
> Here are my questions:
> How can I keep track of time so that I know when the counts are
> done? If I use COUNT, for instance, the code would simply loop thru
> a count and a write command. I would know exactly how long the COUNT
> period would be, but can I count on WRITE taking eactly one clock
> tick? If not, how will I know how long it was from one COUNT period
> to the next when the program loops?
>
> Is there a better way than using EEPROM space to store this? I get
> approximately 100,000 writes on my BS2sx. While I sincerely doubt I
> would ever do 100,000 runs, I would rather not wear out the EEPROM.
> If I used a seperate EEPROM and communicated to it with SPI or I2C,
> can I count on the same speed of execution for the write command?
>
> I would want the data storage to start on a BUTTON, which is simple.
> Should I simply have it end when the EEPROM space for that section of
> the program is full, or is there a better way of implementing this
> such that it only takes up a fixed amount of memory space?
>
> Thanks
> Kevin
>
> --- In basicstamps@yahoogroups.com, "darylmer" <darylmer@y...> wrote:
>> I have been researching what would be needed to accurately capture
>> the RPM's of a flywheel and timing each rotation down to
> microseconds.
>>
>> The flywheel would rotate up to a maximum of about 12000 rpm or
> about
>> 200 revs per second. I need to time each rotation to capture the
>> acceleration and speed at intervals to calculate the horspower and
>> torque.
>>
>> I am looking into using a hall sensor or an optical encoder to
>> capture each rotation of the flywheel and am also looking at a
> BASIC
>> stamp to coordinate the timing and marshalling of data to a PC for
>> graphing, printing, and analysis. There have been a number of
>> messages in here for accurate timing but I'm not sure of what would
>> be the right way to go about this project.
>>
>> Ultimately I would like to have PC software that would provide a
>> countdown to the operator of the dyno and when signal goes 'green'
>> the engine is revved up as the datalogging captures the RPM's and
>> acceleration under a known load and gear ratio etc. Each
> revolution
>> would be timed in subsecond units (resolution greater than 200 per
>> second) and sent down an RS232 serial port to the PC.
>>
>> The questions I have are:
>>
>> 1. Would an optical encoder capture and pulse quick and accuratly
>> enough or would a hall sensor be better for this?
>>
>> 2. What would be able to take the pulses from the sensor and the
>> elapsed time between each revolution and store/send it down a
> serial
>> link to the PC for analysis and computation of Horspower,torque,
>> acceleration?
>>
>> One more piece of information...I am just learning about BASIC
> stamps
>> and electonics, circuits etc. My background is in software
>> development in the corporate world and not so much at lower
> hardware
>> levels. I have done serial comm though.
>>
>> By all means if someone out there already has a package that can do
>> this type of thing at the accuracy level I 'think' I need then that
>> would be great. I still would want to learn how anyway.
>>
>> Thanks for any advice one can give.
>>
>> Darren Ford
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject
> and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

Archiver

What's not covered so far is accounting for aerodynamic acceleration.
With the setup he's talking about one could prepare an acceleration
table for a standard set of conditions by accelerating to a given speed,
shifting into neutral, and measuring the interval required to slow by
some convenient increment. Repeating this over a range of speeds would
allow a good approximation of the negative acceleration at a given
speed.

Mark Marpet wrote:
> ... I do not see how you can calculate torque "the
> number of
> teeth on the sprocket, the circumference of the rear tire, and the
> weight of the rider and bike." Can you tell me how you intend to do
> this?

Archiver

Every dynamometer that I am aware of, from those that measure the
horsepower of a car engine to those fit to bicycle hubs, MEASURE the
torque; the car dynos do it using a force gage through a lever arm, the
bike dynos using a force gage inside the rear hub. What I'm asking is
how do you intend to get that torque. If you measure the traction
reaction force (NOT the ground reaction force, i.e., the weight, but
the force parallel to the ground), you could get what you want, but the
weight of the rider and bike, I don't think, would do it, as the
rear-wheel GRF passes through the centerline of the rear hub, so you
can't get the rear-wheel torque from that.
On the other hand, I could be missing something?

On Friday, September 19, 2003, at 10:20 PM, goflo@p... wrote:

> What's not covered so far is accounting for aerodynamic acceleration.
> With the setup he's talking about one could prepare an acceleration
> table for a standard set of conditions by accelerating to a given
> speed,
> shifting into neutral, and measuring the interval required to slow by
> some convenient increment. Repeating this over a range of speeds would
> allow a good approximation of the negative acceleration at a given
> speed.
>
> Mark Marpet wrote:
>> ... I do not see how you can calculate torque "the
>> number of
>> teeth on the sprocket, the circumference of the rear tire, and the
>> weight of the rider and bike." Can you tell me how you intend to do
>> this?
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject
> and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

Archiver

Hello,

The easiest way to get SRAM for a stamp is the Rampack B from
http://www.solutions-cubed.com/

I have messed around with Stamp - SRAM and you can make a shift register
interface that uses 4 or 5 stamp pins and is faster than the Rampack in
byte sized operations (the Rampack is faster if you can read/write in
blocks). If you have a BS2p then you can use I2C which will require 4
stamp pins (2 for I2C, 2 for SRAM). The I2C method is a little slower though.

The shift register interface uses 7 chips (not including the SRAM). I
tried a circuit with a counter for the address, but it quickly got too big
to be useful. The I2C circuit only uses 2-3 chips.

Of course all of these options will be much slower than writing to the
stamps own EEPROM.

Chuck Chargin Jr.

At 12:15 PM 9/19/2003 -0700, you wrote:
>External SRAM? With the address generated by an external counter and
>clocked by the Stamp you'd use a couple pins, plus the pins needed for
>the data, and a serial to parallel latch. Or if you've got the pins a
>byte-wide bus.
>
>Kevin R. Walsh wrote:
>
> > Is there a better way than using EEPROM space to store this? I get
> > approximately 100,000 writes on my BS2sx. While I sincerely doubt I
> > would ever do 100,000 runs, I would rather not wear out the EEPROM.
> > If I used a seperate EEPROM and communicated to it with SPI or I2C,
> > can I count on the same speed of execution for the write command?
> >
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Archiver

Mark Marpet wrote:
>
> Every dynamometer that I am aware of, from those that measure the
> horsepower of a car engine to those fit to bicycle hubs, MEASURE the
> torque...

Sure. It's often the easiest thing to measure. However if you know
mass, acceleration, velocity, and RPM, power and torque are derived
directly, as follows:

Force = Mass X Acceleration - Mass in lbs, Acceleration in g
Hp = Force X Velocity / 550 - Velocity in fps, Force in ft-lbs
Torque = 5252 X Hp / RPM

It's easy to get wrapped around the axle in these calculations
by mixing units, AKA "dimensions". For instance if you choose to
use acceleration stated in fps/sec instead of "g" units then the
appropriate mass unit is the slug, not the pound. Bear in mind
that total acceleration must include the negative acceleration
produced by friction, drag, grade, and so on.

Anyway, I'm curious to hear about our colleague's approach.

Archiver

I think that you and I are on the same page. You can certainly estimate
friction drag and tire losses--separately or together--with coasting
experiments using an accelerometer on various KNOWN downgrades, and you
can, after figuring out ground losses, estimate aero losses via
different speed experiments on a single grade. You can then factor all
of that in to accelerometer-derived measurements. But, ultimately, I
think it's easier AND more accurate to build a strain-gage into a
torque-arm link (think of the torque arm on the old sturmy-archer
three-speed "english-racers" (an oxymoron if ever there was one) of the
1950s. A/D the strain gage and you are home free.



On Saturday, September 20, 2003, at 02:15 AM, goflo@p... wrote:

> Mark Marpet wrote:
>>
>> Every dynamometer that I am aware of, from those that measure the
>> horsepower of a car engine to those fit to bicycle hubs, MEASURE the
>> torque...
>
> Sure. It's often the easiest thing to measure. However if you know
> mass, acceleration, velocity, and RPM, power and torque are derived
> directly, as follows:
>
> Force = Mass X Acceleration - Mass in lbs, Acceleration in g
> Hp = Force X Velocity / 550 - Velocity in fps, Force in ft-lbs
> Torque = 5252 X Hp / RPM
>
> It's easy to get wrapped around the axle in these calculations
> by mixing units, AKA "dimensions". For instance if you choose to
> use acceleration stated in fps/sec instead of "g" units then the
> appropriate mass unit is the slug, not the pound. Bear in mind
> that total acceleration must include the negative acceleration
> produced by friction, drag, grade, and so on.
>
> Anyway, I'm curious to hear about our colleague's approach.
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject
> and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

Archiver

Mark Marpet wrote:
> I think it's easier AND more accurate to build a
> strain-gage into a torque-arm link ...

Certainly for my app it would be - I'm interested
in measuring rider effort real-time - If I could
get around building a custom derailleur with a torque
link. Of course a Rohloff 14-speed gearbox would solve
that problem, would'nt it!

Archiver

Yes and no. The 14-speed gearbox seems really cool (I never heard of
the Rohloff and had to Google it) but IT doesn't seem to be able to
measure torque. On the other hand, if you're flush enough for that
gearbox, you're should consider the Cycleops Powertap power-measuring
rear hub.

www.nashbar.com Stock number AG-7005 $799.99 each

Of course, the strain gage would do the same thing.

On Saturday, September 20, 2003, at 04:30 PM, goflo@p... wrote:

> Mark Marpet wrote:
>> I think it's easier AND more accurate to build a
>> strain-gage into a torque-arm link ...
>
> Certainly for my app it would be - I'm interested
> in measuring rider effort real-time - If I could
> get around building a custom derailleur with a torque
> link. Of course a Rohloff 14-speed gearbox would solve
> that problem, would'nt it!
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject
> and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

Archiver

Mark Marpet wrote:

> Yes and no. The 14-speed gearbox seems really cool (I never heard of
> the Rohloff and had to Google it) but IT doesn't seem to be able to
> measure torque.

It does'nt measure torque, but there is a torque arm so a transducer
could be grafted on - Not much chance of that at the moment...

Jack

Archiver

Well, to measure the output torque (T) of the rear wheel, I can
measure the radius (r) from the circumference of the wheel.
From there it is simply T=r x F. So now I need to solve for F. For
that I simply need F=ma. m is the mass of the bike and rider. I
have that. a is the acceleration of the bike. I get that from the
rate of change of frequency of the gear tooth counter. Horsepower
is simply torque at a given rpm, so from the gear tooth counter I
get rate and rate of change of the rear wheel RPM.

Now, like someone else pointed out, using this method is rife with
errors. The first is that all of the force output by the rear wheel
is not going into accelerating the bike. It pushes a lot of air,
and that should be accounted for. As someone else pointed out, a
simple coast down will account for that loss.

Second, changes in air temperature, pressure, etc also influence the
results. In a campaign of taking dyno measurements I would be
trying to compare one modification on the bike to another, so the
time seperating the two would be minimized. Also, measuring air
temp, pressure, etc would help to minimize this. Along the same
lines, wearing the same clothes, keeping the gas tank level the
same, not going on a diet or gaining weight, doing two way runs on
largely level ground, etc. will help keep the results stable.

Third, someone asked about why I have to keep it in one gear. The
answer is you don't. It could be done in any gear. I just meant
that if I was going to set up a spreadsheet to back calculate all of
this, I would want to keep it simple and use only one gear.
Further, you would want to do rolling starts so clutch slip was not
involved. You'd want to use a relatively high gear so that the COUNT
function didn't have a large % error, etc.

I think I got my real answer though. Use EEPROM on the chip and
simply deal with the fact that the Stamp will wear out after 100,000
dyno runs. I plan on being old and grey before that happens....

Kevin

--- In basicstamps@yahoogroups.com, Mark Marpet <marpetm@s...> wrote:
> Forgive me, Kevin, but I do not see how you can calculate
torque "the
> number of
> teeth on the sprocket, the circumference of the rear tire, and the
> weight of the rider and bike." Can you tell me how you intend to
do
> this?