Could a satellite use a Miniature Atomic Clock (MAC) to provide GPS services?

I've been investigating GPS satellites and I got curious about onboard atomic clocks. I found this following paper on the concept of a CubeSat GPS constellation using Chip-Scale Atomic Clocks, and even though the Allan Deviation is good enough as the paper mentions, the Aging rate on the clock is of 9E-10 / mo, which if I'm not mistaken would render the satellite pretty much useless after a month.

I searched and found that Microsemi has released a MAC, or Miniature Atomic Clock that even though slightly larger than the CSAC, has an Aging rate of 5E-11 / month.

Does this mean that it could be used for a GPS satellite working for about a year, or am I missing something? Would the power consumption be too much for a CubeSat in your opinion?

• "...would render the satellite pretty much useless after a month." Do GPS satellites rely solely on their internal clock for a month, or do they get regular "coaching" (corrections) from ground stations?
– uhoh
Jun 29 at 0:55
• @uhoh physics.stackexchange.com/a/575117/123208 mentions that the GPS satellite clocks "are (occasionally) adjusted by a ground station (Schriever Air Force Base, Colorado), ultimately based on the master clock from the US Naval Observatory". I guess you'd have to explore the rabbit warren of gps.gov/technical to find out how often those adjustments are made. Jun 29 at 3:33
• @PM2Ring "the GPS satellite clocks "are (occasionally) adjusted by a ground station " In fact the clocks are adjusted once per day using three ground stations. Not only the clock should be adjusted but also the satellite position, therefore three instead of one ground station. The actual satellite position should be known very precisely.
– Uwe
Jun 29 at 8:38
• @GdD The OP is asking about the feasibility of a CubeSat-based alternative to GPS, using chip-based atomic clocks. Jun 29 at 8:54
• The paper to which you linked says the cubesat clocks would need to be updated on an hourly basis to yield 10 meter accuracy. Jun 29 at 13:20

If we want the usual GPS position error less than 10 m we should know the time needed by light or a microwave to cover this distance. The speed of light is $$3 * 10^8 m/s$$, so we need 33.3 nanoseconds for 10 m. To measure a distance, GPS measures the time needed by light for that distance. To be better than 10 m position error, the clock error should be less than 33.3 ns. The GPS satellite clock are aligned once per day, so we need less than 33.3 ns per day.

A day has 24 hours of 3600 seconds, that are 86400 seconds per day. We divide 33.3 ns by 86400 seconds and get $$3.8 * 10^{-13}$$ clock error per day.

The MAC aging rate of $$5 * 10^{-11}$$ per month is $$1.67 * 10^{-12}$$ per day. This is a 144 ns clock error instead of the 33.3 ns needed for the 10 m.

So the MAC from Microsemi could be used not even for a full day. The aging rate should be 4.3 times better.

The given aging rate of $$5 * 10^{-11}$$ per month would result in a position error on the ground of 43 m instead of 10 m.

• I don't follow the logic of equating (a) a ranging accuracy (e.g. 30 nanoseconds) and (b) a clock accuracy PER DAY. Also, a positioning error is not the same as a range estimate error with a single satellite. Jun 29 at 10:18
• @NgPh I changed the text, is it better now?
– Uwe
Jun 29 at 15:36
• Thx indeed for the effort. I was not clear. I was - and still am - struggling to understand how a short-term characteristic (e.g. the Allan Deviation -ADEV) can be used to determine the time for a correction of a long-term clock drift. I think the paper uses the same arguable reasoning and I think that's the root of the confusion for the OP. Microsemi's CSAC spec: Accuracy +/-5E-11 at shipment, ADEV (tau=1000sec)<1E-11, Aging<9E-10/month. I suspect it is wrong to use ADEV, but I can not elaborate on this potential flaw in a clear-cut way, yet. Jun 29 at 17:07
• @NgPh It is much simpler than Allan Deviation. Just think of a small but constant frequency error of the satellite 10.23 MHz system clock. An error bigger than 1E-12. Only one of the satellites got this error. A delta t error is accumulated over the time of a day. If this accumulated time error is 100 ns for instance, we get a distance error of 30 m. The GPS receiver does not know of this error, if the satellite clock is late by 100 ns, it looks like the signal was sent from a longer distance, 100m more.
– Uwe
Jun 29 at 18:37
• I see. IAllow me to restate your approach: Start with the position error budgeted for the clock of ONE satellite (say 10m). ASSUME that short-term instabilities can be neglected. ASSUME that drift model is linear with time. ASSUME that the clock management policy is based on the criterion of drift exceeding allocated error budget. I aks this, just to be sure we are on the same page, but you may have guessed that I suspect your approach is wrong (from an engineering's view). Jun 30 at 9:30

I was hoping that the OP provides some feedbacks, in order to be on the same page so that I can write a very short answer. But, never mind.

I will try, by a analogy, to illustrate the type of pitfalls one should avoid when working on clock requirements in GNSS.

Assume my neighbor has a very expensive Rolex watch and I bought my wife a cheap copy. Then my wife complains that she observes that her watch loses 1 second every day compared the neighbor’s. After one month, it is now 30 seconds late. Should she throw it away after a month? NO! I would explain that she has a very accurate time-keeping system, as accurate as our neighbor’s Rolex. As her watch loses EXACTLY one second per day, she can derive the EXACT and same time shown on the Rolex for ANY day, and this eternally (no aging).

And this is how time-keeping works in GNSS. You have an absolute reference on-ground. The Control Center measures the drift of each satellite clock with respect to the reference, then derive a prediction model to cancel the errors. The computed parameters of the error model are then broadcast by the satellite (together with the ephemeris) in the Navigation Messages. It is these parameters that are updated when needed, not the satellite clock per se (the user receivers make the correction). All GNSS system I know of (GPS,GLONASS, GALILEO, BEIDOU, QZSS,…) follow the same strategy (and basically the same prediction model).

The residual error, after each prediction update, is due to many noisy short-term factors (but not drift and aging, as long as these are still PREDICTABLE). BTW, the contribution of the satellite clock residual errors to the user positioning accuracy is ~ 2m for GPS (civilian service). Other error sources (mainly the ionosphere and the geometry) contribute to the rest of the often quoted 10m performance (in absence of multipath).