-
#1180
by
woods170
on 21 Feb, 2020 20:11
-
Is this old news?
Hard to say. The article says next to nothing. I'm surprised it's enough to get picked up on as "news" for anybody.
Well, the PR tagline for the Commercial Crew program is "American spacecraft launching from America", and now we find out that the Starliner has Russian parts in it, so not 100% American.
Personally I don't see an issue with it, but it can be one of those oddities that doesn't look good if you aren't familiar with how far flung supply chains can be.
Stuff for Starliner comes from over a dozen different countries. Crew Dragon has parts from companies outside the USA as well.
Same for Orion.
There is no such thing as an "all-American" spacecraft. There never has been. Mercury, Gemini, Apollo, Space Shuttle.. they all had parts coming from companies outside the USA.
As such, there is nothing to see here folks. Move along...
-
#1181
by
HeartofGold2030
on 21 Feb, 2020 20:53
-
According to Boeing, the whole Russian parts ‘debacle’ emphasised by Rogozin and some journos is an even bigger non-issue than some of us assumed. I wonder if the decision to use a PCU built by ZAO Orbita was motivated not only by the ISS-proven nature of the tech, but it’s compatibility with the Russian segment’s power-system which was also built by ZAO Orbita?
https://twitter.com/BoeingSpace/status/1230967468769890305
-
#1182
by
Rocket Science
on 22 Feb, 2020 00:05
-
I would only have problems with components being from US adversaries...
-
#1183
by
tyrred
on 22 Feb, 2020 09:55
-
Next thing you know, it will turn out that some of the rare-earth metals used in the manufacturing process of the Russian components were mined in China. Shipped through Iran.
Distractions.
-
#1184
by
erioladastra
on 22 Feb, 2020 15:13
-
Curious how other spacecraft launched from the US such as Cygnus and Dragon (both cargo and unmanned crew test) vehicles make through the described RFI storm, can both berth and dock successfully at ISS... 
Come on Boeing, you're better than this...
Well they didn't suffer anomalies on the way up and so didn't have to try and make use of the TDRS comms perhaps?
That's a genuine question, not a snark
Correct. But Boeing should have better anticipated.
-
#1185
by
erioladastra
on 22 Feb, 2020 15:13
-
There are no AP-101s on Starliner.
Do you know what they are using?
I don't know, but the avionics architecture Boeing developed for GPS satellites is also used for ULA's common avionics suite and SLS, so I wouldn't be surprised if that's also the basis for Starliner.
It's looking like General Dynamics provides the Flight Computers and the System Management Computers
https://gdmissionsystems.com/articles/2019/12/18/featured-story-general-dynamics-supports-starliner-cst-100-space-capsule
The pictures of the computer and transponder look like they have old RS-25 connectors on them. Do they still use this 300 year old technology? I remember soldering cables to these connectors in a GM stamping plant nearly 40 years ago.
No they are not using that but it is proprietary info. But as noted elsewhere GD is providing the computers and they are used on another famous similar spacecraft.
-
#1186
by
SoftwareDude
on 22 Feb, 2020 16:10
-
They base the General Dynamics computers on Intel processors. Intel processors cannot store values into a hard-wired TOD. These processors have only a read-only 66 Mhz tick to keep track of time with. I am back to WTF is a MET?
-
#1187
by
erioladastra
on 22 Feb, 2020 17:23
-
They base the General Dynamics computers on Intel processors. Intel processors cannot store values into a hard-wired TOD. These processors have only a read-only 66 Mhz tick to keep track of time with. I am back to WTF is a MET?
That is MORE than accurate enough. Again, MET is Mission Elapsed Time where zero is liftoff and the ONLY event tied to it was the Orbital insertion burn and if it have been initialized correctly would have been more than accurate enough for the burn.
-
#1188
by
Comga
on 22 Feb, 2020 17:34
-
The OFT Reflight poll above closed yesterday.
The “No” votes had a late resurgence and got back above 4%!
So the vast majority of us here, 96%, think Boeing should be required to fly another OFT.
This might have been a good place for a four way choice of yes or no for “should” and “will”.
I would have qualified my ”should” with a “will not”.
-
#1189
by
Lemurion
on 22 Feb, 2020 18:45
-
The OFT Reflight poll above closed yesterday.
The “No” votes had a late resurgence and got back above 4%!
So the vast majority of us here, 96%, think Boeing should be required to fly another OFT.
This might have been a good place for a four way choice of yes or no for “should” and “will”.
I would have qualified my ”should” with a “will not”.
I think “should but will not” would have won overwhelmingly.
-
#1190
by
joek
on 22 Feb, 2020 19:44
-
They base the General Dynamics computers on Intel processors. Intel processors cannot store values into a hard-wired TOD. These processors have only a read-only 66 Mhz tick to keep track of time with. I am back to WTF is a MET?
Irrelevant. You think those processors do not interface to systems which have the ability to provide a more accurate TOD clock (they generally do)? No idea why you reference a 66Mhz clock--that gives you a time base nominally accurate to ~15us, is internal to the processor-bus, and has little-no relevance or relationship to what happens in the real world (except possibly on a very short term basis). Are you seriously suggesting a higher frequency CPU-time base is required to track events on the ms level? Why?
-
#1191
by
SoftwareDude
on 23 Feb, 2020 01:16
-
They base the General Dynamics computers on Intel processors. Intel processors cannot store values into a hard-wired TOD. These processors have only a read-only 66 Mhz tick to keep track of time with. I am back to WTF is a MET?
Irrelevant. You think those processors do not interface to systems which have the ability to provide a more accurate TOD clock (they generally do)? No idea why you reference a 66Mhz clock--that gives you a time base nominally accurate to ~15us, is internal to the processor-bus, and has little-no relevance or relationship to what happens in the real world (except possibly on a very short term basis). Are you seriously suggesting a higher frequency CPU-time base is required to track events on the ms level? Why?
Why would anyone go to the trouble of doing that?
One tick at 66 mhz = about 15.1515 nanoseconds.
Starting_Time = CurrentTicks();
From here it is a simple matter to calculate any future value you need and to set an interrupt via a HPET chip which costs $1 when ticks exceed a future value with an error of a stored tick count with a resolution of +-100 nanoseconds. This is as good or better as any of the avionics in existing rockets and fighters.
If someone passes in a MET one can simply say it is the starting time and calculate values.
So NET must come as HH:MM:SS:nnn because ticks are never synchronized between processors even in multicore systems.
Back in the old days, one could synchronize across all CPU's in a vehicle because the AP-101 was a hardened IBM 360 with one I/O channel running a modified version of VS/1.
SpaceX does not use hardened chips in the vehicle for the flight computers, they use homegrown equivalent by using 3 x86 Linux systems that vote, each having 3 processors that vote. They have much more computing power. at very little cost.
-
#1192
by
ChrisWilson68
on 23 Feb, 2020 01:24
-
They base the General Dynamics computers on Intel processors. Intel processors cannot store values into a hard-wired TOD. These processors have only a read-only 66 Mhz tick to keep track of time with. I am back to WTF is a MET?
Irrelevant. You think those processors do not interface to systems which have the ability to provide a more accurate TOD clock (they generally do)? No idea why you reference a 66Mhz clock--that gives you a time base nominally accurate to ~15us, is internal to the processor-bus, and has little-no relevance or relationship to what happens in the real world (except possibly on a very short term basis). Are you seriously suggesting a higher frequency CPU-time base is required to track events on the ms level? Why?
Why would anyone go to the trouble of doing that?
One tick at 66 mhz = about 15.1515 nanoseconds.
Starting_Time = CurrentTicks();
From here it is a simple matter to calculate any future value you need and to set an interrupt via a HPET chip which costs $1 when ticks exceed a future value with an error of a stored tick count with a resolution of +-100 nanoseconds. This is as good or better as any of the avionics in existing rockets and fighters.
If someone passes in a MET one can simply say it is the starting time and calculate values.
So NET must come as HH:MM:SS:nnn because ticks are never synchronized between processors even in multicore systems.
Back in the old days, one could synchronize across all CPU's in a vehicle because the AP-101 was a hardened IBM 360 with one I/O channel running a modified version of VS/1.
SpaceX does not use hardened chips in the vehicle for the flight computers, they use homegrown equivalent by using 3 x86 Linux systems that vote, each having 3 processors that vote. They have much more computing power. at very little cost.
It's unclear to me what point you're trying to make, either with your previous post or with this one.
-
#1193
by
SoftwareDude
on 23 Feb, 2020 01:42
-
Where I am going with this is that ULA is doing in software, the equivalent of a mechanical mechanism powered with punched paper tape. It's like a player piano. There might be some different paper tapes for the player piano that astronauts or ground controllers can manually switch between but that's it. The software itself cannot recover from an error.
-
#1194
by
ChrisWilson68
on 23 Feb, 2020 01:45
-
Where I am going with this is that ULA is doing in software, the equivalent of a mechanical mechanism powered with punched paper tape. It's like a player piano. There might be some different paper tapes for the player piano that astronauts or ground controllers can manually switch between but that's it. The software itself cannot recover from an error.
Do you mean ULA or Boeing? ULA built the Atlas V launch vehicle, but it was not involved in the CST-100 spacecraft. That's done by Boeing.
-
#1195
by
joek
on 23 Feb, 2020 02:14
-
Where I am going with this is that ULA is doing in software, the equivalent of a mechanical mechanism powered with punched paper tape. It's like a player piano. There might be some different paper tapes for the player piano that astronauts or ground controllers can manually switch between but that's it. The software itself cannot recover from an error.
Are you seriously suggesting that the software in CST-100 has no conditional logic--that it cannot respond to changing conditions? That would make it impossible for it to perform basic GNC functions (e.g., attitude control, among many other things).[1] What is the basis for such a patently absurd assertion?
[1] Is a control loop intended to maintain a target value responding to "errors"? Yes. Spacecraft, among many other things (cars, airplanes, CNC machines, your oven) all have such control loops.
-
#1196
by
Comga
on 23 Feb, 2020 03:37
-
Where I am going with this is that ULA is doing in software, the equivalent of a mechanical mechanism powered with punched paper tape. It's like a player piano. There might be some different paper tapes for the player piano that astronauts or ground controllers can manually switch between but that's it. The software itself cannot recover from an error.
Are you seriously suggesting that the software in CST-100 has no conditional logic--that it cannot respond to changing conditions? That would make it impossible for it to perform basic GNC functions (e.g., attitude control, among many other things).[1] What is the basis for such a patently absurd assertion?
[1] Is a control loop intended to maintain a target value responding to "errors"? Yes. Spacecraft, among many other things (cars, airplanes, CNC machines, your oven) all have such control loops.
You are putting words in his mouth and creating a strawman argument.
He didn’t say “no conditional logic”.
He just suggested that they didn’t have it where it was needed, that conditions went outside their assumptions without the corresponding logical checks.
And a feedback loop is not the same as error checking.
Verifying that the offsets remain within the limits of the control system IS error checking.
I have no idea how Boeing (yes Boeing) did any of their coding, but we see the visible results. Your arguments in their defense don’t hold water.
-
#1197
by
joek
on 23 Feb, 2020 04:18
-
You are putting words in his mouth and creating a strawman argument.
...
No; again (emphasis added):
Where I am going with this is that ULA is doing in software, the equivalent of a mechanical mechanism powered with punched paper tape. It's like a player piano. There might be some different paper tapes for the player piano that astronauts or ground controllers can manually switch between but that's it. The software itself cannot recover from an error.
And yes, a feedback loop is exactly "error checking": it is intended to bring a system from an off-nominal state to a nominal state. And that is exactly how it referred to: "error", as in "correcting for error". E.g., we should be at position X and we are at position Y--difference is the error. Control loop corrects--or tries to--for that error. Can't correct within specified parameters (e.g., time or available power) or hit a limit switch or whatever? Goes to the next higher level control loop. They are all "errors"; the control loops (emphasis on plural) try and correct for those errors, whatever they may be.
The OP insinuated that
ULA Boeing software is "...like a player piano...", as if it has no sense of and does not vary its behavior: a fixed pre-programmed sequence and does not allow for variation based on external inputs.[1] That is an absurd, ill-informed and inflammatory assertion.
In short, it's all "error checking", just depends on the level-perspective you are viewing the system from.
[1] The last time I worked on anything even close to that was in the late 60''s (Pioneer 10/11), which had little more than a sequencer and extremely limited decision-making-conditional capability. Have not seen anything that primitive since. Heck, by comparison my NEST thermostat has more decision-making capability.
edit: p.s. While there are some portions of the flight that are pre-programmed sequence- or time-driven, the error here was not necessarily in the code, but the external input--in this case the MET clock. Show me one that does not have such a dependence or sequence somewhere in their flight profile and I'll buy you a beer or three. It is the suggestion that CST-100 software is little more than a "player piano" is what sets me off.
-
#1198
by
AJW
on 23 Feb, 2020 17:19
-
The OP insinuated that ULA Boeing software is "...like a player piano...", as if it has no sense of and does not vary its behavior: a fixed pre-programmed sequence and does not allow for variation based on external inputs.[1] That is an absurd, ill-informed and inflammatory assertion.
All indications are that the 'state' that the software had gotten into, alternating thruster firings to the point of both serious damage and depletion of fuel, would have continued unchecked without human intervention and resulted not just in failure to meet the mission objectives, but loss of the Starliner as well. While you are clearly offended by the term "...like a player piano...", I find that the overall behavior of the software stack when in this state met the definition you provided.
From your experience, could you explain why you believe that this unchecked 'state' would not have continued without variation until complete failure? I am assuming that you are not including emergency human intervention on an autonomous craft as one of those 'external inputs'.
-
#1199
by
Kansan52
on 24 Feb, 2020 17:01
-
Nit picking here. It bothers me that everyone is smiles in front of AstroVan II even though the arrow at their feet says the AstroVan II is pointed in the wrong direction.
Come on Boeing, you're better than this...