Might be O/T, but I found it really interesting how they mention "5,352 Martian solar days". Do we humans have plans in the pipeline for a universal time standard we can use wherever we are? Something that is a little more useful than "seconds since UNIX epoch" but something a little less terrestrial than UTC? Or is time going to be based wherever we land or travel (e.g. divide up Mars into time zones upon colonization)? If we don't have a formal ISO solution, it might be a good idea to start pinning one down; might be relevant by the time the standard is finalized.
> Do we humans have plans in the pipeline for a universal time standard we can use wherever we are?
This fundamentally cannot exist. Any "universal" system would drift for observers on different planets. Having different times in New York and New Delhi isn't the worst right now; doing a calendar look-up for the time on Mars isn't as neat. But given we won't have real-time communication, it isn't as big of a problem either.
Somewhat comically J.C.R Licklider's first proposal for what became the internet was titled the Intergalactic Computer Network. He later said he did this because when the project is inevitably downsized it would at least cover the earth.
Interplanetary internet designs and peering are interesting problems to think about though.
There are real, standardized protocols [0] for this sort of thing, now. Early in my career, when I worked at JPL/NASA, I did a bit of work to test these protocols on Linux in a simulated Network of spacecraft. Fun stuff!
What a coincidence, I'm working on the core flight system project right now, which includes an implementation of CCSDS File Delivery Protocol. You might be happy to know that project is still very much alive within NASA (you were probably already aware).
Haha. Great to hear that work still lives! I hope you’re not using the (horrible in retrospect) stuff I wrote 15 years ago that worked on 2.0-2.6 kernels. I remember porting the network kernel driver from 2.0-2.2 manual build system to implementing a (really basic) Makefile that worked with 2.0-2.6.0ish kernels (which were newer at the time). I knew Scott Burleigh was still innovating CCSDS and other protocols at JPL, and, IIRC the work I had done had also been delivered to Ames and ESA for test lab use. I had some other work to create protocol dissectors for Ethereal (before the name change to WireShark). WireShark now includes built in dissectors for CCSDS, CFDP and others.
The small parts of the Mars Rovers (MER) I worked on or worked with didn’t use SQLite. It was too early in SQLite’s history for it to be used on MER. MER also used VxWorks which probably didn’t have a lot in the way of POSIX support at the time. I remember other devs telling me the fun they had supporting 1553 bus on “such a new RTOS”.
Wikipedia say MSL used VxWorks as well.
I’d have to ask a buddy still doing Mission Ops Support at JPL but I’d think the answer is no SQLite on MER or MSL missions. The OSes were fairly custom, non-POSIX builds. The ESA folks might have tried though on their missions.
No worries. Been meaning to investigate VxWorks at some point, mostly from an interest in embedded devices (for specific wearables concepts). This will be another thing to add for that list. :)
As far as I know, it has flown on two government (civil space) missions. I'm not longer at the company so I don't know what else it has or will go into.
I don't know about rovers, but some smaller spacecraft (mainly satellites) use mysql, as well as postgres. Disclaimer: I'm not the right person to ask.
What does it use for time? The spec mentions time in a lot of places, but never defines it. There is even a field to communicate light-time but no mention of how to synchronize anything. I guess this runs on top of another protocol that solves it? Any idea what it is?
So, it’s been a while since I’ve dived in [0], but “time” as a dependency has been, what I would call, “engineered out of the system”. Instead, there’s concepts of (local) timers, Store-And-Forward Overlays, retries, communication opportunities and the overall realization that time is relative and synchronized time can be difficult at a protocol level when link-level distances are always changing (by miles to billions of miles at a time per communication opportunity).
> doing a calendar look-up for the time on Mars isn't as neat
This is actually not that a big deal, in many countries, like Afghanistan and Iran, people observe 3 different calendars for different purposes and they all drift from each other! That is, 1st Jan (Georgian) is not always 24th Jaddi/Dey (Afghan/Iranian - Solar) nor 7th of 7th Jumada i-ula (Lunar/Islamic)..
Leap days are caused by one revolution not being a whole number of rotations.
The weird thing with Mars would be that if you contact someone at 5pm local today it might not be okay to call them at the same time tomorrow, because they would clock in 37 minutes later.
Living on Mars in the next 100 years is already going to be hard enough emotionally, biochemically, and thermodynamically, without having a work schedule that changes by 37 minutes every day.
Everything about it, including the great distance, or perhaps especially the great distance says that Earthers will have to make the affordances. I expect anyone on Mars who didn't come through the ranks of the Armed Forces (and half of the ones who did), and any medical, psychological, or political scientist brought in as an advisor, are all going to give a big ol' "Fuck You" to anyone who suggests otherwise.
I know that system clock drift can be bounded to milliseconds using an atomic clock or GPS receiver, but I didn't know whether we could overcome synchronization difficulties when speed-of-light differences are significant. I thought we could package some coordinate reference system, directional travel metadata (I'm traveling 0.000002c this way), and current system clock time, and synchronize that way.
Fantasy use case: Asteroid mining and traffic control. If you want to boost prepared asteroids to an orbit closer to Mars and you had a space station / spaceships to watch out for, different mining companies might want a clock protocol, a request buffer, and a map instead of synchronously planning, timing, and verifying each and every asteroid orbit change in a central location ("What do you mean you were using Earth time and not correcting for relativity??").
There is Barycentric Coordinate Time which is the time from a hypothetical clock at rest at the centre of mass of the Solar System. This is easier to calculate across spacecraft than an Earth-centric time would be. However, because it's outside of Earth's gravity well it ticks slightly faster than Earth time.
While true it’s still trivial to do such calculations and then output in GMT or whatever. In theory such calculations can get really messy, but atomic clocks are still not accurate enough to make a huge range of minor issues important.
For example we are not just in the sun’s and earth’s gravity field but also the other planets as well. So, with enough precision you would need to account for their locations.
If you ever get the chance go to the Royal Observatory in Greenwich, which has a great explanation of the difficulties (and values) associated with timekeeping:
Setup a transmitter at earth which emits a signal at uniform intervals containing current time (seconds since kanye west's marriage). An observer can then deduce current time if it knows where it is. I don't think relativistic dilation would effect this method.
With multiple such emitters synchronized with each other, one might even be able to 'triangulate' the current time. (I haven't worked out any details)
You can't synchronize the stations because simultaneity does not exist due to relativity. There will always be reference frames where one station signals before another.
We've known since the Viking landers of the 70s that clocks on Mars don't run the same as on Earth, and that's not even accounting for the speed-effects as the Earth keeps "lapping" Mars on their respective race around the sun.
I'm not sure I see what you'd be gaining there, though. You'd be, at great expense, trading one basket of headaches - clocks not staying in sync - for another one: one second measuring a different length of time on each planet.
Yes but then earth's one second would become the standard. This method is supposed to synchronize events between stations. We can always use atomic clocks for local uses.
> This fundamentally cannot exist. Any "universal" system would drift for observers on different planets.
I hear this argument a lot for why we cannot have a universal time standard but it's a weird cyclic argument because it suggests the measurement of time has to be constant while acknowledging that time is relative. So why can't we have a measurement that is also relative?
For example it could be n "ticks" where mass and speed is at a predefined value and allow for decimal points to account for people travelling faster (for example). This means people's life expectancy (for example) could not be measured in "ticks" because "ticks" is used for time synchronisation rather than measuring the passage of time and those who are only interested in the passage of time can use local time zones just like we do now with UTC for keeping equipment synchronised but local time zones for scheduling our human lives.
Fair point, I overlooked that problem. You might get away with using the centre of the galaxy as a point of reference?
To be honest I'm really not qualified to be making these sorts of comments so I'm going to back away from the keyboard and if there's any merit to the idea at all (which there probably isn't) then someone else who understands this stuff better can chime in.
You can factor the drift into the time expression or you can simply agree to use earth time or Martian time or any other time. No fundamental need to base time units on Mars on Martian astronomy.
I thought a second was a SI base unit: (from Wikipedia)
The second, symbol s, is the SI unit of time. It is defined by taking the fixed numerical value of the caesium frequency {\displaystyle \Delta \nu _{\text{Cs}}} {\displaystyle \Delta \nu _{\text{Cs}}}, the unperturbed ground-state hyperfine transition frequency of the caesium-133 atom, to be 9192631770 when expressed in the unit Hz, which is equal to s−1.
Yes, but that frequency depends on the caesium-133's frame of reference. In a deep gravity well or at "high" speed, caesium-133 emits at a lower frequency relative to caesium-133 in deep space moving at "low" speed.
I forget how this was accounted for in Kim Stanley Robin's famous Mars trilogy (highly recommend; best Sci-Fi book I've ever read). I think Earth and Mars were so far apart with time delays and everything else that Martian days/years took on a meaning of their own.
They won't drift if the observers correct for their corresponding known differences. E.g. we know the orbital speed of the planets, so plug those into general relativity and you would know how fast your local time is moving vs time on another planet, and can thus compensate.
According to relativity, you cannot get two different observers to agree on any kind of universal time, or even the order in which two events occurred.
My understanding is that it's just that the order can depend on the frame of reference. If you agree on a frame of reference then you can agree on the time. If you both try to use your own frame of reference then you run into trouble.
There's no preferred frame of reference, meaning that any frame of reference could work, but you can derive one from the cosmic microwave background if you don't like picking something too arbitrary.
Couldn't you just pick a pulsar or something, all agree to take their measurements from X distance from pulsar, and use that as the standard? It would be time + location, making your local time depending on the distance and number of pulses from the 0 starting pointing. As long as you kept account of the number of pulses as you moved through space, you could use that as a standard, and whenever you met up somewhere else in the universe, you could base your time based on their observed number of pulses.
Im not sure pulsars are actually that precise and predictable to not require regular adjustments to equate local times, but it would provide a standard anybody could utilize as long as they could keep an eye on it.
Of course it would break down if someone broke light speed, either with wormholes or some unknown technology, but as long as you are below lightspeed then there shouldn't be any problems.
Pulsar seemed like a good idea but seems it has some difficulties.
Due to their small size, pulsars are relatively weak radio sources. Therefore, the largest radio telescopes in the world are usually needed to observe them. As we have seen, pulsars emit their largest intensity at low radio frequencies around 400 MHz. In particular at such frequencies, however, the pulses suffer from propagation effects when they travel to Earth through the interstellar medium. [0]
You are correct, but thankfully relativity tells us that in this case both events are independent, so neither can be the cause of the other, so it's not that bad of a disagreement.
It's even useful as a consistency model for some distributed systems.
The further apart the observers are and the larger their relative velocities the larger the effect is. There's nothing to stop the differential from being years in extreme cases.
For any speeds we'd be likely to be traveling, in system, it'd likely only be a problem for milliseconds if that. We'd still be able to correct for where things are as we approach them or plan to approach them.
Yeah, I was thinking only of in the Solar System. Beyond that, the primary bound on commercializeable space is probably spacecraft propulsion, which will take a while.
I don't really see the problem with standardizing on 'seconds since the epoch' for any interplanetary communication and having clients convert to something more meaningful to humans. Any other "universal" time format will be just as meaningless when days and seasons are all different lengths.
At a certain point of accuracy you run into issues with this - seconds don't pass at the same rate due to relativistic effects (both speed and gravitational).
An example we already deal with is GPS satellites orbiting Earth. Their clocks tick a little bit slower on account of how fast they're orbiting, and tick a bit faster on account of being further up Earth's gravity well. The gravitational effect is stronger, and the net effect is that a GPS clock advances an extra 38 microseconds over the course of a day (as measured by a clock on the ground).
I don't think the relativistic effects would be a problem in practice. You can synchronize clocks on other planets to the UTC or TAI reference time, which are already specified in terms of the Earth's reference frame.
Because of relativity, clocks on other planets would very slowly drift relative to UTC on Earth. But the drift is on the order of a few parts per billion (see e.g. [1]) which is comparable to what you'd expect anyway, even from a very high-quality temperature-controlled crystal oscillator. So it doesn't add any new clock synchronization difficulties that you wouldn't have anyway.
For the most demanding applications -- the ones that require atomic clocks -- you would still need to take relativity into account. You can either measure time passing at the local rate (in cases where you need to know locally elapsed time to high precision) or you can measure UTC, which allows you to assign a consistent ordering to events on different planets. But for most ordinary purposes, the distinction is irrelevant.
If I did my math right that's 0.178 seconds per year. As long as everyone's handling time the same way you shouldn't have a problem, but it's enough to be noticeable if someone forgets about it.
I suppose the more noticeable oddness for most people would be that the speed-of-light delay in communications from Earth to Mars varies so much. Around 3 light minutes up to 22 depending on where they are in their orbits.
That's around what I got from my back of the envelope Math too (well, I got around 300ms/year). Small enough where you can adjust a leap second everyone few years to take care of the drift. Kind of like converting between UTC, TAI, and UT1.
It may need to be compensated for when receiving transmissions between the planets, but I don't know enough about RF to judge how meaningful the difference is. There was a spacecraft (I think Huygens?) that actually had problems with Doppler shift. I think in that case they forgot to take it into account entirely, so it wasn't that they just forgot the relativistic component.
GPS satellites already control for relativistic effects. Their required accuracy is so high that they wouldn't work without doing so.
You would simply also correct for relativistic effects caused by the orbits of different planets, and boom, you have a pretty consistently defined time that is valid across the entire solar system.
The only thing I can think of involves truly relativistic speeds, which just isn't going to happen for human travel anytime soon, if ever, and certainly not within the solar system.
Seconds according to the atomic clocks at NIST. People operating clocks moving at relativistic speeds will apply the necessary corrections, as GPS satellites already do.
Note that GPS compensates for relativistic effects to allow GPS receivers to act as very accurate clocks (GPS time receivers are considered stratum 0 clocks). If you didn't care about using GPS time receivers you wouldn't have to care about relativistic effects with GPS at all (because all satellites are more-or-less exposed to the same relativistic effects), because a 3D/4D fix already synchronizes the receiver to the satellite's clocks.
Relativity compensation in GPS satellites does not increase spatial accuracy.
The problem comes in due to relativity. Mars and Earth (and other planetoids) travel at different speeds. The very length of a second will drift over time.
No. You would have to observe the planet from your position and that observation changes based on how you move relative to the planet. The whole of SRT and GRT work in such a way that no general clock synchronization can ever exist for observers in different frames of reference.
If you take a reference with you on a journey through the solar system, that reference will stay accurate for an observer travelling with it and drift as seen from an observer that stayed behind. Both views are accurate. Locally, the amount of time that has passed for each observer was different. If you would correct for any observed drift, you would mess with your fundamental unit of time in your local frame of reference and get incorrect measures of time passed in your own frame.
What I had in mind is, you can observe your planet's position and velocity (relative e.g. to center/rotation of the galaxy), and the target planet's relative position and velocity, and use both to translate the observations into virtual "stationary" observations... And "unit of time" would be defined as 1/n of one planetary/galactic revolution, so every observer would be able to calculate their own "galactic time" independently. Well, maybe GPS already does something similar.
No, you can't. Atomic clocks measure the oscillation of atoms (I think Cesium is currently used), and though constant at a fixed point, vary when theyre moving at different speeds. GPS wouldn't be possible without taking this into account, for example. A second on earth will never be the same as a second on Mars.
A second is duration, but we're really interested in instants. Why can't you can define an instant independently of the observers, e.g. in reference to the rotation of the galaxy (i.e. "this happened at angle 37 from Milky Way - Andromeda line, at distance 403 parsecs from Milky Way center, at 692.3 Milky Way rotations since epoch (Big Bang)").
Yeah I don't entirely understand why we don't that already... Like, websites should be sending UNIX time to clients, and then the browser should display it in users local timezone/format.
HTML already has a <time> tag, which one can use to send a machine readable representation of the textual content; it would be easy for browsers to display it in local tz/format. Of course, almost nobody uses it, as usual.
Planck Seconds since the Birth of Jesus. Infallible. But seriously, since time is relative, you can only provide it with a reference included. i.e. Planck Seconds since x event (big bang/whatever) from the perspective of y. Similar to the notion of objective velocity... any object is stationary or moving only in reference to something else. Although I think we can get around that if we could get accurate measurements of quantum foam and determine if those foam bits all have velocity relative to each other.
There is BCT [0] which corrects for gravitational time dilation on Earth relative to the solar system, but I'm not aware of anything on a universal scale. It seems conceptually difficult to do synchronization if the communication round trip time, bounded below by the speed of light, is significant.
I think NTP uses some statistical tricks to get better synchronization than you'd expect over slow, laggy internet links. Possibly something like that could work.
If we're talking interstellar travel, we're likely talking about spacecraft undergoing very significant acceleration and velocity. I'm not a physics expert, but from my understanding it seems that a starship would need to have a very accurate idea of its own acceleration vs reference time curve (relative to some reference frame) in order to calibrate its own ticking clock to the reference frame. For NTP, this isn't so much an issue because on Earth all the endpoints' clocks are all ticking at about the same rate.
It doesn't necessarily need a very good model of acceleration - you can probably get by with a) time at which a reference event is defined to have occurred, and b) distance to that event. From that and your locally-experienced acceleration you can (I think?) calculate relative speed and time drift.
Well the problem is a "second" is just a unit of rotation of the Earth on its axis. So you'd either need to use some other reference material than a rotating body in space or else use some arbitrary one (like Earth, since that's where we are from!) and choose a reference date (why not use one we're all familiar with? I know! We could use the UNIX epoch!).
Even if you did this, your universal time would just be a synchronizing tool. Each human consumer would expect it to be translated into the most relevant time to them. If you think it's hard getting people to adopt a standardized date/time on one planet, every planet you add to the system makes that an exponentially more difficult task.
Vernor Vinge got there way ahead of you, If you haven't read his books and given the way this community slants you are missing out.
> Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
Yes obviously we aren't sitting here measuring the earth's rotation to set our clocks. The point is the meaning of the number remains the same. Seconds, minutes and hours have meaning, and the meaning of those measured amounts of times is directly related to some fraction of the rotation of the planet we are currently sitting on. The point was moving this system of time-keeping to some other planet would discard much of its relevancy to our every-day life, which matters a lot.
That's actually not true if you're using SI units for seconds.
"The SI unit of time is the second (s): The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom."
I'm not a physicist, but I think that's a universal definition - the rate of the periods should be constant everywhere in the universe.
So universal seconds are actually very easy to nail down. Dates are always a little more troublesome. Perhaps seconds since the start of the big bang would be a possibility.
The point wasn't to explain how we measure it or whether it is easy or not, the point is that the unit of measure was selected for its meaning, and that meaning has little relevance on other planets.
Because SI itself assumes that you and whatever you are measuring is in same relativistic frame of reference. When you start to take relativity into account the whole system breaks down horribly.
I'm not sure about the usefulness of increasing precision if you can only guarantee a certain precision upon synchronization. I wonder if increased clock activity translates to increased clock temperature and increased clock variation. And I worry about more frequent logging and disk usage/space.
But one thing I am sure of -- we would make good friends ;)
The reason I haven't tried to revive Swatch Internet Time is that it was based in GMT+1, which is just inane. I don't know if that little detail offended anyone else, but it sure torpedoed the idea for me.
Well, the Martian solar day is a directly relevant measure for a mission that depends on charging batteries each day by solar power. I could see that being used for a lot of planning and operations.
UTC (and international atomic time - TAI) is an average measure of elapsed time that already needs adjusting for relativistic time dilation. None of the accurate clocks used for TAI are at sea level but TAI is reported as though you had all your caesium atoms ringing away at sea level [0].
Everyone else adjusts their clocks with reference to this, making allowance for propagation delays where needed. This includes things like navigation satellites (GPS, Galileo, Glonass, BeiDou etc) which have accurate clocks and significant (for their operation) relativistic dilation.
Since we already have to deal with relativity and propagation delay here on earth I suppose that, if your mission can still ping mission control here on Earth, then you can still set the system clock to UTC or TAI [1]. You will need a look up table for local sunrise times and the like but that seems quite simple compared to the mess that tzdata has to allow for back home.
[0] As I write this I realise that I don't know if TAI will be adjusted for sea level changes or not. Anyone know?
[1] Using TAI might save you from leap second problems while landing on an alien planet.
> Do we humans have plans in the pipeline for a universal time standard we can use wherever we are?
Astronomy generally uses "Julian days" or "Julian years" which are measured in seconds since a certain calendar date. Since they're based on SI seconds intervals are independent of the Earth's movement and leap seconds and all that nonsense.
Most popular epoch is J2000: measured since noon on 1 January 2000.
Mars landers each track local solar time separately and a colony is likely to invent its own timezone with 24 hours and 39 minute days. You need this so that notions like "sunrise" and "sunset" make sense.
The problem you are always going to have is that the inhabitants of each planet will want their 'days' to line up with their day/night cycles. So even without relativity, you aren't going to get a unified date system that works for everyone.
If that's the case Unix time then becomes a decent option, because it's equally human unreadable to everyone. Each planet can then have their own calendar based on that, and computers can deal with the nitty gritty
Time is not homogeneous accross the universe anyway, so what would be the absolute referential ? Best we can do is pick an arbitrary one, and then create algos and tables to convert from that.
We already do that with UTC, and even with something that simple, it gets hard: politics gets in play, and we have to reajust our time slices with leap periods regularly.
One of the proposals for Mars in fiction was to use Earth 24 hours and then stop the clock for those additional 30 or 40 minutes Mars day has. Anyway, I suspect that humans will tend to use the most common standard, meaning some legacy standard and in case of time it is likely would be UNIX time. 110 volts AC too probably :)
Universal, no. But the Darian calendar system has been carefully devised to fit Mars, the moons of Jupiter, and Titan, and as far as i know that's the closest anyone has got:
I've always thought one would need a quantum clock to accomplish the same "instant" across the universe. Something that starts entangled and therefore stays in sync regardless of space and distance.
That's a complete amateur physicist taking a stab at it!! I'm probably horribly wrong :)
Most likely by declaring a standard reference frame and encoding standards for indicating amount of drift from it, tolerance of drift, and standards for how to update against it. A particularly forward-looking standard would encode information about the standard frame used within it, so we could switch from Sol-standard to galactic standard to cluster standard.
Universal time is, of course, impossible in a relativistic universe, but (no sarcasm) that doesn't prevent us from trying, and getting to "close enough to work with for reasonable amounts of effort". Just as only a small portion of the world works on UTC directly right now, this time standard would be something computers would translate for people. Traveling at 80% the speed of light away from Earth in Earth's frame means you wouldn't want to directly use the resulting definition of a Standard Second for human time, but computers would be able to work with it.
An interesting challenge might be the computational cost of conversion to the "standard" reference given a speed near c. If a single CPU tick takes a "standard year" to compute how do you do you account for all ticks in your calculation?Is it possible to get to a sub-year standard time resolution in that scenario?
I don't know. First we'd have to identify if there is one center of the universe; can we guarantee that the universe expands uniformly? I can't find anything online and I'm not a physicist. If there are multiple centroids of the universe, and they're all moving, we probably can't establish an eternal reference point.
Also I think the confidence interval for instrumentation looking that far ahead would be so big comparative to current/possible local solutions, we're probably better off doing something in the Solar System instead.
One advantage of synchronizing to some reference in the Solar System, and maybe setting clock boosters as floating checkpoints in space, is we will always be able to find our way home :)
Hey cheer up now, there's no aliens we've found yet to compare to! We go our own pace and do our own thing, and Mister Rogers will always love you, and that's all that matters.
There are still Power chips (based on PowerPC 750) on Curiosity; it's just POWER1 that's dead:
> That's not the end of Power ISA chips on Mars, though: Curiosity, which is running a pair of RAD750s (one main and one backup, plus two SPARC accessory CPUs), is still in operation at 2,319 Mars solar days and ticking.
There's still a reasonable PPC Mac/Amiga hobbyist community, many of whom will tell you about how much purer PowerPC is compared to the evil ugly x86. As someone who does PPC Linux kernel work the pragmatic part of me would like to drop support for a lot of these older machines, but as long as the machines are still actively used the support gets maintained.
Indeed - the Talos machines are the first new PPC desktops in quite a while. The IBM POWER CPU series is far from dead, just post-Macintosh / PS3/Wii/XB360 consoles, it's not really something you see in the consumer space any more - apart from Talos, which I'm pretty excited about.
"Opportunity likely experienced a low-power fault, a mission clock fault and an up-loss timer fault. The team is continuing to listen for the rover over a broad range of times, frequencies and polarizations using the Deep Space Network (DSN) Radio Science Receiver. The team has begun mission clock fault recovery commanding 'in the blind,' in the hopes of catching the rover during an awake period, as their strategy of last resort."
The linked AP article does not indicate that a failure of the CPU is the issue here (it does not indicate much beyond this vague sentence: "its internal clock possibly so scrambled that it no longer knew when to sleep or wake up to receive commands"). What do you mean with "alive", that it still has power?
