Another Lunar Lander Just Hit The Moon Too Hard

schmitt trigger

Joined Jul 12, 2010
2,165
These landing failures, provides an additional awe and appreciation for the 1960’s Soviet Luna 9 and American Surveyor 1, which succeeded with an infinitely inferior technology.
 

crutschow

Joined Mar 14, 2008
38,625
These landing failures, provides an additional awe and appreciation for the 1960’s Soviet Luna 9 and American Surveyor 1, which succeeded with an infinitely inferior technology.
There's something to be said for the reliability of simplicity.

We sent a man to the Moon with 4kB of RAM and 72kB of ROM ,16-Bits each, with a cycle type of 11.72µs, likely much less processing power than a microwave oven has now.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
16,405
These landing failures, provides an additional awe and appreciation for the 1960’s Soviet Luna 9 and American Surveyor 1, which succeeded with an infinitely inferior technology.
To me, it likely shows how fragile software/hardware is under stress when likely designed and written by modern application standards by people that likely specialize in designing and writing systems to specification. There is a lot of likely there but when it happens so many times (Boeing Max, etc... ) you begin to lose count, IMO, it's not a coincidence that failure happened due to critical sensor failures, at critical times, with responses to the failure that were IMO stupid physically using the science of energy, mass and space but seemed valid or at least plausible in the software. The people back them knew it was inferior technology compared with the science (that hasn't changed since the 1960's) and built things with the knowledge that 'stuff' happens. IMO the issues begin early with the design specification (trying to do something on the cheap that can't be done on the cheap) for these types of system with lots of words for what they want, but a lack of attention to detail of what can go wrong, at the worst possible time.

Yes, awe and appreciation for what they could do with a lot less.
 
Last edited:

schmitt trigger

Joined Jul 12, 2010
2,165
To me at least, the pinnacle of space achievement are the Voyager twin spacecraft.

Voyager 1 in particular, not only ended its primary planetary mission of 3+ years with extreme success, but it has continued into deep space, beyond the heliosphere, and continues to work, although at a diminished capacity, almost 48 years after its launch.

Does anyone know the type of processor it uses?
 

BobTPH

Joined Jun 5, 2013
11,601
I wonder how much it has to do with programmers writing software instead of engineers.
When I was working at Digital, they built a team to do their first cpu chip design. They started them with a semiconductor (chip) design course, pulling people from both hardware and software backgrounds. They found that the ones with hardware background could not hack it because they could not handle the complexity like the software people could. The architect chosen to design the Alpha chip was a software engineer I had worked with on a programming language project.

So, perhaps, you have it backwards.

This was a superscalar design, the first of its kind. Not simple.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
16,405
When I was working at Digital, they built a team to do their first cpu chip design. They started them with a semiconductor (chip) design course, pulling people from both hardware and software backgrounds. They found that the ones with hardware background could not hack it because they could not handle the complexity like the software people could. The architect chosen to design the Alpha chip was a software engineer I had worked with on a programming language project.

So, perhaps, you have it backwards.

This was a superscalar design, the first of its kind. Not simple.
Nope, there a big difference when dealing with the real world of physical interfaces. It's not things that are complicated that is the issue, it is complexity but not of a mathematical sort. I can tell in an instant where something have been designed primarily by physicist and software people. They tend to put far too much trust in things going right (pneumatic operated valves without positive position feedback and such nonsense like , we just have a vacuum error, like shutdown the pumps and release gas in to Mag-Lev turbo pump spinning at 30K rpm), with handling failure modes often being an afterthought. The software people think they handle the complexity of a non-deterministic universe but most of the records of failure like this moon lander, show otherwise.

The architect is a designer of the abstract plan, that takes a different sort of smart, not a hands on builder or hardware engineer or embedded software guy that deals with reality, where playing smart with the universe makes things blowup.
1749413084038.png

This is a very common misconception from otherwise smart software people to think the HW guys can't handle software complexity, we just don't like it because it's boring and are willing to pawn the job to others that lack what we have.
 
Last edited:

WBahn

Joined Mar 31, 2012
33,046
Interesting how we seem to have had fewer failures landing on Mars, than the Moon.
That's a direct reflection of the number of attempts made on each.

There have been about 60 soft landing attempts on the Moon, but only about 20 on Mars. In each case, right at 50% have failed.

Today, NASA missions to Mars have a pretty high success rate because they are using proven technology and techniques borne out from previously higher failure rates. Most crashes are from countries and space programs that are new to the game. The same is true for Mars, there are simply a lot of new players trying to land things on the Moon, and they are going through the same growing pains that the folks that have it down went through.
 

SamR

Joined Mar 19, 2019
5,516
The waters near Cape Canaveral were littered with failures way back when. When the shrimp trawlers returned to the local docks NASA was waiting on them money in hand to see what they had drug up for failure assessments. NASA paid for a lot of damaged nets, so it soothed a lot of anger and resentment of the trawler fleet over the trash NASA was putting on their trawler grounds and damaging their trawl nets.
 
Last edited:
Re the HW / SW debate..
They are very different environments.
Not least.
If sw is found wrong , it can be patched ..if the patch adds a few extra cycles / time to the routine , generally none cares .
If HW is wrong , ok an FPGA could probly be fixed, but in space the general rule is to use OTP parts .
But in HW logic , you can't generally just add clock delays ,
Also remember , in HW , everything is a parallel process , thousands of them on a chip. Look at how hard it is to get even 4 cores of a cpu to work together, the SW tools / theories just don't work in HW.
 
Nope, there a big difference when dealing with the real world of physical interfaces. It's not things that are complicated that is the issue, it is complexity but not of a mathematical sort. I can tell in an instant where something have been designed primarily by physicist and software people. They tend to put far too much trust in things going right (pneumatic operated valves without positive position feedback and such nonsense like , we just have a vacuum error, like shutdown the pumps and release gas in to Mag-Lev turbo pump spinning at 30K rpm), with handling failure modes often being an afterthought. The software people think they handle the complexity of a non-deterministic universe but most of the records of failure like this moon lander, show otherwise.

The architect is a designer of the abstract plan, that takes a different sort of smart, not a hands on builder or hardware engineer or embedded software guy that deals with reality, where playing smart with the universe makes things blowup.
View attachment 350733

This is a very common misconception from otherwise smart software people to think the HW guys can't handle software complexity, we just don't like it because it's boring and are willing to pawn the job to others that lack what we have.
Why would you expect a computer programmer to design and build a "pneumatic operated valves without positive position feedback"?

That's an electro-mechanical design task.

Software and hardware are different domains, not directly comparable. One isn't "better" than the other, hardware specialists are not "cleverer" than software specialists, this is silly, everybody is different.
 
Last edited:
Top