Mars Rover Shot

"The CO" wrote in message
...

"Tarver Engineering" wrote in message
...

"Emmanuel.Gustin" wrote in message
...
Stephen Harding wrote:

Wasn't the rover about to attack 'an interesting geological
feature' when it failed? So it would be legitimate self-defence,
or at worst a legitimate pre-emptive strike...

A much more likely source of failure is the lack of EEs at NASA, as
outlined
in the Shuttle crash investigation board report. Until the areo mafia
is
rooted out of NASA, there can be no forward movement. Aero's havn't
controlled a successful aerospace company since the 1970s, as it has
been
all EE since then.

Actually, it now appears highly likely that it's a problem with the
FLASH memory management software module.

Perhaps.

The FLASH hardware is apparently ok. In short, it appears to be either a
bug or something corrupted it, such as a high energy particle impact.

I know that JPL would lie, so I can't put much stock into what they say.
There is an identical module on Mars now and in a week you right be able to
make such a case. Right now, any such "cause" is unknowable.

I will give JPL credit for creating something that works at all, which is
something that has been problematic at NASA for some time.

In article , "The CO"
wrote:

"Tarver Engineering" wrote in message
...

"Emmanuel.Gustin" wrote in message
...
Stephen Harding wrote:

Wasn't the rover about to attack 'an interesting geological
feature' when it failed? So it would be legitimate self-defence,
or at worst a legitimate pre-emptive strike...

A much more likely source of failure is the lack of EEs at NASA, as
outlined
in the Shuttle crash investigation board report. Until the areo mafia
is
rooted out of NASA, there can be no forward movement. Aero's havn't
controlled a successful aerospace company since the 1970s, as it has
been all EE since then.

Not all EEs. Hughes Aircraft had an ME at the helm for a good while.

Actually, it now appears highly likely that it's a problem with the
FLASH memory management
software module. The FLASH hardware is apparently ok. In short, it
appears to be either a
bug or something corrupted it, such as a high energy particle impact.

Some EE apparently didn't put in EDAC.

--
Harry Andreas
Engineering raconteur

"Tarver Engineering" wrote in message
...

"The CO" wrote in message
...

"Tarver Engineering" wrote in message
...

"The CO" wrote in message
...

Actually, it now appears highly likely that it's a problem with
the
FLASH memory management software module.

Perhaps.


snip

Today the claim is a "file management" problem, which seems likely.

Yes, the software that manages it is the suspect, as they stated
previously.

The flash memory controller is being reported as being software

Yes. That's probably not the ideal way to do that, possibly they were
considering
the likelihood of an unrecoverable hardware failure due to rad or
thermal impact
as more likely than using software for the task. It's probably that the
software
can be debugged or a new version uploaded from here, even now, however
changing out a dodgy card would not be possible.

and this
would not be the first time some softhead grabbed up all the memory
themselve, so that their program alone would run better.

I get the impression it's an actual bug that has arisen due to something
that was
not tested for rather than a memory or cycle hog.

It would net be
the first time such a thing has happened and a goo reason why memory
management units are usually hardware.

Well, it's certainly one reason.

Politics, funding and the need to protect certain people, are the
standard
reasons why Governemnt Agencies lie.

No doubt, but I was under the impression you had some specific reason to
be suspicious.
They do seem to be being quite candid at the moment. Were you perhaps
being a little
over critical based on your perception?

Software and hardware both seem to be faulty.

Software seems to be the very high probability candidate. I've heard
nothing more
about the teams investigating a possible hardware anomaly (on the motor
board) and
this seems less and less likely to be the case as time goes on.

It is an age old mistake of
developers to use the interupt that halts the processor and there was
a
scientist on TV making the claim that the processor was being
interupted,
right before the 138 reboots.

Quite so, but the interrupt is being software driven. The type of error
you describe
would be rather unlikely given the amount of development. I suspect
it's rather more
obscure than that, I get the feeling this is more likely to be something
that only occurs
during heavy memory workloads.

snip

Right now JPL is hacking the system and deleting old files and no
longer
necessary software and perhaps the robot will come back.

I think it's a little more involved than that.

snip

All we can really know is that the machine is suffering from memory
starvation right now. Some how there is a leak, much like what
happens to a
PC under Windows.

