Questions about accelerometer-based alts

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
For you guys wanting to build your own electronics... it's looking like I can probably get some free pcb's fabricated occasionally. In the new job I just started, we are probably going to be doing a lot of small test boards. The boards we build are usually unsuitable for the inexpensive per/board fabrication services (Advanced Circuits, Olimex, et al.) because of the finishes, layer count, filled & B&B vias we use. So, we wind up needing to order at least a single panel (usually 12"x18") from a higher-end proto fab house. Now, the last board we ordered was ~$2K for 100 boards, each about an inch square, ~$20/board. If we had ordered 10 boards, it would have cost $200/board - we're really paying by the -panel-, not the board. Now, we rarely really need 100 boards. So, rather than just getting too many extra board copies that we'll probably throw away, instead, we can put anything else we want on the panel to fill it out. Free boards - get it?

No promises, no set schedules. If it happens, it would happen as board space/time becomes available. And one of the big factors on time is that the layout would have to be finished ahead of time, ready to drop onto the panel when the real work design is ready to go, i.e., the work schedule cannot be delayed.

Size would be limited to a few square inches, tops, but that should fit most on-board electronics.

To do this I would need either 1) finished (and clean!) RS-274X Gerber files; or 2) layout in PCAD200X format, or something readily translatable* into PCAD; or 3) if I do the layout - schematic in .pdf or whatever, plus complete parts list and mechanicals.

*readily translatable does not include Eagle, PCB123, and most other low-end freeware, etc. layout programs.

GC

(oh, btw, we have a desktop reflow oven too)
 
Dave,

From your examination of commercial accelerometers, do you know if integration is done by simply summing the readings or are they using trapizoidal, Simpson's or more complicated integration? Does it matter?

--john
 
Summing the readings would be an easy way that would work decently well, especially in alts with a high sampling rate (such as the R-DAS's 200Hz).
 
Originally posted by jderimig
Dave,

From your examination of commercial accelerometers, do you know if integration is done by simply summing the readings or are they using trapizoidal, Simpson's or more complicated integration? Does it matter?

--john

The only units I have looked at (AltAcc, RDAS) do a simple sum. I don't think that there would be much advantage to using a more complicated numerical integration technique.

As an example, here is some AltAcc data. You can tell by looking at the "Sum units" column that it is just a simple sum. Or at least the data presented by the Flight Analyzer software is. Since it results in the same apogee time as the flight software, it is a pretty safe assumption that the flight software does the same.

# Time Accel Press Sum Accelerat Velocity Altitude PressAlt
# sec units units units ft/sec^2 ft/sec feet feet
# ========= ===== ===== ===== ========= ========= ========= ========
-0.18750 117 230 0 0.00 0.00 0.00 0
-0.12500 117 230 0 0.00 0.00 0.00 0
-0.06250 117 230 0 0.00 0.00 0.00 0
0.00000 117 230 0 0.00 0.00 0.00 0
0.06250 140 230 23 235.74 7.37 1.07 0
0.12500 139 230 45 225.49 21.78 2.73 0
0.18750 141 230 69 245.99 36.51 5.65 0
 
For future reference, you can make the columns line up by using the code tags. It makes it quite a bit easier to read.
Code:
#       Time  Accel  Press    Sum  Accelerat   Velocity   Altitude  PressAlt
#        sec  units  units  units   ft/sec^2     ft/sec       feet      feet
#  =========  =====  =====  =====  =========  =========  =========  ========
    -0.18750    117    230      0       0.00       0.00       0.00         0
    -0.12500    117    230      0       0.00       0.00       0.00         0
    -0.06250    117    230      0       0.00       0.00       0.00         0
     0.00000    117    230      0       0.00       0.00       0.00         0
     0.06250    140    230     23     235.74       7.37       1.07         0
     0.12500    139    230     45     225.49      21.78       2.73         0
     0.18750    141    230     69     245.99      36.51       5.65         0
 
Chris,
Thanks for the legibility lesson. You are a 100 pt computer nerd after all! Truly this is a compliment as in presentation of data is often the most important issue, maybe the most important piece.

For instance the NCR forum last night :rolleyes: This was in no way a slam on JW, egotism is a good thing. That you can have it and still do altruistic stuff fell well below the radar, oh well. That thread got punched. Try to keep it entertaining, if all else fails...
John

PS: You know if Joe has any H999 loads. I want to do the egg demo in a couple weeks and now with all the madness, can't call on Tim L.
 
He probably does - not sure though. I'll probably call there for other reasons sometime this week - I'll ask about that as well. As for the computer nerdiness, I actually learned that trick from Bob Cox (another bonafide nerd if ever there was one) :)
 
