SpaceX News

GIThruster · Post by **GIThruster** » Sat Dec 01, 2012 11:14 pm

Excellent answer. Now if I may press just a little further, does this same process of ongoing coding happen with things like robotic probes? For instance, does anyone know if any sort of updates are sent to Mars Science Lab, and if so, does this require a higher energy consumption than the simple directions given Curiosity? When one plans to design a probe, is there a requirement for ongoing code updates or is that unnecessary?

paperburn1 · Post by **paperburn1** » Sat Dec 01, 2012 11:21 pm

GIThruster wrote:Excellent answer. Now if I may press just a little further, does this same process of ongoing coding happen with things like robotic probes? For instance, does anyone know if any sort of updates are sent to Mars Science Lab, and if so, does this require a higher energy consumption than the simple directions given Curiosity? When one plans to design a probe, is there a requirement for ongoing code updates or is that unnecessary?

code updates can happen as well as repurposing hardware. FPG are used. and it does require more power but i am not sure how much. Or how often.

ScottL · Post by **ScottL** » Sat Dec 01, 2012 11:31 pm

paperburn1 wrote:
GIThruster wrote:Excellent answer. Now if I may press just a little further, does this same process of ongoing coding happen with things like robotic probes? For instance, does anyone know if any sort of updates are sent to Mars Science Lab, and if so, does this require a higher energy consumption than the simple directions given Curiosity? When one plans to design a probe, is there a requirement for ongoing code updates or is that unnecessary?
code updates can happen as well as repurposing hardware. FPG are used. and it does require more power but i am not sure how much. Or how often.

Agreed. To further answer, it's pretty standard practice for firmware updates as well as repurposing instruments if possible. Any firmware update is going to require a reboot which in turn requires all boot tests...etc. Short answer yes and yes.

DeltaV · Post by **DeltaV** » Sun Dec 02, 2012 6:39 pm

NASA JPL is famous for modifying flight and planetary operations software 'on the go' for several probes and missions. Just one example is Galileo after the dish antenna deployment failure. There are numerous other examples.

Being able to upload new software over interplanetary distances to compensate for failures ranks among JPL's greatest accomplishments. The modified software is thoroughly tested on earth using simulations before upload. JPL designs-in such remote reconfigurability from the start because of the distances involved.

In a few cases, the failure happens at a point in the mission where nothing more can be done, such as the Metric vs. Imperial units error which caused the loss of Mars Climate Orbiter. In that case it was an error in the earth-based trajectory modeling software (actually a data file) used to determine thrust for course corrections.

Something all complex, real-time, mission-critical system projects need to do, and usually don't, is to design into their processors, I/O paths and real-time software the ability to access internal signals easily, for testing purposes ('design for testability'), in a way that does not greatly affect normal operation. This capability is absolutely vital for exhaustive testing of complex systems. The complexity limits have been reached if this is not done in the future. Possible exceptions to this need would be intrinsically-obfuscated paradigms such as quantum or neural algorithms. I'm talking here about traditional algorithms.

The old excuses for not doing this, 'not enough processing power, not enough memory and not enough bandwidth', are no longer valid with modern electronics. Knowing what is actually going on with internal signals is far, far better than playing guessing games based on the relatively few signals leading into or out of a processor or control module.

Skipjack · Post by **Skipjack** » Tue Dec 25, 2012 10:46 am

New Grasshopper flight. 12 stories high. Looks awesome!
With two awesome videos in the link.
http://www.newspacewatch.com/articles/s ... light.html

http://www.newspacewatch.com/articles/m ... light.html

ladajo · Post by **ladajo** » Wed Dec 26, 2012 1:53 pm

You have to wonder what the cross wind stability limts are.
Very cool none-the-less.

Skipjack · Post by **Skipjack** » Wed Dec 26, 2012 4:31 pm

ladajo wrote:You have to wonder what the cross wind stability limts are.
Very cool none-the-less.

There seems to have been at least some cross wind. The rocket can be seen leaning into the wind.

ladajo · Post by **ladajo** » Wed Dec 26, 2012 5:06 pm

