Commercial Crew

In article ,
says...

On 2019-07-08 06:35, Jeff Findley wrote:

No. It's most likely in the Falcon 9 because that's got all the
computers which control it anyway.

OK, so if the booster has the logic to detect abort conditions, it can
self abort with or without capsule. Do you know if, in manned mode,
falcon 9 would require the capsule "agree" to abort (akaL multiple
computers needed to agree) ?

No. The capsule has no say. The Falcon 9 computers determine that
"something very bad is happening" and command an abort. The capsule
aborts. There is no choice here as the system is automatic. It has to
be automatic because "bad things" happen very fast!

Very fast. You do know how fast computers are these days, right?

This really depends on implemenmtation. For TCP/IP for instance, a
connection between two hosts can remain active for a fair bit before one
or both sides detect that the "keep alive" has not been received and
connection should be closed. For some apps, this can be in minutes.

Then the engineers wouldn't do it that way, now would they?

you mentioned loss of power/light on a cable. If they have such hardware
detection, then yeah, it can be instant. But if relying on data
protocols, it all depends on the protocol and how quickly both sides
detect the other is gone.

I am sure they do, because that's how a sane engineer would design the
system.

But one would also need to look at implementation. Does loss of layer 1
(in ISO 7 layers model) trigger immediate abort, or do they wish to
gracefully handle temporary loss of it due to vribration etc and not
needlessly trigger a dangerous abort?

Which we *can't* do because we're not SpaceX engineers or any other
organization which has an agreement with SpaceX to see that sort of
engineering information (i.e. NASA engineers reviewing the design for
crew rating purposes).

All of this hand-wringing is silly. You sound like you're second
guessing the SpaceX engineers who have been guided by the NASA engineers
reviewing the designs. In this case the "best minds possible" really
are the ones who designed the thing.

snip

Perhaps I can reformulate the question:

In the event the capsule decides it needs to abort at MaxQ. (say they
realize they forgot the Columbian coffee):

Does it make much of a difference if the booster continues to accelerate
for a few more seconds, or does it need to stop ASAP in order to make it
much easier for capsule to open a large distance gap between the two?

That depends on whether or not this failure mode is covered by the
design. Both SpaceX and NASA would know. We mere mortals, however,
aren't privy to that sort of information.

Yes, because these are liquid fueled engines, if you don't maintain
tank
pressure, the engines physically can't run.

As I recall, the ET was barely pressurized.

This is not true.

https://en.wikipedia.org/wiki/Space_..._external_tank

From above:
LOX: Operation Pressu 34.7?36.7 psi (239?253 kPa) (absolute)
LH2: Operation Pressu 32?34 psi (220?230 kPa) (absolute)

I would not call that "barely" pressurized. The turbopump inlets *need*
that pressure in order to *not* cavitate.

And when accelerating, the
liquid fuel will be pushed down to the bottom where the pumps suck up
the liquids right?

There is some column pressure, but if there is a tank rupture, it's not
like it's going to be a tiny hole. The thing is likely to rip open in a
catastrophic way. This means dropping the internal tank pressure more
than enough to lead to the pumps cavitating and essentially pumping
nothing.

And you keep ignoring the fact that there are pressure sensors for the
tanks as well as a myriad of sensors in the engines which would
*immediately* alert the flight computer that there is something
terribly, horribly, wrong. That means immediate shutdown of all engines
and an abort for the capsule.

Considering the pressures the turbopumps create, wouldn't a minimal
pressure difference in the fuel tanks (from normal to ambiant) be
noticed by the turbo pumps as long as they can pull in liquid fuel/oxydizer?

Turbopumps physically can't operate without the proper head pressure.

I was under impression that in the case of the ET, the pressurization
with helium was done to reduce boiling off as the tank is being emptied
by the engines.

There were no helium tanks in the space shuttle system to pressurize the
main tanks. They were pressurized by ground systems, then by the SSMEs
during flight. Some of the hot H2 pressurized the LH2 tank while some
of the hot O2 pressurized the LOX tank.

Does that tank pressure end up "pushing" fuel to the turbopump intake as
fast as the turbopump sucks up those liquids? or does the turbopump
still "pull" fuel from the tank?

The turbopumps need a minimum amount of head pressure at their inlets in
order to operate. That's why there is significant internal tank
pressure in the first place.

Would a drop in tank pressure result in instant "bad news day" with the
engines, or could they run for some time before bad news happens?
Would time be in milliseconds, seconds? 30 seconds ? a minute ?

Instant cavitation of the turbopumps. They physically can not operate
without the proper head pressure.

Jeff
--
All opinions posted by me on Usenet News are mine, and mine alone.
These posts do not reflect the opinions of my family, friends,
employer, or any organization that I am a member of.

In article ,
lid says...

On 19-07-08 21:31 , Fred J. McCall wrote:
Jeff Findley wrote on Mon, 8 Jul 2019
06:35:25 -0400:


Yes, because these are liquid fueled engines, if you don't maintain tank
pressure, the engines physically can't run. Even if they tried, without
the "head" pressure in the tank, the pumps will cavitate and the flow of
propellant would essentially stop anyway. They wouldn't be able to run
as soon as the pressure in the tanks is released. We're not talking
about a tiny pump here.


The case is even worse for a staged combustion turbopump engine. The
pressure in the fuel tank must be higher than that in the combustion
chamber of the turbopump,

Doubtful, because the propellants are usually pumped into the pump's
combustion chamber (preburner) too, raising the pressure. At least if we
believe the Wikipedia description of staged combustion.

If the pumps start cavitating, that means a pressure drop. Which means
the preburners aren't going to be getting the inlet pressure they need
to operate properly, so their output pressure drops. If their output
drops, the pressure going into the preburners drops even more (because
they get that pressure from the pump outlets in a staged combustion
engine). This is a feedback loop which causes the engine to quickly
stop.

This is not unlike a turbojet engine "flaming out" due to loss of inlet
pressure. On something like the SR-71, that was something alarmingly
easy to do. It had variable inlets to adjust to the speed and altitude
of operation, but if you got that adjustment wrong or maneuvered the
aircraft aggressively, you could easily drop the inlet pressure enough
to flame out one or both engines.

which must be higher than that in the
combustion chamber of the main engine.

That, I do not believe. If the pressure in the tank is higher than in
the engine combustion chamber, why would the pump be needed?

