[sugpro] Re: Verifying Motor Performance Through Flight Tests
- From: shawn.mchatten@xxxxxxxxxxx
- To: sugpro@xxxxxxxxxxxxx
- Date: Mon, 23 Feb 2015 15:54:10 -0500
Not sure I'm following all this conversation but instead of a balloon
can you gather data from a parachute recovery on the way DOWN instead of
on the way up to establish air density etc. For that matter are there
any papers that show air density or viscosity based on a specific
parachute and mass configuration. If not that would be a cool standard
to create for the community.
Shawn
On 2015-02-23 15:05, Michael Monteith wrote:
> 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:
