OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    26.09.99 10:10l 198 Lines 7835 Bytes #-9759 (0) @ EU
BID : HD_99_241L
Read: GUEST
Subj: HamDigitalDigest 99/241L
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0MW<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8APD<
      PI8WNO<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 990926/0250Z @:PI8VNW.#ZH2.NLD.EU #:2725 [HvHolland] FBB7.00g $:HD_99_241
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA19941 ; Sun, 26 Sep 99 00:48:08 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00015956 ; Sun, 26 Sep 99 01:09:33 MET
Date: Sun, 26 Sep 99 01:03:59 MET
Message-Id: <hd_99_241L>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/241L
X-BBS-Msg-Type: B

> >that, but rather matched stations that obtain their required
> >power spread via the use of reasonable power and good
> >antennas. Remember: this is a point to point link I'm working
> >on. It could well be full duplex, thus avoiding T/R switch time
> >issues. However I wish to consider the half duplex alternative
> >because it is easier to coordinate a single frequency.
>
> I'm calling it alligator thinking because you keep insisting that
> you need a much higher power level than is reasonable for the
> link distances you're talking about. That's going to cause all sorts
> of multipath problems due to all of  the reflections the receiving
> end is going to have that are above its noise floor. (It may also
> cause problems for others using the same, or adjacent, frequencies
> for other links.)

I never mentioned the length of the links I am proposing to
build. I only mentioned the length of some EXISTING links.
But apples and oranges in the same bag here. More than one
discussion going on.

1) I'm interested in playing with high speed RF network linking.
Just me. I can own both ends. They can be close. In the same
house perhaps. Cost is not a serious consideration. Might link
to Ted next door (a bit less than 1 km away).

2) I'm interested in replacing a few existing 9600 baud links with
faster links to improve our local network. They are moderate
distance, clear path, easy access to the sites. 1W works fine
for 9600 baud. This one is cost limited.

3) I'm interested in connecting places far apart using RF.
These are long haul links. I've done these before, at 1200 baud,
using troposcatter on 2M. Path lengths are 200 - 400 miles.
A kilowatt and four long yagis helps to make these long links
work. See for example the W5XO links that used to exist
in Texas (high power transmitters, big yagi arrays, tall towers).
Cost is not a serious consideration, at least at my end of the link.
(Consider the cost of a "good" HF station).

I may do one or more or none of the above. Just kicking around
some ideas. Might decide to build a moonbounce station instead.

See further comments below.

> The correct answer is not to just try to "bull through". The correct
> answer is to properly engineer the path so that it will work at a
> power level where multipath will fall below the receive site noise
> floor.

Gary, you not paying attention.
More ERP equals more power spread equals longer path.

> >I guess my bottom line is that I'm not at all interested in why
> >this cannot be done. I'm only interested in how to go about
> >doing it. Where there are no links, a not-quite-perfect link
> >is a huge improvement.
>
> I've told you how to do it. Do the RF path engineering properly.
> There are well established procedures and formulas for doing
> this. AT&T Long Lines, and others who've needed RF links of a
> specified quality, have been using these procedures for over
> half a century. They are well proven.

You told me nothing useful. In fact, all you said was "Don't run
more than 4-10W ever under any circumstances." Well, on most
of my links I run less (1W or 2W) and use aluminium to make
up the ERP requirement. Some run more, on both ends, to make
up the needed power spread.

Also keep in mind it is not always POSSIBLE to use the perfect
path between two perfect stations. This is ham radio. We get
to play. We do not NEED 6 nines.

> >Have begun gathering the needed test gear, which I need in any
> >case to be able to get some existing 9600 baud links working
> >properly. But I still need someone for the "other end" of the
> >high speed link
>
> That's always the case. Networks are by nature cooperative
> efforts.

> 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:48:06 -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:fxLsN+CtZeGXYRlcVcEkcq2ua5a6@4ax.com...

> If excessive power is  used, reflectors well off the line of sight can
> cause multipath reflections which will cause problems. For example,
> a water tower 20 miles off to the left or right of the path may generate
> a reflection that will be strong enough in the receiver to cause problems
> if high power is used. Similarly, terrain features well beyond the
receiver
> can cause problems when excessive power is run.

Gary, no matter what power level is used, the reflections will be the
same ratio to the direct signal. You cannot get better S/N by reducing
the signal. The bit jitter is there no matter what you do. The key is
to reduce the beamwidth until the reflected signal is as much below
the direct signal as required. As the path length increases, it becomes
harder to do this, since the subtended angle of the reflector decreases.
In a perfect world, the required decrease in beamwidth results in
an increase in gain that just offsets the path length increase. However,
increasing transmit power buys you something very important: fade
margin increase and improvement in link reliability. If you count on
the reflections being 'below the noise floor" then you have a misdesigned
slicer, or a poor understanding of wave physics.

But I'm talking long links, over rough terrain, with many reflectors
present.

The same problems occur on very short paths. For example, I have one
link that is only one mile long. One would think this link would be
"perfect". It's not. There are several excellent reflectors along the path.
Eye pattern is all over the place. Guess I could install relay links every
1000 feet or so. Was simpler to install yagis and carefully aim them
to place the worst reflectors into nulls. So I'm using 30-40 more db
of ERP than theory requires. The link works.


>.

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

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

Peter O. Brackett <ab4bc@ix.netcom.com> wrote in message
news:7sgblm$mlr@dfw-ixnews19.ix.netcom.com...
> Charles:
>
> You are missing the whole point.
>
> Don't be so paranoid!  There is not some big conspiracy of tcp/ip linux
> zealots out there.  They honestly want to help ham packet radio.

I would be most interesting in meeting one or two of them
.... those that want to do something with RF and tcp/ip that is.

I only know of one other within a 100 mile radius.

--

   ...  Hank

http://horedson.home.att.net



>.

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

Date: 25 Sep 1999 02:26:54 GMT
From: "Eric S. Johansson" <esj@harvee.billerica.ma.us>
Subject: Let's look at real numbers for TNC software sales

Rob Janssen <nomail@pe1chl.demon.nl> wrote:
> Also, in my opinion an Internet provider cannot offer what is in fact
> a leased line (a dedicated modem and a dedicated line) for each customer
> for $20/month including traffic.  So, you are counting on the fact that
> other customers are paying for your usage.  That is not very popular here,
> because customers like to "get what they pay for" in this country.
> So, when there would be a flat rate telephone service (there *was* such
> a service until the late seventies!), a lot of people would be doing what
> you describe, and the system would collapse because the provider would not


To be continued in digest: hd_99_241M




Read previous mail | Read next mail


 15.06.2026 16:27:33lGo back Go up