<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">Michelle wrote:</font>
<blockquote cite="mid:961220.66189.qm@web52011.mail.re2.yahoo.com"
type="cite">
<pre wrap="">Today's challenge involves the question of a potential requirement.
We've been asked to consider requiring a GPS receiver on every Namaste ground station.
Driving the proposed requirement is a desire to simplify the demodulator on the spacecraft.
Here's the reasoning. By synchronizing frame and perhaps symbol timing to GPS, the searching at the spacecraft is easier because if you know where you are, and you know where the satellite is, then you know the time delay, so that you can make everyone's frames arrive at the same time.
The demodulator's job is easier because the search space is reduced. Once it gets locked to frame timing, it only needs to search a small window for all the other users. If the symbol timing is low enough you could also synchronize symbols across users.
My thoughts on this were that what is really being explored is a timing requirement; not necessarily a GPS hardware requirement. This means qualifying the desired timing uncertainty in something like a timing uncertainty budget (like a link budget, except with respect to timing instead of gain).
There is a balance between power efficiency and receiver effort. The more efficient scheme requires more processing from the receiver. What is the most capable receiver currently under consideration in terms of processing capability? To me, that limit is a constraint on allowable uncontrolled timing uncertainty, whatever that happens to be.
At what point does the receiver start to run out of time and blow chunks? Are current space-qualified options good enough to not have to worry about this, or are current space-qualified options not capable enough? For an uplink data rate of 15kbps, the 8-ary FSK symbol rate is 5kHz. What's the maximum data rate we could send with uncontrolled timing requirements?
While the timing requirement may be met with GPS, I'd like to avoid requiring extra hardware in the ground station whenever possible, especially when it can be replaced with existing hardware and software.
For example, a ranging function can provide slant range and therefore delay and therefore remove the timing uncertainty. There is an associated cost to doing that which needs some analysis, but the cost in this case is processing and capacity, instead of dollars for hardware plus some amount of processing to manage the data from something like a GPS.
</pre>
</blockquote>
<font face="Helvetica, Arial, sans-serif">Since precision timing &
it's relation to GPS are part of my credentials, I need to put in my
comments. <br>
<br>
The "engine" to implement GPS adequate to the task is a pretty
minuscule addition to the complexity of a user terminal. I would
presume that the engine is packaged as a part of the s/c antenna which
needs to have sky visibility anyway. Assuming that the timing needed is
in the sub-millisecond range (and not at the micro-to-nanosecond level)
virtually any GPS engine can fulfill the needs. It will need a space
smaller than 5x5x2.5 cm (2" x 2" x 1") and will consume well under 1
watt. </font><font face="Helvetica, Arial, sans-serif">The cost of a
suitable
GPS antenna+RX module would be less than $30.</font><br>
<font face="Helvetica, Arial, sans-serif"><br>
We can assume that the s/c geocentric 3D position will be known at a
sub-km level simply by making use of Kepler. The same GPS engine that
provides timing will provide the user's 3D geocentric position at a
level better than 10 meters. Therefore each user can know, <i>a priori</i>,
the s/c range to the sub-km level (i.e. significantly better than 300
µsec, neatly matching your 5 kHz requirement). If the s/c assigns TDMA
slots based on its local timing clock (i.e. zero propagation delay), we
can have the user's data arriving at the proper time to fit into the
proper s/c TDMA timing slot.<br>
<br>
Also note -- since the user may be physically remote from his antenna
(and hence
displaced in time by cable, network, computer latency, etc delays),
placing the
timing module at the antenna avoids any timing errors.<br>
<br>
I doubt that your one-way ranging scheme will work. What you can
measure is the apparent arrival time of the s/c signal WRT your
station's local clock (called a pseudorange). But what are you relying
onto synchronize your local clock? GPS uses pseudoranges from 4 (or
typically more) satellites to solve for a 3D position <b>AND</b> a
local clock bias. It also uses pseudorange rates (apparent Doppler
offsets) from the same 4+ satellites to extract the user's 3D velocity
and the receiver's LO offset. With only one satellite, you need the
user's 3D position to be known in order to synchronize the 2 clocks.
And how will you get the position -- "Duhhhh, with a GPS receiver of
course!". I also note that if you use GPS for both position and time,
you have the all the data you need to operate from a moving platform.</font>
<br>
<blockquote cite="mid:961220.66189.qm@web52011.mail.re2.yahoo.com"
type="cite">
<pre wrap="">If the spacecraft was the timepiece, and the stations synchronized themselves to that via information in the downlink, then we could quite possibly save a considerable amount of money in terms of not including a GPS module in every ground station.
</pre>
</blockquote>
<font face="Helvetica, Arial, sans-serif">I fail to see any validity to
the "considerable amounts" statement. I'd argue just the opposite,
that in the grand scheme of things, GPS is the OBVIOUS & SIMPLE
solution. <br>
<br>
73, Tom<br>
</font>
</body>
</html>