SpaceX COTS Demo 2 Updates

[ugordan]

All this talk about resets and reboots is fine and dandy for on orbit but not for ascent

That's what FTINU is for. Failing that, that's what FTS is for.




Yes, it's a joke.

[baldusi]

Rad-Hard computers are PowerPC. They have non RH but same architecture, and probably fully ECC protected. The FPGA is probably the voting logic. And they have triple redundant system (so triple triple). I don't see this as such a huge problem. Specially in LEO. I guess the safe way would be to take a couple of weeks in orbit and watch if there are any issues attributable to this (non recurring reboots or out votes), and how it actually affects the working of the Dragon. If there are very little and all handled gracefully , then no problem.
And I can't see how the frequency of a short range radio can be such a problem. Worst case, switch the frequency!
Of course SpaceX is doing less testing than the ATV. They are trying to make it as cheaply as possible.

[Jim]

And I can't see how the frequency of a short range radio can be such a problem. Worst case, switch the frequency!
Of course SpaceX is doing less testing than the ATV. They are trying to make it as cheaply as possible.

Stop the presses!  We have a solution!   How could we have overlooked this easy solution?  We must be dolts. 

Maybe the frequency can't be changed because it is hardwired into the ISS.  Maybe it is the same frequency used by the EMU's, HTV, and Cygnus and all these would have to be changed too?

[baldusi]

And I can't see how the frequency of a short range radio can be such a problem. Worst case, switch the frequency!
Of course SpaceX is doing less testing than the ATV. They are trying to make it as cheaply as possible.

Stop the presses!  We have a solution!   How could we have overlooked this easy solution?  We must be dolts. 

Maybe the frequency can't be changed because it is hardwired into the ISS.  Maybe it is the same frequency used by the EMU's, HTV, and Cygnus and all these would have to be changed too?

May be, just may be, it's a technical review problem that shows a flawed process, but to put it as a showstopper is really ridiculous? And may be I meant that it was SpaceX problem to find a frequency that was both compatible with ISS (and the rest of the spacecrafts).

[NotGncDude]

All this talk about resets and reboots is fine and dandy for on orbit but not for ascent

