[Namaste-dev] Re: Weekly Report June 23 - July 4, FH-CDMA

Bob McGwier rwmcgwier at gmail.com
Sun Jul 6 09:54:43 PDT 2008

Let me give my quick answer, one not completely satisfactory admittedly,
and then argue for versatility in the ground station design while we study
the issue.

One needs to synchronize the receiver in the spacecraft for each hop.  This
does not come for free.  It is utterly impossible without spending energy
that might otherwise go into a data bit.  Thus my INTUITION is that in a
noise limited system, rather than an interference limited one (again, an
assumption, I admit) is that capacity is reduced by hopping primarily
because of the synchronization requirement.

I will agree that I appealed only to heuristics outside of the one statement
which needs no argument above.  Synchronization requires either extra
engineering complexity and/or energy.  The former increases the probability
of failure and the latter reduces capacity.

I really hope this group will push on to a serious and, frankly, immediate
consideration of building something we can test our ideas with.  The
modulation choice is at best a minor impediment to this initial step.  The
polyphase filter bank analysis and synthesis based SDR receiver and
transmitter for a simulation is under construction.  I will post svn access
to it soon so people can shoot at it.

I appreciate your dialog on this and your thought provoking assessments of
the choices and my primary argument is in favor of theoretical analysis and
simulation.  This physical layer argument is a relevant but only part of
your system diagram.  We should pursue as many pieces in parallel as


ARRL SDR Working Group Chair, AMSAT VP Engineering.
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
"Trample the slow ....  Hurdle the dead"

-----Original Message-----
From: Paul Williamson [mailto:kb5mu at amsat.org] 
Sent: Sunday, July 06, 2008 1:05 AM
To: Bob McGwier
Cc: 'namaste-dev'
Subject: [Namaste-dev] Re: Weekly Report June 23 - July 4, FH-CDMA

At 12:45 PM -0400 7/5/08, Bob McGwier wrote:
>PTT  ->  round trip time -> failure and then you have to start over.

Indeed; that's the same thing I said.

My conclusion from this fact was that we need to make PTT access failures
very rare. Your conclusion seems to be that we must abandon PTT access and
have much more static channel assignments for users. But you haven't given
any arguments about why that is a better answer, nor did you address my
belief that static channel assignment will be too expensive in wasted

I think it has to be a per-user channel assignment, not a per-conversation
channel assignment. With our long propagation delay, "doubling"
(approximately simultaneous PTT by two or more stations in the same
conversation) is unavoidable. If every station in the conversation is
sharing the same physical uplink channel assignment, a double will result in
no station being heard. Worse than FM, even, where at least you can usually
tell something is happening. Not really acceptable. At a minimum, the system
has to be designed so that one station always gets heard. Ideally, it should
be possible for several stations to be talking at once and ALL be heard.
With per-user channel assignments, that's easy (except that the receiving
groundstation needs extra horsepower to process the multiple signals).

If we assume, as you seem to suggest, that a user must hold onto a channel
assignment for the duration of his involvement in a conversation, then a
single net with N checkins (N ~= 50 to 250) would consume the entire
capacity of the system. I submit we can't afford to be that wasteful.

>The first time someone drops the button in a first responder situation...

This is a side issue to the current discussion, but I seriously question the
applicability of the term "first responder" to anything we will ever be
involved with. "Responder" would be OK, but "first responder" is a very
specific technical term and those people are going to be using their own
communications systems.

>... each push means you wait many seconds before they here a beep ...

I'm not sure how it adds up to "many seconds" in any kind of reasonable
system design. To get a delay that long you'd need quite a few round trip
times, and if the probability of success on each attempt is reasonably high,
the chances of needing more than two or three are negligible.

In any case, we're in agreement here that a wait-for-the-beep system is

>If we fail on the random choice of channel, as directed by the satellite
channel occupancy map, you reassign yourself immediately to another channel
that is marked as free of use or interference by the satellite when you have
a failure or loss of resource.  This has a serious advantage ...

I was assuming we would use that scheme, for every access. That's part of
the background assumptions. Sorry if I didn't make that clear in my

>Secondly,  whose clock is master clock on the FH part of this?

As I envision it, the satellite's clock would be master. Stations not
already synchronized to the satellite's clock would have to do a little
two-way ranging experiment -- with the satellite's cooperation -- to
determine the required offset between received downlink time and advanced
transmit uplink time. This doesn't have to be done very often. Ideally, just
on station setup.

Note that this synchronization might be needed (or advantageous) even if we
don't use FH-CDMA. The processing load on the spacecraft could possibly be
reduced by ensuring that all the uplinks are synchronized at some level.
Synchronizing uplink frames would reduce the load on the preamble searcher.
If it's possible to synchronize at the symbol level, that might make
demodulation easier. I don't know, and I don't know how critical it will be
to reduce processing on board the spacecraft. The payload team will need to
tell us that.

> Another weakness in the FH-CDMA is the serious energy must be spent on
acquisition on every hop because of the extreme weak signal coming from the

Please explain. What acquisition is needed? Sounds like you're assuming slow
hopping and sloppy transmitter timing. Is that necessarily the case? I'm
assuming that the hop rate is equal to the symbol rate and that
symbol-to-symbol transmitter timing is very precise. Acquisition would be
needed at the start of each PTT, but it would only be a fine time
acquisition since I'm assuming the ground station is keeping fairly tight
synchronization with the satellite's master clock.

> It seems to me for robustness, we already have to adopt a store and
forward system in the ground terminal whether it is voice or data.

Store and forward voice? Please explain how that's going to work. Voice has
to be very nearly real time to give a satisfactory user experience. Voice
systems I'm familiar with will discard voice frames in preference to
delaying them.

>I suggest that we can defer adoption of ANY physical layer waveform as "the
one" until later since we are doing software defined waveforms anyway.

Yes and no. My block diagram proposal put the uplink modulator into
outdoor-unit hardware (which may or may not be programmable) in order to
greatly reduce loading on the indoor/outdoor link. That's certainly not set
in stone, though. If we need to design in the flexibility to use arbitrary
uplink waveforms, we still can. It might not be free of cost though.

I would hope that analysis on as many waveforms as need to be analyzed could
be completed before we have to finalize any hardware designs for the ground
station. I also hope the ground station hardware can be optimized for cost,
since it likely will be too expensive for comfort even if we do optimize for

73  -Paul
kb5mu at amsat.org

More information about the Namaste-dev mailing list