
23rd April 2015, 12:31 AM
#31
DAaang! There is some serious brain trust here guys! All my rockets have the drag coefficient of a Redwood. I'm just happy they go faster than I can run and higher than I can throw them. Thank my lucky stars I'm not smart enuff to have to worry about this. Seriously interesting stuff can be learned herethanks!
TRA 2383
Somebody told me I was on the watch listI hope I get a Rolex.....
The road to Hell is paved....you're welcome.
I can't remember the last rocket I built, because I haven't built it yet.....

16th June 2017, 05:27 PM
#32
I'm new to this forum so my reply is probably out dated. You referenced the Apogee newsletter above. Did you see a response in newsletter #315 from Dan Moses? He was a mentor for a group of high school students from Falls Church, VA. that submitted a project for the NASA Student Launch Initiative (SLI). The kids used acceleration data and velocity data during the coast phase of their rocket's launch to arrive at a Cd. They plotted acceleration on the yaxis and velocity squared on the xaxis and this resulted in a straight line which could be easily modeled with a y=mx+b equation. They used the slope of that equation (a/v squared) and divided it by 1/2 * rho *A/m to obtain a good approximation of their rocket's Cd. Dan Moses has a Ph.D. and works for NASA so their work has some degree of credibility.

18th June 2017, 03:10 PM
#33
Originally Posted by bobk99
I'm new to this forum so my reply is probably out dated. You referenced the Apogee newsletter above. Did you see a response in newsletter #315 from Dan Moses? He was a mentor for a group of high school students from Falls Church, VA. that submitted a project for the NASA Student Launch Initiative (SLI). The kids used acceleration data and velocity data during the coast phase of their rocket's launch to arrive at a Cd. They plotted acceleration on the yaxis and velocity squared on the xaxis and this resulted in a straight line which could be easily modeled with a y=mx+b equation. They used the slope of that equation (a/v squared) and divided it by 1/2 * rho *A/m to obtain a good approximation of their rocket's Cd. Dan Moses has a Ph.D. and works for NASA so their work has some degree of credibility.
That's pretty slick. Thanks for sharing.
I haven't done much with this in many months, but I also want to compute rho as a function of altitude (nonstandard day conditions) and eventually plot Cd vs Mach. The accel data from the altimeter is pretty noisy, so smoothing/fitting is needed to get started.

18th June 2017, 07:17 PM
#34
Curious about how and where you are going to get your data for plotting Cd vs. Mach It sounds interesting.

20th June 2017, 07:55 PM
#35
Originally Posted by sooner.boomer
A very good question! Also, how accurate are the accelerometers? As previously posted, what are you trying to do with the data? Is "close" good enough?
To quote my materials professor in college, engineering is the science of good enough. I'd be pretty happy with +/ 0.05 on my Cd, but I'm not a high performance flier. I suspect that anyone that really needs precision is willing to pay for a wind tunnel and/or CFD.
NAR L1 "Cheeto Dust", scratch 54mm, H54R (before it became a G54), Mansfield, WA
L2 "Arc Light", Madcow 2.6" Arcas, J285CL, Mansfield, WA, recovery by snowshoe

20th June 2017, 08:20 PM
#36
I'd be happy with +/ 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.

20th June 2017, 11:02 PM
#37
Originally Posted by bobk99
I'd be happy with +/ 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.
There's plenty of MPR that can break m1; CTI's g65 is a prime example.

21st June 2017, 12:40 AM
#38
Originally Posted by bobk99
I'd be happy with +/ 0.05 on my Cd any day too. I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.
Mach number means velocity in a nondimensional form. I want to back out Cd vs. Mach number, which is the proper way to characterize rocket drag. Many HPR rockets exceed Mach=1, if that is what you mean.
I just want to prove to myself that I can crunch the numbers, account for all variables correctly, and produce a curve that "looks" correct. I have no illusions that it is the "correct" answer, as measured flight data is very squirrely and does not follow nice assumptions. The raw data (say from a Raven) is very noisy and requires data fitting/smoothing in order to perform calculations upon. This is the first hurdle and is an area of numerical methods that I am not very familiar with.
Last edited by Buckeye; 21st June 2017 at 12:52 AM.
Reason: more stuff

21st June 2017, 12:46 AM
#39
Originally Posted by dhbarr
There's plenty of MPR that can break m1; CTI's g65 is a prime example.
This doesn't really describe a solution. It is like saying "Sunoco 97 octane gasoline goes 150 mph."

