Gold codes (this article calls them chipping codes) can be used to solve a lot of engineering problems where you need to synchronise two things. Eg. "I want to transmit an infrared signal and receive it somewhere else, but the signal isn't bright enough to detect! - no worries, use a 1023 bit gold code, and suddenly you get a 30x effective brightness increase, and perfect time sync, with no hardware changes!"
However... beware that you should never transmit the codes once per millisecond. Thats the GPS rate, and GPS is very easy to accidentally interfere with if you use their gold codes. Instead transmit at some other data rate (ie. once per 1.2 milliseconds), or generate your own gold code set, and you won't disrupt GPS.
The article says that GLONASS time counts days from zero to 1461, then resets back to zero. This is 4 years if we think leap year is once 4 years. But it is not. Leap year is once 4 years, but each 100 years it is not, except each 400 years it is. This is on average 365.2425 days per year not 365.25 days per year. Is GLONASS not long term thinking ahead enough?
GLONASS transmissions have fields for earth orientation parameters that are too small to allow for unbounded DUT1: it has a built-in assumption that its system time is close to earth rotation angle.
Off-topic: I was looking at the first visualization (the globe with the satellites) and thought to myself: "how cool is that the author also drew the stars in the galaxy behind the globe?". Only after 3 seconds I realized this was just dust on my screen.
> One of those additional complexities worth mentioning is the velocity of a satellite relative to the observer on Earth. Due to Doppler effect this changes the frequency of the signal as seen by the receiver. To correctly acquire the signal the device has to tune in on both the time offset and the appropriate frequency.
Can someone help me understand why, in the last two interactive figures, the "Difference of Summed Areas" signal leads the "Actual Satellite X Source Data" signal?
It seems as though the receiver signal is almost predicting the source data bit changes, which should not be the case.
GPS satellites don’t correct for relativistic effects. They just set the Earth as the preferred frame, which is a great choice for a terrestrial positioning system.
I’ll see if I can find the paper it’s quite interesting.
Edit: I can't find the specific paper I'm thinking of. It's one that discusses how when other orbiting bodies want to use GPS they have to make a bunch of complex corrections that terrestrial users don't. But a search for Earth Centerered Inertial Frame will find you plenty of papers discussing the general concept.
GPS satellites don't compensate for relativistic effects (except for the huge offset built into their atomic clocks), but receivers certainly do. The satellite orbits are slightly elliptical which leads to varying gravitational time dilation. If this is not taken into account, positioning is off by around 10 m [1]. This is an effect from general relativity, so it might be left out in simple textbook explanations.
Too late to edit, but here is the paper that I meant: https://apps.dtic.mil/sti/pdfs/ADA516975.pdf. At a mere 12 pages it's an easy read. Needless to say, the military is almost certainly the highest quality source for info on the actual engineering practicalities of GPS.
First sentence of the introduction:
The Operational Control System (OCS) of the Global Positioning System (GPS) does not include the rigorous transformations between coordinate systems that Einstein's general theory of relativity would seem to require
I believe there is a correction for the onboard satellite atomic clocks, which run faster than ground/ECI clocks due to a combination of special and general relativistic effects. The correction is a simple one - they just calibrate the clock with a small polynomial. IIRC nothing but the linear and constant terms are even required or used.
"Relativity in the Global Positioning System" by Neil Ashby of the University of Colorado is excellent. Chapter 6 discusses relativistic corrections for satellites using GPS.
Quote from the paper:
“Relativistic principles and effects which must be considered include the constancy of the speed of light, the equivalence principle, the Sagnac effect, time dilation, gravitational frequency shifts, and relativity of synchronization.“
So many factors to unpack yet the solution is right there.
Interestingly while all those points factor in it would be possible to have a working GPS system without "understanding" the error or having any grasp of relativity.
To expand on that, consider if the satellites went up (with ideas of basic triangulation from beacons orbiting) and then the drifting error for a supposedly fixed ground position was noticed what could be done?
The 'unknown cause' error function over time twixt fixed position and uncorrected GPS calculation can be fed into a Kalman filter to derive weights that eliminate the error.
Typically what happens in many instrumentation applications is models are created to derive functions to emit answers, errors are noticed, people think hard to add extra terms to account for errors and eventually either all errors are accounted for or some residual 'wobble' remains which can be smoothed away by an adaptive error model.
To this day in high precision GPS applications post processing runs are used to improve accuracy that account for relativity factors, atmospheric twinkle factors, (other factors I'd have to look up), and still there's a bit or error left over that can be sweep away (for a time) with a Kalman filter.
Gold codes (this article calls them chipping codes) can be used to solve a lot of engineering problems where you need to synchronise two things. Eg. "I want to transmit an infrared signal and receive it somewhere else, but the signal isn't bright enough to detect! - no worries, use a 1023 bit gold code, and suddenly you get a 30x effective brightness increase, and perfect time sync, with no hardware changes!"
However... beware that you should never transmit the codes once per millisecond. Thats the GPS rate, and GPS is very easy to accidentally interfere with if you use their gold codes. Instead transmit at some other data rate (ie. once per 1.2 milliseconds), or generate your own gold code set, and you won't disrupt GPS.