As I posted in my reply to JF, tank pressures in the shuttle ET were on
the order of 32 to 37 psi (check the Wikipedia entry for "space shuttle
external tank" for the precise numbers). That's clearly far lower than
the combustion chamber pressure of the SSME. So, as you say, that's why
you need the turbopumps in the first place. They raise the pressure of
the propellants higher than the combustion chamber pressure to account
for pressure losses in the cooling channels and injectors.

To figure out tank pressure, you start with the required head pressure
for the pump inlets. Then you add in a bit more pressure for the
plumbing losses to those inlets (since on the shuttle that plumbing is
relatively long compared to an in-line booster). Then you add in a bit
more for a factor of safety. That gives you the pressure in the tanks.

Jeff


--
All opinions posted by me on Usenet News are mine, and mine alone.
These posts do not reflect the opinions of my family, friends,
employer, or any organization that I am a member of.

On 19-07-09 13:47 , Jeff Findley wrote:
In article ,
lid says...

On 19-07-08 21:31 , Fred J. McCall wrote:
Jeff Findley wrote on Mon, 8 Jul 2019
06:35:25 -0400:


Yes, because these are liquid fueled engines, if you don't maintain tank
pressure, the engines physically can't run. Even if they tried, without
the "head" pressure in the tank, the pumps will cavitate and the flow of
propellant would essentially stop anyway. They wouldn't be able to run
as soon as the pressure in the tanks is released. We're not talking
about a tiny pump here.


The case is even worse for a staged combustion turbopump engine. The
pressure in the fuel tank must be higher than that in the combustion
chamber of the turbopump,

Doubtful, because the propellants are usually pumped into the pump's
combustion chamber (preburner) too, raising the pressure. At least if we
believe the Wikipedia description of staged combustion.

If the pumps start cavitating, that means a pressure drop. Which means
the preburners aren't going to be getting the inlet pressure they need
to operate properly, so their output pressure drops. If their output
drops, the pressure going into the preburners drops even more (because
they get that pressure from the pump outlets in a staged combustion
engine). This is a feedback loop which causes the engine to quickly
stop.

Yes, but this argument does not (as such) show that the tank pressure
should be larger than the preburner combustion-chamber pressure, as Fred
(mistakenly and admittedly) claimed. A calculation is needed, as you
explain later.

which must be higher than that in the
combustion chamber of the main engine.

That, I do not believe. If the pressure in the tank is higher than in
the engine combustion chamber, why would the pump be needed?

As I posted in my reply to JF, tank pressures in the shuttle ET were on
the order of 32 to 37 psi (check the Wikipedia entry for "space shuttle
external tank" for the precise numbers). That's clearly far lower than
the combustion chamber pressure of the SSME. So, as you say, that's why
you need the turbopumps in the first place. They raise the pressure of
the propellants higher than the combustion chamber pressure to account
for pressure losses in the cooling channels and injectors.

Yes. (I believe some small rockets use pressure-fed engines, where the
tanks are small enough to stand large pressures without having a
horrible mass.)

To figure out tank pressure, you start with the required head pressure
for the pump inlets. Then you add in a bit more pressure for the
plumbing losses to those inlets (since on the shuttle that plumbing is
relatively long compared to an in-line booster). Then you add in a bit
more for a factor of safety. That gives you the pressure in the tanks.

Plus you consider if more pressure is needed to stabilize the tank
against buckling under mechanical loads.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

Jeff Findley wrote on Tue, 9 Jul 2019
06:47:28 -0400:


This is not unlike a turbojet engine "flaming out" due to loss of inlet
pressure. On something like the SR-71, that was something alarmingly
easy to do. It had variable inlets to adjust to the speed and altitude
of operation, but if you got that adjustment wrong or maneuvered the
aircraft aggressively, you could easily drop the inlet pressure enough
to flame out one or both engines.


The same sort of problem can happen with turbofans. The F-14 Tomcat
was notorious for compressor stalls, particularly on maneuvers
involving yaw. This actually led to the death of the first female
F-14 pilot when she lost an engine on a carrier approach.


--
"Rule Number One for Slayers - Don't die."
-- Buffy, the Vampire Slayer

In article ,
says...

On 2019-07-09 06:33, Jeff Findley wrote:

No. The capsule has no say. The Falcon 9 computers determine that
"something very bad is happening" and command an abort.

So theoretically, if the "something very bad" severs the data lines to
capsule, the capsule won't eject?. I would have thought that capsule
losing telemetry from rocket might cause capsule to decide to eject.

If the capsule loses connection to the booster, the capsule would
initiate an immediate abort. Also, if the launch vehicle loses
connection with the capsule, it will immediately abort as well, which
means its engines shutdown.

This is what we've been saying all along. The booster and the capsule
both have their own control systems and are capable of *independent*
abort, once initiated.

or is there an expectation that the rocket will detect eed to eject
before data lines are ruptured? (thinking about rocket still on pad,
crew on-board and tanks start to rupture).

That's another type of failure. There are *lots* of ways the booster
can fail. That's why the tanks all have sensors (helium tanks, LOX
tanks, and kerosene tanks), the engines all have sensors, and etc. The
launch vehicle also has its own guidance system which can detect if it's
on the right trajectory with the correct acceleration.

Look, the US has had more than half a century to accumulate data on how
liquid fueled launch vehicles fail. So, if there is a known failure
mode, you can bet there is a sensor for that failure mode. This is the
21st century and computers are super fast, so keeping track of all of
those sensors isn't hard and doesn't take something the size of the
Saturn's Instrument Unit to handle this sort of stuff.

If the capsule door is still open, I take it the capsule would receive
the "eject" command from the stack below, but sound the alarm to get
crew to walk off instead of igniting the abort engines to eject capsule?
There must be some logic in the capsule to handle the abort signals from
below?

If the door is still open, it's a "very bad day", not only for the crew
in the capsule, but for the ground crew at the pad as well. NASA thinks
that this is highly unlikely since most everything is in a "steady
state" while the thing is fueled.

That's the way NASA's always done things, and it was an uphill battle
for SpaceX to get NASA to agree to load the propellant after the crew is
strapped in. In a Dragon 2, there simply is no possibility that the
door would be open if the launch vehicle failed on the pad.

I'd say we really don't have enough data to say which is safer for the
crew in the capsule. But I think it's very easy to say which is safer
for the ground crews, IMHO.

Which we *can't* do because we're not SpaceX engineers or any other
organization which has an agreement with SpaceX to see that sort of
engineering information

Yet the other guy seems sure enough to be able to insult me for asking
questions. Pbviously he has all the information.

We don't really have all the information because SpaceX is private and
they've not published papers on this stuff. But, information about how
previous abort systems work is more widely available on sites like
NASA's NTRS. Given that prior art, it's fairly easy to speculate about
how you would do things.

All of this hand-wringing is silly. You sound like you're second
guessing the SpaceX engineers who have been guided by the NASA engineers

Am not second guessing, I am trying to understand how it was
implemented. I asked about data protocols between capsule and stage I
to see how long it took for capsule to find out something was wrong, or
how long for stage to find out it hasn't heard from capsule in X time.
The response was "computers are fast", which isn't a response because
the data protocols dictate how fast each node detect loss of
communication. (used TCP example to show that computer can take forevery
to detect loss of communication).

Isn't that how discussion happen when people aren't set on insulting
those who ask questions ?

To detect a loss of communications between the booster and the capsule,
you don't need a communications protocol other than some way to detect
that there is no connection anymore. This could be as simple as four
wires going between the capsule and booster. One is ground. The other
is held at some positive voltage by the booster. The other is held at a
positive voltage by the capsule. The booster has a voltage sensor on
the capsule's positive voltage line. The capsule has a voltage sensor
on the on the booster's positive voltage line. In this way, either the
capsule or the booster can detect "loss of connection" with the other.

And finally, the last wire is normally kept at ground potential but can
be "pulled" to a positive voltage by either the booster or the capsule.
Both the capsule and the booster have a voltage sensor on their end of
this line. So if one detects "loss of connection", it will send an
"abort" signal to the other.

So, see how this covers all the bases? If only one of the positive
voltage lines goes to zero voltage, this triggers an abort on the end
that senses it. If all the lines are severed simultaneously, both ends
will sense it and they'll both abort.

I'm sure there are other ways to do this (e.g. optical cables or even
pneumatic lines instead of electrical cables), but the principle is the
same.

And note that the above would be in addition to whatever computer
network connects the two. That network would pass information like a
single Merlin engine shutting down in the first stage that is *not* an
abort situation. That way the crew in the capsule always knows what's
going on.

Ok, Ok, I get that. Out of curiosity, in a Shuttle example where it
needs head pressure of 35psi, how precisely must the pressure be
regulated? Are the engines tuned to such precisiuon they tolerate only
half a PSI variation? 1 PSI ? 5PSI ? 10 PSI?

I ask this in a context where 35PSI may be the optimal pressure for the
ET, but at what pressure would cavitation start ? 34.9 ? 34 ? 33? 30 ?
25? 20?

Are there uppoer likmits to pressure beyond which the turbo pumps start
to misbehave? I am assuming that if the Shuttle reached over 3Gs while
ascending, the turbopumps had to be able to accept the "pressurized" 35
PSI plus the weight of the fuel being accelerated as well.

From Wikipedia:

LOX tank
Operation Pressu 34.7?36.7 psi (239?253 kPa) (absolute)

LH2 tank
Operation Pressu 32?34 psi (220?230 kPa) (absolute)

I believe during flight that the pressure was maintained by operating
valves on the pressurization lines that came from the SSMEs. The
control loop for this would keep the pressure in the ranges specified
above.

But in addition to that, if something went wrong with the pressurization
system and it went above a certain maximum value, I believe the vent
valves would open to release the pressure to prevent the tanks from
bursting. This would still be a bad thing to be venting LH2 and/or LOX
during flight, so I'm sure some sort of abort would still be in order if
you're venting during flight.

I would think any sanely designed self pressurized launch vehicle stage
would have a similar design to the shuttle.

Engineers don't just "wing it", they go through a detailed analysis
asking what would happen if a component failed. Not only that, they
would go through each individual way a component could fail. For
example, a valve can fail open (when commanded to close) or that same
valve can fail closed (when commanded to open). More subtly, it could
fail by leaking while closed and that leak could be internal or
external.

So for every way something can fail, you have to analyze what that
failure does to the system.

Jeff
--
All opinions posted by me on Usenet News are mine, and mine alone.
These posts do not reflect the opinions of my family, friends,
employer, or any organization that I am a member of.

JF Mezei wrote on Tue, 9 Jul 2019
13:48:49 -0400:

On 2019-07-09 06:33, Jeff Findley wrote:

No. The capsule has no say. The Falcon 9 computers determine that
"something very bad is happening" and command an abort.

So theoretically, if the "something very bad" severs the data lines to
capsule, the capsule won't eject?. I would have thought that capsule
losing telemetry from rocket might cause capsule to decide to eject.


Again, let's assume the implementers of this stuff are NOT cretins,
shall we? You seem to be stuck on thinking data is flowing TO the
capsule. That's wrong. It flows the other way to the flight
computers and TM aggregators in the second stage. The capsule doesn't
'decide' anything other than getting the **** out of there when it
receives the "get the **** out of here" signal or when it detects the
loss of the "get the **** out of here" line. The easiest way to
implement this would be to simply have a discrete line with a constant
'one' signal on it. When the line goes to zero the capsule blows out
of there. I'm sure they did something more complex than that, but
even this simple approach would work.


or is there an expectation that the rocket will detect eed to eject
before data lines are ruptured? (thinking about rocket still on pad,
crew on-board and tanks start to rupture).


There is certainly some hope of that, since the sooner you get away
from a disaster the better off you are, but if by 'expectation' you
mean 'designed relying on', then no. See the very simple scheme I
suggested above. If things are intact enough the abort logic in the
booster pulls the "get the **** out of here" line to ground (zero) and
the capsule gets the **** out of there. If lines get severed, nobody
is feeding that constant voltage 'one' signal in anymore, the line
drops to zero, and the capsule gets the **** out of there. As I said,
I'm sure the actual implementation is more complex than that to add
robustness and such, but the simple implementation works and is better
than any 'theory' you've come up with.


If the capsule door is still open, I take it the capsule would receive
the "eject" command from the stack below, but sound the alarm to get
crew to walk off instead of igniting the abort engines to eject capsule?
There must be some logic in the capsule to handle the abort signals from
below?


If the capsule door is still open the abort system isn't armed and
there is no fuel in the booster so there's nothing much to explode
down there. Remember, Falcon 9 and Crew Dragon are using a 'load and
go' system. What that means is that first the crew boards, straps in,
and the doors are closed. Then the abort system arms. THEN they
start putting fuel in the boosters.

Which we *can't* do because we're not SpaceX engineers or any other
organization which has an agreement with SpaceX to see that sort of
engineering information

Yet the other guy seems sure enough to be able to insult me for asking
questions. Pbviously he has all the information.


"The other guy" insults you when you ask stupid questions, which you
seem to have a penchant to do constantly.

Again, start from the assumption that the folks who implemented this
are NOT cretins.

All of this hand-wringing is silly. You sound like you're second
guessing the SpaceX engineers who have been guided by the NASA engineers

Am not second guessing, I am trying to understand how it was
implemented.


Given the nature of your questions, I'm not sure you're capable of
understanding the answer.


I asked about data protocols between capsule and stage I
to see how long it took for capsule to find out something was wrong, or
how long for stage to find out it hasn't heard from capsule in X time.


No, you're asking about a NETWORK protocol. There is none. You don't
need one because in all cases there is one 'person' talking and one
'person' listening, so in all likelihood what exists is a bunch of
discrete data lines from 'talkers' to 'listeners'. As I told you
before, typical telemetry rates are 20Hz and 10Hz. Which one is used
in any particular case depends on how critical the data is and how
fast it can change. I would expect 'safety critical' lines to be
running at 20Hz, which means 50ms between updates.


The response was "computers are fast", which isn't a response because
the data protocols dictate how fast each node detect loss of
communication. (used TCP example to show that computer can take forevery
to detect loss of communication).


Yes, if you make bad assumptions about the data architecture and
assume the implementers are cretins you can arrive at all sorts of
unreasonable conclusions. "Computers are fast" is a perfectly
adequate answer if you have even a tiny glimmer of a clue about this
stuff. Let me see if I can impart one.

OK. You've got all these different sensors sending data to a
computer. These are direct lines, so there is no 'network lag'
because there is no network and no 'node' contending for time. Now,
the computer needs to be able to process that data and build it into a
telemetry stream with Important data appearing every 50ms and less
important data appearing every 100ms. Now, the computer needs to be
fast enough to be able to do this (first case of "computers are fast"
being an answer). Note that the computer also needs the speed and
capacity to take all the requisite data and do two other things with
it. First, it needs to calculate the 'range safety flight
termination' conditions and determine whether to engage the FTS.
Second, it needs to analyze the 'get the **** out of here' conditions
and determine whether to pull that trigger. It needs to be able to do
both of those things at the rate the data arrives (in an ideal world;
if your computer speed is limited you only use every other data item
that comes in, which is another case of "computers are fast" being an
answer).


Isn't that how discussion happen when people aren't set on insulting
those who ask questions ?


Nobody is "set on insulting" you. Put your safety pin in your shirt
and proceed directly to your 'safe space'. When you say stupid **** I
call it stupid ****. Get over it.

As I recall, the ET was barely pressurized.

This is not true.

35psi isn't that big of a pressure.

BTW, I was under impression that the ET was pressurized just before
launch by closing the vent and letting boiling liquids pressurize the
tanks. Did they actively close valves and pump more H2 and O2 into tanks
to pressurize them?


If it worked the way most such systems do, there would have been COPVs
filled with high pressure helium to maintain pressure of the tanks.
Remember, you need to maintain pressure as the propellants are burned.

catastrophic way. This means dropping the internal tank pressure more
than enough to lead to the pumps cavitating and essentially pumping
nothing.

Isn't the actual danger the shockwaves in the pump that cause it to fail
in dramatic way as opposed to not sucking up enough of the fuel/exydized
to maintain sufficient thrust ?


Pumping nothing is very bad for high power high speed pumps.

And you keep ignoring the fact that there are pressure sensors for the
tanks as well as a myriad of sensors in the engines which would
*immediately* alert the flight computer that there is something
terribly, horribly, wrong. That means immediate shutdown of all engines
and an abort for the capsule.

But while still at pad, this would only act based on pressure sensors in
the tanks, right?


Unlikely for a lot of reasons.

Turbopumps physically can't operate without the proper head pressure.

Ok, Ok, I get that. Out of curiosity, in a Shuttle example where it
needs head pressure of 35psi, how precisely must the pressure be
regulated? Are the engines tuned to such precisiuon they tolerate only
half a PSI variation? 1 PSI ? 5PSI ? 10 PSI?


The problem is not the engines. It's the pumps.


I ask this in a context where 35PSI may be the optimal pressure for the
ET, but at what pressure would cavitation start ? 34.9 ? 34 ? 33? 30 ?
25? 20?


Why do you persist in asking questions that a) don't matter, and b)
nobody is likely to know?


Are there uppoer likmits to pressure beyond which the turbo pumps start
to misbehave? I am assuming that if the Shuttle reached over 3Gs while
ascending, the turbopumps had to be able to accept the "pressurized" 35
PSI plus the weight of the fuel being accelerated as well.


I'm sure there is some 'upper limit', but you'd probably blow the tank
before you hit it.


--
"Some people get lost in thought because it's such unfamiliar
territory."
--G. Behn

JF Mezei wrote on Thu, 11 Jul 2019
13:17:55 -0400:

On 2019-07-09 23:13, Fred J. McCall wrote:

Again, let's assume the implementers of this stuff are NOT cretins,

I never assumed such. I don't question the engineers, I questions the
answers.


Sorry, but the implications in a lot of your questions assume exactly
that, because if you do NOT assume that your questions become moot.


If I ask "why is the sjky blue", and I get "because it is blue", then I
ask again.


Which isn't what happened at all.


If someone answers "because computers are very fast", I point out this
is not necessarily the case, it all depends on implementation.


Yes, if you assume the implementers are cretins you can implement slow
**** on fast hardware, but why would you?

shall we? You seem to be stuck on thinking data is flowing TO the
capsule. That's wrong. It flows the other way to the flight
computers and TM aggregators in the second stage.

Is the capsule "dumb" until it is released at which point its consoles
light up and crews (and capsule computer) have control?


Are you "dumb" until you are released at which point your eyes light
up and some form of intelligence shines forth? Frankly, I'm waiting
for that day. The capsule knows about itself and controls itself. No
need for data to leave the capsule for any of that. DUH!


You are stating the decision to abort is made by Falcon9 and not
Dragon2. Considering it is Dragon2 which activates its rockets to "get
the hell out of there", I would assume differently.


And that's why I spent 30+ years as an engineer at a missile design
house and you obviously did not. What you would "assume" is as
irrelevant as it is wrong.


You state data flows TO the Falcon computers, not to the Dragon. I
suspect that it is different.


What you "suspect" is both irrelevant and wrong.


While the Falcon computers run the show, i
suspect Dragon2 is getting the same telemetry so that the Dragon2 can
make the decision to abort should telemetry point that away.


I know it's hard for you, but think about it. The booster needs to do
things like decide when to fire the FTS and abort the flight whether
or not there is a Crew Dragon up top or not. A lot of the data and
logic used to do that is in the flight computers in the second stage.
Why in the hell would you complicate the system by requiring all that
data also flow to the capsule and all that logic be duplicated in the
capsule computers when a simple "get the **** out of here" discrete is
adequate to the job? The only reason to spread that kind of work
around is if the computers aren't fast enough (another case of
"computers are fast" being the answer to your question).


Also, I
would assume that Dragon2 has various instruments such as IMUs which
also add to the data available to gauge if trajectory/acceleration is
nominal or not.


Why would you assume that the booster itself, which has to do the
range safety calculations (modern rockets tend to not rely on that guy
on the ground but make the decision themselves), doesn't have IMUs?


(Whether those flow back to the Falcon9 computers, I
don't know, hence my questions)


All Crew Dragon telemetry data flows to the flight computers in the
second stage for aggregation into the telemetry stream. Do you NEVER
bother to try to look things up before you argue about them?


The logic to declare "abort" may be identical for Falcon9's computers
and Dragon2, but it is quite possible that Dragon2 makes its own
decision to fire the "eject" engines (assuming, but not relying on
Falcon9 computers reaching same decision).


Anything is possible but that would be a stupid and overly complex way
to implement things. Again, let's start by assuming that the
implementers are NOT cretins.


Remember that if the Falcon9 computers fail, you still want Dragon2 to
make the decision to abort.


Remember that if the Falcon 9 computers fail you lose the signal on
the "get the **** out of here" line and the capsule gets the **** out
of there.

of there. I'm sure they did something more complex than that, but
even this simple approach would work.

Your idea of a single strand in a cable having voltage or not is simple.


Yes, and it was given as a simple example to try to give you a clue.


But wouldn't rocket designers want to focus on having redundant data
path as opposed to having a whole bunch of different strands going
through complex connectors between sections, increasing odds of a single
strand losing connection due to cold, vibration?


Which part of "example" and "I'm sure they did something more complex
than that" is it that has left you confused? So what do you do if one
of your redundant data paths is reporting that you're ****ed and the
other is not? You don't know which one is broken, so you're going to
abort anyway. Given that, why do you need redundant paths.


You may recall that the Shuttle had a number of scrubs due to faulty
connectors.


Which is a good proof by demonstration that rocket designers do NOT do
what you claim.

suggested above. If things are intact enough the abort logic in the
booster pulls the "get the **** out of here" line to ground (zero) and
the capsule gets the **** out of there.

This would mean that all Falcon9s have been built with that line. This
ios why I think this is much more of a data driven appraoch since
Falcon9s were designed with data link to upper stages.


You might want to Read The Falcon Users Guide (RTFUG). Please pay
particular attention to Section 5.2.2.

Why do you think it's "too hard" to have discrete abort lines but
apparently trivial to send all the booster TM up to the capsule?

If the capsule door is still open the abort system isn't armed and
there is no fuel in the booster so there's nothing much to explode
down there.

At the time of the design, as NASA hadn't yet reluctantly agreed to let
crews ingress before fueling, wouldn't SpaceX have designed the software
to handle a case where rocket is fueled as crew ingress? I assume that
the abort would only be armed after door was closed anywatys?


No, and the case you cite is the stupidest of all. IF there are
safety concerns about 'load and go', you are certainly not going to
have the crew board while fueling is in progress. If 'load and go' is
a no-go, you would fuel the rocket, board the crew, seal up the
capsule, then arm the abort system.


Should ground workers have been in capsule during "something bad is
happening", I take it they were considered expandable since abort
wouldn't be triggered (and not being strapped in, you couldn't really
fire abort system without seriously hurting them).


Then they're dead because there is no way to save them, which is why
'load and go' is actually safer.

No, you're asking about a NETWORK protocol. There is none.

Do you know this for sure?


Again, assume the implementers are NOT cretins. Why do you need one?
Why would you design it to be slow?

As I told you
before, typical telemetry rates are 20Hz and 10Hz.

Do you know how SpaceX implemnented telemetry data transfers and
aggregation? Gas SpaceX published what sort of data links/protocol is
being used? Somehow I doubt they used the antique military protocol
that was used on shuttle and ISS.


Do you know **** from Shinola? Just which 'antique military protocol'
are you referring to and just what does it have to do with telemetry?
Lots of these things are done in fairly standard ways because it
works, it's simpler than reinventing the wheel, and it makes safety
certifications easier.

While you're doing that whole RTFUG thing read Section 2.5 as well.


Telemetry is typically sent blindly without any expectation of
acknolwledgement. In an ethernet environment, it would likely be sent as
a broadcast group where any interested device can listen in. (so Fancon
computers, the radio that copies telemetry to ground and the Dragon2
could each get their copy of the telemetry data).


And monkeys COULD fly out your butt and the software COULD be set up
to avoid pegasi in flight, but it would be silly to do so.


Somehow I suspect they didn't use the antique military slow standard.


What the **** are you talking about?


It
is very likiely that this is a "blind" data protocol where recipient
doesn't acknowledge and is sent as a broadcast for anyone interested to
listen to the telemetry. (including the radios that send telemetry back
to groudn station). Has SpaceX documented how they implemented it?


Time to RTFUG Section 2.5 again.


If, as you say, it is the Falcon9 computers that receive everuything and
doesn't send stuff to the Capsule, then telemetry from the capsule would
be sent in the blind too, like other telemetry.


Telemetry data is sent from the capsule to the flight computers in the
second stage because those are the guys who control the S Band
transmitters that send the stuff out.


How automated is the Soyuz abort?


I have no idea and little interest in antique Russian systems.


There are obvious situations where the
abort is a no brainer, but there are edge cases where it isn't so obvious.


The computer can ALWAYS make a better decision than the humans because
"computers are fast". It's a binary choice, edge case or no.


Consider Columbia. Telemetry started to be lost progressively and some
values being received off-scale. If you were to automate this, at what
point would the computer sound "red alert" and get crews to close
helmets because loss of ship was predicted?


Closing helmets was done by the evolution in progress, not by "Oh ****
me oh **** me oh **** me!"

Yes, if you make bad assumptions about the data architecture and
assume the implementers are cretins

The answer I got here was "computers are fast". I repeat again, it all
depends on how you iomplement the data comms which was point of my
question since not all data communications detect loss of link
immediatly, and some never do.


And I repeat again, start from the assumption that the implementers
are NOT cretins. I've given you numerous examples of why "computers
are fast" is actually the answer (if you start from that assumption).
Have you pulled your head out and understood what I said?


If a command to abort is issued only by the Falcon9 computer, but link
to capsule is severed, then the only way for Capsule to make decision to
abort is to detect that the link has been severed.


Which is why you'd use a line with a constant one value on it. Lose
the connection and it drops to zero. Do you not understand even
simple explanations? Note that a similar method (called "breakwire
pairs") is used to detect actual separation of the payload from the
second stage in the standard payload interface.


IF telemetry is also sent to capsule, then loss of telemetry flow is one
way to detect it. But if, as you claim, data flows only from capsule to
Falcon9 computer, then how is the capsule supposed to know the link is
broken?


Loses voltage on the "get the **** out of here" line. Do you even
bother to read and understand the explanations you're given or are you
just wasting everyone's time? Both Jeff and I described very similar
"breakwire" discrete lines.


And this goes back to Falcom9 design. Did they change the computers to
handle Dragon2 and different data paths and protocols, or were those
already fully capable of bidirectional data flow between Falcon9 and
Stage2 and payload before?


Neither. There is not "bidirectional data flow between Falcon9 and
Stage2 and the payload". There is no doubt additional software
running on the second stage flight computers and implementation of
what is referred to in the FUG as "custom interfaces". See section
5.2.2 first paragraph.

unreasonable conclusions. "Computers are fast" is a perfectly
adequate answer if you have even a tiny glimmer of a clue about this
stuff.

No it is not.


Yes it is. I'm sorry you're stupid.


Your example about computer being fast enough to process telemetry does
not handle the issue of having Falcon9 and Dragon2 and how each other
detect a fault between each other. Being fast enough to do computations
does not imply it will detect loss of connection between Falcon9 and
Dragon2 instantly.


Did you read what else I wrote or do you just pick where you want to
place nits and disregard the rest?


It all depends on the types of data exchanges between the two.


See "breakwire pairs", above.

OK. You've got all these different sensors sending data to a
computer. These are direct lines, so there is no 'network lag'

Unless you know how SpaceX has implemented telemetry in its rockets, you
can't claim to know hwo it is implemented. To save weight and redice
likelyhood of failures, it is unlikely that they run physical electrical
wires from each sensor all the way to a computer with a gazillion lines
in it. Even the Shuttle didn't do that and used the old military
protocol to aggregate telemetry onto a single low speed network cable.
(there was a polling mechanism to poll each sensor at pre-programmed
intevals).


Fine. You just sit over there and be stupid. I'd bet it didn't
'poll' the way you're thinking of it and didn't work at all like you
think it did. You've still got to run wires from the sensor to
SOMEWHERE. Since that's the case, why not just run the to where the
data is needed? Again, assume the implementers are NOT cretins.

If it worked the way most such systems do, there would have been COPVs
filled with high pressure helium to maintain pressure of the tanks.
Remember, you need to maintain pressure as the propellants are burned.

I had been told that for the Shuttle, the ET simply closed the vents
before liftoff to let the boiling process raise pressure and continued
boiling would keep pressure steady to compensate for all the LH2/LOX
vacating the tanks.


Why does that seem unlikely to me given the rate propellants are being
consumed?


Was unaware of pipes flowing back to the ET to get SSMEs to send high
pressure gases back to the individual tanks to pressurize them.


That could be made to work just as long as you never shut down the
SSME while the ET is attached.

Why do you persist in asking questions that a) don't matter, and b)
nobody is likely to know?

When someone answers "I don't know" or "SpaceX hasn't made that
information public", then I respect that. But when you insult me for
asking a question where I have no way to know that the answer is not
known, how am I supposed to react?


You don't 'ask questions'. You build in implications that are stupid
in the extreme. When you do that, I'm going to point out the stupid.


--
"Some people get lost in thought because it's such unfamiliar
territory."
--G. Behn

In article ,
says...

If a command to abort is issued only by the Falcon9 computer, but link
to capsule is severed, then the only way for Capsule to make decision to
abort is to detect that the link has been severed.


Which is why you'd use a line with a constant one value on it. Lose
the connection and it drops to zero. Do you not understand even
simple explanations? Note that a similar method (called "breakwire
pairs") is used to detect actual separation of the payload from the
second stage in the standard payload interface.


IF telemetry is also sent to capsule, then loss of telemetry flow is one
way to detect it. But if, as you claim, data flows only from capsule to
Falcon9 computer, then how is the capsule supposed to know the link is
broken?


Loses voltage on the "get the **** out of here" line. Do you even
bother to read and understand the explanations you're given or are you
just wasting everyone's time? Both Jeff and I described very similar
"breakwire" discrete lines.

Agreed. This is basic logic level type stuff that's been around long
before digital computers or even analog computers. It's the kind of
thing you use to control a remote amplifier in a car. +12V on the "amp
turn on" wire turns on the amp. Lose voltage on that "amp turn on" wire
(for any reason) and the amp turns off. JF should note that with this
design, the amp doesn't care *why* that line went to 0V (off), it just
turns off. Cutting the wire will make the amp turn off just as quickly
and as reliably as the head unit in the front of the car deliberately
dropping the voltage in the "amp turn on" wire to 0V when the user turns
off the head unit. There is no complex "telemetry" or "data transfer
protocol" here. It's a simple binary function (on or off) so you can
use a single wire to control it.

K.I.S.S. A sane engineer just does *not* use a complicated network
protocol for a binary, mission critical, time critical, function like a
crewed capsule abort. It's just not going to happen.

Computer networks are great if you want to control a "smart light" from
your "smart phone". I know lots of people who love those things and set
up complex rules for when the lights go on and off and dim at different
levels. But, if the light absolutely has to turn on and off reliably,
you really can't beat a $.49 light switch mounted in an electrical box
in the wall.

Jeff
--
All opinions posted by me on Usenet News are mine, and mine alone.
These posts do not reflect the opinions of my family, friends,
employer, or any organization that I am a member of.

JF Mezei wrote on Sat, 13 Jul 2019
16:02:06 -0400:

On 2019-07-11 19:12, Fred J. McCall wrote:

I know it's hard for you, but think about it. The booster needs to do
things like decide when to fire the FTS and abort the flight whether
or not there is a Crew Dragon up top or not. A lot of the data and
logic used to do that is in the flight computers in the second stage.

Are you sure about that?


Quite sure.


Falcon9 not only launches but it also descends and lands, and that
second part is done without second stage. So first stage MUST have
logic in it.


You say that like it means something. What you've argued is that
because your lungs work your brain isn't important.


It seems more likely to me that each stage has logic,


Of course they do. Uh, so what?


... and each stage may
be getting full telemetry from the other.


That's only "more likely" if you're willing to ignore everything
that's ever been published about how it works


If there is an explosion in
second stage, I would assume first stage needs to know so it can turn
off its engines ...


Again you seem to think you have a point when you do not. The main
engine control computers are at the top of the second stage. If they
stop talking, it's pretty simple logic for the first stage to know to
shut down.


and either fall into ocean or activate range safety if
required.


The range safety stuff is all in the second stage. Again, simple
logic for the first stage to fire it when the second stage stops
talking.


(and similarly, Dragon2 would initiate the ejection motors to
get the hell out of there - with stage 2 out, Dragon2 may not be getting
telemetry from Stage1 to tell it to abort so it would need to make its
decision on its own.


Crew Dragon doesn't get telemetry from the first stage whether Stage 2
is there or not.


You are the one who thinks this is all implemented very simpkly with a
singlewire that has voltage on or off. I am the one who says that surely
the engineers provided for very redundant decission making that is more
likely distributed rather than focused on any one stage's computer(s).


That's because I'm an engineer who worked for a missile design house
for 30+ years and you ... are not. No sane engineer makes safety
critical systems overly complex just for the **** of it. You do the
simplest thing that answers the mail and move on.

Why in the hell would you complicate the system by requiring all that
data also flow to the capsule and all that logic be duplicated in the
capsule computers when a simple "get the **** out of here" discrete is
adequate to the job? The only reason to spread that kind of work
around is if the computers aren't fast enough (another case of
"computers are fast" being the answer to your question).

Redundancy and disaster tolerance in logic.


WHICH YOU DO NOT WANT IN A SYSTEM LIKE THIS!


The User Guide to which you
refer menations how SpaceX built a reducncant fault tolerant computer
architecture.


Which has nothing to do with a system such as that we're talking
about.


Doesn't mentions simple copper wires to signal


You don't read, do you?

"Falcon vehicles are capable of detecting 6 separation events through
breakwire pairs, and a separation indication signal for each will be
included in launch vehicle telemetry. Additional breakwire sensing may
be available, contact SpaceX for more information. SpaceX requires
that at least one circuit on each spacecraft electrical connector be
looped back on the spacecraft side for breakwire indication of
spacecraft separation within launch vehicle telemetry. Customers may
request that any number of circuits on the spacecraft electrical
connectors be looped back on the launch vehicle side for breakwire
indication of spacecraft separation within spacecraft telemetry."

That's from Section 5.2.2, which I told you to read.


And I
would have to assume that NASA wants the crew in capsule to be informed
of what the hell is happening. Especially since the capsule and any
recorders in it is far more likely to be recovered for post accident
forensics.


What can they do about it? NOTHING!


Unlikel you, I think the SpaceX folks have thought throught all this and
made the system far mroe redundant than you claim it is, all the while
being compatible with existing Falcon9 stage 1s which may fly a cargo
mission and then a crewed mission or vice versa.


No, unlike me, 'think' is what you do NOT do. I think SpaceX folks
have indeed thought through all this and implemented the simplest
system that answers the mail, which is NOT what you are suggesting.

Why would you assume that the booster itself, which has to do the
range safety calculations (modern rockets tend to not rely on that guy
on the ground but make the decision themselves), doesn't have IMUs?

I never stated this. A lot of mission critical computers sytems have
multiple separate computers (some with slightly different software) to
do the same purpose and "vote" on actions when there is a difference
between computers.


But not in things like escape systems, where what you want is a single
"we're ****ed" vote sending you on your way rather than having the
capsule destroyed because it's hanging around waiting for election
results.


(As I recall, the Shuttle used "muscle" as voting, where each computer
would activate a device in one way, and if those ways differed, the
device would end up moving in the direction where more computers asked
it to move). More modern systems do this at software level.


You're comparing apples and aardvarks again. The Shuttle had big
pieces of its flight envelope where there was little chance of
survival if something went wrong. Most 'abort' scenarios were pretty
much all manual. NEITHER of those things is true of the Falcon 9/Crew
Dragon.

All Crew Dragon telemetry data flows to the flight computers in the
second stage for aggregation into the telemetry stream.

This does not disagree with what I think is happening. And I would say
all second stage telemetry flows to the stage 1 computers as well, and
vice versa such that each stage gets full telemetry feed.


You can say that all you like. It's wrong.

Do you NEVER
bother to try to look things up before you argue about them?

It has been admitted that this has not been published and we are only
speculating. Yet, you claim that it is published and that I should be
looking this up.


What is "it" and who has claimed it has not been published?

Anything is possible but that would be a stupid and overly complex way
to implement things. Again, let's start by assuming that the
implementers are NOT cretins.

Yet you are the one stating all they need is a simple wire pair to send
voltage or not, and you abort whenever voltage goes down.


You don't read, do you? That was a "simple example" to try to give
you some small clue, which is apparently a concept you are just too
bloody thick to comprehend.


I suspect the
engineers are far more throughough than this in the decision to abort
and propagating it to each stage in the rocket.


I suspect you're adamantly clueless. You're welcome to remain so.


From the user guide:
"The Falcon 9 launch vehicle is equipped with a standard flight
termination system. This system includes two redundant strings of
command receiver and encoder, batteries, safe and arm devices, and
ordnance in the event of an anomaly in flight."

Note the use of word "command" and "encoder". Encoding of commands does
not lead one to believe a simple voltage or no voltage on the copper
line you argue.


You've conflating two things that are not related. The case you
describe above is there for EXTERNAL range safety termination of the
vehicle, where the Range Safety folks on the ground decide to
terminate things for whatever reason. Why do you constantly try to
argue your 'points' by dredging up irrelevant ****e? Do you seriously
believe that an internally commanded activation of the FTS works that
way?

Remember that if the Falcon 9 computers fail you lose the signal on
the "get the **** out of here" line and the capsule gets the **** out
of there.

And if stage 2 has one tank explode in flight (but does not cut that
magic line), how are the other stages supposed to know if Stage 1
continues to supply power to your magic line?


Do I need to buy you some crayons and a Big Chief tablet so you can
draw this stuff out? It's simple. Tank in second stage explodes (or
shows pressure readings on the way to explosion). Second stage says
"**** me **** me **** me" and commands "get the **** out of here" and
everyone ****s off. Just how do you think a line gets from the first
stage to the capsule without going through the second stage? I'm
sorry, but I thought even a low grade moron could figure out that such
lines would be implemented in both directions. I apparently
overestimated you.

You may recall that the Shuttle had a number of scrubs due to faulty
connectors.


Which is a good proof by demonstration that rocket designers do NOT do
what you claim.

Are you claiming that SpaceX reproduced the "lots of connectors" which
caused so many problems at launch for the Shuttle? I argued that
designers did not reproduce the SHuttle concept, and then you argue
against my argument, which point to you arguing that they did reproduce
this.


How do you think signals get around? Magic?


You are the one claiming there is a dedicated line with voltage on off
for abort, which means extra connectors in the wiring between each stage.


The connectors and wires already exist.

"Up to 96 additional (48 redundant) commands can be accommodated as a
nonstandard service; please contact SpaceX for details."

From Section 5.2.2 of the FUG, which I told you to read.

No, and the case you cite is the stupidest of all. IF there are
safety concerns about 'load and go', you are certainly not going to
have the crew board while fueling is in progress. If 'load and go' is
a no-go, you would fuel the rocket, board the crew, seal up the
capsule, then arm the abort system.

It was discussed right here when NASA reluctantly agreed to board crew
before fueling for Dragon2 flights.


The way you implied it in your question was certainly NOT discussed
here.


So this was a change in sequence of
events, so I argued that prior to that agreement, SpaceX would have had
to make accomodations for both sequences in its software.


You argued wrong. No 'software' change is required. It's all manual
steps.

Do you know this for sure?


Again, assume the implementers are NOT cretins. Why do you need one?
Why would you design it to be slow?

Not all protocols require an ACK for every packet. You can use Ethernet
group broadcast for telemetry (anyone subscribing to the group gets a
copy of the packets) for instance. There would still be a protocol
within the ethernet packets to format the data, identify the source,
type of data etc. But on the same ethernet, you could also have IP
packets between command computers (point to point) for actual commands).


Again, assume the implementers are NOT cretins.


Remember that you had previously argued there was one wire betwene
sensors and the computer. (which I guess you will now predictably deny).


Only because it's a lie (which is typical of you). What I described
was A SIMPLE EXAMPLE OF WHAT COULD BE DONE TO TRY TO GIVE YOU A
GLIMMER OF A CLUE. Are you really this illiterate, is it your innate
stupidity, or your intellectual dishonesty that leads to you permuting
that into a positive assertion about the actual design?

Do you know **** from Shinola? Just which 'antique military protocol'
are you referring to and just what does it have to do with telemetry?
Lots of these things are done in fairly standard ways because it
works, it's simpler than reinventing the wheel, and it makes safety
certifications easier.

SpaceX got where it is today by ditching old stuff still in use by the
big guys. So it would not surprise me if MIL 1533 was replaced with
something newer to transmit telemetry to the computers. 1533 not
mentiond on the SpaceX user guide document.


Ah, you finally mention what you're talking about by name. Would you
be surprised to learn that 1553 is not slow and is used almost
everywhere in everything that flies? If something faster is needed
Firewire will often be used. But so what? None of this has anything
to do with standard telemetry rates, which are 'standard' because
they're what telemetry recorders and such understand.

Telemetry data is sent from the capsule to the flight computers in the
second stage because those are the guys who control the S Band
transmitters that send the stuff out.

Read the manal again. S Band telemetry transmitters on both stage 1 and
2. Remember both remain alive and controlled separately after they
separate. I would assume Dragon2 has its own as well since it too
eventually is autonomous and wants to transmit telemetry to ground.


For its own telemetry, perhaps. Again you're raising irrelevancies to
the original issue.

The computer can ALWAYS make a better decision than the humans because
"computers are fast". It's a binary choice, edge case or no.

It all depends on the software and how engineers though of every
possible scenario including ones not thought about before.


Then the situation won't be recognized by people, either.


(consider
Apollo 1 where they didn't think of implications of 19 psi of pure O2 in
the capsule to simulate 5psi difference with oustide).


Apples and aardvarks (again). And they DID think of it. They just
accepted the risk.


Consider a case where Stage 1 and 2 think flight is perfectly nominal,
but Dragon2 is unable to maintain cabin pressure. Would all stages have
"manned" software to make the decision to abort based on telemetry from
Dragon2, or would Dragon2 send the Abort command, knowing the stages
below it would have no idea something has gone wrong.


You'd probably ride it out in the suits and land immediately.


This is whyt I am stating that what the engineers designed is somewhat
nmore complex than what you are stating.


Except you have no clue about what engineers do or how engineering
works.


There are many ways to implement this, hence my cuiriosity on which way
they chose.


Yes, there are many ways. Many of them are stupid. Again, start from
the assumption that the implementers are NOT cretins.

Closing helmets was done by the evolution in progress, not by "Oh ****
me oh **** me oh **** me!"

Informing crew of a situation is very important. Consider the case where
had flight computers been more "modern", they might have done a fault
tree analisys and detected that sensors that depend on a wiring bundle
that passes near left wind leading edge are being lost and advised crew
of a progressive failure, including crew on lower deck. That could have
given them enough time to don/close helmets and consider options for
bailing once possible.


Just when do you think it would have been possible?


In the case of Dragon2, I would have to assume that their software will
signal faults from lower stages before those faults result in a
situation where the abort is required (followed by range safety of lower
stages). Consider engines enable to steer sufficiently, it make take a
while before the rocket passes the boundary of nominal vs abort flight
trajectory.


So?


So I would assume that Dragon2 has plenty of telemetry and messages to
crews on performance of each stage below (including its own performance)


Assume what you like. Feel free to sit over there in the corner and
be wrong.

And I repeat again, start from the assumption that the implementers
are NOT cretins. I've given you numerous examples of why "computers
are fast" is actually the answer

The computer ARCHITECTURE is far more important when looking at mission
critical systems. How many are interconnected with same telemetry, if
they all run the same software or different software meant to reach same
conclusions, the voting mechanisms and when happens when one or more
computers are disconnected/fail.


OK, since you like hypothetical situations so much, let's pose one.
You have redundant software, some of which is saying you're ****ed and
some of which is not. The possible choices are enumerated below:

1) A single "we're ****ed" vote triggers abort. This is what sane and
safe systems do. So what does the redundancy and voting buy you other
than complexity and delay?

2) There is actual 'voting', which leads to the following
possibilities:

2a) The "We're ****ed" votes win, you abort, and everyone lives.

2b) The "We're not ****ed" votes win, which leads to the following
possibilities.

2b1) It was a data anomaly and nothing was really wrong, so everybody
lives.

2b2) It wasn't a data anomaly and you really are ****ed and everyone
dies.

That last one is why this sort of system isn't implemented the way you
keep pushing for it to be implemented.


The data paths between sensors, devices and the computers are also
important because they are also mission critical.


And all those things typically are. In Falcon it appears they use
dual redundancy.

pairs") is used to detect actual separation of the payload from the
second stage in the standard payload interface.

This could simply be a "sensor" which then sends a data command on teh
telemetry bus/network to the computer. As opposed to the actual copper
wire with or without voltage traveling all the way to the computers.


Is your English defective? Do you not understand what "breakwire"
means?


--
"Ignorance is preferable to error, and he is less remote from the
truth who believes nothing than he who believes what is wrong."
-- Thomas Jefferson

In article ,
says...

On 2019-07-11 19:12, Fred J. McCall wrote:

I know it's hard for you, but think about it. The booster needs to do
things like decide when to fire the FTS and abort the flight whether
or not there is a Crew Dragon up top or not. A lot of the data and
logic used to do that is in the flight computers in the second stage.

Are you sure about that?

Yes. Because even on an uncrewed flight, the launch vehicle has to
monitor itself to insure it's on the right trajectory. If its not, it
initiates the FTS (flight termination system) in order to make sure that
it doesn't go completely off course which might endanger people who are
outside of the exclusion zone underneath the intended flight path.

Falcon9 not only launches but it also descends and lands, and that
second part is done without second stage. So first stage MUST have
logic in it.

Of course it does. But that does not negate the fact that the second
stage needs to know its trajectory all the way to orbit. So it would
make sense that the second stage computers are the ones to insure
mission success. Landing happens *after* first stage separation. It's
a secondary objective not directly tied to mission success.

It seems more likely to me that each stage has logic, and each stage may
be getting full telemetry from the other.

Why would the first stage ever give a damn about the second stage?

If there is an explosion in
second stage, I would assume first stage needs to know so it can turn
off its engines and either fall into ocean or activate range safety if
required.

It's going to know right away because its going to lose the link to the
second stage and its engines will shutdown. The FTS is present
regardless if this is a crewed mission or not. There really is no
difference between an uncrewed Falcon 9 Block 5 and a crewed Falcon 9
Block 5 except the that payload is different.

(and similarly, Dragon2 would initiate the ejection motors to
get the hell out of there - with stage 2 out, Dragon2 may not be getting
telemetry from Stage1 to tell it to abort so it would need to make its
decision on its own.

We've gone over this what feels like 100 times. The "abort now" wire
going to the capsule that should have a positive voltage during launch
will drop to zero volts. Dragon 2 won't care if that's because it was
actively commanded or because the wire was severed. It simply does not
matter what causes this to happen. The fact is that triggers the abort
regardless. That's how it "fails safe".

You are the one who thinks this is all implemented very simpkly with a
singlewire that has voltage on or off. I am the one who says that surely
the engineers provided for very redundant decission making that is more
likely distributed rather than focused on any one stage's computer(s).

That is because the initiation of an abort really only needs one signal
wire (and a ground as a voltage reference). We've both been telling you
this from the beginning, but you simply won't listen.

Why in the hell would you complicate the system by requiring all
that
data also flow to the capsule and all that logic be duplicated in the
capsule computers when a simple "get the **** out of here" discrete is
adequate to the job? The only reason to spread that kind of work
around is if the computers aren't fast enough (another case of
"computers are fast" being the answer to your question).


Redundancy and disaster tolerance in logic.

KISS. All you need is one abort line. It's voltage is positive when
everything is "a.o.k.". It drops to zero volts to signal an abort.
That drop to zero volts can either be an active command from the launch
vehicle, or it can be due to the wire being severed. It does not matter
what causes the abort wire to drop to zero volts. All that matters is
that is what triggers the capsule to abort.

Sure you could let the capsule monitor telemetry from the launch vehicle
during the flight. But that is *separate* from the abort system.

The User Guide to which you
refer menations how SpaceX built a reducncant fault tolerant computer
architecture. Doesn't mentions simple copper wires to signal And I
would have to assume that NASA wants the crew in capsule to be informed
of what the hell is happening. Especially since the capsule and any
recorders in it is far more likely to be recovered for post accident
forensics.

I mentioned it could be any other sort of connection (optical,
pneumatic, and etc) as you only need two values. The value you'd get by
a severed connection is the one that signals an abort (i.e. the passive
value). That means the launch vehicle is sending the active value,
which means "a.o.k.", otherwise.

Unlikel you, I think the SpaceX folks have thought throught all this and
made the system far mroe redundant than you claim it is, all the while
snip

You just don't get it, do you? Keep your day job. Engineering isn't
for you.

Jeff
--
All opinions posted by me on Usenet News are mine, and mine alone.
These posts do not reflect the opinions of my family, friends,
employer, or any organization that I am a member of.