Drifting Spacecraft Time - A Solution ?

Description and discussion of registration and use of the Data Warehouse

Moderators: pa3weg, g4dpz, admin

Drifting Spacecraft Time - A Solution ?

Postby G7III » Sun Aug 17, 2014 8:35 pm

Not quite sure where to post this suggestion, but since it would have an impact on the warehouse, I chose here. Maybe it might be time to create a new area within the forum for generic technical discussions ? (I do have another one coming up re Funcube-1's behaviour coming out of eclipse) Anyway, here goes:

I see on the warehouse website there is a note about the spacecraft time, and that it (understably) drifts, to quote: "The date/time in the csv file is 'SatelliteTime' It is based on the number for sequences / frames it has transmitted since spacecraft initialisation after separation (2013-11-21 07:38:16). This time will drift as it is based on the MCU clock which is not temperature controlled. In the future we may be able to give realtime if we can model the drift". Being a time-nut (related to the time-lords...) I couldn't resist giving this some thought.

I'm not sure there is a need to model the drift, rather than actually just measure it. What we need is stations that are syncronised with UTC, either via a GPS Disiplined Oscillator, or other means. If we record the UTC time when we receive each frame, then by calculating the spacecraft time (which I assume is spacecraft_epoch (5*sequence_number) [Yes yes, roll overs, reboots we will have to deal with], we can calculate the offset of the spacecraft clock from UTC *for each frame*, espesially if we take into consideration the delay in transmitting the frame through space, which should be easily calculateable from distance, which is easily grabbed from a predict server. Essentially:

frame_rxtime_utc = utc - (tlmframe-signal_delay) # Possibly minus another 5 seconds due to the length of time to transmit the frame, would depend on the logic
spacecraft_offset = abs(frame_rxtime_utc - tlmframe_time


spacecraft_epoch is 2013-11-21 07:38:16 expressed as the number of seconds since 01-01-1970.
frame_rxtime_utc is the UTC Time of the received frame *adjusted for signal delay*
frame_offset is the difference between UTC and Spacecraft Time *when that frame was transmitted*

To be honest the signal delay adjustment probably isn't needed, but us time-nuts like accuracy :)

I have no idea how easy or difficult it might be to add extra code to the Dashboard to do this [Its a simple gettimeofday() call or Windows equivelent], but more of a concern would be being sure that the reference clock on the PC is aligned with UTC.

Since I'm using the Linux decoder, and have access to a GPSDO, I will try to hack together something to do this in the next few weeks (While it won't take me long, things are going to be busy for the next fortnight). I probably get 30-40 packets on average on a "good pass" of FC1 (I have an issue on the evening pass as she comes out of eclipse at the moment, more on that in another post). To begin with, I am simply thinking of a CSV format text file, with the following fields:

UTC Time of Receive Frame (Adjusted for signal delay)
Spacecraft Time (Calculated from the Spacecraft and Sequence Number)
Spacecraft Clock Offset (Calculated as per above)
Sequence Number (For Reference)
TLM Frame Itself (For Reference)

Doing it this way allows some awking, cutting and grepping, which would allow the frame to be sent on up to the Warehouse free of the extra info.

Would it be useful to folks to be able to have a record of the offset of the spacecraft's clock offset to UTC ? Anyone else using the Linux decoder from OZ9AEC interested ? That would gain us more data on the drift if more of us were doing it ?
Further additions could add temperature and eclipse/sunlight data, so maybe we could actually detect how the drift is related to temperature...


Posts: 3
Joined: Fri Aug 15, 2014 9:46 pm

Re: Drifting Spacecraft Time - A Solution ?

Postby Phlash » Sun Sep 14, 2014 9:49 pm

Hi Iain,

Just one thought from me - it might be better to separate the UTC receive time from the predicted transmission delay when recording information in the CSV, along with the satellite position prediction co-ordinates. This permits later correction if required. For time nuts, how about also recording the NTP precision (if using NTP), or local GPSDO error certainty?

Have fun,
Posts: 7
Joined: Thu Dec 26, 2013 4:07 pm

Return to Support

Who is online

Users browsing this forum: No registered users and 1 guest