-
#900 by vulture4 on 11 Dec, 2015 20:33
-
The Shuttle was committed to land with the deorbit burn about an hour ahead of the actual landing. There were cases where the weather got worse but none that put it in an unacceptable situation. If the vehicle had been able to land autonomously (the capability was there but never tested) it would actually have been safer. The SpaceX booster stage lands less than an hour after launch, and if weather doesn't appear acceptable for landing the launch can be delayed. I don't think this will be a problem.
-
#901 by Jim on 11 Dec, 2015 21:32
-
Also, the range is not going to want a change in mid-flight.
At one point, they must have been able to handle it, because isn't that exactly what a TAL or RTLS abort would have been?
There is no range safety implications with those. All the assets go down range. Range safety is not involved with the orbiter landing -
#902 by Jim on 11 Dec, 2015 21:34
-
Jim,
You know as well as I do how fast the weather can change in Florida. It's going to take about a half hour for that stage to boost back to the Cape, and the winds at various high and mid range altitudes can change from fairly calm to howling fast in minutes.
No, it will be closer to 15 minutes. The booster only burns for 3 minutes -
#903 by Jim on 11 Dec, 2015 21:36
-
The range will know exactly how to handle a course change - that's their job.
No, the potential changes have to be known pre launch. And no, it doesn't have to be their job. They can say that one one cape landing point per mission. -
#904 by wolfpack on 11 Dec, 2015 21:51
-
My thought is that even though current designs have no uplink to rearrange landing site. it will be useful as time goes by.
Avionics runs a real-time operating system (RTOS) in flight. The difference between RTOS and a non-RTOS (think Microsoft Windows) is that an RTOS prioritizes tasks (ie - #1 keep the rocket pointed up, #2 send telemetry, #3 do something less important but ABOVE ALL ELSE, make sure #1 gets done even if it means dropping #2 and #3) whereas a non-RTOS will do absolutely everything asked of it, but may take a long time (ie - boot Windows laptop, go get coffee while the thing starts, come back, see you still can't open your email, get another coffee, etc). So there's a non-zero risk that asking the flight software to do something via uplink might not actually get done. This is probably very small given the speed of modern computers, but it's not zero. Add on top of that the very real need to verify uploaded data before allowing it to execute (ie - I transmitted "LAND on Cape" but a few bit errors on the way up changed that to "LAND on Titusville"). You want to make sure the computer has no errors in it before pressing the "GO" button.
These are obviously absurd examples but the point is that making changes to an executing program in flight carry real risk. -
#905 by eriblo on 12 Dec, 2015 00:08
-
The range will know exactly how to handle a course change - that's their job.
No, the potential changes have to be known pre launch. And no, it doesn't have to be their job. They can say that one one cape landing point per mission.
What I was trying to say in not so many words was that their job is to make sure that any deviations from the predetermined trajectory does not result in the launcher going anywhere else - and that they know just which buttons to press
I don't see any point in anyone wanting to complicate this and it would be a lot of work to ensure it doesn't increase the risks. -
#906 by DecoLV on 12 Dec, 2015 00:11
-
I agree real-time changes are impossible, but if a significant weather change is known -- at least up until fueling -- somebody could run out to the pad with a thumb drive and plug it into a USB port in the side of the stage, no?
-
#907 by punder on 12 Dec, 2015 00:23
-
I don't understand. An orbiter doing RTLS would be carrying hypergolic propellants, there might be a large solid upper stage in the payload bay, and it is an airliner-sized vehicle moving at a couple hundred knots. I can imagine a damaged RTLS orbiter posing a bigger threat than a returning F9 1st stage. Why are there no implications for range safety?Also, the range is not going to want a change in mid-flight.
At one point, they must have been able to handle it, because isn't that exactly what a TAL or RTLS abort would have been?
There is no range safety implications with those. All the assets go down range. Range safety is not involved with the orbiter landing -
#908 by meberbs on 12 Dec, 2015 01:05
-
...
Launch vehicles are autonomous and do receive any uplinks. The FTS is moving to an autonomous system and it won't use receivers.
By launch vehicles do not receive uplinks, I assume you just mean the first stage. The second stage definitely can receive uplinks, otherwise they wouldn't have been able to choose whether or not to abort the re-ignition of the second stage during the CRS-1 mission. (Where the secondary payload had to be released too low due to fuel constraints after an engine failure and NASA margin requirements).
Is there any source for the information that they don't have any uplinks to the first stage? (Or do you work for SpaceX so you are the source? I know that can happen here.)
I also would be surprised if range safety gave approval for there not being an operator with an FTS button, no matter how much automation you put into the stage.
While there are constraints on what can be changed mid-flight, if an uplink was available, changing landing location would not be technically challenging, especially if you were just selecting from some pre-defined scenarios. All you would have to do upon receiving the message (after error checking) is swap out a pointer. This isn't something time consuming.
if ( boostBackData->okToChange() ) { boostBackData = *ASDSBoostBackData;}
A better programmer than me may know an extra safeguard or two that might be needed especially if things are multithreaded. Worst case is that the message is either ignored or not received, and the stage does what you originally told it before launch.
Note that I agree with the logic that they probably haven't implemented this, since the need to change landing site is very low probability. -
#909 by Dante80 on 12 Dec, 2015 01:20
-
I don't understand. An orbiter doing RTLS would be carrying hypergolic propellants, there might be a large solid upper stage in the payload bay, and it is an airliner-sized vehicle moving at a couple hundred knots. I can imagine a damaged RTLS orbiter posing a bigger threat than a returning F9 1st stage. Why are there no implications for range safety?
Because the range cannot do anything.
In the case of F9, the range can detonate the rocket if it gets off course. -
#910 by Martin.cz on 12 Dec, 2015 01:27
-
While there are constraints on what can be changed mid-flight, if an uplink was available, changing landing location would not be technically challenging, especially if you were just selecting from some pre-defined scenarios. All you would have to do upon receiving the message (after error checking) is swap out a pointer. This isn't something time consuming.
Yeah - unless the stage already started homing on the previous location - then re-targeting might not be possible (not enough energy/fuel to change the trajectory - in such case the stage should probably want to target a designated safe-impact area instead) or might be rather complicated (the stage would need to be able to compute and execute a new trajectory - while deciding if the fuel/energy margins are sufficient to reach the new target).
But part of that (at least the checking if the new target could be actually reached) cold be computed ground side - possibly in realtime at once for multiple "backup" targets. That way you know the stage has a chance to reach the new target safely even before sending the command. -
#911 by Kabloona on 12 Dec, 2015 01:28
-
Steven Pietrobon just posted this pic in the updates thread.
It looks like they've repositioned the GN2 thruster clusters. They used to be up near the top of the interstage. Now it looks like they're down in between the grid fins. -
#912 by Johnnyhinbos on 12 Dec, 2015 01:34
-
Huh - the full res image struck a chord with me. The SpaceFlight101 specs in F9FT showed the grid fins with an aerodynamic fairing, and the picture you supplied is without. I wonder which one is the current version...?
-
#913 by Dante80 on 12 Dec, 2015 01:37
-
For reference, the older thruster positions.
Also, do the fins lack aerodynamic housings in the FT design, or they are simply not installed yet?
-
#914 by Kabloona on 12 Dec, 2015 01:40
-
The FCC permit includes the barge and its location. In the barge tracking thread there has been some recent activity, moving jacks aboard & etc. But yes, there's some amount of speculation, which is why I said, "in all likelihood". And of course plans could change: the barge could spring a leak or blow a thruster or something. But I think I'm safe in saying that careful watchers expect the ASDS to be deployed... and rather soon, too: it takes a few days to get on station. So shortly after the static fire you'd expect to see it leave port.
wouldn't a new permit be needed even for the barge landing as this is a new model launcher,and the last one exploded in flight. Doesn't that cancel out the permit?
The FCC application was for transmitter permits for the barge, etc. You may be confusing that with the FAA permit for the landing attempt, which is a different animal. -
#915 by Kabloona on 12 Dec, 2015 01:42
-
Also, do the fins lack aerodynamic housings in the FT design, or they are simply not installed yet?
Looks to me like there are still fittings around the grid fins for the fin fairings, and the fairings are just not installed yet. -
#916 by Johnnyhinbos on 12 Dec, 2015 03:21
-
Also, do the fins lack aerodynamic housings in the FT design, or they are simply not installed yet?
Looks to me like there are still fittings around the grid fins for the fin fairings, and the fairings are just not installed yet.
I asked someone who has been working on this booster if the fairing were going to be added and he said no. I also asked if he knew why the thruster pods had been relocated and he said yes, but since he didn't know if it had been publicly discussed he couldn't answer. (This was all through the Facebook group) -
#917 by Dante80 on 12 Dec, 2015 03:59
-
Then it would be pretty safe to assume that they are both weight cutting measures?
-
#918 by OxCartMark on 12 Dec, 2015 04:17
-
These are obviously absurd examples but the point is that making changes to an executing program in flight carry real risk.
I'm not going to tackle the question of whether its possible to change landing destinations in flight or not but I want to point out that it certainly doesn't require changing any program code in flight to do so if it was in fact made to be selectable in flight. You'd have both destinations pre-loaded and at some point after the second stage is away the software would look for the current destination setting and execute the flight control needed to get there. It would be no more a change to an executing program than any switch input that the software may be looking at. -
#919 by joek on 12 Dec, 2015 04:38
-
wouldn't a new FAA permit be needed even for the barge landing as this is a new model launcher,and the last one exploded in flight. Doesn't that cancel out the permit?
An FAA license is required regardless, not a permit. These are not operated under an FAA permit as they are for hire, and thus must be licensed. For landing, FAA approval is always required, and possibly Range approval (depending on landing location). Does not matter if it is a new vehicle or whether the previous flight was successful.
