[Namaste-dev] Re: Tuesday Challenge For June 3, 2008

Michelle w5nyv at yahoo.com
Wed Jun 4 08:58:23 PDT 2008


Thank you so much for the great input. I follow your discussion and I see the adjustment.

Here's some notes on what I'm after, based on reading all the responses so far to the Tuesday Challenge.

I am searching for the underlying timing uncertainty requirement, if it exists. I don't want to add hardware when it's not strictly necessary, meaning 

1) that there is actually a requirement to be met and 
2) the requirement cannot be met with other solutions. 

So, at least in my mind, there are two things that must be shown in order to require a particular implementation. 

1) The failure of the hardware on the spacecraft to work without additional timing information, 
2) and no better option meets the potential timing requirement.

I have no problem with adding GPS if it's necessary to get the job done, but I must be able to understand what the job is. In this case, it seems to be successful demodulation. Is timing control necessary for demodulation in the first place? In other words, will the demodulator run out of time without timing control? If yes, and I need to be shown - not told - that this is the case, and if no other solution is superior to GPS, then GPS becomes a requirement. 

If we can work out our reasoning and achieve as good a coverage of all the cases as possible in anticipation of what the payload team can achieve given their constraints of reliability and complexity (challenging space issues), then we'll be in good shape. The answer depends, of course, very heavily on the payload team's engineering efforts, but if we can define where the corner cases are, then we'll have established a wide scope of response, ranging from strict timing not required because the demodulator can handle it to strict timing required for this satellite but not that one down to strict timing required or you can't communicate at all.

What do you all think of that as a plan?

Also, an addendum - the 5kHz symbol timing is not a requirement in the sense of a maximum or a minimum, but is what we figured will provide very good voice quality without eating up too much in terms of bandwidth. I should have used something other than a particular number in the example (I should have said something like N kHz symbol rate) in order to avoid accidentally setting expectations or artificial limits. My apologies for being a bit careless there - live and learn!
 
-Michelle W5NYV




----- Original Message ----
From: "Tom Clark, K3IO" <k3io at verizon.net>
To: Michelle <w5nyv at yahoo.com>; Namaste <namaste-dev at amsat.org>
Sent: Tuesday, June 3, 2008 7:21:02 PM
Subject: Re: [Namaste-dev]  Tuesday Challenge For June 3, 2008

In the note I posted earlier
today I need to correct a (not so) small numerical error:

Since precision timing
&
it's relation to GPS are part of my credentials, I need to put in my
comments. 

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. The cost of a
suitable
GPS antenna+RX module would be less than $30.

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, a
priori,
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.

:'(    Brain fade caused me to make an error of a factor
of 100 in the sentence in red italics :-!    -- specifically,
the speed of light gives 1 km = 3 µsec (and not 300 µsec):-[ .  

A simple GPS clock, running in conventional "4D navigation"mode (3D position plus clock) can
easily provide a 3 µsec (5-sigma) 1 PPS clock signal.
Combining  geometric and clock errors, it should be possible to insure a priori bit timing as seen at the s/c at
the 10µsec level, compatible with data
rates up to 100 kb/s. All the other conclusions still apply.


73, Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsat.org/pipermail/namaste-dev/attachments/20080604/efcfaf0f/attachment.html


More information about the Namaste-dev mailing list