21st June 2017, 01:05 AM
#40
Originally Posted by bobk99
I was just wondering how he was going to get Mach data since even HPR is sub sonic unless your into sounding rockets.
"MPR means subsonic" is a common misconception, up there with "tubefins can't break mach".
Originally Posted by Buckeye
This doesn't really describe a solution. It is like saying "Sunoco 97 octane gasoline goes 150 mph."
As minimum drag shapes are rather robustly attested both in theory and actual practice, pointing out a single example rather does dispel the common myth.
I did not say "white propellant breaks mach" :)

21st June 2017, 12:49 PM
#41
Originally Posted by Buckeye
Mach number means velocity in a nondimensional form. I want to back out Cd vs. Mach number, which is the proper way to characterize rocket drag. Many HPR rockets exceed Mach=1, if that is what you mean.
I just want to prove to myself that I can crunch the numbers, account for all variables correctly, and produce a curve that "looks" correct. I have no illusions that it is the "correct" answer, as measured flight data is very squirrely and does not follow nice assumptions. The raw data (say from a Raven) is very noisy and requires data fitting/smoothing in order to perform calculations upon. This is the first hurdle and is an area of numerical methods that I am not very familiar with.
That would be great, I've wanted to do this for some time but never worked through all the steps...
QRS: 124
AMRS: 32 L2 RSO
Highest: 13,647 feet. Fastest: Mach 1.55.
Largest Motor: CTI 1115J530 IM
Current Projects: HPR X Wing

21st June 2017, 01:54 PM
#42
FWIW, You can find the formulas for CD rendering in my 2007 NARAM R&D Report, _Analyzing Accelerometer Data from Off Vertical Trajectories_. I have a VBA Excel spreadsheet somewhere that does it.

21st June 2017, 05:45 PM
#43
I am not an expert on this but have just enough knowledge to be dangerous. I would recommend that you not use altitude to derive velocity or for that matter the velocity that your Raven may record. Both can lag or lead due to Bernoulli and Ram effects as well as inadequate venting. Bear with me if you already know this. Your best source of data is from the accelerometers and on the Raven 3 they sample at a very high rate 200 Hz to 400Hz depending on lateral or axial measurements. I believe 400 Hz is 400 samples per sec. By comparison the Altimeter 3 samples at 244 samples per second (which is adequate for science fair projects and the like) You may try using the root mean square method to crunch this boat load of data. In other words square each value that you get every second, add up the squares and divide by 400 and then take the square root of that. But I am not a statistics expert and others who are may disagree or have a better strategy.The RMS method is used by EE's to calculate alternating current voltage from the sine wave. In any case the work sounds interesting and good luck.

21st June 2017, 07:09 PM
#44
I would be interested in your formulas also. Are they in the Technical Review Volume 25 (price $18 plus shipping)? Thanks for the comment

21st June 2017, 08:13 PM
#45
Originally Posted by bobk99
I am not an expert on this but have just enough knowledge to be dangerous. I would recommend that you not use altitude to derive velocity or for that matter the velocity that your Raven may record. Both can lag or lead due to Bernoulli and Ram effects as well as inadequate venting. Bear with me if you already know this. Your best source of data is from the accelerometers and on the Raven 3 they sample at a very high rate 200 Hz to 400Hz depending on lateral or axial measurements. I believe 400 Hz is 400 samples per sec. By comparison the Altimeter 3 samples at 244 samples per second (which is adequate for science fair projects and the like) You may try using the root mean square method to crunch this boat load of data. In other words square each value that you get every second, add up the squares and divide by 400 and then take the square root of that. But I am not a statistics expert and others who are may disagree or have a better strategy.The RMS method is used by EE's to calculate alternating current voltage from the sine wave. In any case the work sounds interesting and good luck.
In my experience, sampling rate is not a problem. The error in Cd from altitude mismeasurement is rather low (even though Cd, as a rule, is very sensitive to any sort measurement of error) because density misestimates from this source are typically small.
That said, I'm afraid I cannot endorse Raven accelerometer data in general for anything except... entertainment and a few qualitative applications.

22nd June 2017, 12:09 AM
#46
Originally Posted by bobk99
I would be interested in your formulas also. Are they in the Technical Review Volume 25 (price $18 plus shipping)? Thanks for the comment
If you are a NAR member then R&D reports are available for free at the NAR web site.