Doesn't seem to be a simple memory leak. If I may use a *very* crude
analogy,
it looks to bear some resemblance to the issue that arises with DOS when
the
root directory has it's maximum of 255 entries.

I respectfully suggest therefore that your statement is indicative
of
strong personal bias not based on
realistic knowledge of the onboard computer system. How much do you
actually know about the effects of
ionised particles/he protons on computer memory, specifically,
FLASH, or
memory diagnostic routines in VxWorks RTOS environments running on a
20Mhz RAD6000 hardened version of the PowerPC chip?

Quite a bit.

Ok. I'll be interested to see the end result of the rover recovery
efforts.

I was mistaken is claiming the two landers are identical, as the
second
robot has some chips that are a generation newer than the broken bot.

Not aware of that. Thank you. Interesting.

snip

JPL's track record may not be perfect, but I suspect that they are
well
in front of whoever is in second
place. (Russia?)

As was pointed out to the Queen at the completion of the first
America's
cup:

"there is no second place"

LOL. I can agree with that.

The US has to go back to the Moon for strategic reasons,

Strategic? What can you do from the moon that you can't do from
LEO (in the military sense)?

otherwise the Chinese will gain a military advantage within a few
years.

Hmm, seems unlikely that it would be either significant or any real
advantage.
They are very much playing catch-up ball here.

Mars is a dead planet

That is yet to be scientifically demonstrated. Make it 'likely to be a
dead planet' and
I might agree.

and probably is not going to be of much interest.

Sorry, can't agree.

I'd like to see JPL send a robot to one of the Moons of Jupiter

ISTR there is a mission of that kind planned.

instead of sending a man to Mars.

How about 'as well as'.

The CO

"The CO" wrote in message
...
I was mistaken is claiming the two landers are identical, as the second
robot has some chips that are a generation newer than the broken bot.

Not aware of that. Thank you. Interesting.

Today JPL validated what I wrote yesturday and they now expect to be able to
have the broken robot completely functional, in a few days.

If JPL does that, I say they are pretty smart.

"Tarver Engineering" wrote in message ...
"Harry Andreas" wrote in message
...
In article , "The CO"
wrote:

"Tarver Engineering" wrote in message
...

"Emmanuel.Gustin" wrote in message
...
Stephen Harding wrote:

Wasn't the rover about to attack 'an interesting geological
feature' when it failed? So it would be legitimate self-defence,
or at worst a legitimate pre-emptive strike...

A much more likely source of failure is the lack of EEs at NASA, as
outlined
in the Shuttle crash investigation board report. Until the areo mafia
is
rooted out of NASA, there can be no forward movement. Aero's havn't
controlled a successful aerospace company since the 1970s, as it has
been all EE since then.

Not all EEs. Hughes Aircraft had an ME at the helm for a good while.

My mistake, you are quite correct. In fact, most MEs can work complex
numbers; while an Aero with a BSAE will be lost. I had an aero come up to
me at Dryden and speak with fascination at the huge difficulty he had
applying complex numbers. From the way he described it, I don't believe he
had ever seen a number written with a "j". before his masters level work.

Actually, it now appears highly likely that it's a problem with the
FLASH memory management
software module. The FLASH hardware is apparently ok. In short, it
appears to be either a
bug or something corrupted it, such as a high energy particle impact.

Some EE apparently didn't put in EDAC.

From the story today it apears JPL used a software MMU. That would make the
most likely cause of the problem some softhead that couldn't get their
program to run without hogging memory. It is a story repeated again and
again in industry.

It is nice to see you posting, Harry.

I have been programming vxWorks for 12 years. There is a basic mmu
that comes with and another that is more traditional that keeps tasks
from clobbering each other. But from the press release, it sounds like
to me exactly the same problem I complained to Wind River 10 years
ago: That all the directory entries are cached in regular dram memory
(on bootup, it rereads all the directory entries into memory). I
believe it was something like 64 bytes per entry. So when a customer
of mine logged 20000 data files, his system ran out of regular memory
because I didn't factor in this possibility. I think I heard they had
to delete 10s of thousands of files - probably freeing a few precious
megs of memory.