How is that in any way "vital"? Having people inside doesn't prevent you from using the robot arm berthing system used by the cargo Dragons. It's a planned feature of the manned version, but that has little to do with it being manned.

On the man-rating...the cargo Dragon is actually already man-rated. Once it's up at the ISS, people have to open the door and go inside to unload supplies and load experiments for return to Earth. What it lacks is a launch escape system. Well, and seats.

On the versatility...apart from carrying more cargo and more crew, the Dragon is equipped with heat shielding that can handle return from lunar or Mars trajectories, and for reuse. It's even adaptable for landing on other bodies such as Mars, as in the Red Dragon proposal. It's launcher can operate in single core or three core variants, eventually with varying degrees of core reuse depending on payload/orbit requirements.

So the OP's claim that Soyuz is "much more versatile" is really rather bizarre...

It's entirely possible it actually was recorded in some buoyant piece of hardware, just in case...but it'd probably have been intended to be picked up out of the debris field of a descent failure in fair weather. Where would it have ended up after the storm tore the rocket apart?

They could engineer a ruggedized black box with a tracking beacon and deployment system...but that's a bit much when they've only got a few water landings left, and those are unlikely to happen in storms. I think they were more concerned with making the rocket land itself.

They claim it was successfully able to return to the surface and perform a soft "landing". Which it did...and it did so in thoroughly bad weather, in high winds and on heavy waves instead of solid ground. Their mission objectives were met completely the moment the rocket cut its engine and started tipping over. Actually fishing the thing out of the ocean intact would have been a nice bonus, but it has nothing to do with their actual plans for recovery and reuse...and the only reason it didn't happen is that nobody wanted to attempt it during the storm.

You *do* realize the power output of a rocket engine isn't electrical, right?

In reality, spacecraft have strictly limited power budgets. The booster's electronics are running off battery power from the moment the umbilicals disconnect. It also flew above the bulk of the atmosphere, so you can't exactly rely on air cooling to keep the transmitter from frying itself...and there's plenty of other power-consuming, heat-producing electronics that have rather more important functions. And a more powerful transmitter would be completely unnecessary for the solid-ground landings, which SpaceX hopes to start by the end of the year.

Stronger signals take bigger transmitters with higher power consumption. They don't normally require such a signal: for launch (and eventual solid-ground landings) they have line of sight with big receivers, and when they actually recover a stage, they'll be able to get recordings. The splashdown was below the horizon from the launch site, and the video signal was picked up from a chase plane. To top it all off, weather was lousy and deteriorating fast.

They'll have a lot more launches and landings, another water-landing test is coming up soon. Getting video on an early test that was given a 60-70% chance of failure and wasn't even an actual solid-ground landing was a lower priority than trying to make it succeed.

The DC-X was a small scale experimental vehicle built to demonstrate vertical takeoff and landing under rocket power. It was never able to or intended to fly very high or very fast.

This was the first stage of a Falcon 9 orbital launch vehicle, returning after boosting the second stage and payload, on a launch that actually delivered a payload to the ISS. It's far bigger (the empty Falcon 9 first stage masses about as much as the fully fueled DC-X), far more capable, and it's currently being mass produced. It also uses a cheaper and easier to handle fuel and a more efficient and flexible staged architecture than the SSTO architecture envisioned for the launchers derived from DC-X.

Those boosters were hollow steel tubes, open at the back. Seawater partially flooded them, that's why they popped up. The Falcon 9 first stage is mostly empty tanks that aren't going to flood (barring severe damage from the waves). If held vertical, the weight of the entire stage wouldn't push it down even two meters into the water...its diameter is greater than that. The engines aren't that heavy, half the mass of the vehicle is in those very long tanks...it's going to float very high in the water, on its side.

NASA is paying for Dragon missions to the ISS, not just mass to orbit. They're getting a lot more than the launch: delivery of a Dragon loaded with supplies to the ISS, a brand new man-rated spacecraft that people will be working inside while it's at the ISS, return of more payload to Earth than any other option currently available, and operations in orbit and recovery. And probably also various other expenses and extra work involved in working with NASA and the other ISS partners. Their defense launches are also priced higher for the same reason, working with the DOD involves extra work that the customer demanding it has to pay for.

