OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    26.09.99 09:56l 168 Lines 7806 Bytes #-9759 (0) @ EU
BID : HD_99_241K
Read: GUEST
Subj: HamDigitalDigest 99/241K
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8APD<PI8WNO<PI8HGL<
      PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990926/0249Z @:PI8VNW.#ZH2.NLD.EU #:2724 [HvHolland] FBB7.00g $:HD_99_241
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA19939 ; Sun, 26 Sep 99 00:42:14 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00015953 ; Sun, 26 Sep 99 01:09:22 MET
Date: Sun, 26 Sep 99 01:03:52 MET
Message-Id: <hd_99_241K>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/241K
X-BBS-Msg-Type: B


This is dramatically brought home to me every day when I bring in ENG
live shots. Almost invariably, when I have the truck operator reduce power,
ghosting is sharply reduced. We try to run just enough power to overcome
the gaussian noise, and let most of the multipath signals fall below the
noise floor (FM threshold). This produces the best pictures, and also 
produces the least interference to other trucks which may also be bringing 
in shots. I often have to use spatial reuse to bring in all the shots with the
limited number of channels we have available to us, so it is especially
important to minimize mutual interference. (It is good amateur practice
too. The FCC admonishes us to use the minimum necessary power.)

>Is there any horse sense, generally about FSK,
>that say, how many db below the main signal, would a path that's
>say, 1/4 of a bit late, need to be before the channel is reliable?  Is a
>path a few db down that's 1/2 of a bit late really bad?  Here across
>the SF Bay, I assume that even the line of site paths, still have that
>line of site path, and another reflection off of the bay -- and I've heard
>off the Bay Bridge, of all things. .

The required CNR for a given data rate and occupied bandwidth is easily 
calculated using the Shannon relation. Treating the reflections as just more 
noise, it is easily possible to show what level of intersymbol distortion
multipath which can be tolerated for a given link. Ordinary multipath is
a bit harder to characterize. In general, wide shift FSK is more tolerant 
of ordinary multipath than narrow shift. It is a form of frequency diversity. 
SS is an extreme form of that.

>And finally, say, we warp ahead in time to the future where everything
>is Spread Spectrum, and FSK is long forgotten.  Is Spread Spectrum,
>because of it's immunity to multi-path, going to actually make these
>billiard ball paths -- that is up and over mountains and bouncing off
>buildings and things useable?  Or is something else going to bite us,
>even with Spread Spectrum.

I think something else is going to bite us. The main difficulty with
SS is dealing with high RF sites. The receiver front ends necessarily
have to be wide open to receive the very broad signals. That leaves
them vulnerable to other high power emitters on the site. The desense
and IMD that we normally fight with narrow pass cavities will kill us
when we have to open the system up to a wide bandwidth. 

We still need those high sites to give us coverage, because amateurs 
are thin on the ground, and the economics require high relay sites to
provide adquate coverage. At least in metropolitan areas, virtually every 
suitable high site is already covered with high power emitters, so they 
are something with which we will always have to contend.

There's also the issue of spreading sequence negotiation for multiple
access sites. That's not a simple problem to resolve for a dynamic
user environment with bursty data traffic. It is easier for CDMA cellular
where connections stay nailed up for the duration of a call. If we have
to negotiate for each packet, system performance will be dismal. OTOH,
if we use nailed up connections, we have a different sort of capacity
problem. It isn't an easy problem to resolve.

>(Btw, it occured to me that if Alligator thinking is bad, bad, bad,
>then the HDTV people might have a little problem here in the
>SF Bay area, with all it's hills.)

If you'll check, you'll find that HDTV licensees are running 1/10th or
less the power that NTSC stations are using. This offers considerable
help against alligator induced multipath problems because signals 
are nearer the detection threshold.  Field experience has shown that 
HDTV (actually we're just calling it DTV now), is generally more robust 
against multipath than NTSC. And since we aren't transmitting computer 
data which must arrive error free, some bit errors are tolerable. They just 
show up as a slightly noisier picture thanks to the interleaving we do. We 
don't get the objectionable ghosting that plagues NTSC transmissions.

Atlanta also has hilly terrain. When we started DTV broadcasting
a year ago, we did extensive field testing. In general, our coverage is
larger for DTV than it is for NTSC despite the fact that we're running
only 1/10th the power. Picture quality is better in virtually every case.

OTOH when the signal goes, it goes. It is pretty much an all or nothing 
situation. Either you get a virtually perfect picture, or you get no picture 
at all. That's because we operate close to the detection threshold. In the
main, that's a desirable characteristic. Viewers don't have a favorable
impression of stations which deliver crappy pictures, but most of the
time the reason the pictures are crappy is that the viewer hasn't done 
the proper engineering on his end of the path to get a good picture.

With DTV, he either does that, or he doesn't watch. So we get virtually
zero picture quality complaints from DTV viewers. Sales of DTV sets
are brisk, the local high end stores say that they're selling them as fast 
as they can get them. If there were serious problems, we'd be hearing 
about it because those high end viewers are the most discriminating,
and complain the loudest when things aren't right.

Gary
Gary Coffman KE4ZV  | You make it  |mail to ke4zv@bellsouth.net
534 Shannon Way     | We break it  |
Lawrenceville, GA   | Guaranteed   |
>.

------------------------------

Date: Fri, 24 Sep 1999 22:30:15 -0400
From: Gary Coffman <ke4zv@bellsouth.net>
Subject: Let's look at real numbers for TNC software sales

On Fri, 24 Sep 1999 06:31:29 -0500, "Charles Brabham" <n5pvl@texoma.net>
wrote:
>
>Brian Kantor <brian@karoshi.ucsd.edu> wrote in message
>news:7se4el$rm4$1@karoshi.ucsd.edu...
>> So to sum up:
>>
>> Gary maintains that a network may well not be worth doing unless it is
>> high performance.
>
>...And since that is not practical, Gary maintains that it's "OK" to just
>get on the Internet and PRETEND that that high-performance network exists.
>This is much more important to Gary, as as ham, than using radio.

You continue to spout this lie, Charles, but you can't back it up. Our network
is 100% amateur radio, always has been. One of our users offers a wired 
internet gateway, but it is for wired internet access only, ie like a phone
patch 
on a voice repeater. It is not used to route between segments of the network. 
(It couldn't, that would require at least two wired internet connections, and
we 
only have one.) You're not only an idiot, you're a stupid lying idiot, a fool,
and a 
buffoon who can't tell the difference between a service offered over the
network
and the network itself.

Gary
Gary Coffman KE4ZV  | You make it  |mail to ke4zv@bellsouth.net
534 Shannon Way     | We break it  |
Lawrenceville, GA   | Guaranteed   |
>.

------------------------------

Date: Fri, 24 Sep 1999 19:37:00 -0700
From: "Hank Oredson" <horedson@att.net>
Subject: Let's look at real numbers for TNC software sales

Gary Coffman <ke4zv@bellsouth.net> wrote in message
news:bZfrN=2K6pft23oz4JS1MrcBvtG9@4ax.com...
> On Wed, 22 Sep 1999 18:18:05 -0700, "Hank Oredson" <horedson@att.net>
wrote:
> >Why do you keep saying "alligator"? That means a station
> >which hears poorly compared to how well it can be heard
> >by normal stations. I am certainly not talking anything like


To be continued in digest: hd_99_241L




Read previous mail | Read next mail


 16.06.2026 05:23:14lGo back Go up