OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    07.10.99 22:23l 169 Lines 7179 Bytes #-9727 (0) @ EU
BID : HD_99_250D
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/250D
Path: DB0AAB<DB0KFB<DB0CZ<DB0LX<DB0LEL<DB0TTM<DB0FP<DB0SRS<DB0AIS<DB0NDK<
      DB0ACH<PI8JOP<PI8ZAA<PI8HWB<PI8VAD<PI8WNO<PI8HGL<PE1NMB<EA7URC<PE0MAR<
      PI8VNW
Sent: 991007/1554Z @:PI8VNW.#ZH2.NLD.EU #:5808 [HvHolland] FBB7.00g $:HD_99_250
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
	id AA20628 ; Tue, 05 Oct 99 19:11:18 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
	id AA00016237 ; Tue, 05 Oct 99 13:14:32 MET
Date: Tue, 05 Oct 99 13:09:54 MET
Message-Id: <hd_99_250D>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/250D
X-BBS-Msg-Type: B

>no connectivity at all. If you want to connect to someone using
>packet radio, you have to get a signal to them!

Virtually everywhere else in the US outside the metroplexes is empty
too, from the amateur network perspective. We all face the problem of
lots of miles and few digital hams. But that still doesn't mean high power 
stations trying to blast across obstructed paths of poor quality and wildly 
varying propagation are the right answer. 

The correct answer is to install a sufficient number of unmanned relay 
stations sited so that the paths are bridged by hops of reasonable length 
and quality. That's what the Europeans are telling you that they've done, 
and it is what I've been telling you that the GRAPES network has done in 
our service area. (It is what AT&T did too in the days when their long line 
networks were RF based.)

Using Dxer mentality stations to try to do the job in huge hops is just 
absurd. BER will reach intolerable levels over any significant number 
of hops. Multipath will kill you at any reasonable network speed. Latencies 
due to retries and low speeds become enormous. Etc. Generally, total 
system cost will be higher if you try to use such absurd setups too.

(BTW there are good reliable propagation studies that have been done for 
network engineering purposes that lay out for you what's needed to build 
a satisfactory RF network at any particular level of capability. Ignoring them
won't make what they have to tell you about the requirements for adequate 
network RF path performance go away.)

Now it does take a good bit of organization and cooperation to gain 
access to sufficient relay sites, install them, maintain them, and 
operate them as part of a coherent network. That's the real problem.
You have to do a good enough selling job to get a sufficient number
of people to dig into their pockets and fund the network, and you have 
to find enough hardy souls who will give of their free time to do all the 
nasty little chores that are required to keep a good 24x7 network 
operational. The less densely populated the area, the better selling
job you're going to have to do.

To sell people on supporting such a network, you have to offer attractive 
enough capabilities and network services to them to make it worth their 
while to participate. Store and forward BBS applications just won't cut it 
anymore as a sufficient reason to maintain an extensive amateur radio 
network.  There aren't enough people interested, and those who are aren't 
willing to spend what it takes to maintain an extensive radio network for 
such a marginal return in utility. 

Today you have to be able to support more attractive and useful applications 
to get the sort of user base you need to fund and support an extensive RF 
network. For the most part, that means you have to be able to offer lots more 
network speed and reliability than you can achieve with alligators bellowing 
to each other across the swamp.

>> With such overstrething links, the link reliability is somewhere
>> between 50 and 95 % and as such, the link is interesting only to
>> bulletin forwarders, no wonder that the interest for packet radio is
>> decaying in the US and in other places with low population (and ham)
>> density.
>
>Nonesense.

It isn't nonsense. It is gospel truth. And it is coming from people with
first hand experience at running radio networks with capabilities above
the tin can and string level. This isn't something you can fix in software. 
This isn't something you can just bull through. You have to pull out the
proper RF design tools and get down to doing serious radio engineering. 

You can't have a good RF network without doing the nitty gritty RF path 
engineering required to do the job properly. And if you can't supply a 
good enough RF network, you won't attract and retain enough users 
to sustain it. We've been down the road you want to travel. It is a dead 
end.

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

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

Date: Mon, 04 Oct 1999 18:13:36 +1300
From: Winton Bell <w.bell@psyc.canterbury.ac.nz>
Subject: Checking.

Hllo Nathan,

I think you will be ok, with the connections.
Just check that the ground is continuous from end of interface cable to
transciever, with a multimeter.
If you have pin 2 & 3 of TNC for rx/tx data then these should be active
when you first try to get communicantion.

To test software, if TNC not used before ensure battery is Ok. Replace
if neccessary.  Try to do a reset action on the TNC, and observe a bit
of dialog from TNC and the cmd: prompt.
Then type at++ at the CMD: prompt.
If a receiver digital channel is connected to the audio input then some
data should show on screen.

Attention can be shifted to increasing numbered pins, and a pulse
deector applied to those pins if neccessary later on.
A break-out box with LED display is useful for serious investigation of
the TNC operation.

Done forget to load on the date:, Time: MYCALL, MYAlias, and MYMem with
your calsign, Alias callsign-1, MYM callsign-3 for example then you
should be able to connect with a BBS on a chosen channel for your area.
73 Winton ZL3AO at Christchurch.
>.

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

Date: Sun, 03 Oct 1999 08:37:26 -0500
From: kyle <kyle@sigma.net>
Subject: FA: Ku 14 Ghz Satellite Transceiver

I've got a commercial satellite transceiver on ebay. Go take a look and
email me with any questions.
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=174757753

>.

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

Date: Sun, 3 Oct 1999 18:45:39 -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:rNf3N8I6cO1=mxxFAJpY0LCh6xgK@4ax.com...

> That you seem to think that the only ham radio network revolves
> around servicing BBS applications is an indication of how far out
> of touch you seem to be with current realities.

Gary, I use tcp/ip here on the ham radio network.

We don't create any artificial barriers between the different services here.
I can, and do, interface with the 'BBS network" over the exact same
links I use for tcp/ip. Thus I can do both from the same application.
In fact I'm doing that now, as I type this post. If I addressed an email
to your "BBS network" mail address, it would go there via ham radio
(if such links exist, but you already said they did not). If I address it
to your internet email address, it will go there.

"There is only one network."
.... except in some places that intentionally isolate themselves.

I did not suggest that you USE a BBS system to enter or read messages.


To be continued in digest: hd_99_250E




Read previous mail | Read next mail


 26.05.2026 07:29:38lGo back Go up