GRAIL Time Transfer Assembly Algorithm Document
JPL D-61501
Copyright 2013 California Institute of Technology. Government sponsorship
acknowledged.
Prepared:
Courtney Duncan, GRAIL GPA System Engineer
Concurred:
Charles Dunn, GRAIL Payload Manager
Revisions
2009 July 15, Version 1.2
2009 April 18, Version 1.1
2009 January 26, Version 1.0
Purpose
This document describes the GRAIL TTA and MWA frequency scheme. An
accompanying spreadsheet supports the calculations.
GRAIL-A
USO frequency.
4.832000 MHz
X 8 to GPA = 38.656000 MHz
X 12 to MWA = 57.984000 MHz
Ka-Band MWA multiplies by 564 = 32702.976000 MHz (=GRAIL-B - 670032 Hz)
One tone integration is 20.000000 milliseconds of which 19.000000
milliseconds is non-dead time and 1.000000 millisecond is dead time.
The tone integration rate is 50 per second.
Synthesizer Ratio
GPA_refA* 52.5 + 39333 / 524288 =
GPA_refA * 27564453 / 524288 = 2032340040.527344 Hz to 16 digits.
Sample Rate
GPA_refA / 2 = 19.328000 MHz (This is the "P-Code" rate.)
The signal is sampled at 38.656000 MHz and every other sample is discarded.
Chipping Rate
C/A code divider: 20
C/A chip rate = SampRate / 20 = 966400 chips / second
(Details of the ASIC divide by 20 are shown in the accompanying spreadsheet.)
Code Cycle
1023 chips
cycle rate = chip rate / 1023 = 944.672532 code cycles / second (~msec)
Per second, this is exactly 944 cycles with a remainder of 688 chips. Epochs
are calculated from this.
Databits
20 code cycles = 20460 chips
databit rate = chip rate / 1023 / 20 = 47.233627 bits / second (~50)
databit length = 21.171 milliseconds.
Data Message
256 databits in a message.
Message length = (1023 * 20 * 256) / chip rate = 5.419868 seconds (~6 sec.)
One 32-bit long in each 120-bit message contains the time code. The high
order 14 bits are the "repeat count" (explained below) and the low order 18
bits are the "message count." Each bit in the message excepting those in
the synchronization and end codes are duplicated with an inverse (explained
below) such that it takes 240 bits to send the 120-bit message. The message
contains an 8 bit synchronization code and an 8 bit end code making a total
of 8 + 240 + 8 = 256 bits per message.
Both GRAILs have a databit edge on a one second epoch every 5115 seconds
(1 hr. 25 m. 15 s.) A "fortnight" is 256 of these periods. (See GRAIL-A
and GRAIL-B below.)
Fortnight = 5115 * 256 = 1309440 seconds (15 d. 3 hr. 44 m. 0 s.)
There are 241600 GRAIL-A data messages in a fortnight. This is 0x3afc0 (18
bits wide) meaning that the message count rolls over from 0x3afbf to 0x00000
each fortnight.
GRAIL-B
USO frequency.
4.832099 MHz (=GRAIL-A + 99 Hz)
X 8 to GPA = 38.656792 MHz
X 12 to MWA = 57.985188 MHz
Ka-Band MWA multiplies by 564 = 32703.646032 MHz (=GRAIL-A + 670032 Hz)
One tone integration is 19.999590 milliseconds of which 18.999611
milliseconds is non-dead time and 0.999980 millisecond is dead time.
The tone integration rate is 50.001024 per second.
Synthesizer Ratio
GPA_refB * 57 + 48322 / 524288 =
GPA_refB * 29932738 / 524288 = 2207.000020707123 Hz to 16 digits.
Sample Rate
GPA_refB / 2 = 19.328792 MHz (This is the "P-Code" rate.)
The signal is sampled at 38.656792 MHz and every other sample is discarded.
Chipping Rate
C/A code divider: 19
C/A chip rate = SampRate / 19 = 1017284 chips / second
(Details of the ASIC divide by 19 are shown in the accompanying spreadsheet.)
Code Cycle
1023 chips
cycle rate = chip rate / 1023 = 994.412512 code cycles / second (~msec)
Per second, this is exactly 994 cycles with a remainder of 422 chips.
Epochs are calculated from this.
Databits
20 code cycles = 20460 chips
databit rate = chip rate / 1023 / 19 = 49.720626 bits / second (~50)
databit length = 20.112 milliseconds.
Data Message
256 databits in a message.
Message length = (1023 * 19 * 256) / chip rate = 5.148769 seconds (~6 sec.)
One 32-bit long in each 120-bit message contains the time code. The high
order 14 bits are the "repeat count" (explained below) and the low order 18
bits are the "message count." Each bit in the message excepting those in
the synchronization and end codes are duplicated with an inverse (explained
below) such that it takes 240 bits to send the 120-bit message. The message
contains an 8 bit synchronization code and an 8 bit end code making a total
of 8 + 240 + 8 = 256 bits per message.
Both GRAILs have a databit edge on a one second epoch is every 5115 seconds
(1 hr. 25 m. 15 s.) A "fortnight" is 256 of these periods.
Fortnight = 5115 * 256 = 1309440 seconds (15 d. 3 hr. 44 m. 0 s.)
There are 254321 GRAIL-B data messages in a fortnight. This is 0x3E171 (18
bits wide) meaning that the message count rolls over from 0x3E170 to 0x00000
each fortnight.
GRAIL-A and GRAIL-B
Ka-Band Beat Frequency
Difference in USOs: 99 Hz
X 8 to GPA = 792 Hz
X 12 to MWA = 1188 Hz
Ka-Band MWA multiplies by 564 = 670032 Hz.
(For reference: 12 X 564 = 6768 )
The tone integration rates of 50.000000 and 50.001024 per second cause
GRAIL-B 20 millisecond integrations to lap those of GRAIL-A every 976.161616
seconds (16 m. 16.161616 s.). The two rates lap at one second (that is,
fifty 20 millisecond laps) every 48808.080808 seconds
(13 h. 33 m. 28.080808 s.) but do not occur together on an integer second
for 241,600,000 seconds (7.7 years). Note: This number is not related to a
Fortnight.
Carrier Offsets
GRAIL-A uses a scheme based on its USO to sample the signal from GRAIL-B
generated from the scheme based on its USO. This results in a baseband
carrier offset from subharmonic sampling as follows:
Carrier Offset = GR-B-tx - GR-A-samp * int(GR-B-tx / GR-A-samp)
= 2207.00002070712 - 19.328000 * int(2207.00002070712 / 19.328000)
= 3.60802070712271 MHz for the S-Band signal.
The virtual local oscillator is 114 * GR-A-samp = 2203.392000 MHz.
GRAIL-B uses a scheme based on its USO to sample the signal from GRAIL-A
generated from the scheme based on its USO. This results in a baseband
carrier offset from subharmonic sampling as follows:
Carrier Offset = GR-A-tx - GR-B-samp * int(GR-A-tx / GR-B-samp)
= 2032.34004052734 - 19.328396 * int(2032.34004052734 / 19.328396)
= 2.85846052734405 MHz for the S-Band signal.
The virtual local oscillator is 105 * GR-B-samp = 2029.481580 MHz.
Fortnights
GRAIL-A has a databit edge occur on a one-second edge every 1023 seconds
(17 m. 3 s.) but GRAIL-B only has this every 5115 seconds = 5 * 1023
(1 h. 25 m. 15 s.). There are 256 of these 5115 second periods in a
fortnight because this is how often GRAIL-A and GRAIL-B data messages start
at the same time and on an integer second.
Fortnights are therefore calculated differently on each side but the number
of seconds in a fortnight is the same (1309440).
GPA-A and GPA-B send data messages every 5.419868 and 5.148769 seconds
respectively. GPA-B sends 254321 - 241600 = 12721 more messages in a
fortnight than GPA-A does, message lapping it about every 102.935 seconds.
12721 is prime so there is no shorter period of time in which both data
messages start on an integer second than a fortnight.
Note that a colloquial fortnight is two weeks. A GRAIL fortnight is 15
days, 3 hours 44 minutes and 0 seconds and is referred to as a "GRAIL
fortnight," a "fort-time," or, in context of a GRAIL discussion, a
"fortnight."
GRAIL Ambiguity
The 14-bit repeat count counts fortnights. This means that the fundamental
ambiguity of the Time Code is
2^14 * 1309440 = 21453864960 seconds = 679.8 Julian years.
At that time, the fortnight counter wraps from 0x3FFF to 0x0000.
Note that 21453864960 takes 35 bits to represent (~5 X 2^32) so problems in
the seconds-since counters will more likely occur after only 136 years, as
is the case with GPS which counts seconds since 1980. (i.e. 2116)
Contents of Data Message
The data message is 256 bits long. All but the first ten and last eight
bits are coded in order to preserve a maximum number of bit edge transitions
for tracking. The encoding of one bit with two is as follows:
0b0 encodes to 0b01
0b1 encodes to 0b10
The first 12 bits of the message are
0x8BX where 0x8B is the synch byte (as in GPS) and
X is 0bppgg where g is
0b01 for GRAIL-1 and
0b10 for GRAIL-2 and
pp is set to 0b10 or 0b00 to provide correct parity for the entire message.
(Note that the one-bit GRAIL flag is encoded into two bits per the encoding
scheme.)
The next 20 bits are ten encoded zeros, that is, 0x555555. Therefore,
Message[0] = 0x8BX55555, with X defined above.
Continuing,
Message[1,2] = 14 bit fortnight count and 18 bit message index encoded into
64 bits.
Message[3,6] = 64 bit double encoded into 128 bits. This double represents
the time offset measured at the transmitting GPA. This is used by the
receiving GPA to compute the absolute clock offset and range as discussed
below.
Message[7] contains a 12 bit status word encoded into 24 bits followed by
the 8 bit end flag 0xF0. Currently, the status word (Status2) is unused and
is set to 0xFFF, therefore
Message[7] = 0xCCCCCCF0.
Note that with the encoding pattern, it is impossible for more than two ones
or two zeros to occur in a row. Therefore, the synch pattern 0x8B and the
end flag 0xF0 cannot occur in the data and, apart from the possibility of
bit reception errors, there is no possibility of false synch.
In the ongoing data stream, the end flag 0xF0 is immediately followed by the
next synch code 0x8B.
Calculation of "seconds since" from the Time Code
Both sides keep time in message indexes and fortnights as described above.
For GRAIL-A a 256 databit message is 5.419868 seconds long and there are
241600 of them in a fortnight.
For GRAIL-B a 256 databit message is 5.148769 seconds long and there are
254321 of them in a fortnight.
GRAIL-A and GRAIL-B both have 256 * 20 * 1023 = 5,237,760 chips per data
message where
256 is the number of bits per message,
20 is the number of code cycles in a databit, and
1023 is the number of chips in a code cycle.
The number of "seconds since" the time origin is calculated by converting
the time code in the message to chips and then to seconds using the
side-specific chipping rate. The durations of chips, bits, and messages are
different on the two sides, but the length of the second is the same.
Note: Due to the start-up strategy, the origin of GPA time will ordinarily
be one fortnight and 42 seconds previous to the first GPA of the pair to
boot up initially.
Calculate GRAIL-A seconds-since at end-of-message from its data message as
Fortnights * 1,309,440 + (message index) * 5,237,760 / 966,400
Calculate GRAIL-B seconds-since at end-of-message from its data message as
Fortnights * 1,309,440 + (message index) * 5,237,760 / 1,017,284
Where
1,309,440 is the number of seconds in a fortnight;
5,237,760 is the number of chips per data message;
966,400 is the number of chips per second on GRAIL-A: 19,328,000 / 20;
1,017,284 is the number of chips per second on GRAIL-B: 19,328,396 / 19;
19,328,000 is the sample frequency of GRAIL-A; and
19,328,396 is the sample frequency of GRAIL-B.
Calculation of Clock Offset and Range
When the GPAs are tracking each other they each compute a pseudorange
between the two systems. The pseudorange is the difference between "seconds
since" calculated from the received message (above) and the corresponding
"seconds since" at the receiving instant in the receiving GPA.
At GPA A,
prAB = TimeA - TimeB at the GPA A measurement epoch.
For GPA B,
prBA = TimeB - TimeA at the GPA B measurement epoch.
A second-order effect due to drift between the clocks during the signal
time-of-flight is neglected.
In the unlikely case that the clocks are exactly synchronized,
prAB = prBA = range / C (seconds) (C is the speed of light) and
offset = 0.
Each GPA calculates its own pseudorange and transmits this value in the data
message to the other GPA so that both GPAs have both pseudoranges from which
they can perform range and clock offset calculations.
In the general case, both the range and the clock offset are calculated from
the two pseudoranges:
range / C = ( prAB + prBA ) / 2
and
offsetAB = -offsetBA = ( prAB - prBA ) / 2.
Nudge
"Nudging" is the process of correcting the present receiver's time by some
amount to bring it into synchronization with another source, in this case
the other GPA. (This concept is inherited from GPS where the receiver is
synchronized to GPS time after a point position solution with clock offset
has been calculated successfully.) Typically, both integer and fractional
parts of the time are changed, so the 1 PPS output phase will typically
change when the nudge occurs.
Synchronization of the two-GPA system involves a nudge on one end and a
possible integer time count correction on the other described below. The
amount to nudge or correct comes from the clock offset calculation described
above.
When this is complete, the 1 PPS output signals of both GPAs are
synchronized. The offset between them subsequently should be the same as
subsequently calculated clock offsets.
(The cases of the system wrapping around to zero time after 679.8 years and
causing possible confusion to the initial synchronization process or of the
seconds-since integer part counter wrapping 2^32 are not addressed in the
code.)
There is no clock "steering" on GRAIL since the standard is the USO outside
of the GPA. The clock offset is therefore allowed to drift to arbitrary
size. The synchronization requirement is 100 nanosecond knowledge so the
calculated clock offset must be accurate to 100 nanoseconds.
The clock offset immediately after a nudge should not be much larger than
one sample time, about 50 nanoseconds but this offset will grow with time
since the USOs are not expected to be exactly on their nominal frequencies.
How Time Transfer Works
In GPS, the raw count of seconds in a receiver is adjusted to "seconds since
1980" from the navigation solution and adjusted to UTC for display purposes
using leap seconds from the GPS navigation message.
GRAIL GPAs have no concept of "UTC" or "GPS Time" but they do count integer
seconds and establish their own ad hoc time origin in order to synchronize
their clocks.
When a GPA boots up, it starts counting the seconds of its internally
generated 1 PPS at the number 42 (heritage from Black Jack). After "Beep"
mode and loading operating software, it begins transmitting ranging code on
its S-Band transmitter. The ranging code is calculated from the GPA raw
seconds count as described below.
Each GPA calculates the ranging code it transmits from its own "seconds
since" count and calculates the "seconds since" of the other GPA from the
ranging code it receives.
The GPA with the larger seconds since count, that is, the one that was
booted first or already has its clock set, is considered the standard in the
following clock synchronization scenarios. Consider the present GPA to be
"A" and the other GPA to be "B."
Two conditions are being satisfied by the synchronization algorithm:
1. The pulse per second (1 PPS) phase will be the same on both ends (within
a sample time ~ 50 nanoseconds).
2. Both clocks will read a time greater than a fortnight.
First, form dt = TimeB - TimeA. This is the amount by which we want to
change (or "nudge") TimeA to match TimeB.
Case 1
If dt < 0, that is, TimeB < TimeA and TimeA is already greater than a
fortnight, we do nothing.
GPA B is in Case 3 and will perform all of the correction.
Case 2
If dt < 0, that is, TimeB < TimeA and TimeA is less than a fortnight, we
increase TimeA by a fortnight.
GPA B is now in Case 3 (if it has not yet calculated its own dt) or Case 4
(if it has) and will perform the remainder of the correction.
Case 3
If dt >= 0, that is, TimeB >= TimeA, and either dt or TimeA is greater than
a fortnight, we adjust our time by dt.
GPA B was in Case 1 when we made our dt calculation.
Case 4
If dt >= 0, that is, TimeB >= TimeA, but dt is less than a fortnight and
TimeA is less than a fortnight, we increase dt by a fortnight and adjust our
time by dt.
GPA B was in Case 2 when we made our calculation and will also correct its
own clock by exactly a fortnight.
Clocks are now synchronized.
The upshot of this approach is that if during science operations, one GPA
restarts, the other GPA maintains the ongoing seconds-since count and 1 PPS
phase and the restarted GPA synchronizes to it. In the case where both
receivers start or restart, the one that starts counting first sets the
initial seconds-since count and 1 PPS phase.
It is unlikely that during a mapping phase both GPAs will be down at the
same time, so it is likely that, once established, there will be a monotonic
system seconds-since count for each mapping phase.
Acronymns
DOWO Dual One Way [Clock] Offset
DOWR Dual One Way Range
EM Engineering Model
IF Intermediate Frequency
LO Local Oscillator
GPA Gravity Processor Assembly
GRAIL Gravity and Interior Laboratoy
MWA Microwave Assembly (32 GHz to 670 KHz conversion)
"Seconds Since" Time elapsed since the "origin of time"
TTA Time Transfer Assembly
USO Ultra Stable Oscillator