Chris, see if he plans to be present feb launch, and if so has the bat out of hell reload. Back to topic,
J
 
Originally posted by denverdoc
... setting the threshold for a definite descent might get ejection at a lower speed even tho its now "falling". Or is this wishful thinking on behalf of my friend, Jim Amos.
John S

Mostly wishfull thinking.

In order for this to be true the decrease in velocity due to drag must be greater than the increase from gravity. You might recall that the measured acceleration around apogee is typically very close to zero.

As a check I ran a quick Rocksim simulation of a 5.5" rocket on a J275 along with plenty of wind so it would be well off vertical. The total velocity at apogee was about 125 ft/sec and it was just a wee bit less 1/4 of a second later which was the minimum.

Light weight, large cross section, and high horizontal speed increase the effect but it is typically pretty small.
 
Originally posted by UhClem
The only units I have looked at (AltAcc, RDAS) do a simple sum. I don't think that there would be much advantage to using a more complicated numerical integration technique.


The G-wiz is similarly just a simple sum. In the case of the G-wiz, the velocity change for each 1/16 second increment is calculated from the acceleration value. Then, the velocity changes are summed.

I've been looking at the G-wiz data to try to determine how I might manage the charges for dual altimeters. I did some flight simulations over a range of launch angles to get the acceleration data and then did the integration in the same way that the G-wiz does it. A plot of the time to the actual and calculated apogee is attached. I was surprised that the calculated apogee isn't all that late until the flight angle is pretty severe.
 
Originally posted by UhClem
Mostly wishfull thinking.

In order for this to be true the decrease in velocity due to drag must be greater than the increase from gravity. You might recall that the measured acceleration around apogee is typically very close to zero.

As a check I ran a quick Rocksim simulation of a 5.5" rocket on a J275 along with plenty of wind so it would be well off vertical. The total velocity at apogee was about 125 ft/sec and it was just a wee bit less 1/4 of a second later which was the minimum.

Light weight, large cross section, and high horizontal speed increase the effect but it is typically pretty small.

Interesting, I ran an MD 54 mm rocket thru the same kind of sim, thinking maybe the higher velocity would make up for the smaller cross sectional area: almost an identical result with a min velocity of 125 fps with the velocity inflection .25 or so late relative to apogee.

John S
 
Originally posted by JimJarvis50
The G-wiz is similarly just a simple sum. In the case of the G-wiz, the velocity change for each 1/16 second increment is calculated from the acceleration value. Then, the velocity changes are summed.

I've been looking at the G-wiz data to try to determine how I might manage the charges for dual altimeters. I did some flight simulations over a range of launch angles to get the acceleration data and then did the integration in the same way that the G-wiz does it. A plot of the time to the actual and calculated apogee is attached. I was surprised that the calculated apogee isn't all that late until the flight angle is pretty severe.

Jim.

Nothing like data to make you scratch your head, vs intuition. I've always set zero delay using gee data with the MC2 and baro from the MMC^2 figuring the odds of simultaneous deployment were minimal given the few msec of BP EC event duration. So far its worked OK, but one never knows when ole Murph will show up to ruin a perfectly good day. So what are your thoughts now in light of this finding?
John S
 

Latest posts

Back
Top