Use GPS time to set T0 for LTM / GOLF

[ac2cz]

We receive the GPS time with Diagnostic records. The first Diagnostic record in each reset could be used to set T0. If no diagnostic records are received then we could default to the time on the ground.

Additionally we can compare the GPS time to the time on the ground to confirm it is working and to track the drift of the spacecraft clock.

[ac2cz]

Priority raised as we need a mechanism to support this after launch.

[burnsfisher]

This would be good for MESAT-1 also, although GPS time is in a different location. Let me know if I should find some way to tag it for you in each satellite that has it.

[ac2cz]

If it is pretty similar then I can just use this to track. If it turns out to be substantially different then we may want a separate record.

This is on the list of "things to do to setup the server". I usually work on that a couple of months before launch and run a test with interested parties. Typically I use recordings from the flight unit tests, so that is a dependency.

[burnsfisher]

Actually, it IS on a Diagnostics tab. I forgot that there was one for MESAT. So likely similar.

On Fri, Apr 1, 2022 at 5:20 PM Chris Thompson @.***> wrote:

If it is pretty similar then I can just use this to track. If it turns out to be substantially different then we may want a separate record.

This is on the list of "things to do to setup the server". I usually work on that a couple of months before launch and run a test with interested parties. Typically I use recordings from the flight unit tests, so that is a dependency.

— Reply to this email directly, view it on GitHub https://github.com/ac2cz/FoxTelem/issues/715#issuecomment-1086334892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASNGPGE7EGN5MBU4NNIRTTVC5SC5ANCNFSM5F7U3RHQ . You are receiving this because you commented.Message ID: @.***>

[ac2cz]

My initial design is as follows:

The MASTER file will contain a flag that indicates the spacecraft has a GPS Timebase.
hasGPSTime=true

The MASTER file will also contain a flag that allows the user to decide if T0 is set from the GPS time or from the T0 file from amsat.org. This is a safety mechanism in case the GPS time does not work. We can then turn it off in FoxTelem and amsat ops will need to maintain T0 as normal. This might be better as a central flag, but for now it will be changeable in FoxTelem. user_useGPSTimeForT0=true

If a spacecraft MASTER file contains hasGPSTime=true then at least one payload should indicate that it contains the GPS time. For MESAT1 payload 5 has the GPS time so that is indicated with: layout5.hasGPSTime=true

Note that all of these flags can be setup and changed with the SpacecraftEditor and I have made these changes for MESAT1. But nothing has been done yet for GOLF-T.

The fields for the GPS time must be exactly as defined below (based on the fields for MESAT1): public static final String GPS_VALID = "UTCValid"; public static final String GPS_SECONDS = "UTCSeconds"; public static final String GPS_MINUTES = "UTCMinutes"; public static final String GPS_HOURS = "UTCHours"; public static final String GPS_DAY = "UTCDay"; public static final String GPS_MONTH = "UTCMonth"; public static final String GPS_YEAR = "UTCYear";

When a frame is received that contains the GPS time then the timestamp is calculated from its component parts. If we have user_useGPSTimeForT0=true in the spacecraft file then T0 for the current reset is calculated and saved to the T0 file. This is then used when plotting the graphs as normal.

This code will also run on the server, which will build a comprehensive T0 file for all received timestamps. As usual, FoxTelem will download the latest version of this file when it starts up and periodically when running for a long time.

There are some questions to address:

1. We will likely receive many GPS Timestamps for a given reset. Do we use the first timestamp, the last timestamp or an average of all timestamps to set T0? A later design may well store multiple timestamps at many uptimes, so that a more accurate time can be interpolated, but for now we will try to automatically set T0.
2. When the T0 file from the server is downloaded it is possible that it overwrites a timestamp that the user has received. This will only happen if frames are not being sent to the server.
3. Is user_useGPSTimeForT0 required? If the mechanism for GPS timestamps does not work and we maintain the T0 file as normal at amsat.org, then the T0 file will overwrite any incorrect timestamps.

[ac2cz]

This is implemented in 1.12y. A couple of notes.

1. The very first timestamp is used to set T0. I notice that the next timestamp in my test file is 6 seconds different. I could average the timestamps, but for how many? Surely the earlier timestamps will be more accurate than later ones, given a large uptime drifts. Unless we implement multiple timestamps within a reset, it seems prudent to use the first timestamp.
2. This should be left open until it is tested on the server.

[burnsfisher]

A couple things. First about the six seconds difference: What you may not have seen (and I may have neglected to tell you) is that along with the GPS time is also sent the spacecraft time in seconds at the time the GPS time was received. (Called SecondsInEpoch I think) That is what the s/c T0 should be calculated. There might well be a varying amount of time between GPS and the downlink time since the GPS time is sent to the IHU asynchronously from when the IHU downlinks the telemetry. The epoch is NOT sent because the GPS time will always have been captured during the current epoch.

[burnsfisher]

Regarding which GPS time: Clearly, as you say, it would be best to have multiple time hacks since the S/C time will certainly drift. But I'd be tempted to say that the local FoxTelem should default to NOT using the downloaded time, so long as the server has it and updates T0. That way the online version and everyone with FoxTelem is consistent. And again for consistency, I think that I'd take the first (or 2nd or 3rd) data that comes into the server. If you took the latest or average then it would keep changing.

But note that you are no longer restricted to "trusted" stations. The GPS time, Epoch, and S/C Seconds are all part of the telemetry with no dependency on the time it was sent to the server.

[ac2cz]

Ok, thanks for pointing out the secsInEpoch field. I see that and will use the value there.

I think I have an approach that will work with the server and the local FoxTelem. The server version will be the master and will overwrite what you have locally. So everyone will have the same. However, if you have received a timestamp for a new reset that is not yet on the server then you will temporarily have the new value locally.