Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life. http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
l8r, Mike N. Christoff
Jul 17 '05
198  17478 
"Rick Osborn" <ri************@yahoo.com> wrote in message <news:27**************************@posting.google. com>... I think they should turn it off and turn it on again.
They need to reinstall Winblows...
--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote: Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote: Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
"This behavior is by design."
--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
"This behavior is by design."
--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Tony Hill" <hi*************@yahoo.ca> wrote in message <news:3d******************************@news.1usene t.com>... On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote:Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Tony Hill" <hi*************@yahoo.ca> wrote in message <news:3d******************************@news.1usene t.com>... On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote:Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Joe "Nuke Me Xemu" Foster wrote: "Tony Hill" <hi*************@yahoo.ca> wrote in message <news:3d******************************@news.1usene t.com>...
On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote:
Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Maybe they should have used java....
Run the system through junit...
Engineers struggled to diagnose what was wrong with the rover. Among the
possible causes: a corruption of its software or computer memory.
Spirit is one-half of an $820 million mission. Its twin, Opportunity, is
expected to land on Mars late Saturday. The twin rovers are supposed to
examine the Red Planet's dry rocks and soil for evidence that it was
once wetter and more hospitable to life.
java.lang.RoverException(line: 10,345)
Dope?
Joe "Nuke Me Xemu" Foster wrote: "Tony Hill" <hi*************@yahoo.ca> wrote in message <news:3d******************************@news.1usene t.com>...
On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"
<cr*****@rogers.remove.com> wrote:
Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.
The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Maybe they should have used java....
Run the system through junit...
Engineers struggled to diagnose what was wrong with the rover. Among the
possible causes: a corruption of its software or computer memory.
Spirit is one-half of an $820 million mission. Its twin, Opportunity, is
expected to land on Mars late Saturday. The twin rovers are supposed to
examine the Red Planet's dry rocks and soil for evidence that it was
once wetter and more hospitable to life.
java.lang.RoverException(line: 10,345)
Dope? ri************@yahoo.com (Rick Osborn) writes: I think they should turn it off and turn it on again.
It may be a bit hard to reach the on/off switch.
If I was to make such a vehicle, I woul dmake sure to allow it to be
rebooted by remote control even when the computer is in some undefined
state, e.g., by having a simple circuit listening to the incoming
signals and when a specific sequence occurs, reboot the main computer.
Torben ri************@yahoo.com (Rick Osborn) writes: I think they should turn it off and turn it on again.
It may be a bit hard to reach the on/off switch.
If I was to make such a vehicle, I woul dmake sure to allow it to be
rebooted by remote control even when the computer is in some undefined
state, e.g., by having a simple circuit listening to the incoming
signals and when a specific sequence occurs, reboot the main computer.
Torben
"Joe \"Nuke Me Xemu\" Foster" <jo*@bftsi0.UUCP> wrote in message news:<10***************@news-1.nethere.net>... "Rick Osborn" <ri************@yahoo.com> wrote in message <news:27**************************@posting.google. com>...
I think they should turn it off and turn it on again.
They need to reinstall Winblows...
or WhimClose
"Joe \"Nuke Me Xemu\" Foster" <jo*@bftsi0.UUCP> wrote in message news:<10***************@news-1.nethere.net>... "Rick Osborn" <ri************@yahoo.com> wrote in message <news:27**************************@posting.google. com>...
I think they should turn it off and turn it on again.
They need to reinstall Winblows...
or WhimClose
> LOL - love that one Joe, I'll have to add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..
* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)
you write it wrong:
MicrobaStard is right!
--
____________ http://reader.imagero.com the best java image reader.
> LOL - love that one Joe, I'll have to add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..
* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)
you write it wrong:
MicrobaStard is right!
--
____________ http://reader.imagero.com the best java image reader.
Randy Howard wrote: Keep in mind that ALL aircraft land with flaps.
That's simply not true.
You're right, of course. I had in mind the big commercial jets
when I was comparing the landing speed of 747s with others of the
same general class.
...accomplished pilots practice flapless landings in
case of a system failure.
Absolutely.
--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Randy Howard wrote: Keep in mind that ALL aircraft land with flaps.
That's simply not true.
You're right, of course. I had in mind the big commercial jets
when I was comparing the landing speed of 747s with others of the
same general class.
...accomplished pilots practice flapless landings in
case of a system failure.
Absolutely.
--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
On Thu, 22 Jan 2004 17:24:19 -0800, Uncle Al <Un******@hate.spam.net>
wrote: "Michael N. Christoff" wrote:
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
Since they're getting good signal, but meaningless data, the antenna
is not likely to be the problem, is it?
Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."
One presumes the same engineering glitch is in the other rover.
I wouldn't "presume" anything without considerably more data.
Actually, I would - I presume that NASA has people working on the
problem that are at least as competent as you are ;-)
--
Al Balmer
Balmer Consulting re************************@att.net
On Thu, 22 Jan 2004 17:24:19 -0800, Uncle Al <Un******@hate.spam.net>
wrote: "Michael N. Christoff" wrote:
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
Since they're getting good signal, but meaningless data, the antenna
is not likely to be the problem, is it?
Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."
One presumes the same engineering glitch is in the other rover.
I wouldn't "presume" anything without considerably more data.
Actually, I would - I presume that NASA has people working on the
problem that are at least as competent as you are ;-)
--
Al Balmer
Balmer Consulting re************************@att.net
"ak"
...
| > Windoze and MicroBastard ..
...
| MicrobaStard is right!
LOL! Yep, that fits ;-)
"ak"
...
| > Windoze and MicroBastard ..
...
| MicrobaStard is right!
LOL! Yep, that fits ;-)
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<6b********************@news20.bellglobal.com >... Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it.
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life."
Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.
Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.
Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.
Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."
The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Rant complete! ... -.-
Harry C.
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<6b********************@news20.bellglobal.com >... Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it.
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life."
Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.
Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.
Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.
Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."
The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Rant complete! ... -.-
Harry C.
In article <av********************@news20.bellglobal.com>, mc********@sympatico.caREMOVETHIS says... Thanks to Mickey Segal for this link
NASA Makes Contact With Mars Rover
http://news4colorado.com/nationworld...023135646.html
Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
--
Randy Howard
2reply remove FOOBAR
In article <av********************@news20.bellglobal.com>, mc********@sympatico.caREMOVETHIS says... Thanks to Mickey Segal for this link
NASA Makes Contact With Mars Rover
http://news4colorado.com/nationworld...023135646.html
Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
--
Randy Howard
2reply remove FOOBAR
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<6b********************@news20.bellglobal.com >... > Java is certainly not a member of this tight-knit
> club of system implementation languages, and I simply cannot picture
> anyone even attempting to implement a real-time OS using it.
>
As I mentioned, you would not implement the OS in Java, but would
implement a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that
rolled onto the planet's surface on Thursday in search of signs of water and
life."
Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.
Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.
Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.
Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."
The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Rant complete! ... -.-
Harry C.
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<6b********************@news20.bellglobal.com >... > Java is certainly not a member of this tight-knit
> club of system implementation languages, and I simply cannot picture
> anyone even attempting to implement a real-time OS using it.
>
As I mentioned, you would not implement the OS in Java, but would
implement a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that
rolled onto the planet's surface on Thursday in search of signs of water and
life."
Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.
Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.
Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.
Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."
The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Rant complete! ... -.-
Harry C.
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<6b********************@news20.bellglobal.com >... > Java is certainly not a member of this tight-knit
> club of system implementation languages, and I simply cannot picture
> anyone even attempting to implement a real-time OS using it.
>
As I mentioned, you would not implement the OS in Java, but would
implement a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that
rolled onto the planet's surface on Thursday in search of signs of water and
life."
I just copied that from the article to introduce the link, it is not my
personal opinion.
[argument based on this snipped]
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Perhaps in your group, some messages from the thread are being lost, but the
fact that Java is (almost certainly) not on the rover has been mentioned
numerous times already by many different people.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Well it depends. Is the new technology easy to use, inexpensive, and does
it offer useful capabilities and features PLCs do not? These are all
factors that may make changing to a new technology, as tried and true as the
older one may be, a good idea.
l8r, Mike N. Christoff
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<6b********************@news20.bellglobal.com >... > Java is certainly not a member of this tight-knit
> club of system implementation languages, and I simply cannot picture
> anyone even attempting to implement a real-time OS using it.
>
As I mentioned, you would not implement the OS in Java, but would
implement a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
No, what you actually posted was (unless attrition of this to you was
in error):
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that
rolled onto the planet's surface on Thursday in search of signs of water and
life."
I just copied that from the article to introduce the link, it is not my
personal opinion.
[argument based on this snipped]
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Perhaps in your group, some messages from the thread are being lost, but the
fact that Java is (almost certainly) not on the rover has been mentioned
numerous times already by many different people.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Well it depends. Is the new technology easy to use, inexpensive, and does
it offer useful capabilities and features PLCs do not? These are all
factors that may make changing to a new technology, as tried and true as the
older one may be, a good idea.
l8r, Mike N. Christoff
It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
In any case what the rover has accomplished thus far is a technical
feat that we should be proud of.
Sandeep
-- http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool
It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
In any case what the rover has accomplished thus far is a technical
feat that we should be proud of.
Sandeep
-- http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool
"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et... Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
There is no life on Mars. They all live inside.
"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et... Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
There is no life on Mars. They all live inside.
On 24 Jan 2004 07:45:20 -0800, ev********@hotmail.com (EventHelix.com) wrote: It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.com/platforms/platformvdt/>, thinks the
following is a real advantage -- and perhaps so also did NASA:
<quote>
Reduces time-to-market by cutting integration and testing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
typically the most time-consuming stages of the development process.
</quote>
On 24 Jan 2004 07:45:20 -0800, ev********@hotmail.com (EventHelix.com) wrote: It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.com/platforms/platformvdt/>, thinks the
following is a real advantage -- and perhaps so also did NASA:
<quote>
Reduces time-to-market by cutting integration and testing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
typically the most time-consuming stages of the development process.
</quote>
In article <j9*******************@news20.bellglobal.com>, mt0000
@sympatico.nospam-remove.ca says...
"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et... Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
There is no life on Mars. They all live inside.
So that is what happened to the Morelocks.
--
Randy Howard
2reply remove FOOBAR
In article <j9*******************@news20.bellglobal.com>, mt0000
@sympatico.nospam-remove.ca says...
"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et... Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)
There is no life on Mars. They all live inside.
So that is what happened to the Morelocks.
--
Randy Howard
2reply remove FOOBAR
Uncle Al <Un******@hate.spam.net> wrote in message news:<40***************@hate.spam.net>... mitch wrote:
Uncle Al wrote:
Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr. How many planes do you know that cruise at 100,000 feet absent
any oxygen at all? Martian aircraft are a bad dream.
Hmm. Then the test of a Mars glider plane back in August of 2001 was
just a bad dream? ;-) Work has begun on a propellered version of the
glider cited below. Enjoy.
AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE
The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude.
Read the article: the glider was released at 101,000 feet.
If
the silly thing will be diddling at even 1000 ft altitude Martian, the
air will be thinner.
Martian gravity is less, hence the pressure relative pressure
difference between 0 and 1000 feet will be less than that on Earth:
less than 5%.
"Ye canna break the laws of physics."
The Concorde flew at 60,000 feet and gulped air like a madman. The
U-2 did 75,000 feet, breathed air, and it was a bitch to fly. The
SR-71 Blackbird could barely do 100,000 feet while at Mach 3+ with its
cockpit windshield simmering at 620 F. It drank 8000 gallons/hr of
fuel. It breathed 6 million ft^3 of air/minute.
Al ... organizational bashing is fun and rewarding, but must be taken
with up with taste. Sending flawed subtly mirrors into space while
good ones sit in storage, and launching on colder and colder days
until disaster strikes: these are both errors of judgement well within
the capability of the political machine. But making fundamental
science errors in the preliminary design stages, and saying something
(whose gross design parameters are available to anybody willing to
take the time to look) can work when it not only can't but, according
to you, grossly can't?
That is down at the 5 sigma tail of Bayesian probability, and you know
it.
Of your three examples, only the U-2 is remotely relevant, since it
was essentially a powered glider; and it did not gulp air and fuel,
which you seem fixated on. Who the hell said anything about
air-breathing flight, anyway?
The basic principles and parameters are well known: you have your
Martian atmosphere, you have your structural requirements, you have
your power requirements, you have your known solar cell efficiency.
The engineering either comes together or it doesn't. Have you run the
figures? The issue is whether you can build a large enough and light
enough airframe to move enough rarefied gas to generate sufficient
lift to sustain flight at a drag sustainable by some reasonable power
make-up from solar cells. There are people who could do this on the
back of an envelope.
No ... I haven't run the calculations either. But knowing that high
altitude long dwell time solar powered sail planes have been seriously
considered on Earth, that flight costs less power with slower flight
and larger lifting area, knowing the experience with very light weight
miniminally powered structures accumulated by the human-powered flight
school ... all this give credibility to the idea and tends to suggest
that Al is making an ill-considered shot from the hip, as usual.
And this is not to mention aerostats ... you may have noticed also how
the test glider was carried to 101,000 ft? I suppose that was a
physical impossibility too?
Uncle Al <Un******@hate.spam.net> wrote in message news:<40***************@hate.spam.net>... mitch wrote:
Uncle Al wrote:
Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr. How many planes do you know that cruise at 100,000 feet absent
any oxygen at all? Martian aircraft are a bad dream.
Hmm. Then the test of a Mars glider plane back in August of 2001 was
just a bad dream? ;-) Work has begun on a propellered version of the
glider cited below. Enjoy.
AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE
The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude.
Read the article: the glider was released at 101,000 feet.
If
the silly thing will be diddling at even 1000 ft altitude Martian, the
air will be thinner.
Martian gravity is less, hence the pressure relative pressure
difference between 0 and 1000 feet will be less than that on Earth:
less than 5%.
"Ye canna break the laws of physics."
The Concorde flew at 60,000 feet and gulped air like a madman. The
U-2 did 75,000 feet, breathed air, and it was a bitch to fly. The
SR-71 Blackbird could barely do 100,000 feet while at Mach 3+ with its
cockpit windshield simmering at 620 F. It drank 8000 gallons/hr of
fuel. It breathed 6 million ft^3 of air/minute.
Al ... organizational bashing is fun and rewarding, but must be taken
with up with taste. Sending flawed subtly mirrors into space while
good ones sit in storage, and launching on colder and colder days
until disaster strikes: these are both errors of judgement well within
the capability of the political machine. But making fundamental
science errors in the preliminary design stages, and saying something
(whose gross design parameters are available to anybody willing to
take the time to look) can work when it not only can't but, according
to you, grossly can't?
That is down at the 5 sigma tail of Bayesian probability, and you know
it.
Of your three examples, only the U-2 is remotely relevant, since it
was essentially a powered glider; and it did not gulp air and fuel,
which you seem fixated on. Who the hell said anything about
air-breathing flight, anyway?
The basic principles and parameters are well known: you have your
Martian atmosphere, you have your structural requirements, you have
your power requirements, you have your known solar cell efficiency.
The engineering either comes together or it doesn't. Have you run the
figures? The issue is whether you can build a large enough and light
enough airframe to move enough rarefied gas to generate sufficient
lift to sustain flight at a drag sustainable by some reasonable power
make-up from solar cells. There are people who could do this on the
back of an envelope.
No ... I haven't run the calculations either. But knowing that high
altitude long dwell time solar powered sail planes have been seriously
considered on Earth, that flight costs less power with slower flight
and larger lifting area, knowing the experience with very light weight
miniminally powered structures accumulated by the human-powered flight
school ... all this give credibility to the idea and tends to suggest
that Al is making an ill-considered shot from the hip, as usual.
And this is not to mention aerostats ... you may have noticed also how
the test glider was carried to 101,000 ft? I suppose that was a
physical impossibility too?
Ahh, how quickly we blame software. The actual problem appears to
be hardware (see article below) that is causing the computer to
reboot about once every minute. Last I heard from NASA, Spirit
did an unexpected 73 Mbit dump of electrical subsystem information,
which would seem to support NASA's theory of hardware failure, via
the 128 Kbit/sec uplink to the Orbiter. And, BTW, it is NASA's
software running on VxWorks that is allowing the reboot to occur
due to a watchdog timer expiration, i.e., NASA's software is not
resetting the timer before it expires. The OS has nothing to do
with it, in this case. ;-)
---------------------------
NASA fights to revive Spirit on Mars
====================================
By Richard Stenger
CNN
(CNN) --Attempting to diagnose a nearly mute and temporarily delirious
spacecraft more than 100 million miles away, NASA mission controllers
said Friday that they suspect a hardware problem on the six-wheeled Mars
rover may have caused a severe malfunction.
The craft, Spirit, has sent back little more than beeps and sporadic
data bursts since Wednesday, forcing NASA engineers to scramble for
answers at an inopportune time: an identical robot ship is poised to
land on the other side of Mars on Saturday night or Sunday morning.
Cautioning that they will need more time to understand what went wrong,
project engineers said they have determined that Spirit has rebooted or
tried to reboot itself more than 60 times a day since the failure.
The preliminary health checkup includes both bad news and good news for
the $400 million mission, designed to search for evidence of water on
the red planet in the ancient past. First the bad.
"We will not be restoring functionality to Spirit for some time, for
days or weeks, even in the best of circumstances," Pete Thiesinger, Mars
rover project manager, told reporters at NASA's Jet Propulsion
Laboratory in Pasadena, California.
A measure of hope
-----------------
Now the good. NASA engineers think they can maintain the spacecraft's
current health for some time, communicating simple commands and
receiving simple replies, but nothing comparable to the flood of
geological and photographic data from the first 18 days of the mission
in Gusev Crater, a roughly 100-mile-wide pockmark thought to have once
been filled with water.
"I expect we will get functionality back from this rover," Thiesinger
added. The chances that it will be perfect again are not good. But the
chances that will not regain functionality are low, too, he said.
The culprit remains a mystery, but engineers have pinpointed the time
when the glitch began. Spirit was using an onboard motor to move its
thermal spectrometer for a test when the motor unexpectedly conked out.
After that, its messages to Earth became sporadic, feeble and in some
cases garbled. More detective work determined that its processor
repeatedly wakes up, attempts to load software data, finds a problem and
then presses its own reset button.
JPL engineers have coaxed Spirit back into regular and coherent contact
with Earth, albeit in very simple conversations. They think one possible
cause is that a hardware system has broken and affected the software
somehow.
"We're a long, long way from being done here, but we have serious
problems and our ability to work around them is unknown," Thiesinger said.
Into thin Martian air
---------------------
If performing long-distance therapy on Spirit were not enough, NASA must
guide an identical twin rover to a landing in Meridiani Planum, a
high-elevation plain loaded with a mineral that often forms in the
presence of water.
The Martian atmosphere is much thinner there than it is where Spirit
landed, and a recent dust storm in the region thinned it even further.
The conditions mean that Opportunity's parachute will have a harder time
slowing the craft as it prepares to land.
To compensate, the craft will deploy its parachute much sooner before
touchdown, which is scheduled for 12:05 a.m. ET.
"This will be challenging because it's the highest-altitude landing that
NASA has ever attempted," said Wayne Lee, the engineer in charge of
Opportunity's entry, descent and landing.
Find this article at: http://www.cnn.com/2004/TECH/space/0...act/index.html
Alf P. Steinbach wrote: On 24 Jan 2004 07:45:20 -0800, ev********@hotmail.com (EventHelix.com) wrote:
It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.com/platforms/platformvdt/>, thinks the
following is a real advantage -- and perhaps so also did NASA:
<quote>
Reduces time-to-market by cutting integration and testing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
typically the most time-consuming stages of the development process.
</quote>
Ahh, how quickly we blame software. The actual problem appears to
be hardware (see article below) that is causing the computer to
reboot about once every minute. Last I heard from NASA, Spirit
did an unexpected 73 Mbit dump of electrical subsystem information,
which would seem to support NASA's theory of hardware failure, via
the 128 Kbit/sec uplink to the Orbiter. And, BTW, it is NASA's
software running on VxWorks that is allowing the reboot to occur
due to a watchdog timer expiration, i.e., NASA's software is not
resetting the timer before it expires. The OS has nothing to do
with it, in this case. ;-)
---------------------------
NASA fights to revive Spirit on Mars
====================================
By Richard Stenger
CNN
(CNN) --Attempting to diagnose a nearly mute and temporarily delirious
spacecraft more than 100 million miles away, NASA mission controllers
said Friday that they suspect a hardware problem on the six-wheeled Mars
rover may have caused a severe malfunction.
The craft, Spirit, has sent back little more than beeps and sporadic
data bursts since Wednesday, forcing NASA engineers to scramble for
answers at an inopportune time: an identical robot ship is poised to
land on the other side of Mars on Saturday night or Sunday morning.
Cautioning that they will need more time to understand what went wrong,
project engineers said they have determined that Spirit has rebooted or
tried to reboot itself more than 60 times a day since the failure.
The preliminary health checkup includes both bad news and good news for
the $400 million mission, designed to search for evidence of water on
the red planet in the ancient past. First the bad.
"We will not be restoring functionality to Spirit for some time, for
days or weeks, even in the best of circumstances," Pete Thiesinger, Mars
rover project manager, told reporters at NASA's Jet Propulsion
Laboratory in Pasadena, California.
A measure of hope
-----------------
Now the good. NASA engineers think they can maintain the spacecraft's
current health for some time, communicating simple commands and
receiving simple replies, but nothing comparable to the flood of
geological and photographic data from the first 18 days of the mission
in Gusev Crater, a roughly 100-mile-wide pockmark thought to have once
been filled with water.
"I expect we will get functionality back from this rover," Thiesinger
added. The chances that it will be perfect again are not good. But the
chances that will not regain functionality are low, too, he said.
The culprit remains a mystery, but engineers have pinpointed the time
when the glitch began. Spirit was using an onboard motor to move its
thermal spectrometer for a test when the motor unexpectedly conked out.
After that, its messages to Earth became sporadic, feeble and in some
cases garbled. More detective work determined that its processor
repeatedly wakes up, attempts to load software data, finds a problem and
then presses its own reset button.
JPL engineers have coaxed Spirit back into regular and coherent contact
with Earth, albeit in very simple conversations. They think one possible
cause is that a hardware system has broken and affected the software
somehow.
"We're a long, long way from being done here, but we have serious
problems and our ability to work around them is unknown," Thiesinger said.
Into thin Martian air
---------------------
If performing long-distance therapy on Spirit were not enough, NASA must
guide an identical twin rover to a landing in Meridiani Planum, a
high-elevation plain loaded with a mineral that often forms in the
presence of water.
The Martian atmosphere is much thinner there than it is where Spirit
landed, and a recent dust storm in the region thinned it even further.
The conditions mean that Opportunity's parachute will have a harder time
slowing the craft as it prepares to land.
To compensate, the craft will deploy its parachute much sooner before
touchdown, which is scheduled for 12:05 a.m. ET.
"This will be challenging because it's the highest-altitude landing that
NASA has ever attempted," said Wayne Lee, the engineer in charge of
Opportunity's entry, descent and landing.
Find this article at: http://www.cnn.com/2004/TECH/space/0...act/index.html
Alf P. Steinbach wrote: On 24 Jan 2004 07:45:20 -0800, ev********@hotmail.com (EventHelix.com) wrote:
It seems to be a software problem. The rover is rebooting frequently.
Who says there is no life on Mars? ... We have bugs.
xWorks, who made the operating system for both this probe and
the previous American one that failed, see
<url: http://www.windriver.com/platforms/platformvdt/>, thinks the
following is a real advantage -- and perhaps so also did NASA:
<quote>
Reduces time-to-market by cutting integration and testing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
typically the most time-consuming stages of the development process.
</quote>
From a website "spaceflightnow.com" (still sounds like software)
Rover project manager Peter Theisinger gave the following update on
activities to diagnose Spirit's ailment and return the craft to working
order:
"We made good progress overnight and the rover has been upgraded from
critical to serious. We have a working hypothesis we are pursuing that
is consistent with many of the observables and consistent with
operations that we performed on the vehicle last night. It involves the
flash memory on the vehicle and the software used to communicate with
that memory.
"The processor on Spirit has three kinds of memory:
"There is the random access memory just like the memory in your
computer, which is used basically in a real-time mode. And that memory
is volatile, so when we turn off the rover at night that memory goes
away.
"We have flash memory. That memory is just like the memory in a digital
camera. It can also be read to and written from easily. But it has
non-volatile characteristics -- the information that is stored there
stays overnight even if the vehicle is powered down.
"And then we have we call double EPROM, which is
electrically-programmable memory. That is more difficult to write to and
read from, and we use that to store part of the flight software image.
"The vehicle normally uses the flash memory mostly for the storage and
retrieval of engineering and the scientific telemetry. The software has
to communicate with the flash memory -- has to open up files, establish
file directories, close files in that flash memory. That process has to
work correctly.
"We are capable of operating the vehicle without going to the flash
memory in what we call a 'cripple mode.' That is name we have chosen --
you should not read too much into that. That basically tells the flight
software that when it boots up, it should operate with its file
directory out of the random access memory rather than the flash memory.
That would avoid any issues that we might have with either the flash
memory itself or the flight software that is used to write to it.
"Let me talk about the chronology of what happened in the last 24 hours.
If you recall when we last talked at yesterday's press conference, we
were attempting to shut down the vehicle because the batteries were
becoming depleted. We had an apparent inability to shut down the vehicle
last night, yesterday at the end of the Mars day, which is about the
time of the press conference at 9 a.m. Pacific. That was in fact
confirmed because later we had a UHF communications session with Odyssey
where we got 73 megabits of data, mostly fill or garbage data, although
we did get some fault data, some current, some 14 hours old.
"We did not know but thought we might go into low-power overnight if the
batteries were fully depleted. When came up this morning we looked for
the 9:30 Mars time communications window and it was not there,
indicating, we thought, that we had gone into low-power. That would
cause the vehicle to come up at 11 o'clock and tell us that.
"We, just prior to 11 o'clock, sent a command to the vehicle that said
'go into this cripple mode.' That is only done at the next reset, so
then we sent a command to the vehicle that said 'and reset' in order to
do that. And we timed it so that when the 11 o'clock session would
start, we would begin to get that session at 10 bits per second
indicating we'd gone into low-power. When the commands reached the
spacecraft light-time away, it would send us into cripple mode, reset
the computer and we would come up in the mode. And in fact that is
precisely what happened.
"At that point, we commanded a one-hour communications session at 120
bits per second. That communications session happened as planned.
"The progressive set of resets that we were getting into every hour did
not reoccur, leading us to conclude that our hypothesis is largely
correct -- that is there is something involved in the flight software
that talks to the flash memory that's causing this difficulty.
"Why that might cause us difficulty is because when the spacecraft first
wakes up it needs to communicate with the flash memory to establish a
file structure and when it goes to sleep and shuts down, just like you
shut down your computer at home, it needs to go out to that memory and
close all of those files and clean everything up. If it is unable to do
that, it would not complete those tasks appropriately and will basically
reset itself and not shut down.
"In the midst of that 120 bits per second, one-hour session, we decided
to shut down the vehicle in order to replenish the batteries. We
commanded the shutdown just prior to the end of the communications
session so that we would see the communications session terminate early
if we were able to operate it correctly. That happened. And we sent two
post-shutdown beeps, which we expect not to hear if it is asleep but we
would hear if it was not asleep, and we did not get those, once again
confirming that the vehicle to the best of our ability to determine is
now sleeping on Mars.
"We also yesterday as part of the command sessions during this period of
time terminated tonight's UHF passes and reset the uploss timer. The
uploss timer is a set of fault code that go into play when the vehicle
thinks it has a communications problem and causes some things to switch
state and we didn't want to get into that if we could avoid it. Both of
those were confirmed to be successful.
"So we have a vehicle that is stable now in power and thermal. We have a
working hypothesis that we have confirmed. The fault protection to the
best of our estimation has worked as designed. It took us a lot to
figure out what was going on, but we think everything has worked in the
fault protection as we expected it to do.
"We have a go-forward plan. The cripple mode, which we can use every
day, needs to be re-established every day because it loses the memory
that that's the way it should start up. So every morning we will need to
start up in cripple mode, so we need to establish an operational way of
doing that every day for the next few sols (Mars days).
"We need to establish a high-rate link in order to be able to get much
more data back, particularly if we want to read out the flash memory and
determine what has happened. What we will plan to do is likely to use
the Odyssey afternoon relay pass for that purpose prior to the afternoon
shutdown.
"We need to then establish the contents of flash to find out what
happened and then we need to move forward with the diagnosis and
recovery of the vehicle capability based upon what we find there.
"Remember that this was all kicked off by Sequence 2502. That was the
sequence that was using the elevation motor in the mast failing out,
failing to complete (on Wednesday). We still do not know the details of
why that happened and we need to do that.
"The mission consequences of this are uncertain at the present time. But
I think that we feel that we probably have more capability left in the
vehicle that we can establish than the worst-case scenarios by quite a
bit. We still see a couple of weeks to determine what had happened and
to rebuild our confidence into what is working on the vehicle and to get
back closer to routine operations. I think we are probably like three
weeks away from driving, I am guessing.
"The team will begin to go into double-shift operations probably a day
or so after Opportunity's landing where we have a re-plan period and
then an operational period as we begin to work through the forensics of
this.
"But this is a very good news. We've established an ability to
communicate with the vehicle reliably, we've established that in fact we
do have controllability of the vehicle, can establish a good power and
thermal state, our working hypothesis is one that we can work around
with significant measure if it turns out our working hypothesis is
correct. So a good day for an Opportunity landing."
From a website "spaceflightnow.com" (still sounds like software)
Rover project manager Peter Theisinger gave the following update on
activities to diagnose Spirit's ailment and return the craft to working
order:
"We made good progress overnight and the rover has been upgraded from
critical to serious. We have a working hypothesis we are pursuing that
is consistent with many of the observables and consistent with
operations that we performed on the vehicle last night. It involves the
flash memory on the vehicle and the software used to communicate with
that memory.
"The processor on Spirit has three kinds of memory:
"There is the random access memory just like the memory in your
computer, which is used basically in a real-time mode. And that memory
is volatile, so when we turn off the rover at night that memory goes
away.
"We have flash memory. That memory is just like the memory in a digital
camera. It can also be read to and written from easily. But it has
non-volatile characteristics -- the information that is stored there
stays overnight even if the vehicle is powered down.
"And then we have we call double EPROM, which is
electrically-programmable memory. That is more difficult to write to and
read from, and we use that to store part of the flight software image.
"The vehicle normally uses the flash memory mostly for the storage and
retrieval of engineering and the scientific telemetry. The software has
to communicate with the flash memory -- has to open up files, establish
file directories, close files in that flash memory. That process has to
work correctly.
"We are capable of operating the vehicle without going to the flash
memory in what we call a 'cripple mode.' That is name we have chosen --
you should not read too much into that. That basically tells the flight
software that when it boots up, it should operate with its file
directory out of the random access memory rather than the flash memory.
That would avoid any issues that we might have with either the flash
memory itself or the flight software that is used to write to it.
"Let me talk about the chronology of what happened in the last 24 hours.
If you recall when we last talked at yesterday's press conference, we
were attempting to shut down the vehicle because the batteries were
becoming depleted. We had an apparent inability to shut down the vehicle
last night, yesterday at the end of the Mars day, which is about the
time of the press conference at 9 a.m. Pacific. That was in fact
confirmed because later we had a UHF communications session with Odyssey
where we got 73 megabits of data, mostly fill or garbage data, although
we did get some fault data, some current, some 14 hours old.
"We did not know but thought we might go into low-power overnight if the
batteries were fully depleted. When came up this morning we looked for
the 9:30 Mars time communications window and it was not there,
indicating, we thought, that we had gone into low-power. That would
cause the vehicle to come up at 11 o'clock and tell us that.
"We, just prior to 11 o'clock, sent a command to the vehicle that said
'go into this cripple mode.' That is only done at the next reset, so
then we sent a command to the vehicle that said 'and reset' in order to
do that. And we timed it so that when the 11 o'clock session would
start, we would begin to get that session at 10 bits per second
indicating we'd gone into low-power. When the commands reached the
spacecraft light-time away, it would send us into cripple mode, reset
the computer and we would come up in the mode. And in fact that is
precisely what happened.
"At that point, we commanded a one-hour communications session at 120
bits per second. That communications session happened as planned.
"The progressive set of resets that we were getting into every hour did
not reoccur, leading us to conclude that our hypothesis is largely
correct -- that is there is something involved in the flight software
that talks to the flash memory that's causing this difficulty.
"Why that might cause us difficulty is because when the spacecraft first
wakes up it needs to communicate with the flash memory to establish a
file structure and when it goes to sleep and shuts down, just like you
shut down your computer at home, it needs to go out to that memory and
close all of those files and clean everything up. If it is unable to do
that, it would not complete those tasks appropriately and will basically
reset itself and not shut down.
"In the midst of that 120 bits per second, one-hour session, we decided
to shut down the vehicle in order to replenish the batteries. We
commanded the shutdown just prior to the end of the communications
session so that we would see the communications session terminate early
if we were able to operate it correctly. That happened. And we sent two
post-shutdown beeps, which we expect not to hear if it is asleep but we
would hear if it was not asleep, and we did not get those, once again
confirming that the vehicle to the best of our ability to determine is
now sleeping on Mars.
"We also yesterday as part of the command sessions during this period of
time terminated tonight's UHF passes and reset the uploss timer. The
uploss timer is a set of fault code that go into play when the vehicle
thinks it has a communications problem and causes some things to switch
state and we didn't want to get into that if we could avoid it. Both of
those were confirmed to be successful.
"So we have a vehicle that is stable now in power and thermal. We have a
working hypothesis that we have confirmed. The fault protection to the
best of our estimation has worked as designed. It took us a lot to
figure out what was going on, but we think everything has worked in the
fault protection as we expected it to do.
"We have a go-forward plan. The cripple mode, which we can use every
day, needs to be re-established every day because it loses the memory
that that's the way it should start up. So every morning we will need to
start up in cripple mode, so we need to establish an operational way of
doing that every day for the next few sols (Mars days).
"We need to establish a high-rate link in order to be able to get much
more data back, particularly if we want to read out the flash memory and
determine what has happened. What we will plan to do is likely to use
the Odyssey afternoon relay pass for that purpose prior to the afternoon
shutdown.
"We need to then establish the contents of flash to find out what
happened and then we need to move forward with the diagnosis and
recovery of the vehicle capability based upon what we find there.
"Remember that this was all kicked off by Sequence 2502. That was the
sequence that was using the elevation motor in the mast failing out,
failing to complete (on Wednesday). We still do not know the details of
why that happened and we need to do that.
"The mission consequences of this are uncertain at the present time. But
I think that we feel that we probably have more capability left in the
vehicle that we can establish than the worst-case scenarios by quite a
bit. We still see a couple of weeks to determine what had happened and
to rebuild our confidence into what is working on the vehicle and to get
back closer to routine operations. I think we are probably like three
weeks away from driving, I am guessing.
"The team will begin to go into double-shift operations probably a day
or so after Opportunity's landing where we have a re-plan period and
then an operational period as we begin to work through the forensics of
this.
"But this is a very good news. We've established an ability to
communicate with the vehicle reliably, we've established that in fact we
do have controllability of the vehicle, can establish a good power and
thermal state, our working hypothesis is one that we can work around
with significant measure if it turns out our working hypothesis is
correct. So a good day for an Opportunity landing."
> Here often anything greater than a few processor instruction cycle latency leads to a non-recoverable error situation.
On a current processor, "a few [...] cycles" is about a nanosecond. Unless
you want to depart at warp speed from a sun going supernova, I see no
application requiring that small a reaction time. The Shuttle avionics runs
on "cycles" of evaluation that are on the order of several milliseconds,
IIRC - and that is in a _very_ dynamic environment.In particular...
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
....experience shows that's not usually the case. The context-switching
overhead determined by software (OS) architecture, but also by the hardware
(size of processor context, memory hierarchy, etc) seem to have led to
latencies that seem not to have improved much in the past decade, if not
worsened.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit.
....which is very difficult to evaluate on a modern processor in any case.
Jan
> Here often anything greater than a few processor instruction cycle latency leads to a non-recoverable error situation.
On a current processor, "a few [...] cycles" is about a nanosecond. Unless
you want to depart at warp speed from a sun going supernova, I see no
application requiring that small a reaction time. The Shuttle avionics runs
on "cycles" of evaluation that are on the order of several milliseconds,
IIRC - and that is in a _very_ dynamic environment.In particular...
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
....experience shows that's not usually the case. The context-switching
overhead determined by software (OS) architecture, but also by the hardware
(size of processor context, memory hierarchy, etc) seem to have led to
latencies that seem not to have improved much in the past decade, if not
worsened.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit.
....which is very difficult to evaluate on a modern processor in any case.
Jan
> NASA is renowned for its antenna failures - the Hubble space telescope,
HST didn't and doesn't have antenna problems.
Ulysses at Jupiter
That one is going 'round the sun, and has had no problems of the sort.
and now their little radio-controlled go-cart on Mars.
....which isn't having an antenna problem, either.
As far as I can remember, the only probe to have an antenna failure was
Galileo. Feature creep caused by delays and other mods caused that one -
a bit of bad luck was also involved. OTOH, if the delays hadn't been,
another problem would likely have caused it to disintegrate during cruise,
if that hadn't been (painfully) found on another satellite and a work-around
identified.
As usual, you win some and you loose some.
Jan
> NASA is renowned for its antenna failures - the Hubble space telescope,
HST didn't and doesn't have antenna problems.
Ulysses at Jupiter
That one is going 'round the sun, and has had no problems of the sort.
and now their little radio-controlled go-cart on Mars.
....which isn't having an antenna problem, either.
As far as I can remember, the only probe to have an antenna failure was
Galileo. Feature creep caused by delays and other mods caused that one -
a bit of bad luck was also involved. OTOH, if the delays hadn't been,
another problem would likely have caused it to disintegrate during cruise,
if that hadn't been (painfully) found on another satellite and a work-around
identified.
As usual, you win some and you loose some.
Jan
On Thu, 22 Jan 2004 17:24:19 -0800, Uncle Al <Un******@hate.spam.net>
wrote: NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
I only know of one antennae failure. Gallileo's antenna failed to
open correctly. As I recall there was speculation that some of the
grease in the struts degraded (or something) during the long years of
storage following the Challenger explosion.
NASA has had it's up's and downs. That's understandable. They are
doing things that nobody has ever done before. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jacob navia |
last post by:
Mankind has now two robots wandering about in the planet Mars. No,
it wasn't Mars that invaded Earth, but Earth that landed in Mars
more than two...
|
by: concettolabs |
last post by:
In today's business world, businesses are increasingly turning to PowerApps to develop custom business applications. PowerApps is a powerful tool...
|
by: CD Tom |
last post by:
This happens in runtime 2013 and 2016. When a report is run and then closed a toolbar shows up and the only way to get it to go away is to right...
|
by: CD Tom |
last post by:
This only shows up in access runtime. When a user select a report from my report menu when they close the report they get a menu I've called Add-ins...
|
by: Naresh1 |
last post by:
What is WebLogic Admin Training?
WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge...
|
by: jalbright99669 |
last post by:
Am having a bit of a time with URL Rewrite. I need to incorporate http to https redirect with a reverse proxy. I have the URL Rewrite rules made...
|
by: antdb |
last post by:
Ⅰ. Advantage of AntDB: hyper-convergence + streaming processing engine
In the overall architecture, a new "hyper-convergence" concept was...
|
by: Matthew3360 |
last post by:
Hi there. I have been struggling to find out how to use a variable as my location in my header redirect function.
Here is my code.
...
|
by: AndyPSV |
last post by:
HOW CAN I CREATE AN AI with an .executable file that would suck all files in the folder and on my computerHOW CAN I CREATE AN AI with an .executable...
|
by: Arjunsri |
last post by:
I have a Redshift database that I need to use as an import data source. I have configured the DSN connection using the server, port, database, and...
| |
