Eight long years ago, when the Martian rovers Spirit and Opportunity were steaming towards our dusty neighbor, JPL systems engineers [Julie Townsend] and [Scott Doudrick] were stuck trying to solve a very strange problem. After the twin rovers landed, the rover drivers would have to live on Mars time. Because a Martian day lasts 24 hours, 39 minutes, rover team members would have to report to work 39 minutes later than the previous day. After much cajoling, a watchmaker by the name of [Garo Anserlian] was convinced to create a mechanical watch that lost 39 minutes per day, giving the team responsible for driving Spirit and Opportunity across the Martian desert these last eight years a temporal connection to the task at hand.
Of course, a lot happens in eight years. Now we have incredibly inexpensive, fully programmable TI Chronos watch, used by [Arko] to make a wristwatch set to Martian solar time. Instead of a master watchmaker selling the slowest wristwatch ever for hundreds of dollars, staying on Curiosity time is a simple matter of reprogramming a $50 wrist-mounted computer.
The build began by taking the default firmware for the Texas Instruments EZ430 Chronos wristwatch. In its stock configuration, the Chronos takes a 32.768khz clock signal, counts out clock pulses, and increments the number of seconds every time a counter reaches 32,768.
Because a Martian Sol is 24 hours, 39 minutes and 35 seconds of Earth time, [Arko] needed to program the seconds display to change every 1.027 Earth seconds. This meant changing the seconds every 33,668.833 clock cycles, instead of the Earth-oriented 32,768 clock cycles.
There’s one small glitch with that plan: the timer in the Chronos wristwatch can’t deal with floating point numbers, meaning [Arko] had to settle for incrementing the number of seconds ever 33,668 or 33,669 clock cycles. After a bit of math, [Arko] found using a value of 33,669 would mean his Martian time watch would only lose about 2 seconds a day, a minute after 78 Martian Sols, or 8.57 Martian minutes after one Martian year.
The build only took [Arko] five hours in front of his computer, and he doesn’t consider this to be a finished product. He plans on adding a few bells and whistles such as being able to display both Earth and Mars time. Still, an awesome build if your job description includes driving a rover across the Martian plains.
37 thoughts on “A Watch For Curiosity’s Drivers”
One way to get around the floating point limitation and keep more accurate time is to unroll the timing loop and alternately increment the seconds every 33,669 or 33,668 clock cycles.
If the desired seconds clock rate is 33,668.833 cycles/second, this is 33,668 and 5/6 clock cycles per second. Unroll the timing loop into 6 stages. In 5 of the stages, increment the seconds every 33,669 cycles. In the 6th stage, increment the seconds every 33668 cycles. This averages to the desired clock rate of 33,668.833.
Brilliant! This is a great idea! I will try it out :) thank you
You can do this kind of thing with zero error
You basically dither around the exact number of clocks you want.
you just need to shift the decimal point far enough to get the precision you want if your using only integer math.
IE multiply all the “floats” by 10 instead of using 33668.83 counts = 1 second 3366883 counts = 1 second, plug that into the maths in the link I sent you and you should wind up with 0 error.
Worst case hit me up with an email I’ll post something in your blog
This is basically the same thing as giving yourself a few extra bits of fixed-point precision. Since your counters aren’t all modulo-some-power-of-two, the effective bit count won’t be an integer.
Floating point is overused and overrated for tasks in which the range of numerical range is narrowly defined. But it is certainly convenient for the programmer, up until they start having mysterious accuracy problems due to unpredictable epsilons. Decide your precision requirements up front; for example, you might want to count money accurately to the nearest cent. No need for floating point there; just have an integer counting the number of cents! This is fixed point, and you’ll never have to worry about $0.03 looking like $0.029999999999999999.
Moreover, the properties of fixed-point numbers become very useful when the value being counted has a natural modulus, for example angles (360 degrees) or time of day (24 hours or [heh] 24.6597222 hours). If you scale your values such that they map directly to the magnitude range of the underlying storage, everything will wrap automatically. For example, if you use a sixteen-bit counter for your angles and you declare there to be 65,536 counts per revolution, you’ll never need to do “mod 360”. Just be sure you really do want your value to be limited. In the case of angles, there are applications where you actually want negative angles or angles greater than one revolution.
Another thing to mention: using fixed point avoids the need for exponent bits. A 32-bit integer has 32 bits of precision, whereas a 32-bit float has only 24 bits of precision, if you include the sign bit. And of course, fixed point is always available, unlike floating point.
The math in this article seems a touch off. If a Martian day is 88,775 seconds and an Earth day is 86,400 seconds, there would be ~33668.740=(33668+20/27)=(32768*88775/86400) quartz pulses per 1/86400th Martian day, not 33668.833.
However, that’s not the only thing that’s off. Per Wikipedia, a Martian day is long by 37 minutes 22.663 seconds, not 39 minutes 35 seconds. Redoing the math gives ~33618.550=(33618+46466/84375) quartz pulses per 1/86400th Martian day. That’s quite a bit faster.
46466 out of 84375 “seconds” (1/86400th Martian day), you will want to increment your “second” display whenever your counter reaches 33619; these are the slow seconds. The rest of the time (37909 out of 84375), increment your “second” display when the counter hits 33618; these are the fast seconds.
This requires being able to count to 84375. If you only have sixteen-bit counters, you might want to instead round 46466/84375 (~0.5507) to 1/2 (0.5). Then you alternate between slow and fast seconds, deciding which is which simply by checking if the current seconds display is even or odd.
“Range of numerical range”, heh. Pretend I said numerical magnitude.
Woah, great catch! I will update the code shortly!
I think people (initially andygoth) here are getting confused between a Sidereal Day and a Solar Day.
The Sidereal day (as you pick up from the Physical Characteristic section on Wikipedia) is the time it takes a body to do one complete rotation. But, by the time Mars has done a complete rotation from the previous day’s noon it’s moved a little bit round its orbit, so the sun is not yet as its highest point in the Martian sky, the planet has to rotate a little bit extra to get back to noon. That little bit extra on Mars is the difference you’ve found. For Earth the difference is a about 4 mins.
You obviously want the Solar day for working.
From further down in the Wiki article:
The Solar day on Mars is 24 hours, 39 minutes, and 35.244 seconds..
Hmm, researching further… we have yet more kinds of seconds to deal with. An Earth day lasts 86,400 “seconds of mean solar time” (a.k.a. “ephemeris seconds”), by definition. Such seconds are not equal to SI seconds; they’ve been getting longer since 1967, when the SI second was set equal to the ephemeris second. Going from this, watches (whose goal is to measure days and fractional days) already don’t use the same definition of second as physicists do. Therefore it makes sense for a Martian watch to use yet again a different definition of second in order to fit having 86,400 per Martian day. Sorry Snyder, but “seconds” aren’t even seconds on Earth, so why would they be on Mars?
Chris Jordan, yes you are right. I did use the Sidereal day. I had meant to say so, but lost that text in editing before I posted the comment. Your explanation makes sense, thank you.
Let’s go forward from the time period you state. This makes a Martian day “slow” by 2375.244 (Earth ephemeris) seconds, so each Martian ephemeris second lasts 33668.83328 ticks, or 33668+2604/3125. For 2604 out of 3125 seconds (being 1/86400 of a Martian day), count a slow second (which lasts 33669 ticks); the rest of the time, count a fast second (33668 ticks).
This is the same thing as DogsBody is saying, except I don’t round to 3/4 like he does. 3/4 is convenient because it makes it possible to decide whether it’s a fast or slow second just by looking at the current seconds display and comparing it to 45 (45/60=3/4). More sophisticated methods exist, but they involve dividing by fifteen; I’m not sure if that operation is supported on your platform.
Jon, I’ve updated the blog and latest code with this new modification! Thanks!
You’re welcome. It’s a cool project and I’m glad I was able to help.
Perhaps you should read this:
Though, I like that you’ve come to some of the same conclusions as NASA, who do use an extended second.
Perhaps the watch needs to show the Martian date too on the Darian Calendar too.
I don’t know why you wouldn’t just dither the results. Every 1000 seconds you would have the precise result. To simplify it you could use a 4 to 1 ratio and then every 1000 seconds do a 33 millisecond leapback.
I agree with Jon, that would certainly be the best way to go, other than getting a floating point capable chip. Cool thing though. Gave me the Idea to make a solar system wide clock! :D
Jon beat me to it :)
= 33668 5/6
= 7 * 28859 / 6
So set the overflow for 28859. Every 6th overflow count a fake 7th overflow.
Crap, that’s a speedup, my bad
I feel a bit bad that I still haven’t done anything with my Chronos I got for half price, but the install refused to work on my main pc and when I wore it as a normal watch it would reset too often to be useful in that respect.
Ah nuts, still getting uses to a touchscreen keyboard and put my username in wrong.
Bad, Bad, Bad.
Seconds are still seconds on Mars. You can’t go
redefining fundimental units of measure for convienece.
A better plan is to reset the hour counter to 0 after 24hours and the extra 39 minutes. 35 seconds.
That was the first program I made, but it turns out the team does not use that method to keep track of time. They scale the solar day so that the Sol is 24 hours. Both the android app and mars24 app have 24 hour sols. This is why I rewrote it with a modified second timer.
Software hack: change the timing loop (already discussed).
Hardware hack: change the oscillator. Load the crystal, detune to about 32.565 KHz and you are good to go.
32768 oscillators are very common and very inexpensive.
How would you go about building a precise 32.575kHz oscillator without exceeding the cost of the original mechanical watches made by Garo Anserlian?
the frequency is close enough that if you add (or possibly remove) capacitive load from the crystal, you can detune it to your target frequency.
IIRC, you can usually get 1-2% change out of a quartz crystal by changing the load capacitance.
8 tears ago mechanical watches were pretty antique just as they are now, 8 isn’t 80. Plus everybody check the time on his phone, and at control centers maybe a big clock on the wall or a screen clock I’m sure.
Still, it’s fun to have a mars-watch, I get that.
I wonder if it be possible to exploit the temperature stability of the crystal?That is put it in a cold(er) place such that the crystal’s speed drops to the aforementioned 32.575.Unfortunately i see that 32768 crystals are quite stable which rules out the practicality of this approach.
Does NASA only run the rovers in the sunlight? That would seem like a pretty expensive operation to not run 24hrs (and 39 minutes) a day. Does the rover not have batteries to store the daytime sun energy? If they run constantly then martian time would seem irrelevant.
In fact the rover uses nuclear, it doesn’t need Sun. I think they runs it only the day to be able to see. These camera are not made to run at night and it’s a waste of ressource.
During the night, the old solar rovers (one still working) probably use battery power on nothing but heating to keep themselves alive, especially when the mission controllers never quite know how much solar energy they will get per day (panels could accumulate more dust or possibly get cleaned by a wind storm).
Thankfully the recently-landed Curiosity rover mostly avoids this problem with its RTG power source. I haven’t heard if Curiosity actually drives at night or not. Not sure if the RTG has enough output to both heat itself to stay alive, and run the lights needed for the navigation cameras to see hazards while driving. Could also be that for navigation, it needs to see further out than the lights can reach.
Even if Curiosity doesn’t drive at night, some experiments (the laser spectrometer for example) might actually work better at night.
I wonder if they could have equipped Curiosity to find Spirit and Opportunity and repair them. That would have been very clever and frugal. In fact, perhaps all our rovers should go in pairs on short distance between them and be equipped to service each other – that is a lessons human Earth explorers learned from ancient times: “don’t go into wilderness alone, if anything bad happens to you, there’ll better be someone to help you”
24h:39m:35s is a bit larger than 1.027 earth day. Ticks should be every 33668.74.
By using 33669 osc-ticks/mars-sec you’re adding 22400 extra osc-ticks/mars-day (86400 mars-secs * 0.26 extra osc-ticks) or ~1/4sec.
You could get it closer, by counting three seconds of 33669 osc ticks followed by one of 33668. Averages to 33668.75, which is about 800 extra osc ticks/day, or 20msecs/day.
Assuming you want something decent. :-)
“..would only lose about 2 seconds a day, a minute after 78 Martian Sols, or 8.57 Martian minutes after one Martian year.”
If you know the drift of this watch you can counter it in software perfectly by e.g. waiting one second each half day. In turn it runs perfectly for its use. I hope they aren’t going to run scientific experiments with that watch.
If you need to reset the clock, do you need to reset the clocks for both worlds? That would be very bothersome.
It seems to me that you an derive the Martian clock from earth clock (provided you have the date), wouldn’t that be easier and not have to deal with precision issue?
hmm. I’m wondering if the Martian day is longer, does this mean the workers are putting in overtime, while only being credited for straight time?
I’m pretty sure if you work at Nasa you’re not quibbling about overtime.
What’s amazing here is the fact that Opportunity is still running strong on Mars after 8 years. It had an expected lifetime of just three months (technically 90 sols). So it’s about 32 TIMES beyond its warranty.
Curiosity’s expected lifetime is 2.5 years, to exceed its lifetime as much as Opportunity has is so long as to boggle the imagination – or NASA’s budget for the next couple of centuries.
I’m amused that mechanical watches were modified in 2004 for Spirit and Opportunity’s arrival at Mars. Even back in those dark ages it would have been possible to make a wrist-size microcontroller with a time display showing both Mars and Earth time. Now it’s trivial to write an app, and apps do exist for the iPhone and Android.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)