I recently built this:

http://jtauber.github.com/mars-clock/

It's a single web page with calculations being done live in Javascript.

It started off just as a way to calculate the LMST and LTST for Curiosity but it has a range of calculations for Mars overall from Allison and McEwen's 2000 paper.

Recently I've started adding explanations of each of the calculations including the formulas used.

It's been a huge learning experience for me and I'd appreciate any feedback, both in terms of experts correcting what I've done incorrectly and amateurs such as my self saying what they'd like elaboration on.

James, nice first post. Great contribution. This is what we like to see on UMSF.

Secondly, a question. Where does it get it's time reference from?
Is it a reference from an online time code source or is it getting its reference from the system clock on the local computer?

Also, just in terms of layout. Any chance of putting the clocks across the page with the mouse-over explanations underneath perhaps. It would save scrolling.

That's the great part of his work - you can check yourself how he did it:

(line 385) He's getting it from the browser, which in turn asks the system.

There's some offset between the various seconds ticking over. By reading the code, I take it that's a base amount you added on purpose to align the clock to the actual timekeeping millisecond, right?

The code's nice. The only two suggestions I'd make are, 1) setInterval at 10ms might not work so well on older browsers, especially IE8. Perhaps change the interval time based on the browser? 2) maybe for speed on that milliseconds display, update the texts during update via getElementById() rather than jQuery (but I doubt that's much of an improvement - jQuery's pretty fast, especially on post 2010 browsers)

Nice work!

This is fantastic. Useful and also quite pretty to look at. Please add Opportunity!

Usually when I'm looking for Mars time I'm looking to figure out Ls for a past date or the Earth date corresponding to a sol date or some such. I can do this using Mars24, but it's kludgy. I would love to have an easier way to do that (though I am not sure what I'd recommend as far as a user interface for that goes.)

I'm a big fan of separators to make it easier to see thousands, millions, &c.

I'll investigate adding Opportunity now :-)



I could try add separate pages for that. Let me add Opportunity first then I'll see about that.

Done!

So far I haven't been able to confirm how mission time is calculated for MER-B Opportunity.

http://www.giss.nasa.gov/tools/mars24/help/notes.html says



but also



and, in either case, I don't know the longitude to use. The values I've tried (such as 354.5 E) don't give a mission time anything like what Mars24 gives.

Perhaps I should ask on the Rover-specific forum. (mod: deleted duplicate thread)

Nevermind, I've worked it out.

It's calculated as Coordinated Mars Time / AMT -01:01:06.

I guess I could translate that to a longitude but there's no need to for my purposes.

And, done!

This is looking good, James. Your Oppy time agrees well with Lemmon's Oppy clock, which shows LMST. What is HLST?

Your Oppy clock differs from the MER filenames clock, but then that one shows LTST.

Awesome work! And well done with the explanations. I'll link to it in my next posts about Curiosity and Opportunity. I suggest you add a link to your clock in your signature on this forum -- saves people hunting for it and people asking "where is that clock again?"

