Reports growing over the last couple of days seem to highlight an embarrassing coding error for Boeing, that I can't work out how it got through the test program. A space mission has essentially 2 mission elapsed times - one fro liftoff, and another from an arbitrary time before that - often power-up of the rocket. This is because both the launcher and payload will have various scheduled tasks to do in some order prior to liftoff, and in the case of a crew capsule such as this, that could include abort events. It seems that from the moment that Starliner separated from the Cygnus upper stage, it took the 11+ hours mission elapsed time since rocket power-up, in place of the few minutes mission elapsed time since liftoff. This meant that the Starliner got very confused about where it was, its attitude, and various other things It burned Reaction Control thrusters to try to fix the attitude and orbit, but without doing its scheduled orbital circularistion main engine burn. This meant that the antenna was wrongly oriented to get the correct commands from Mission Control to rectify the missed circularisation burn until it was too late to synchronise with the ISS. It also meant that the RCS thrusters burned waaaay harder than they were ever designed for- short pulses versus seconds long blasts - so those got very robustly tested this mission at least.
They could have still rendezvoused with the ISS in a couple of weeks, but the spacecraft by then would possibly be running short of other consumables. I suspect the main reason for the rendezvous being called off was that ISS control wouldn't let a vehicle inside into its proximity that had recently exhibited such a fundamental programming error, at least without crew aboard who could take control if things went awry. Memories are still vivid of Mir nearly getting killed when a docking Progress supply vehicle collided with it.
What I can't figure out, is how such a fundamental issue wasn't found in testing. When you design and certify an airliner, you build an "Iron Bird" frame, which places all the flight hardware from sensors, to actuators, wires and computers in approximately their authentic positions relative to each other, and with authentic cable lengths etc. Then you subject it to myriad of tests from simulated flights and emergency events, sensor inputs, glitches etc and see how it behaves. There is no reason why you can't do this with a launch stack & its capsule's systems, and if they did I can't fathom how this issue didn't manifest in the flight simulations done with the Iron Bird.
jimbob wrote: ↑Tue Dec 24, 2019 6:02 pm
It seems to have had long missions for something that's just a test vehicle
It is more that there aren't very many offensive or surveillance capabilities that require you to get your hardware back - at least not in a time-frame measured longer than hours or days. The payload bay isn't big enough to contain a telescope as you'll find on an optical surveillance satellite. You could have EM sniffing equipment, but you don't really need that back either after its job is done. For context, Hubble is believed by analyists to be very closely related to the US Keyhole surveillance satellites of its day, it came from the same design house and had similar optics sizes, and filled up the entire Space Shuttle payload bay.
What the X-37 does give you is the ability to launch devellopment hardware, put it through much more accurate tests simulating mission environments and scenarios for long duration than is possible on the ground, then get it back to analyse. It can also release objects to interact with - make approaches with "satellite killer" hardware, grapplers, potentially directed energy weapons etc. This last bit was hinted at in the press release after the most recent X-37 flight which referenced releasing a number of cube sats - which had conspicuously not been added to the database of orbital objects that the US maintains. The speculation was that the cube sats never separated far from the X-37, and were probably recovered again after tests were complete.