22nd June 2017, 12:39 AM
#47
Originally Posted by Larry Curcio
FWIW, You can find the formulas for CD rendering in my 2007 NARAM R&D Report, _Analyzing Accelerometer Data from Off Vertical Trajectories_. I have a VBA Excel spreadsheet somewhere that does it.
Interested in how accurate you believe your derived data was.
QRS: 124
AMRS: 32 L2 RSO
Highest: 13,647 feet. Fastest: Mach 1.55.
Largest Motor: CTI 1115J530 IM
Current Projects: HPR X Wing

22nd June 2017, 03:16 AM
#48

22nd June 2017, 12:10 PM
#49
Originally Posted by UhClem
If you are a NAR member then R&D reports are available for free at the NAR web site.
The report in question on the NAR site is randomly missing 3/4 of the pages. Useless. So much for my member benefit....
http://nar.org/memberonlyreports/r...9,%202007).pdf

22nd June 2017, 12:32 PM
#50
Originally Posted by Larry Curcio
That said, I'm afraid I cannot endorse Raven accelerometer data in general for anything except... entertainment and a few qualitative applications.
Wow. Well, what do you recommend? Is there a hobby accel altimeter out there suitable for flight analysis? I already tried a MARSA 54LHD and found the data export lacking. The Raven data export looks great, but the accel itself was wacked and needed replacement. So, no data yet (Hmm, maybe I am catching your drift!). What is left  AIMExtra, AltusMetrum?
I learned that accelbased deployment generally sucks, so all I need the accel to do is record data. Eh, or just give up on this folly and use simulations (models, CFD, wind tunnel) for Cd and trajectory analysis. The sims are better anyway.

22nd June 2017, 01:05 PM
#51
It's missing pages 522

22nd June 2017, 01:15 PM
#52
Raven data were yielding inertial altitudes smaller than barometric altitudes on hot days. All of the normal sources of analytical error would have the opposite effect. The manufacturer attributed the problem to nonlinear response, and asserted that all hobby units would have similar problems, but I did not observe comparable problems with the old ARTS or RDAS units. (This is just my own observation and opinion. YMMV)
I'm out of the game now. I contacted Altus Metrum years ago, and they said, at that time, that their product was a package, and that it was not designed to give data for external analysis. That may have changed. (If you read my 2007 and 2011 R&D reports, you'll see that I analyze things differently.) For that reason, never tried them. Lost interest in rockets because of these issues.
LarryC

22nd June 2017, 04:06 PM
#53
Larry,
I understand your frustration with commercial electronics. But, the way I look at it my Altimeter 3 is that it is good enough for my experiments. What does it matter whether your within only 1 or 2 sigma in the grand scheme ? It's the journey to the answer that is fun. If I wanted to be 3 sigma I would have gotten my degree in aeronautical engineering instead of chemistry and worked for Space X or NASA.
Hang in there............

22nd June 2017, 05:20 PM
#54
It is missing more than that. Larry's table of contents says 80+ pages, but the NAR pdf only has 21.

22nd June 2017, 06:25 PM
#55
I just purchased the CD. It had better be all there. I can share the info.

23rd June 2017, 12:08 AM
#56
Originally Posted by Buckeye
I learned that accelbased deployment generally sucks,
It is only bad in some circumstances.
The first is if it is implemented badly. It isn't difficult to do right and I still use a 1999 vintage AltAcc2. (That uses the PIC16C71 with an 8 bit ADC!) The RDAS Compact also does very well and I suspect the more recent RDAS Tiny. The Tiny has much less noise in the data as well.
Assuming that the altimeter is working well, then the only other problem is flight profiles that mess with the one big assumption at the heart of the algorithm: measured acceleration is lined up with gravity.
This doesn't happen often. Flight 3 of my PAC3 being about the only time for me.

23rd June 2017, 01:23 AM
#57
Originally Posted by UhClem
then the only other problem is flight profiles that mess with the one big assumption at the heart of the algorithm: measured acceleration is lined up with gravity.
Altimeter makers are not FORCED to make that assumption, but many (but not all ) do. In fact it can be shown that the probability of a flight adhering to the 1g gravity offset assumption approaches 0.

23rd June 2017, 01:06 PM
#58
Is there any way someone can find out whether the accelerometer you have adheres to that assumption? That is, can you run a test to see if it adheres to the minus 1G? Would launching with 2 or 3 devices and comparing results on several flights be worth while?Has anyone in this forum tried that ?

23rd June 2017, 04:38 PM
#59
For those who are interested, I found a decent source from NXP on calibrating 3 axis accelerometers. Some of the points they make are :
Threeaxis accelerometers supplied for the consumer market are typically calibrated by the sensor manufacturer using a sixelement linear model comprising a gain and offset in each of the three axes. This factory calibration will change slightly as a result of the thermal stresses during soldering of the accelerometer to the circuit board. Additional small errors, external to the accelerometer, including rotation of the accelerometer package relative to the circuit board and misalignment of the circuit board to the final product, will also be introduced during the soldering and final assembly process.
The original factory accelerometer calibration will still be adequate for the vast majority of consumer applications. Manufacturers of premium products looking to obtain improved accuracy from a consumer accelerometer may, however, wish to perform their own calibration either by repeating the calibration performed by the accelerometer manufacturer or by using a more sophisticated calibration mode
* The apparent gravitational acceleration on the earth's surface varies by 0.7% from minimum to maximum. The apparent gravitational acceleration at the recalibration site is irrelevant if the product is to be used to provide orientation angle estimates from ratios of accelerometer channel readings but should be known if the product is required to provide highaccuracy acceleration or gravitational measurements.
•The original six parameter (gain and offset in each channel) factory calibration can be recomputed
to correct for thermal stresses introduced in the soldering process.
* A 12 parameter linear calibration model can correct for accelerometer package rotation on the circuit board and for crossaxis interference between the accelerometer’s x, y and z channels.
• The orientation angles used for the recalibration must be carefully selected to provide the best calibration accuracy from the limited number of measurement orientations available. Optimum orientation angles for a given number of measurements are listed.
•Linear least squares optimization is an efficient mathematical technique to compute the
recalibration parameters from the available measurements using simple matrix algebra. Worked
examples are provided throughout the text.
•These techniques can be extended to include temperature dependence by performing the recalibration at two or more temperatures and interpolating the fitted calibration parameters to the actual temperature.
Accelerometers are used in applications requiring either absolute or relative acceleration measurements.
Examples of absolute acceleration measurements are determining the earth's gravitational field or the acceleration forces experienced in an automobile in units of ms2 An example of using relative accelerations is the calculation of orientation angles using ratios of the readings from the x, yand zaccelerometer channels.
Although what follows may seem an obscure point, it does need to be briefly discussed since the objective of this application note is highprecision calibration. Although the earth's gravitational field is often stated to be 9.81ms2, in practice the apparent gravitational field measured by an accelerometer varies by 0.7% from minimum to maximum over the earth's surface as a consequence of the earth's rotation, the earth's equatorial bulge and the effects of altitude. The apparent gravitational field at sea level at the north pole is 9.832 ms2 but is only 9.763 ms2 at the 5895 m summit of Mount Kilimanjaro located almost on the equator.
This document assumes that the accelerometer recalibration is being undertaken for highprecision calculation of roll and pitch orientation angles from the ratios of accelerometer channel readings. In this case the precise apparent gravitational field at the recalibration site cancels in the mathematics and is simply assumed to be '1g'.
If, however, the recalibration is being performed to produce an absolute estimate of gravity or linear acceleration in units of ms2 then the apparent gravitational field at the recalibration site must be known and stored on the product for a simple final multiplication from '1g' to the required gravity or acceleration estimate measured in m s2
The rest of the paper explains how to recalibrate the accelerometer using trig and matrix algebra as well as using least squares to average out the results, which is beyond the scope of 99.9 % of model rocketeers including yours truly.

23rd June 2017, 05:10 PM
#60
Originally Posted by bobk99
For those who are interested, I found a decent source from NXP on calibrating 3 axis accelerometers.
Completely beside the point. What is needed is a measurement of the rockets orientation. That requires a 3 axis gyro.
Similar Threads

By Dr. Quigley in forum Rocketry Electronics and Software
Replies: 4
Last Post: 19th July 2012, 01:41 AM

By m85476585 in forum The Watering Hole
Replies: 0
Last Post: 26th February 2010, 08:23 PM

By DTH Rocket in forum Rocketry Electronics and Software
Replies: 3
Last Post: 19th June 2009, 07:13 PM
Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules
 
