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

Space Opera · « **on:** 08/22/2016 11:43 pm »

Dear all,

I have written a fully automated algorithm that is able to get the videos from SpaceX on Youtube, to run Optical Character Recognition (OCR) on each frame of the videos, to get time, frame number, altitude and velocity at each image and to post-process this. All the regions of interest for OCR are visible in the rectangle in this figure:

The post-processing consists in filtering and clean interpolation of the data to make it suitable for analysis. Raw data is heavily impacted by lag in the framerate, by rounding errors, by actual glitches in the telemetry display and occasionnaly by OCR errors, so that it needs time and love to become nice and a bit more reliable.
The automated process includes the creation of an Excel file with both raw and filtred data. Now that I have this algorithm working very efficiently on all previous videos with suitable display (i.e. CRS-9, Eutelsat, Jason-3, JCSAt-14, JCSAT-16, SES-9 and Thaicom-8), I will be able to update this post at each new launch with the same graphical interface in the webcast (can't wait NSF2017 with wiki-like pages). Sometimes the telemetry is cut-off a bit short during the webcast so the data is obvioulsy depending on what is visible, but overall it works surprisingly well.

I have seen many people here struggling with data by hand and naked eye to build curves, and I hope this file will help those interested in the only reliable source of data for Falcon 9 trajectory (or at least altitude and velocity norm). You can use it as you wish, to compare flights, to guess the position, etc

Some examples of what can be directly visualized from this file:

----------------------------------------------------------------------------------------------------------------------

Structure of the file:
- 1 sheet per flight
- First line is a comment to indicate if the raw velocity (as shown in the webcast) is in km/h or in m/s
- Columns A to D are the raw data :
--- Column A is the number of video frames since T0. T0 is automatically detected when "T-00:00:00" becomes "T+00:00:00".
--- Column B is a direct transcription of the chronometer.
--- Column C is a direct transcription of the altitude, in m (although shown in km in the webcast).
--- Column D is the velocity, expressed either in km/h for earlier missions and in m/s for the latest missions.
- Columns G to I are the cleaned data:
--- Column G is the time, expressed in seconds since T0. Time sample is 0.1s.
--- Column H is the filtred altitude, in m.
--- Column I is the filtred velocity norm, in m/s.

Don't hesitate to play with the data, to give me any feedback and to suggest any improvement, I'll do my best to implement it. And come back after each flight for the updated version of the document.

Space Opera.

AnalogMan · « **Reply #1 on:** 08/23/2016 01:01 am »

I had a little play with plotting some data - here are graphs for Jason-3. Acceleration curve was generated by numerical differentiation of the velocity data.

Hobbes-22 · « **Reply #2 on:** 08/23/2016 06:10 am »

Interesting project.

About the lag in the framerate: would it help if you could download the file from YouTube to a local .mp4 file, so you can play it without interference from Youtube's servers and your internet link? Or are you already doing that and is the source material compromised?

Semmel · « **Reply #3 on:** 08/23/2016 07:27 am »

Wow, thanks! That is very interesting. I was thinking of doing something similar myself but didnt get very far because I lack the skills in video frame grabbing. I was thinking of using long exposure images and triangulation to get the flight path and take it from there. Your data is far better! Lets see if I can squeeze out some more info from your data. Unfortunately I just arrived at work and dont have time for that. Cant wait.. my fingers are itching like crazy!

JamesH65 · « **Reply #4 on:** 08/23/2016 01:05 pm »

Quote from: Hobbes-22 on 08/23/2016 06:10 am

Interesting project.

About the lag in the framerate: would it help if you could download the file from YouTube to a local .mp4 file, so you can play it without interference from Youtube's servers and your internet link? Or are you already doing that and is the source material compromised?

I believe the source is inaccurate - ie the on screen data doesn't seem to match what the image shows. The lag is in the SpaceX 'reporting', not the final video.

Space Opera · « **Reply #5 on:** 08/23/2016 01:15 pm »

You are right, the lag is not due to the video format itself. Of course, I first download the *.mp4 file in 1080p, I don't stream it directly. And the lag comes from the telemetry, not from the video. It appears that the chronometer behaves as expected (so it is probably run "offline", and not an input from the telemetry), but both the velocity and the altitude are sometimes stucked for several frames on one value. Almost invisible with the naked eye, but very visible in the charts.

Semmel · « **Reply #6 on:** 08/23/2016 05:38 pm »

Space Opera,

Thanks for the data. I want to analyse it with python and to do that its best to have the data within a text file. Now, I could do that from your excel sheets manually but for future flights, it would be best to have the data in a text file format like .csv for instance. Could you change your program such that it produces text files instead of excel? Also, a separate file for the frame grab data and the interpolated data would be fantastic because the index value (frame number vs. time) is not the same. Could you do that?

Cheers,
Semmel

@edit: examples for THAICOM_8 appended. You can use other delimiters but tabulator if you want, its not important. Also, I used the .txt ending because the forum restrictions do not know .csv.

S.Paulissen · « **Reply #7 on:** 08/23/2016 05:55 pm »

Is copying and pasting spreadsheets into notepad and seeing it as tab delimited that much work?

Space Opera · « **Reply #8 on:** 08/23/2016 06:55 pm »

Yes Semmel I can do that easily, it is the same effort for me.

Do you expect ( 1 file for raw data + 1 file for filtred data) * each flight ? It will be a lot of files...

Semmel · « **Reply #9 on:** 08/23/2016 07:32 pm »

Space Opera,

you wanted some feedback.. After first data inspection of the thaicom launch, it seems your interpolation is very slightly underestimating the true value. Nothing serious but maybe worth a fix. I cant do it right now my self because there is some problem with some packages and I dont have the time to fix it. Need to wait until the weekend for that. See the appendix for a visualization. Otherwise, quite good interpolation, nice and smooth and not overfitted. @edit: see appended figure.

Paulissen,

I have very limited time at moment. My 3 month old son requires almost all my free time and I would rather spend what limited time I have on analysing data rather than fixing the format. Its probably some 2-liner for Space Opera to output the data as text files. Doing it that way is much more efficient than manually. Also I am a programmer, I hate to do repetitive tasks manually if it can be automated. If you think its not much work, be my guest.

Semmel · « **Reply #10 on:** 08/23/2016 07:35 pm »

Quote from: Space Opera on 08/23/2016 06:55 pm

Yes Semmel I can do that easily, it is the same effort for me.

Do you expect ( 1 file for raw data + 1 file for filtred data) * each flight ? It will be a lot of files...

See, there I go for to make sing him into sleep and you have an answer already. Yes, one raw file per flight and one interpolated one might be best. Also easily scalable for future flight so you dont have to update existing data all the time.

S.Paulissen · « **Reply #11 on:** 08/23/2016 07:37 pm »

This is very interesting. I never realized that staging-reignition took so long. When I reduce the resolution to 1s, there is a 10s window of zero to negative velocity change between, ostensibly the time between MECO-SECI.

s m/s
1 8123
2 8262
3 8331
4 8343<-meco
5 8333
6 8323
7 8313
8 8296
9 8284
10 8272
11 8255
12 8243
13 8231
14 8229
15 8238<-seci
16 8248
17 8265

EDIT: apparently my crude method does the same thing Semmel.

Semmel · « **Reply #12 on:** 08/23/2016 09:10 pm »

Paulissen,

It doesnt look like Space Opera always took the lowest value for a sequence of identical values. It seems to be more intelligent, especially at the beginning and end. I try to improve some other time.

Here is a plot showing some values. I used the atmospheric model from Wikipedia to include atmospheric drag in order to see MaxQ. It looks grossly wrong though. I always imagined the peek to be much slimmer and it also should align with the throttle back as seen in the acceleration data. At least the order of magnitude of the drag force seems to be reasonable (about 20% of F9 thrust)

I used these equations:
air density: https://en.wikipedia.org/wiki/Atmospheric_pressure#Altitude_variation
drag: https://en.wikipedia.org/wiki/Atmospheric_drag#Drag_at_high_velocity
and included the values provided by Space Opera for hight and velocity.
For the F9, I used
fairing cross section area in m^2: A = (0.5 * 5.2)**2 * Pi
drag coefficient (guess) for the fairing: C_d = 0.07
pressure at sea level: p_0 = 10132
scale height: h_0 = 8435
and the equations
p = p_0 * exp(-h / h_0)
F = 0.5 * p * v**2 * C_d * A
where v is the velocity in m/s, h the height in m, p the air pressure and F the force of the drag.

Space Opera · « **Reply #13 on:** 08/23/2016 10:41 pm »

Your work is pretty cool and deserves a comparison to the actual max-q indicated for each mission. I could apply voice recognition as well to get the moment the speaker says "max-q" (half kidding).

As you noticed, I have done something a bit more tricky in terms of interpolation than just "blind" interpolation. In addition, I have to guess how their altitude data is rounded: is it a round(), a floor() or a ceil() ? Consistency checks seem to say it is round(), but I'm still not very confortable with this conclusion.

I take good note for your observations about the under-estimated values, and I will check tomorrow where it comes from and correct it if needed.

Proponent · « **Reply #14 on:** 08/23/2016 11:02 pm »

Very cool, Space Opera!

Does SpaceX use the same reference frame all the way from take-off to orbit? My recollection from LEO launches was that the burn-out speed was consistent with circular speed in an inertial frame, but the that speeds early in flight were obviously in a rotating, Earth-fixed frame (otherwise the speed at lift-off would be over 300 m/s).

Is the speed deduced at the moment the rocket reaches Mach 1 (I haven't seen recent launches, but in earlier launches this was called out) consistent with a rotating frame, allowing for a lag?

S.Paulissen · « **Reply #15 on:** 08/23/2016 11:22 pm »

Quote from: Proponent on 08/23/2016 11:02 pm

Very cool, Space Opera!

Does SpaceX use the same reference frame all the way from take-off to orbit? My recollection from LEO launches was that the burn-out speed was consistent with circular speed in an inertial frame, but the that speeds early in flight were obviously in a rotating, Earth-fixed frame (otherwise the speed at lift-off would be over 300 m/s).

Is the speed deduced at the moment the rocket reaches Mach 1 (I haven't seen recent launches, but in earlier launches this was called out) consistent with a rotating frame, allowing for a lag?

The raw data says they only ever reach 7480.6 m/s so I assume they -only- use inertial frame. As a 160km altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

EDIT:

I, again, very crudely smoothed the function in a way that ... I sort of am okay with. After simply averaging the duration of the track (520s) with the number of observations I got a time 'step size' of 0.033309s which comes out to (unsurprisingly the frame rate of the video 30.022), and smoothed the time function by incrementing EVERY data read out 0.033309s and got, a smoother but essentially the same graph I had before, with the data only barely meeting the bottom of the raw points, but only on occasion. I then realized that the raw data is 'backwards skewed' in the time dimension as it accumulates velocity for ~1s while being frozen in time before stepping forward to meet 'reality'. To be honest, these curves that only meet the bottom are probably more correct than wrong.

To fairly visualize the smoothened data I tried to 'mimic' the backwards time bias by making the smoothened data look forward 30 frames, and averaging them to get the following graph.

Semmel · « **Reply #16 on:** 08/24/2016 06:41 am »

Ach right.. The lack of knowledge of the rounding method and also the lack of knowledge how and when the data is projected onto the screen makes the true curve anybodies guess. I have to revoke my statement that the interpolation needs improving, please leave it ad it is Space Opera.

Proponent · « **Reply #17 on:** 08/25/2016 12:22 pm »

Quote from: S.Paulissen on 08/23/2016 11:22 pm

The raw data says they only ever reach 7480.6 m/s so I assume they -only- use inertial frame. As a 160km altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

Thanks, S. Paulissen. I presume you mean "rotating frame" rather than "inertial frame."

Space Opera · « **Reply #18 on:** 08/25/2016 11:13 pm »

Does anyone could provide the launch azimuth for each flight ? From this information, I should be able to reconstruct a crude 3D trajectory as well...

S.Paulissen · « **Reply #19 on:** 08/26/2016 03:01 am »

Quote from: Space Opera on 08/25/2016 11:13 pm

Does anyone could provide the launch azimuth for each flight ? From this information, I should be able to reconstruct a crude 3D trajectory as well...

I know that SES-8 and 9, JCSAT14 and 16, AMOS6, Thaicom8,and ABS/eutelsat2 were a 90 degree azimuth, and I don't think it'd be a stretch at all to say that all GTO launches are 90 degrees as well. The little bit of inclination change is done during the GTO insertion burn.

http://www.faa.gov/about/office_org/headquarters_offices/ast/licenses_permits/media/LLS%2014-090%20Rev%202%20-%20License%20and%20Orders%20(FINAL)%2001_21_2016%20-%20signed%20copy.pdf

CRS-6 was 46.62 degrees azimuth. And most CRS missions will be nearly 42.

Jason3 was 142.8 according to one article but that doesn't sound right to me.
http://www.nasa.gov/press-release/noaa-s-jason-3-spacecraft-ready-for-launch-0

Quote from: Proponent on 08/25/2016 12:22 pm

Quote from: S.Paulissen on 08/23/2016 11:22 pm
The raw data says they only ever reach 7480.6 m/s so I assume they -only- use inertial frame. As a 160km altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

Thanks, S. Paulissen. I presume you mean "rotating frame" rather than "inertial frame."

Yes. I have no idea why I wrote the wrong thing up there. Not enough coffee I guess. $:-\$

Semmel · « **Reply #20 on:** 08/26/2016 08:59 pm »

Got my smoothing function back

and applied it on some of the data, not to improve the initial interpolation though.

I updated the flight data plot with some annotations. Its very interesting what you can see in the data, especially the acceleration. You can clearly see the Max Q throttle and of course MECO and the ignittion of the second stage. Less clearly but still good enough, one can see the fairing separation and also a throttle back of the M1D at around 300s. I have not heard about that one before.

Unfortunately, my atmosphere model still seems grossly wrong. I assume I have some units wrong, will investigate when I have time.

I also added a plot to show the velocity components in vertical and horizontal direction. Its very nice to see how the F9 launches vertically and ends up thrusting horizontal. I tried to get acceleration data from these as well but due to the nature of data gathering (brilliant as it is done), the interpolation fragments dominate the plots and you cant see what is going on any more.

I will be back with more computations when I have time

S.Paulissen · « **Reply #21 on:** 08/27/2016 03:26 pm »

That's awesome Semmel. I, too, caught the second stage throttle in your previous graph you made but did not comment on it. Your new graph is clearly superior as I did not notice the fairing separation at all. Great work!

When I saw the acceleration curves the other day, it made me wonder if we could suss out a more definite mass of the fairing and second stage based on the change of acceleration from staging events.

Semmel · « **Reply #22 on:** 08/27/2016 10:42 pm »

Quote from: S.Paulissen on 08/27/2016 03:26 pm

That's awesome Semmel. I, too, caught the second stage throttle in your previous graph you made but did not comment on it. Your new graph is clearly superior as I did not notice the fairing separation at all. Great work!

When I saw the acceleration curves the other day, it made me wonder if we could suss out a more definite mass of the fairing and second stage based on the change of acceleration from staging events.

Hi Paulissen,

yes, estimating the mass of the fairing should definitely be possible. I will work on that tomorrow maybe if family life allows it ;-) Currently I am trying to align my atmospheric model (its getting more complex every time I touch it!) with the throttle back of the first stage. The reason for this is, if I have the correct drag force on F9, I can use the mass (initial mass is known), the acceleration and drag force to compute the thrust of F9. That way, I can compute the throttle setting of F9 when it throttles back for max Q. Currently that is not possible because I cant get the dynamic pressure to work. If anyone has a suggestion of what is wrong, please let me know!

Input:
h # height of falcon in [m]
v # velocity of falcon in [m/s]

# some constants
T_0 = 288.15 # Sealevel standard temperatur [K]
p_0 = 101325 # Sealevel pressure [Pa]
h_0 = 8435 # Scale Factor for air pressure [m]
R = 8.31447 # ideal gas constant [J/(mol*K)]
g = 9.80665 # earth gravity [m/s^2]
L = 0.0065 # temperature lapse [kg/m]
M = 0.0289644 # molar mass of air [kg/mol]
mach_peak = 1.1 # assumed mach number for which the drag peaks
gamma = 1.4 # adiabatic index of air. Estimation.

# Falcon 9
A = (0.5 * 5.2)**2 * np.pi # cross section area in [m^2]
C_0 = 0.07 # drag constant value at speed far below mach1

# Standard atmosphere
std_atm_h = [ 0.0, 11000.00, 20000.00, 32000.00, 47000.00, 51000.00, 71000.00, 500000.00]
std_atm_T = [288.15, 216.65, 216.65, 288.65, 270.65, 270.65, 214.65, 214.65]
atm_T = sc.interpolate.interp1d(std_atm_h, std_atm_T, kind='linear')

# Temperature at hight values
T = atm_T(h)

# air pressure depending on hight
p = p_0 * np.exp(- g * M * h / (R * T_0))

# air density depending on pressure and temperature
rho = p * M / (R * T)

# mach depending on pressure and air density
# https://en.wikipedia.org/wiki/Speed_of_sound#Speed_of_sound_in_ideal_gases_and_air
mach_1 = np.sqrt(gamma * R * T / M)
mach = v / mach_1

# Drag coefficient model depending on mach number, following this approximation: http://home.myfairpoint.net/tfr001/atmos3.htm
C_d = C_0 * np.power(300.0, -(mach_peak - mach)**2) + 0.01 * mach + C_0

# drag computation taken from https://de.wikipedia.org/wiki/Luftdruck#Variabilit.C3.A4t_und_Extremwerte
F_drag = 0.5 * rho * v**2 * C_d * A
p_dyn = 0.5 * rho * v**2

There is not much that can be wrong to fix the values. If the model is correct but some values are wrong, there is not much that can be fixed.
For max drag, only rho can be wrong. So if rho is wrong, it can only be because of the pressure p or temperature T, the other stuff is just physics. I tried to fudge the temperature to align the values and the resulting temperatures are rediculus. So its not T. Leaves the pressure p. Since maxQ is a product of pressure and velocity squared, it is not enough to change the scale of p, as it would only affect the hight of the curve, not the location of its maximum. So the pressure equation needs to be adjusted inside the exponent. I figured,
p = p_0 * np.exp(- 1.75 * g * M * h / (R * T_0))
gives a reasonable lineup. That factor of 1.75 is rediculus, I dont think that such an error can happen inside there. Maybe velocity and height are seriously out of sync in the telemetry data, but that is pretty unlikely I would say. I am at a loss here. Any suggestion would be wonderful!

DAZ · « **Reply #23 on:** 08/28/2016 03:14 am »

Trans sonic drag and lack of area rule shape?

IainMcClatchie · « **Reply #24 on:** 08/28/2016 05:13 am »

This is awesome work. Are you writing the code in Python? What graphing package are you using?

You might try checking your atmosphere against the NASA standard atmosphere of 1976. You can test individual points with this online calculator, or you can just use the model here.

nicp · « **Reply #25 on:** 08/28/2016 09:24 am »

If I read that correctly the cross-sectional area for the Falcon assumes a diameter of 5.2m - its less than 4 isn't it?
Great stuff...

EDIT: Oh, 5.2m is the fairing diameter of course..

moralec · « **Reply #26 on:** 08/28/2016 10:17 am »

This thread really shows how awesome NSF is! Amazing work!

Proponent · « **Reply #27 on:** 08/28/2016 11:49 am »

Quote from: Semmel on 08/27/2016 10:42 pm

C_0 = 0.07 # drag constant value at speed far below mach1

Seems awfully low to me. Attached is a paper on the aerodynamics of the Block I Saturn I. While I wouldn't expect it to be a close match to the Falcon 9, I would have thought it would agree in order of magnitude. Have a look, for example, at the plot of the axial-force coefficient on page 31 of the PDF, which I believe is the same as the drag coefficient at zero angle of attack.

Herb Schaltegger · « **Reply #28 on:** 08/28/2016 01:44 pm »

Drag coefficient for an ogive-shaped fairing and long cylinder should be pretty easy to find in some basic aerodynamic texts and/or AIAA papers. This may not allow for easy internet research, but that kind of thing has been methodically studied by NACA/NASA since at least the 1930's.

Space Opera · « **Reply #29 on:** 08/28/2016 01:45 pm »

My own MaxQ calculation show roughly similar results.
The most probable is that our numbers are wrong, but is it possible that the throttle decreases before MaxQ ? Because clearly my curves show that the loss of acceleration seconds before MaxQ leads to a significant lower MaxQ than if the throttle was keep constant.

ugordan · « **Reply #30 on:** 08/28/2016 01:52 pm »

Quote from: Space Opera on 08/28/2016 01:45 pm

The most probable is that our numbers are wrong, but is it possible that the throttle is decrease before MaxQ ?

I think they may actually be throttling down for the supersonic/transonic regime buffeting. John Insprucker sort of hinted at that in a few webcasts, IIRC. If you compare to the velocity plot, it seems to be around Mach 1.

Herb Schaltegger · « **Reply #31 on:** 08/28/2016 02:59 pm »

Quote from: ugordan on 08/28/2016 01:52 pm

Quote from: Space Opera on 08/28/2016 01:45 pm
The most probable is that our numbers are wrong, but is it possible that the throttle is decrease before MaxQ ?

I think they may actually be throttling down for the supersonic/transonic regime buffeting. John Insprucker sort of hinted at that in a few webcasts, IIRC. If you compare to the velocity plot, it seems to be around Mach 1.

Indeed. And MaxQ is typically right around Mach 1, though rarely if ever exactly at that point. It varies from vehicle to vehicle, T/W ratio, ascent profile, etc.

ugordan · « **Reply #32 on:** 08/28/2016 06:12 pm »

I know, I was just pointing out that the throttle down doesn't appear to match max Q which for F9 occurs several seconds after going supersonic. I think I remember only one instance where maxQ was called out *before* supersonic, it might have been the Orion Delta IV Heavy launch.

Semmel · « **Reply #33 on:** 08/28/2016 07:48 pm »

Quote from: IainMcClatchie on 08/28/2016 05:13 am

This is awesome work. Are you writing the code in Python? What graphing package are you using?

You might try checking your atmosphere against the NASA standard atmosphere of 1976. You can test individual points with this online calculator, or you can just use the model here.

Yes, I use python and the matplotlib package. I checked pressure values against lists online and they are pretty good. Only very minor deviation. Also, I use the standard atmosphere model for the temperature vs. altitude approximation.

Quote from: Herb Schaltegger on 08/28/2016 01:44 pm

Drag coefficient for an ogive-shaped fairing and long cylinder should be pretty easy to find in some basic aerodynamic texts and/or AIAA papers. This may not allow for easy internet research, but that kind of thing has been methodically studied by NACA/NASA since at least the 1930's.

I guestimated there. The most stuff I found on drag coefficients is for unpropelled objects. If the engines of the F9 wouldnt run, it would have something in the order of 0.2 or 0.25. An airfoil has something below 0.05, so I went for a small number in the middle. The Saturn 5 is nice and all, but it has rather awkward shape and it had fins at the base, which increase Cd quite a lot. Nevertheless, I have an alternative plan how to find out.. Not telling you in case it is utter nonsense and I dont want to embarrass my self ;-)

Quote from: Space Opera on 08/28/2016 01:45 pm

My own MaxQ calculation show roughly similar results.
The most probable is that our numbers are wrong, but is it possible that the throttle decreases before MaxQ ? Because clearly my curves show that the loss of acceleration seconds before MaxQ leads to a significant lower MaxQ than if the throttle was keep constant.

Well, I count on our numbers being wrong for now. But I have an alternative plan.. needs time though that I currently dont have. The data is not running away, I will get to it eventually.

Quote from: ugordan on 08/28/2016 01:52 pm

Quote from: Space Opera on 08/28/2016 01:45 pm
The most probable is that our numbers are wrong, but is it possible that the throttle is decrease before MaxQ ?

I think they may actually be throttling down for the supersonic/transonic regime buffeting. John Insprucker sort of hinted at that in a few webcasts, IIRC. If you compare to the velocity plot, it seems to be around Mach 1.

Quite possible. Actually an interesting proposal. I added the region of mach 0.9 to 1.2 to the plot. Not an exact fit but quite close. Interesting interesting interesting.

ugordan · « **Reply #34 on:** 08/28/2016 08:02 pm »

Quote from: Semmel on 08/28/2016 07:48 pm

Quite possible. Actually an interesting proposal. I added the region of mach 0.9 to 1.2 to the plot. Not an exact fit but quite close. Interesting interesting interesting.

Does that take into account the lower speed of sound at that altitude (10-ish km)? I think Mach 1 might be around 300 m/s or thereabouts there.

Semmel · « **Reply #35 on:** 08/28/2016 08:19 pm »

Quote from: ugordan on 08/28/2016 08:02 pm

Quote from: Semmel on 08/28/2016 07:48 pm
Quite possible. Actually an interesting proposal. I added the region of mach 0.9 to 1.2 to the plot. Not an exact fit but quite close. Interesting interesting interesting.

Does that take into account the lower speed of sound at that altitude (10-ish km)? I think Mach 1 might be around 300 m/s or thereabouts there.

Yes. Here a short list

h [m]	mach	speed of sound [m/s]
6991	0.9	312
8052	1.01	308
9512	1.18	301

IntoTheVoid · « **Reply #36 on:** 08/28/2016 08:58 pm »

Quote from: Semmel on 08/27/2016 10:42 pm

# air pressure depending on hight
p = p_0 * np.exp(- g * M * h / (R * T_0))

# air density depending on pressure and temperature
rho = p * M / (R * T)

From https://en.wikipedia.org/wiki/Density_of_air:
I see the formula below, and while yours has some similar features, I don't see the equivalence. (Though I'll admit that could be my own ignorance.

)
Not sure why you're using eⁿ, have h in the exponent, and not using L.

Semmel · « **Reply #37 on:** 08/29/2016 07:04 am »

I took this equation since its a bit simpler:

https://en.wikipedia.org/wiki/Atmospheric_pressure#Altitude_variation

You find this equation not only on wikipedia, also many other sites use that form. I dont think the approximation can be responsible for the differences we see. It wouldnt be a well accepted one if that was the case.

Proponent · « **Reply #38 on:** 08/30/2016 06:15 am »

Quote from: Semmel on 08/28/2016 07:48 pm

The Saturn 5 is nice and all, but it has rather awkward shape and it had fins at the base, which increase Cd quite a lot.

The data posted apply to the Block I Saturn I, which had no fins, though I do realize now that I had confused C_0 with Cd, so the discrepancy with the Saturn I is not nearly as large as I had thought.

Proponent · « **Reply #39 on:** 08/30/2016 06:31 am »

Quote from: Semmel on 08/29/2016 07:04 am

I took this equation since its a bit simpler:

https://en.wikipedia.org/wiki/Atmospheric_pressure#Altitude_variation

You find this equation not only on wikipedia, also many other sites use that form. I dont think the approximation can be responsible for the differences we see. It wouldnt be a well accepted one if that was the case.

That equation assumes the temperature is constant. Standard atmosphere models usually divide the atmosphere into regions, some of which are isothermal and some of which have linear temperature gradients. A suggestion for a quick-and-easy tweak: use an isothermal model optimized for the altitude at which max Q drag occurs.

meithan · « **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.

Semmel · « **Reply #41 on:** 09/01/2016 08:00 am »

Quote from: meithan 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.

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 · « **Reply #42 on:** 09/06/2016 01:39 am »

Quote from: Semmel on 09/01/2016 08:00 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 · « **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 · « **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 · « **Reply #45 on:** 01/21/2017 03:54 am »

Any headway on the mass of the fairing?

Semmel · « **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 · « **Reply #47 on:** 01/21/2017 05:38 pm »

Quote from: Semmel 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?

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 · « **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.

About -7 m/s for CRS-16,
-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.