From 571bc4219d36888c5cf8abec35b2b80ca901cb69 Mon Sep 17 00:00:00 2001 From: Bdale Garbee Date: Thu, 27 Apr 2023 12:47:30 -0600 Subject: [PATCH] change a couple I've to we've --- FAQs/apogee-above-100k.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/FAQs/apogee-above-100k.mdwn b/FAQs/apogee-above-100k.mdwn index b4fba3b..77b77c4 100644 --- a/FAQs/apogee-above-100k.mdwn +++ b/FAQs/apogee-above-100k.mdwn @@ -51,18 +51,18 @@ close. After that, as you're flying purely on accelerometer data, there's no way to re-correct the state, so the apogee estimates can be off by quite a bit. -In the worst cases that I've seen, the baro sensor data was wildly +In the worst cases that we've seen, the baro sensor data was wildly incorrect above mach due to poor static port design, leaving the state estimate of speed across the 30km boundary way off and causing the apogee detection to happen far from the correct time. The good news is that correctly determining apogee is not really all that important at those altitudes; there's so little density that a -drogue will have almost no drag anyways. The data I've seen shows a very +drogue will have almost no drag anyways. The data we've seen shows a very parabolic path down to about 50k'-60k', even with a recovery system deployed... -So, what I've been recommending is to set up two apogee plans: +So, what we've been recommending is to set up two apogee plans: 1. Use the built-in apogee detection, but add a significant delay (as much as 30 seconds). This will probably fire near enough to apogee -- 2.47.2