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

Paul Williamson kb5mu at amsat.org
Sat Jul 5 22:05:00 PDT 2008


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 capacity.

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 unacceptable.

>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 analysis.

>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 ground.

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 cost.

73  -Paul
kb5mu at amsat.org


More information about the Namaste-dev mailing list