### Author Topic: Falcon 9 velocity/altitude values from webcast  (Read 55900 times)

#### meithan

• Full Member
• Posts: 104
• Mexico
• Liked: 91
• Likes Given: 6
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #40 on: 09/01/2016 04:41 am »
First and foremost, fantastic work Space Opera!! I have indeed been harvesting data from the webcasts manually. Data from your automated tool will be a very useful contribution to those of us that like to plot/analyze flight data.

Next, let me jump into the discussion about Semmel's plots (which are great!).

1) Being able to see the fairing jettison event in the acceleration data is very cool! I just checked the webcast, and fairing jettison occurs at ~3:40 (220 s), which is a rather good match to what we're seeing!

2) I'm with ugordan on the reason the first stage throttling down around the 50 s mark: I think it's for the transonic region before Mach 1. In my estimation, Mach 1 is passed at 62 seconds (there's no "going supersonic" callout in the webcast for this launch, sadly), so the throttling is definitely occurring prior to going supersonic, and well before max Q.

3) As for the dynamic pressure issue, I redid Semmel's plots except that I'm using the ISA1976 standard atmosphere for density/temperature calculation (I have a Python implementation of it, which I'll gladly share if anyone wants it). I'm attaching a plot that compares my dynamic pressure, temperature and density curves to Semmel's for the first 185 seconds. Semmel's curves, which I reproduced from the code he pasted upthread, are shown as dashed lines (the temperature curves are nearly identical).

Semmel: I think there's a typo in your temperature table. The bold value should be 228.65 (=-44.5°C):

std_atm_T = [288.15,   216.65,   216.65,   288.65,   270.65,   270.65,   214.65,    214.65]

It doesn't make a huge difference, though (and none whatsoever before the ~95 s mark); the attached plot uses the corrected value.

We're using the exact same data for velocity and altitude, so the only difference is in the density calculation. Comparing the plots, it seems that the small difference we have in computed density is enough to noticeably alter our dynamic pressure curves. In my calculation, max Q occurs at 72.2 s, reaching a substantially lower value of 29.6 kPa, mainly because density falls off quicker in the ISA1976 model.

Semmel's atmospheric model is a bit weird because he's assuming piecewise linearly-varying temperature yet uses the exponential formula for pressure (which is the solution for constant temperature). IntoTheVoid provided the correct formula in the case of linearly-varying temperature (and that's all the ISA1976 does, really).

Still, Semmel's time of max Q is much closer to the callout in the webcast (which occurs at ~83 s) than mine, so I don't really know which to trust more. I think the bottomline is that the dynamic pressure curve is kind of sensitive to small details in the calculation, so we should take it with a grain of salt.
« Last Edit: 09/01/2016 04:43 am by meithan »

#### Semmel

• Senior Member
• Posts: 2178
• Germany
• Liked: 2433
• Likes Given: 11916
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #41 on: 09/01/2016 08:00 am »
First and foremost, fantastic work Space Opera!! I have indeed been harvesting data from the webcasts manually. Data from your automated tool will be a very useful contribution to those of us that like to plot/analyze flight data.

Next, let me jump into the discussion about Semmel's plots (which are great!).

1) Being able to see the fairing jettison event in the acceleration data is very cool! I just checked the webcast, and fairing jettison occurs at ~3:40 (220 s), which is a rather good match to what we're seeing!

2) I'm with ugordan on the reason the first stage throttling down around the 50 s mark: I think it's for the transonic region before Mach 1. In my estimation, Mach 1 is passed at 62 seconds (there's no "going supersonic" callout in the webcast for this launch, sadly), so the throttling is definitely occurring prior to going supersonic, and well before max Q.

3) As for the dynamic pressure issue, I redid Semmel's plots except that I'm using the ISA1976 standard atmosphere for density/temperature calculation (I have a Python implementation of it, which I'll gladly share if anyone wants it). I'm attaching a plot that compares my dynamic pressure, temperature and density curves to Semmel's for the first 185 seconds. Semmel's curves, which I reproduced from the code he pasted upthread, are shown as dashed lines (the temperature curves are nearly identical).

Semmel: I think there's a typo in your temperature table. The bold value should be 228.65 (=-44.5°C):

std_atm_T = [288.15,   216.65,   216.65,   288.65,   270.65,   270.65,   214.65,    214.65]

It doesn't make a huge difference, though (and none whatsoever before the ~95 s mark); the attached plot uses the corrected value.

We're using the exact same data for velocity and altitude, so the only difference is in the density calculation. Comparing the plots, it seems that the small difference we have in computed density is enough to noticeably alter our dynamic pressure curves. In my calculation, max Q occurs at 72.2 s, reaching a substantially lower value of 29.6 kPa, mainly because density falls off quicker in the ISA1976 model.

Semmel's atmospheric model is a bit weird because he's assuming piecewise linearly-varying temperature yet uses the exponential formula for pressure (which is the solution for constant temperature). IntoTheVoid provided the correct formula in the case of linearly-varying temperature (and that's all the ISA1976 does, really).

Still, Semmel's time of max Q is much closer to the callout in the webcast (which occurs at ~83 s) than mine, so I don't really know which to trust more. I think the bottomline is that the dynamic pressure curve is kind of sensitive to small details in the calculation, so we should take it with a grain of salt.

Fantastic meithan, thank you for spotting the typo! And yes, the model I use is quite crude, working basically outside my comfort zone here. I would be happy to adapt your atmosphere model. I want to publish my script once I feel reasonably confident that its correct, is it ok if it contains (full or part) of your code?
My next goal is to estimate the mass of the fairing. I know how to do it, just need time for the implementation which is not before the weekend and I can't make any promises even then.

#### meithan

• Full Member
• Posts: 104
• Mexico
• Liked: 91
• Likes Given: 6
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #42 on: 09/06/2016 01:39 am »
Fantastic meithan, thank you for spotting the typo! And yes, the model I use is quite crude, working basically outside my comfort zone here. I would be happy to adapt your atmosphere model. I want to publish my script once I feel reasonably confident that its correct, is it ok if it contains (full or part) of your code?

Well, real life got in the way and I just now got the time to clean up the code a bit so I can share it. I uploaded it to pastebin:

US1976.py

After instantiating the class, you can use the provided member functions density(), temperature(), pressure(), sound_speed() and viscosity() to compute values as a function of altitude (which must be in meters). The code works both in Python 2 and Python 3.

Note: I didn't want the code to depend on numpy, so these functions are not numpy-friendly in the sense that you can't pass ndarrays of altitude values to them. So you can either compute values one at a time (through direct looping or Python's map) or alternatively create vectorized versions in numpy, like this:

atmo = US1976()
dens = np.vectorize(atmo.density, otypes=[np.float])

After that something like this should work:

h = np.linspace(0,86000,100)
density = dens(h)

As for using it in your published code, sure, I'm releasing it under the GPL so use it as you see fit.

#### Semmel

• Senior Member
• Posts: 2178
• Germany
• Liked: 2433
• Likes Given: 11916
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #43 on: 09/08/2016 08:41 am »
Thank you meithan, I will use your model as it is much better than my crude one. Ill post the results as soon as I have time for it. Time is rather scarce at moment but the data is not running away and due to the disaster at LC40, there will probably not any more data coming in within the next few months or so. Thanks again!

#### Space Opera

• Member
• Posts: 40
• Liked: 86
• Likes Given: 3
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #44 on: 01/16/2017 10:42 pm »
I updated the trajectory file on the first post with the Iridium-1 launch.
Unfortunately, they cut the velocity/altitude display before SECO...

#### S.Paulissen

• Full Member
• Posts: 443
• Boston
• Liked: 334
• Likes Given: 511
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #45 on: 01/21/2017 03:54 am »
Any headway on the mass of the fairing?
"An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field." -Niels Bohr
Poster previously known as Exclavion going by his real name now.

#### Semmel

• Senior Member
• Posts: 2178
• Germany
• Liked: 2433
• Likes Given: 11916
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #46 on: 01/21/2017 01:18 pm »
I realised that this is much more complex than I thought. I have to fit a physical acceleration profile to the data. But part of the acceleration is eaten by gravity. That part depends on the centrifugal force which in turn depends on the horizontal velocity in orbital reference frame. The data is in ground reference frame and to transform in between the two, my 2D model is not sufficient because I can't model the orbital plane properly.

I don't have the time to start over (child and family are more important). Maybe I model the acceleration in the 2D version and we just have to cope with the uncertainty. What do you think?

#### 1

• Full Member
• Posts: 377
• El Segundo, CA
• Liked: 760
• Likes Given: 10
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #47 on: 01/21/2017 05:38 pm »
I realised that this is much more complex than I thought. I have to fit a physical acceleration profile to the data. But part of the acceleration is eaten by gravity. That part depends on the centrifugal force which in turn depends on the horizontal velocity in orbital reference frame. The data is in ground reference frame and to transform in between the two, my 2D model is not sufficient because I can't model the orbital plane properly.

I don't have the time to start over (child and family are more important). Maybe I model the acceleration in the 2D version and we just have to cope with the uncertainty. What do you think?

If the velocity gauge in the videos indicates the total magnitude of rocket's velocity (which I'm pretty sure it does), then it's reasonable to use that to calculate the total magnitude of acceleration. Any perterbations 'felt' by the rocket should therefore be built into the displayed numbers; and thus I think you're fine just doing a simple point-to-point delta-V calculation for your acceleration profile. Without explicit knowledge of what that velocity indicator is actually measuring velocity relative to, I wouldn't bother trying to break the acceleration into vector components. If you can get an answer within, say, +/- 10% of actual, I'd say that's pretty good.

#### LouScheffer

• Senior Member
• Posts: 3432
• Liked: 6207
• Likes Given: 870
##### Re: Falcon 9 velocity/altitude values from webcast
« Reply #48 on: 08/25/2019 08:51 pm »
Determining loft of trajectory from the webcast:

I initially thought it was odd that the acceleration during the coast between stage 1 cutoff and stage 2 ignition was not the usual value for gravity - 9.8 m/s.  In fact it has quite a range of values.

-4 m/s for for Thaicom-8
-2 m/s for Arabsat and -3 m/s for STP-2, and
-5 m/s for RocketLab Electron

At first I thought this might just be the effect of partial orbital velocity.  But since the apparent centripital acceleration goes like v^2, and v is less than a third of orbital velocity, that can't be the whole story.  But then I realized that the main effect is that the velocity is measured from the launch pad.  This means we are not viewing the acceleration straight on, but at an angle.  In fact we can figure what the angle is, and hence the downrange distance at staging.

Mission       acc        alt    vel      v     assumed     horiz     acc      new   downrange
during    (km)  km/hr     m/s      angle   velocity    grav   angle     (km)
coast                              (deg)      (m/s)   m/s^2   (deg)

CRS-16          -7       74    5700   1,583.33      45   1,119.59    9.44    47.87    66.94
Thaicom-8       -4       69    8331   2,314.17      25   2,097.35    8.83    26.95   135.71
Arabsat         -2      100   10725   2,979.17      20   2,799.50    8.20    14.12   397.64
STP-2           -3      126   11061   3,072.50      20   2,887.21    8.11    21.71   316.53
Electron        -5       76    8195   2,276.39      30   1,971.41    8.92    34.09   112.31

The calculation goes like this, column by column.  The acceleration during coast is read off the plots above, which in turn get the value by differentiating velocity.  The altitude and velocity are from the webcast.  To find the horizontal velocity, we assume an angle to horizontal.   Fortunately the exact value is not critical, so we just assume RTLS is most lofted, GTO next, then FH least.  The we can find an estimated horizontal velocity.   Next we estimate the sub-orbital correction for the forward velocity, using v^2/r and remembering that the horizontal velocity is about 400 m/s more than indicated because of Earth rotation.  This gives us the local gravity estimate.   Since we only see sin(theta) of this, the angle to the launch site is sin-1(observed/gravity).  Finally we can find the distance downrange at staging as altitude/tan(angle).

We can plot these and the results look just as you would expect.   RLTS is most lofted, so it does not get too far downrange.  GTO is next, then the FH missions.  Arabsat was less lofted than STP-2 since it was aiming at a much lower initial orbit.

Tags: