Launch Samples per Second
Range: 10,15, 20, 25, 30, 33 samples/sec. (default 20 samples/sec.)
This setting allows you to select the number of samples per second that are taken from the time
that you arm the Quasar until it detects nose-over. The default setting (20 samples per second) is
adequate for most flights. However, there may be reasons why you want to turn it up or down.
For example, if you have a very short-burn motor (like a CTI V-Max) you may want to turn it up
to 33 samples per second to make the velocity and acceleration figures more accurate. If you
have a very long-burn motor you may want to turn it down to 15 samples per second, although
20 should be fine. Note that increasing the sample rate decreases the amount of memory…
more on that later.
Descent Samples per Second
Range: 1, 2, 4, 5, 8, 10 samples/sec. (default 2 samples/sec.)
The setting allows you to select the number of samples per second that are taken after nose-over
is detected. When you’re coming down, you’re generally not going to be going very fast relative
to your velocity going up, even if you freefall for a few seconds and the FailSafe kicks in.
Consequently, there’s really no reason to have the same high rate of sampling that you use for
the ascent part of the flight. Reducing the sampling rate after nose-over saves a lot of memory,
and allows you to record longer flights. For most flights, the default 2 samples/sec. rate is fine.
About Sampling Rates and Memory Usage
At this point you may be wondering about how long a flight the Quasar can record before
running out of memory, and what happens if that occurs. The Quasar saves about 2,000 samples
for each flight. When you’re sitting on the pad or launched and have not yet reached LDA, the
sampling rotates through those memory locations, saving the last reading < 3’ AGL as the “start
of flight”. Once you hit LDA, the recording continues until either 1) the End of Flight
benchmark (your rocket hasn’t moved for at least 5 seconds) is reached, or 2) the memory wraps
around to the start of flight location. In either case, recording stops there (it won’t overwrite
valid ascent data), but this does NOT affect any pending deployment events… if you run out of
memory before the main chute is deployed, it will still be deployed, but you won’t see it in the
data downloads because it can’t be recorded.
Now, you may be wondering how long a flight you can have with “only” 2,000 memory
locations. Quite a long one, actually. Let’s say that you want to fly to 30,000’ and your motor
will get you there in 30 seconds. At 20 samples per second, that’s 600 samples. That leaves
about 1,400 samples left for the “down” part of the flight. At 2 samples per second, that’s 700
seconds, or over 11 minutes. You’d have to be coming down at a rate of about 40 ft/sec under
drogue to exhaust the memory, there’s no way you’re gonna be coming down that slow from
30,000’ (unless you really like walking a lot). More likely, it’s going to be 50-70 feet/sec. Let’s
say that we come down at 60 ft/sec from 30,000’, that’s about 500 seconds, or 1,000 memory
locations at 2 samples/sec. You’d still have over 400 samples left when you land, nearly 20% of
your memory.
To Next Page
Loading...