[sugpro] Re: Verifying Motor Performance Through Flight Tests
- From: "Michael Monteith" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "michael_r_monteith@xxxxxxxxx" for DMARC)
- To: sugpro@xxxxxxxxxxxxx
- Date: Mon, 23 Feb 2015 12:05:57 -0800
Steve,
I actually didn't want to post it here as it was kind of off topic in the
sense it wasn't
sugar propellants in the strict sense but it is in the sense of measuring
results. I
forgot to take out the group email and put Richards in it so we could discuss
his
findings. But that's okay as long as others don't mind. I hate you can't
un-send. lol
But glad I did in a way too. I think your last statement sums it up. It's
fun and we
learn a lot from it.
Hey, if I don't like the limitations of the instrumentation I can build bigger
and better.
Been there, done that too. Guess if nothing else it will give me an excuse to
work
more with my Arduino boards. I'm used to digging through datasheets as sometimes
that's the best way to find what is ideal for your specific use. Guess I'll
have to find
out from the 2 altimeters I'm looking at which specific parts they use.
For this part going in I just needed more of personal experience and what
others have
already done to at least start off with and an altimeter setup that would
suffice.
I love the fact EggTimer TRS has gps and radio for tracking and for that price
I get
altimeter and tracking. Except I won't have accelerometer. Then with the
raven I have
baro and accel but lose gps and radio. If I had the money I'd just go with
the Altus but
I love my marriage thanks. I'm much better off with a little here and there.
Hey, if I have to do a tethered balloon to obtain comparison data it might be
the way to go
actually. I'd like to see that report you're talking about.
Discouraged? No Way. Challenged? Great! Never know what might become of
it.. Nothing
if I don't try.
Michael
--------------------------------------------
On Mon, 2/23/15, Steve Peterson <steve_peterson@xxxxxxxxxxxxx> wrote:
Subject: [sugpro] Re: Verifying Motor Performance Through Flight Tests
To: sugpro@xxxxxxxxxxxxx
Date: Monday, February 23, 2015, 2:23 PM
On 02/23/2015 09:50 AM,
Michael Monteith (Redacted sender
michael_r_monteith@xxxxxxxxx
for DMARC) wrote:
> I'm kind
of
> anal when it comes to accuracy.
Oh dear, madness lies in this direction...
:-)
As a test equipment
guy, you know the difference between accuracy and
precision (or resolution). And you probably
also know about error
budgets. So
you're going to have to just slog through some math to
decide just how much resolution and
accuracy you're going to need in
your
test instruments (altimeter) to determine the motor thrust
curve
with the accuracy and resolution you
desire.
That will help
decide whether 30 ft or 1 ft resolution is required in
your altimeter. However it ignores the
altimeter's *accuracy* which
probably
won't be anywhere near that. For instance if you get one
altitude measurement of 100 feet with 1 ft
resolution and when the
altitude was really
200 feet, then you get another altitude measurement
of 500 feet with 1 ft resolution and the
altitude is really 300 feet,
your velocity
data will be quite different from what it should have
been.
The best you can do
is read the datasheets for the pressure sensor and
the accelerometers that are used, then study
the atmosphere a bit, then
do some math.
Then give up :-)
One of the
problems (almost always ignored by folks) is that when we
convert pressure to altitude we assume that
the air over our launch site
follows the
atmospheric model of such-and-such a year. I think the
latest was 1976 or something (it's been a
while since I looked into this
for drag
calculations). The obvious problems are local temperature
and
pressure, but you can (in theory)
correct for this. However, even after
those
corrections, it turns out that the atmosphere's *rate of
change*
in pressure vs. altitude even for a
given location is not constant over
time
and doesn't match the "standard day"
model--weather balloons are
launched daily
that measure this (among other things) and you can get
this data if you search the net a bit. What you
want is the data from a
weather balloon
launched from nearby and near the time of your rocket
launch (along with stable weather over a few
days). There was a paper on
this floating
around the net that I can't quickly locate -- Adrian or
someone mentioned it a few years ago and it
explained all this.
Alternatively, you can launch your own device
(gps and barometer) in a
balloon and use
that data. It probably can't be a previously launched
*rocket* because the gps will lose tracking
on the way up. Sigh....
Then, of course, you have to consider the
response time of your pressure
sensor
*system* which includes (among other things) the air hole in
your
electronics bay which you might want
to consider (at least to the point
of
eliminating it as a factor) along with acoustic resonances,
etc. And
maybe factor in the effects of air
temperature on the sensor &
associated
electronics.
So, why not
use accelerometer data instead? Well, that's no slam
dunk,
either. Start with the
accuracy/resolution of the chip itself, then
start adding up the errors in things like the
A/D conversion, the
voltage reference,
etc. However, you still need the atmospheric
information because you need to calculate the
drag which requires air
density (which you
will have to deduce from the pressure information).
Adrian (IIRC) was trying to calculate apogee
from accelerometer data and
you just want
to calculate force, which won't involve the same
accumulation of error that an apogee calc
would, but you'll still have
plenty of
other sources of error to put into your error budget.
I don't mean to discourage
you from tackling this--and you'll want a
decent flight computer *anyway*--but you should
know going in that if
you expect super
accuracy/resolution, it will involve a lot more than
flying a few motors. You're going to need
to create an acceptably
accurate/precise
*experimental system* in order to get really good motor
measurements. That, of course, could be fun in
and of itself.
From the
practical point of view of determining motor thrust
profiles,
however, after a while, the data
from a static test starts looking
better
and better :-) At least it does to me. But, again, we do
this
stuff because it's fun and we
learn a lot in the process. So carry on :-)
--Steve
Other related posts:
