SpaceX Falcon 9 FT - ORBCOMM-2 - Dec. 21, 2015 (Return To Flight) DISCUSSION

[WHAP]

...

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.)

What a fantastic example of a post worded as if it's fact, but with no evidence whatsoever, and most likely completely untrue.  All of the reasons you give for why F9 must have uplink capability are easily accomplished with logic that's preprogrammed.  That is - if you don't reach a certain orbital condition at a certain phase of flight, then you skip a specific step in the sequence.  It is extremely unlikely that the second stage has uplink capability, and, even if it did, SpaceX would need the ability to transmit from multiple locations.  Think about where the second stage was when it became known that it wasn't going to achieve a sufficient orbit for second stage relight - pretty low on the horizon, with a measurable probability of an erroneous, incomplete, corrupt, or completely missed signal.  Even if it was known earlier, when the vehicle was closer/higher relative to the horizon, what would have been uplinked?  And what criteria would have been used to send that uplink?  Do you believe that was done real time?  All of that logic could easily reside in the flight computer, and would avoid the possibility that an uplink wouldn't reach the vehicle.

[WHAP]

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?

No.  Are you aware that, on the ground, there are hard lines between the control center and the vehicle?  That's one of the reasons for electrical umbilicals.  There is software that often needs to be updated while the vehicle is on the ground, maybe even fueled.  It's a lot easier to do that via a command from the control center than by loading software onto a stick and sending someone out to plug it into the rocket.

[joek]

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?

Real time changes to the flight path are not impossible and are not prohibited.  It has happened in the past.  What is required is that an approved flight plan for each potential flight path be approved prior to flight.

[meberbs]

...

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.)

What a fantastic example of a post worded as if it's fact, but with no evidence whatsoever, and most likely completely untrue.  All of the reasons you give for why F9 must have uplink capability are easily accomplished with logic that's preprogrammed.  That is - if you don't reach a certain orbital condition at a certain phase of flight, then you skip a specific step in the sequence.  It is extremely unlikely that the second stage has uplink capability, and, even if it did, SpaceX would need the ability to transmit from multiple locations.  Think about where the second stage was when it became known that it wasn't going to achieve a sufficient orbit for second stage relight - pretty low on the horizon, with a measurable probability of an erroneous, incomplete, corrupt, or completely missed signal.  Even if it was known earlier, when the vehicle was closer/higher relative to the horizon, what would have been uplinked?  And what criteria would have been used to send that uplink?  Do you believe that was done real time?  All of that logic could easily reside in the flight computer, and would avoid the possibility that an uplink wouldn't reach the vehicle.

It was almost certainly below the horizon. The separation occurred at about 9PM EST, 25 minutes after launch. (ref) The plan had there been no issues was to perform the burn about 45 minutes after the dragon separated. (article link) None of this is relevant, because downrange tracking stations are also used. (I couldn't quickly find information on what SpaceX uses downrange, but any rocket launch I have seen has had continuous telemetry, even after I'd expect the rocket to be well below the horizon.)

All of the wording I remember from articles and statements about that launch implied the final call was made by humans, not autonomously. In particular, Chris Bergin's article that I linked above states: "Unfortunately, the propellant mass check at SECO-1 failed to pass the requirements to ensure safe insertion of Orbcomm and the second stage in an orbit away from Station, resulting in no second burn commanded." The phrasing of "no second burn commanded" indicates to me that the second burn wouldn't happen without input from the ground. Maybe I am misunderstanding this statement, but I don't see how it is "extremely unlikely" that the second stage has uplink capability. It is not that difficult to do, and gives you a lot more confidence in case something goes wrong that a predetermined plan doesn't account for.

To answer your questions, the uplink likely would be something like "ok to proceed with second burn". Criteria would be based on the telemetry downlinks, the article I linked has more specifics. If the ok to proceed uplink isn't received, then there wouldn't be a second burn, which makes it fail safe. 

This thread is getting pretty off topic. We should probably take some of the discussions about what it takes to redirect a stage to another thread.

[rcoppola]

WRT the change in thruster placement:

-The may have been moved down for optimum control authority (doubtful)
-Possibly because of the extended nozzle on the M1D-Vac
-Or because of where all 3 cores will be attached in a FH configuration

[JamesH]

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.

Absolutely. Talk of software changeout, RTOS or non-RTOS etc are irrelevant.,As are the continual 'this is how its always been done' comments. Because in case anyone hasn't noticed, no-one has ever returned a first stage to landing site. If we went with 'this is how it's always be done' we wouldn't be landing at the launch site. Or indeed at all.

Much as I hate the phrase, this is a paradigm shift, and it will in all likelihood involve similar shifts in existing procedure.

It perfectly possible to simply send a message to the stage to abort its primary landing site and go somewhere else. That can either be a pre programmed site (secondary) or a new set of coordinates. Making that a solid non-spoofable link is a solved problem - error correction, checksums and encryption. Nothing in the software of a rocket like this is anywhere near as complex as in something like a Tesla car with autonomous driving. Now that IS a complex problem, orders of magnitude more difficult than the maths involved in landing a stage, and the implication of it going wrong are considerably worse than a rocket landing.

I do agree that weather is not likely to be a reason for a last minute change of landing site.

[Jim]

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).

No, it can't receive uplinks nor are there uplink transmitters for the stages.  Those decisions were programmed into the stage preflight. 

[Jim]

Maybe I am misunderstanding this statement, but I don't see how it is "extremely unlikely" that the second stage has uplink capability. It is not that difficult to do, and gives you a lot more confidence in case something goes wrong that a predetermined plan doesn't account for.

Yes, you did.  And yes, it is difficult.

[Kabloona]

,As are the continual 'this is how its always been done' comments.

You seem to be willfully missing the point. This is how SpaceX does it NOW (no uplink for retargeting).

Could they implement an uplink in the future to change the landing coordinates in flight? Yes, it's technically possible. But it complicates the system and is not necessary.

So the arguments here are not about how it's currently done by F9. The arguments are about the merits and challenges of implementing such a system in the future. In my view it's an unnecessary complication and I doubt SpaceX will go that route.

Others will have different opinions about what SpaceX should/will do. You are free to have such an opinion, but don't mistake your opinion about what they should/could do for what they are doing NOW (no uplink for retargeting).

[OxCartMark]

Talk of software changeout, RTOS or non-RTOS etc are irrelevant.,As are the continual 'this is how its always been done' comments. Because in case anyone hasn't noticed, no-one has ever returned a first stage to landing site. If we went with 'this is how it's always be done' we wouldn't be landing at the launch site. Or indeed at all.

Much as I hate the phrase, this is a paradigm shift, and it will in all likelihood involve similar shifts in existing procedure.

When I hear assertions otherwise, especially those without any source or reasoning I have a name for it.  "ICBM Think".  My take is that old school ICBMs don't have any recallability because it could be spoofed by those at the destination.  Similarly, ICBM derived launchers would by evolution not have that capability.  But a rocket whose design is lead by someone with a silicon valley software background, someone whose cars have over the air software updating, it would be hard to understand why that capability didn't make it into the rocket.

Nuff of this off topicating.  Lets get back to ORBCOMM-2 - RTF DISCUSSION THREAD.

[Johnnyhinbos]

Any speculation about the changes to the landing legs? Looks like the stowed attachment point is different, and there are dual protrusions along each side...

[JamesH]

,As are the continual 'this is how its always been done' comments.

You seem to be willfully missing the point. This is how SpaceX does it NOW (no uplink for retargeting).

Could they implement an uplink in the future to change the landing coordinates in flight? Yes, it's technically possible. But it complicates the system and is not necessary.

So the arguments here are not about how it's currently done by F9. The arguments are about the merits and challenges of implementing such a system in the future. In my view it's an unnecessary complication and I doubt SpaceX will go that route.

Others will have different opinions about what SpaceX should/will do. You are free to have such an opinion, but don't mistake your opinion about what they should/could do for what they are doing NOW (no uplink for retargeting).

SpaceX don't do it now, I know. I never said they did. But why do people think it won't be done in the future - near future at that?.  It's not, as some people seem to think, a complicated thing to do compared with modern car software engineering (as shown in above post). That what I mean by 'not done this way' comments.

The first stage is already autonomous, which means it guides itself to a landing point ( I presume its the only 1st stage to ever do this as its the only one that has ever been fitted with guidance?). This is not a pre-programed set of instructions - the pre programmed bit is the final location - it's still needs to steer itself down to that point. The software is constantly adjusting RCS, grid fins etc to do that steering. If you want to change the  final landing point, you change nothing but the landing location (within reason, and the distance the stage can move cross range depends on the height at which you change the landing location). The stage simple aims for the landing point.  This is not a complex problem - and in fact already solved because they have got within a smidge of landing it.

[Jim]

As are the continual 'this is how its always been done' comments. Because in case anyone hasn't noticed, no-one has ever returned a first stage to landing site. If we went with 'this is how it's always be done' we wouldn't be landing at the launch site. Or indeed at all.

Much as I hate the phrase, this is a paradigm shift, and it will in all likelihood involve similar shifts in existing procedure.

Wrong, It has nothing to do with how its always been done.  it is an unneeded capability and an expense with little ROI.  There is no reason to employ uplink nor is it really viable.

[Jim]

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.

Yes, it does require code change and a major one.  Software is not changed while the vehicle is operating.  It is all done preflight and verified. There are no parameters changed while the vehicle is operating the flight software. 

[Wetmelon]

No, it can't receive uplinks nor are there uplink transmitters for the stages.

What?  Yes it can, and yes there are.  See section 4.3.5, the Iridium uplink for stage recovery operations: http://www.spacex.com/sites/spacex/files/falcon_9_users_guide_rev_2.0.pdf

Granted, that doesn't say anything about software modification uplinks.  I highly doubt they would upload new software mid-flight, I even doubt they would attempt to change the landing destination mid-flight through uplink.  But changing a destination in your flight controller based on pre-determined parameters is fairly trivial.  Closed-loop controllers are designed to be able to handle a moving setpoint (destination).  Obviously the earlier you make this change, the better, as the rocket has more time to make adjustments and has to do them less aggressively.

[Kabloona]

The first stage is already autonomous, which means it guides itself to a landing point ( I presume its the only 1st stage to ever do this as its the only one that has ever been fitted with guidance?). This is not a pre-programed set of instructions - the pre programmed bit is the final location - it's still needs to steer itself down to that point. The software is constantly adjusting RCS, grid fins etc to do that steering. If you want to change the  final landing point, you change nothing but the landing location (within reason, and the distance the stage can move cross range depends on the height at which you change the landing location). The stage simple aims for the landing point.  This is not a complex problem - and in fact already solved because they have got within a smidge of landing it.

As a retired engineer having worked on several vehicles (Pegasus, Taurus, Transfer Orbit Stage) I'm well aware of how launch vehicle guidance systems work.

Your summary is in fact an illustration of why uplink retargeting for landing is unnecessary. All the computing power needed is already on the vehicle, and adding software logic to select from a list of multiple landing targets would be trivial.

The F9 flight computer could, for example, store a table of multiple landing coordinates (say, the centers of all the pads at LC-13) and, if for some reason on final descent it found itself too far from the main pad, could decide to land at one of the alternate pads that was closer to its trajectory.

That's an example of autonomous choosing between multiple pads at the same landing complex. IMO it's less likley that they would allow the stage to choose between distant landing targets (ie LC-13 or the barge offshore). But it's technically possible.

The recurring question is not whether it's technically possible. The question is whether uplink retargeting of landing coordinates is *necessary* . I don't see it as necessary.

Now, since we've cluttered this thread enough, perhaps future discussions of this should go in a separate thread in the subject of "In-flight retargeting of F9 first stage landing" or something to that effect.

Back on topic, in-flight retargeting is not going to happen on the OG2 mission. Whether it should happen in future flights is a matter of opinion that belongs elsewhere.

[Jim]

When I hear assertions otherwise, especially those without any source or reasoning I have a name for it.  "ICBM Think".  My take is that old school ICBMs don't have any recallability because it could be spoofed by those at the destination.  Similarly, ICBM derived launchers would by evolution not have that capability.  But a rocket whose design is lead by someone with a silicon valley software background, someone whose cars have over the air software updating, it would be hard to understand why that capability didn't make it into the rocket.

Wrong take away.  A car can coast and stop if something is wrong with its code.  Not the same for a rocket in flight.
And what you mean without source or reasoning?  I have yet to see any valid reason to incorporate such a change.

Fact:  There are no down range transmitters
Fact:  With transmitters, there is no guarantee that the command will be received or acted upon.
Fact:  It would take an avionics and software architecture to incorporate such a capability

When I hear repeated off the cuff assertions such as these, I have a name for it, "candidate for the ignore list".

[Jim]

No, it can't receive uplinks nor are there uplink transmitters for the stages.

What?  Yes it can, and yes there are.  See section 4.3.5: http://www.spacex.com/sites/spacex/files/falcon_9_users_guide_rev_2.0.pdf

Note the UHF Command Receiver, specifically.  Granted, that doesn't say anything about software modification uplinks specifically.  I highly doubt they would upload new software mid-flight, but changing a destination in your flight controller based on pre-determined parameters is fairly trivial.  Closed-loop controllers are designed to be able to handle a moving setpoint (destination).  Obviously the earlier you make this change, the better, as the rocket has more time to make adjustments and has to do them less aggressively.

Wrong, wrong and wrong.  That UHF Command Receiver is the FTS reciever.  It is separate and dedicated to the FTS.  It is isolated from the vehicle's avionics.

[Kabloona]

No, it can't receive uplinks nor are there uplink transmitters for the stages.

What?  Yes it can, and yes there are.  See section 4.3.5: http://www.spacex.com/sites/spacex/files/falcon_9_users_guide_rev_2.0.pdf

Note the UHF Command Receiver, specifically.  Granted, that doesn't say anything about software modification uplinks specifically.  I highly doubt they would upload new software mid-flight, but changing a destination in your flight controller based on pre-determined parameters is fairly trivial.  Closed-loop controllers are designed to be able to handle a moving setpoint (destination).  Obviously the earlier you make this change, the better, as the rocket has more time to make adjustments and has to do them less aggressively.

The UHF command receiver is for FTS and is a standalone system that has nothing to do with guidance.

[saliva_sweet]

What about Table 4-8: "Falcon 9 RF susceptibility" in the user guide? There's an entry for telecommand in addition to the FTS on a different frequency. There does appear to be something more than FTS going up, no?