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