I wonder how stable it will be once its gets up away from the ground and encounters stronger wind effects. Obviously some velocity imparts some measure of stability, but you have to slow down somewhere...

Skipjack · Post by **Skipjack** » Wed Dec 26, 2012 10:57 pm

ladajo wrote:I wonder how stable it will be once its gets up away from the ground and encounters stronger wind effects. Obviously some velocity imparts some measure of stability, but you have to slow down somewhere...

Well, one can always look at the DC-x for reference on that. It was pretty good at that.

DeltaV · Post by **DeltaV** » Tue Jan 15, 2013 6:48 pm

Once you get to 10’s of MLOC, you’d better not be using something like C++ or C, because you’ll NEVER, EVER close all the bugs. NEVER. Every C++ system I know of at that size ships with known bugs that they haven’t found yet. Dozens to hundreds of known bugs will be shipped.
...
Anyway, due to lack of newbie engineers trained in something other than C/C++, the F-35 systems are written in C/C++, last I looked. This is one of the reasons why I think we should just kill it now.

C++ in large systems leads to bugs that are hard to replicate, hard to find and a need for lots of static code analysis to try to find the bugs in the source. Seen it many times in industry. C++ is a horrible implementation language unless you literally disable many so-called “features” in the language to preclude them ever being used.

Pentagon lowers F-35 performance bar

Perhaps in worst shape is the F-35's software. According to the report, even the initial Block 1 software package is not complete, some 20% remains to be delivered and flight tested. An initial version of the more advanced, but still not combat capable, Block 2A software was delivered four months late to flight test. "In eight subsequent versions released to flight test, only a limited portion of the full, planned Block 2A capability (less than 50 percent) became available and delivered to production," the report reads. "The program made virtually no progress in the development, integration, and laboratory testing of any software beyond 2B. Block 3i software, required for delivery of Lot 6 aircraft and hosted on an upgraded processor, has lagged in integration and laboratory testing."

Skipjack · Post by **Skipjack** » Tue Jan 15, 2013 7:08 pm

Interesting article about the Tom Mueller, the father of the Merlin rocket engine series that powers the Falcon boosters:
http://tuts.pinehead.tv/2013/01/14/unde ... in-engine/

303 · Post by **303** » Sat Jan 19, 2013 5:49 pm

well its highly unlikely that c++ is used in a fighter plane, since its not suited to parallel tasks and/or time-critical applications, this is an area where ADA was king back in the day... i dont know what, if anything, replaced it

DeltaV · Post by **DeltaV** » Sat Jan 19, 2013 6:48 pm

303 wrote:well its highly unlikely that c++ is used in a fighter plane, since its not suited to parallel tasks and/or time-critical applications, this is an area where ADA was king back in the day... i dont know what, if anything, replaced it

JOINT STRIKE FIGHTER
AIR VEHICLE
C++ CODING STANDARDS
FOR THE SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAM
Document Number 2RDU00001 Rev C
December 2005

ScottL · Post by **ScottL** » Sat Jan 19, 2013 7:06 pm

303 wrote:well its highly unlikely that c++ is used in a fighter plane, since its not suited to parallel tasks and/or time-critical applications, this is an area where ADA was king back in the day... i dont know what, if anything, replaced it

I don't believe this statement is correct. C++ has supported multithreading for decades, but then again, almost all languages do now. I'm pretty sure you could code the whole thing in C# or Java if you so choose, although I definitely have my preferences when it comes to certain performance metrics.

hanelyp · Post by **hanelyp** » Sun Jan 20, 2013 2:34 am

C++ is most certainly capable of parallel tasks and/or time-critical applications. The approach you take doing them depends on whether you have an operating system under your application or are programming on bare metal. If you're dealing with millions of lines of code, better hope you have an operating system and task spaces to keep bugs isolated.

The one major liability of the language is the need to directly attend to numerous details that some other languages do for you, making it easy to shoot yourself in the foot if you get sloppy. This is also the languages greatest strength. A skilled programmer may know better when a resource can be released. And details done for you, out of sight and mind, can knife you in the back.