HLST = Hybrid Local Solar Time (according to http://en.wikipedia.org/wiki/Timekeeping_on_Mars)

I first saw the term used on http://www.lpl.arizona.edu/~lemmon/mars-tau-b.html (presumably the same Lemmon )



If HLST is in fact LMST (which Lemmon's Oppy clock suggests it is) then I should be able to add LTST easily (as I just need to add the equation of time)

Thanks!

I've added LTST for Opportunity but it disagrees with http://www.greuti.ch/oppy/html/filenames_ltst.htm

I just added the equation of time to the LMST but not sure what the other site is doing differently.

LTST caused Tman issues when he built that if I recall correctly. I know there was a +-10 minute error problem at one stage but I can't recall how he corrected it. I remember that he used an old perl script of mine to look at an alternative way to calculate it but my code was based on the same sources as yours and I haven't looked at it in years so I can't throw any light on the issue right now.

You might find something in the original discussion here and it could be worth sending a PM to Tman. He hasn't logged in since late last year but a PM might alert him by e-mail and elicit a response.

Hi James,

Haven't done much with scripts and the program for ages and for sure I'm not up-to-date with the language - so I hope you don't want go too deep here.

Your Script has this:

Something has gone wrong here. HLST or 'Mission Time' is definitely not LMST.
I wonder why Oppy's one is so different from the Curiosity one. Where are Oppy's coordinates (longitude)? Did you use HLST instead of LMST for Oppy's LTST?

I guess the point here (in this Thread) is a 'little' confusion between HLST and LMST.

James, this is awesome. I have been working on a somewhat related project (in Ruby,
actually, not much different from Python).

I'd be interested in seeing if there might be some synergy possible here...

Would you mind contacting me offline?

Thanks!

Hal Fulton
rubyhacker@gmail.com

Can't sleep -- let's see if writing about time zones does it. :^) At least I'll clarify my sloppy use of "LMST".

Technically, I should have used HLST in the MER clocks, as I do on the tau page. LTST (local true solar time) is defined by 0:00 being local true midnight every day, with the length of a "second" (etc.) changing over the year due to the elliptical orbit (equation of time). LMST is a special case of what I call "time zone time". It has a fixed second (slightly longer than an SI second), and a fixed day (24-hour) duration that is equal to the average duration of the solar day. Once you define a meridian, you know the offset from any fixed reference time. In theory, LMST uses ones actual (local) meridian, thus it is a "solar time" that is both "local" and "mean". For MER, the actual meridian was dropped in favor of a nearby one that made LTST and planning time align during the 90-sol mission. Thus, "hybrid local solar time", HLST (not sure why they dropped "mean" and kept "local"--seems backwards). LMST is like being in the sweet spot of your time zone on Earth; HLST is like being somewhere else in your time zone. To me, that distinction is, philosophically, small. It is how you set your watch, not how fast your watch runs. If you use things like EDT or PST or CEST, you use types of HLST (even if that term is--rightly--not in general use).

In practice, I look at what NAIF says about the planning time[*] of the midnight immediately preceding landing, so I use a fixed time reference rather than a longitude. The MSL time reference is a suspiciously round number. So, I have suspected it is really an HLST (maybe just a "local-ish mean solar time"), but have never cared enough to ask or verify. I prefer to set my clock and move on. So I guess I do the mission clocks the way I use my watch on this planet--my airplane lands, they tell me what time it is; I never ask what longitude it is, and I don't adjust my watch as I "rove" until I hit a time zone line.

I'll put up a page for Curiosity ASAP (I run the clock on my laptop). The clock won't surprise anyone who has Mars24--but you can see the numbers & math in the javascript file. (The "tau" part will be content free, probably for a long time--at this stage for MER none of that was available.)

* I use planning time as a generic term that includes HLST, LMST, or whatever framework people use when scheduling activities. LTST may factor into our thinking, but planning time uses a fixed second. I don't even want to get into SCET or SCLK[**]--those are downstream of the activity planning process. (I find that very few people know when they are with respect to seconds past Jan 1, 2000, at any given time, but non-sarcastic rovers almost always do.)

** I guess I should add: Spacecraft Event Time in UTC; Spacecraft Clock.[***]

*** Oh my, I've got footnotes to my footnotes. Time to go.

Thanks Marc for your clarifications.

For Spacecrafts on Mars and along with their images it's nice to have local true solar time, since the position and motion of the sun is so dominant.

For my MER Filename decoder, that is trying to get LTST for each entered image link or code, I've never used any SCLKs to synchronize the seconds past Jan 1, 2000. No clue how to use and get it into my JavaScript program.
(Btw, I just see there was another adjustment on 05 Sep 2012)

Instead of that, I still go via the Pancam Data Tracking Web Interface to get the current drift of the Spacecraft's clock on Mars. Where I mean there is always an assumed constant drift implemented, till the next monthly or more "clock adjustment session" between Earth and the Spacecraft is performed, where then the time will be finally correct adjusted for this day/sol (as I understand that).
You can find this/my calculation in the javascript file under // Start Clock Correction Spirit (or Opportunity).

That's the whole thing that I use now for my 'new' MSL clock and image decoder too, but where I have to go without such as the Data Tracking Web Interface.
Until further options, I've assumed that in the official Raw Images site the UTC time below the images are accurate, i.e. it is possible to get the drift of MSL's clock on Mars of them.
So it goes currently with that displayed drift together with the seconds in the filename code of the images - when they are integrated. Otherwise have a look at the tooltip below the enter box for more options.

The above display of the current Sol and local time should as usually be accurat as Mars24 - still correlated with the system time accuracy of the executing computer and the used coordinates.

Great thread! I reprogrammed my TI Chronos watch a few months back to keep track of Curiosity's time.

http://arkorobotics.com/blog/?p=93

You guys are more than welcome to take a look at my code and try it out. Pretty straightforward code and the watch has only drifted 4 minutes since September (I just recently re tuned it).