It doesn't need to brake to a complete stop and then retrace its outgoing path, it needs to bend it's largely-upward trajectory into one that comes back down over the landing site, and manage its velocity so it doesn't go too high and hit the atmosphere too fast on the way back down. As for the difference in separation speed, the flight profile for the reusable flights may very well take a more vertical trajectory during the first stage burn, the first stage taking on more of the gravity losses and going more for altitude rather than speed, and the ratio of propellant loading between the first and second stages may be different for reusable flights...they could oversize both at a minor cost in mass and tweak the ratio to suit the launch, the maximum loading being set by the first stage thrust rather than the total tank capacity.

It got up there while carrying a lot more propellant and a whole second stage. The braking burn uses only 3 engines to limit the acceleration and ends with just enough propellant left to stop it when it reaches the ground. On top of this, it gets passive aerodynamic braking the whole way down.

The mass ratio for the first stage burn, burdened with the second stage and braking propellant, is probably around 4, and a braking burn with equal delta-v would need the same mass ratio, except with no second stage and ending with the rocket empty. The overall first stage mass ratio is around 30, so all else being equal, a return would take around 3/29 = 10% of the propellant on the first stage. But all else is not equal, the returning rocket is mostly empty tanks descending through a thick atmosphere that provides plenty of braking, so the final burn only has to bring it to a halt from terminal velocity, and I omitted the second stage propellant. Overall, 4% sounds quite reasonable.

They're already doing precision landings with the Grasshopper vehicles. The only splashdown landings are going to be tests of the vehicle control, like this one, where the vehicle is not intended to be reused.

"For example, consider a system that is designed completely around events. If one can visualize the inter-connection of components, and one annotates each component with the types of events that it generates (perhaps using expressions), one can easily grasp the overall behavior much more easily than one could if that same design were expressed textually. Thoughts?"

You're making a big assumption that has been contradicted by actual real-world examples. Complexity is hard, and the difficulty has nothing to do with it being in text form. A screen filled with an easy to understand graphical representation is easy to understand because the representation is simple enough to fit on a single screen, not because it's graphical. The systems best able to cope with complexity are textual.

Hardware is also much simpler than software, and it still has bugs. You'll have a hard time finding a complex part that doesn't have an errata sheet. It's also harder and more expensive to debug and test, and typical VHDL makes heavy use of testbenches and simulation to verify individual modules. Conventional software often isn't tested this way. If you want to improve software, encourage adoption of methodologies like unit testing.

You've got a powerful text based language for the actual implementation. Why go to a limited, clumsy graphical program for the high level stuff? "It's simple enough you can do it graphically" isn't a compelling reason. Why do you want to do it graphically? Simple, easy to read diagrams are easy to read because they are simple, not because they are graphical. They have use in education, but need to be kept simple to stay meaningful. The people selling these tools love simple examples. Complex ones look very impressive at a glance and give the illusion of being more comprehensible than a similar view of code, but aren't actually very useful, so the salesmen don't dwell on them for long.

You're just giving yourself headaches when things inevitably grow beyond the limitations of the tools, and you have a huge mess of connected boxes that you have to refactor or rewrite in text format. Not to mention having to wade through reams of near-unreadable machine-generated code when stuff goes wrong, or constantly having to refer to diagrams and models in a separate tool when dealing with the interface between the two.

It's quite true. Logic circuits of any complexity is generally done in a HDL, checked in simulation, and prototyped on FPGAs before being put in silicon. Designs are sold or licensed as Verilog or VHDL. Layout may be manually tweaked graphically (especially for particularly timing-critical things), but that's because the restrictions of a 2D graphical representation closely match the restrictions of a largely 2D integrated circuit.

You can express in a few lines of code what would take pages of gate-level schematics. You can easily parameterize components for reuse. You can separate implementation details from from intent and let the synthesizer find opportunities to reuse logic or adapt implementation details to the situation. You don't have to pore over multi-sheet hierarchal schematics tracing signal lines. And you don't end up finding that stuff that looked connected actually wasn't.

cjonslashdot's comment about symbols was particularly off the mark. Large schematics involve *lots* of named signals. Often actually connecting things with a line would make the schematic hopelessly unreadable, and they actually terminate in a little tag with the signal name, leaving you to hunt for the other end in a haystack of lines and symbols...but it's still an improvement over the impenetrable tangle of lines you'd have otherwise.