Mars Clock Options

[Tman]

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:

CODE

                var curiosity_lambda = 360 - 137.4;
                var curiosity_sol = Math.floor(msd - curiosity_lambda / 360) - 49268;
                var curiosity_lmst = within_24(mtc - curiosity_lambda * 24 / 360);
                var curiosity_ltst = within_24(curiosity_lmst + eot * 24 / 360);
                
                var opportunity_sol_date = msd - 46235 - 0.042431;
                var opportunity_sol = Math.floor(opportunity_sol_date);
                var opportunity_mission = (24 * opportunity_sol_date) % 24;
                var opportunity_ltst = within_24(opportunity_mission + eot * 24 / 360)

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.

[Hal Fulton]

I recently built this:

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

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

[Deimos]

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.

[Tman]

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.

[arko]

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).