More about the Tianwen-1 timestamps

In my previous post I explained how our problems using the orbit state vectors transmitted in the telemetry of Tianwen-1 were caused by an incorrect interpretation of the timestamps attached to these vectors. The timestamp is a 32 bit counter with a 100us resolution, but the difficulty is that the epoch of this counter is not known. It seems that the epoch is around 2020-07-23 00:00 UTC, which is the day of launch, but not quite because approximately 57 minutes need to be subtracted from the epoch.

In my post I used some sort of experimental procedure to determine the correction that needs to be subtracted from the timestamp, and I obtained 3400.2 seconds, which I believe should be accurate to within a few seconds.

However, I found this correction somewhat unsatisfactory, as I wasn’t able to explain where it comes from. Now I think I have found a reasonable explanation.

The thing that has led me to find the explanation is the rollover of the 32 bit counter. Such a counter will roll over every 4.97 days, so the first rollover we’ve seen happened yesterday at around 2020-07-27 22:22 UTC. The interesting thing is what has happened with the bytes preceding the timestamp. Before the rollover, the two bytes before the 32 bit timestamp had the value 0x014f. Without further context, this could be a field meaning anything. But after the rollover those bytes have changed to 0x0150. The simplest explanation is that the counter is 48 bits wide instead of 32 bit. In fact, using a 32 bit counter with such a short rollover period would be a bit uncomfortable.

Whereas in my previous post I used the epoch 2020-07-22 23:03:19.8 UTC as corresponding to the 32 bit counter value of 0x00000000, now we learn that the correct 48 bit counter value is 0x014f00000000. If we work out what is the timestamp corresponding to the 48 bit counter value 0x014f00000000, we get 2015-12-31 15:59:55.384 UTC. Now, this is pretty close to 2015-12-31 16:00:00 UTC, which is in fact 2016-01-01 00:00 Beijing time. So I guess that this is the correct epoch, and my attempt to estimate the correction had an error of 4.616 seconds.

From my experience I reckon it makes a lot of sense for a Chinese spacecraft to use Beijing time. In fact, during the Longjiang-2 mission we had to work both with Beijing time and UTC. Occasionally we had some problems due to mix-ups between these, as you can read in this post. To be honest, during the last few days I was sort of expecting to find the difference between UTC and Beijing time somewhere, but couldn’t.

So it seems that the mystery is solved. The fact that 0x014f00000000 was close to 2020-07-23 00:00 UTC was a red herring that left us wondering for a few days. From now I will be using 2015-12-31 16:00:00 UTC as the epoch for the 48 bit counter.

Why UTC and not TAI, GPS or any of the other timescales? Well, any choice would be justifiable, but since my attempt to find the correct epoch differs only in 4.6 seconds from the interpretation using 2015-12-31 16:00:00 UTC and TAI, GPS and other timescales differ much more than this from UTC, I guess that UTC is the appropriate choice.

Even though the change of 4.616 seconds with respect to the epoch I considered in my previous post is small, I have run again the comparison with Project Pluto optical ephemerides. We see that the error in right ascension has improved, since before it was around -13 arcseconds. The declination error is still very similar.

Speaking of this comparison, it is perhaps convenient to remark that I am not considering light-time delay when computing the right ascension and declination coordinates in GMAT. I don’t know if the Project Pluto ephemerides include this effect or no, but I think that it should be on the sub-arcsecond level.

I have updated my state vector extraction Python script to use the new epoch of 2015-12-31 16:00:00 UTC. I am also parsing CCSDS Space Packets appropriately to extract the state vectors, since my naïve approach described in the previous post was broken by a change in the telemetry layout.

In order to prevent any future mistakes or ambiguity with the timestamps, both r00t.cz and I are now printing the value of the 48 bit counter in hex with the state vectors. The most recent state vector we have as of writing this post is

[01501aba489e] 2020-07-28 10:49:02.735800 89863673.8787385 -113018692.66463104 -48678816.82643805 27.01057277640917 16.63007185316535 7.870227496859988

It was collected by Paul Marsh M0EYT this morning.