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

Michelle w5nyv at yahoo.com
Tue Jun 3 10:54:05 PDT 2008


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. 

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.

The Tuesday Challenge is to wade in to this discussion, pick up whatever seems most interesting or whatever is in most egregious need of correction - and participate!

There are several link documents in the Requirements Analysis section of the website www.amsat.org/namaste, and this discussion will result in additions and expansions to those documents. 

more soon,

-Michelle W5NYV


More information about the Namaste-dev mailing list