1-Hence the 2 out of 3 voting fault tolerance. A non-issue really
2-(#1 makes this point moot but...) Rad hardening is not terribly necessary for ascent for obvious reasons, and you know it.

[Jim]

 And may be I meant that it was SpaceX problem to find a frequency that was both compatible with ISS (and the rest of the spacecrafts).

No, that is not the solution.  The transmitters are fixed on all those other vehicles

[Jim]

Rad hardening is not terribly necessary for ascent for obvious reasons, and you know it.

Then why is solar flux level a launch constraint for some vehicles and is part of the LRR and FRR weather briefs?  Obviously, you don't know the reasons. 

[NotGncDude]

Rad-Hard computers are PowerPC. They have non RH but same architecture, and probably fully ECC protected. The FPGA is probably the voting logic. And they have triple redundant system (so triple triple).

Sorry to nitpick here but you're generalizing stuff that shouldn't be generalized and that you don't know.

1-There are some rad-hard computers that are not PowerPc. There's nothing special about the architecture, it's not related

2-How can you speculate that the FPGA is probably the voting logic? You don't know that *at all* (I *said* PowerPC core inside an FPGA) then continue as if what you speculated were the true.

[NotGncDude]

Rad hardening is not terribly necessary for ascent for obvious reasons, and you know it.

Then why is solar flux level a launch constraint for some vehicles and is part of the LRR and FRR weather briefs?  Obviously, you don't know the reasons. 

Hehe. That's funny.

I said not terribly necessary. The probability of an upset is negligible compared to an orbital application, but it's there and depends on solar flux, duh. Besides, you just said it, for "some" vehicles. Maybe those vehicles don't have radiation hardened CPUs?

[Jim]

I said not terribly necessary. The probability of an upset is negligible compared to an orbital application, but it's there and depends on solar flux, duh. Besides, you just said it, for "some" vehicles. Maybe those vehicles don't have radiation hardened CPUs?

Launch vehicles, which was my point about resets, don't have hardened CPUs,

[mmeijeri]

Launch vehicles, which the topic of discussion, don't have hardened CPUs,

Interesting, why not?

[baldusi]

Rad-Hard computers are PowerPC. They have non RH but same architecture, and probably fully ECC protected. The FPGA is probably the voting logic. And they have triple redundant system (so triple triple).

Sorry to nitpick here but you're generalizing stuff that shouldn't be generalized and that you don't know.

1-There are some rad-hard computers that are not PowerPc. There's nothing special about the architecture, it's not related

Of course I speculated. I though I made that clear in the first three sentences. If I actually knew the intricacies somebody should probably have serious problems under ITAR.
But PowerPC is probably within the top of performance in commercial rad boards that I know of. Clearly WindRiver runs into the RAD750. And it's got a very robust development kit. But yes, pure speculation.

2-How can you speculate that the FPGA is probably the voting logic? You don't know that *at all* (I *said* PowerPC core inside an FPGA) then continue as if what you speculated were the true.

As I said, I speculated. If you want the reasoning, is very simple. The rad hard process is incredible expensive. But many rad hard FPGA are available. A voting logic for an embedded system would probably be very, but very low scale. And very tricky to get right. I'm sure it would be developed in an FPGA. I would be extremely surprised if it weren't an FPGA also in the final design even if an ASIC was available to whoever developed the board.
In particular, if you could make a couple of firmware that are logical equal but use different zones of the FPGA, you could try to load a different firmware in the event of a faulty chip. All highly speculative, of course.

[sitharus]

Rad-Hard computers are PowerPC. They have non RH but same architecture, and probably fully ECC protected. The FPGA is probably the voting logic. And they have triple redundant system (so triple triple).

Sorry to nitpick here but you're generalizing stuff that shouldn't be generalized and that you don't know.

1-There are some rad-hard computers that are not PowerPc. There's nothing special about the architecture, it's not related

2-How can you speculate that the FPGA is probably the voting logic? You don't know that *at all* (I *said* PowerPC core inside an FPGA) then continue as if what you speculated were the true.

Both PowerPC and ARM are licensed IP cores, not off the shelf dies. They come in many different editions with different features, so rad hardening, ECC, FPGA addons and all the fancy bits are up to the manufacturer's integration engineers.

[Nomadd]

Launch vehicles, which the topic of discussion, don't have hardened CPUs,

Interesting, why not?

 They only have to survive a few minutes. Radiation damage or a circuit getting flipped are events that occur mostly at random. If you're up a year, you better have hardened or great redundancy. Five or ten minutes probably isn't much to worry about.

[Antares]

How could the Station-to-Dragon comm frequency (and power) issue crop up only now? Was it believed before that it'd be fine, but now some bureaucrat is making a fuss of it, or is this a real oversight by NASA and/or SpaceX?

Like the FAA licensing and range approval that delayed the first F9 launch, my educated guess says this is something SpaceX said would be okay even though working levels of NASA were telling them it needed to be fixed/worked.  Now that the verifications for going to ISS are moving toward needing to be closed very soon, the fact that it's open without a clear path to closure is getting increased attention up the management chain.  When a technical item gets to Gerst's level, it's a pretty big concern - probably in the realm of schedule.

[spacetraveler]

It's looking more and more like if the mission is combined that SpaceX will not fly anything in 2011.

[mr. mark]

Fine with me, I'd rather have a combined COTS mission in early 2012 Jan. Feb. than 2 rushed COTS missions over the same time frame. Better, if combined to get it right. No one likes to wait but in the meantime we can get excited about the first Taurus 2 launch in Fall/Winter.

[Namechange User]

Fine with me, I'd rather have a combined COTS mission in early 2012 Jan. Feb. than 2 rushed COTS missions over the same time frame. Better, if combined to get it right. No one likes to wait but in the meantime we can get excited about the first Taurus 2 launch in Fall/Winter.

Tick tock, tick tock....but in the meantime, it is imperative we rid the world of everything that exists within US inventory now that can service ISS. 

How long can "we" remain "excited" when ISS is in the danger zone and still expect all the things that are within the popular knowledge-base to come to pass and come to pass so that they have a real, meaningful impact on the future?

That's the problem that is ignored by so many.

[tigerade]

It's looking more and more like if the mission is combined that SpaceX will not fly anything in 2011.

Yeah, but wasn't there an article out a few months saying that NASA would have to decrew the ISS if there wasn't a cargo flight this year?

[Jorge]

It's looking more and more like if the mission is combined that SpaceX will not fly anything in 2011.

Yeah, but wasn't there an article out a few months saying that NASA would have to decrew the ISS if there wasn't a cargo flight this year?

If there was such an article, it was incorrect. But I don't think there was. I recall it being more like if there is no cargo flight this year *and* STS-135 doesn't happen, ISS *might* need a reduction in crew size.