OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    12.10.99 15:32l 176 Lines 7713 Bytes #-9721 (0) @ EU
BID : HD_99_257D
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/257D
Path: DB0AAB<DB0SL<DB0RGB<OK0PPL<OK0POK<9A0YRB<PP5BLU<IW9EXL<SV1AAW<SV1AAW<
      EA7URC<PE0MAR<PI8VNW
Sent: 991012/0914Z @:PI8VNW.#ZH2.NLD.EU #:7513 [HvHolland] FBB7.00g $:HD_99_257
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To  : HDDIG@EU

Received: from pa2aga by pi1hvh with SMTP
        id AA21147 ; Tue, 12 Oct 99 08:57:30 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
        id AA00016345 ; Tue, 12 Oct 99 07:47:08 MET
Date: Tue, 12 Oct 99 07:44:20 MET
Message-Id: <hd_99_257D>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/257D
X-BBS-Msg-Type: B

>> of their impact on other operators and other network links sharing the
>> same band segment. Part 97 requires us to use good engineering
>> practice, and such links are not good engineering practice on shared
>> spectrum. Radio  gaming (Dxing, contesting, etc) is a different topic,
>> which I won't address here except to say that those activities shouldn't
>> occur in band plan segments set aside for data networks.
>
>Where did I say these troposcatter links were in "band plan segments
>set aside for data networks"? 

So, were they in band segments set aside for satellite operation, or for
other weak signal modes, or were they in band segments coordinated for 
repeaters? I don't think they'd be very welcome there either, do you? Do 
try to think a bit, we have band plans and coordination for good reasons. 
People who ignore planning and coordination on a regular basis aren't 
subscribing to good amateur practice. If you were operating in a band
segment that was designated as a stomp everybody else, devil take the
hindmost, free for all segment, then I suppose your activities were within 
the guidelines. But the only thing that qualifies that I can think of for that
sort of behavior is on 27 MHz.

>Your very narrow view of ham radio
>does not even allow you to consider any other activity than "perfect,
>planned, coordintated, up forever" network links? 

No. My view is that if you're going to do networking, then you should
do it in accordance with band plans, coordination, and good engineering
practice. Doing otherwise is anti-social. If you choose to do something
other than networking, then you play by the rules for that activity and
stay within the bandplan for that activity. Causing  difficulties for others
is never good amateur practice.

>Guess you will just
>have to miss out on a good deal of the fun that can be had playing
>with the various digital modes. 

I do a lot of playing with other digital modes. I'm active on PSK31,
the Hell modes, and I have an even better performing weak signal
method that I've been experimenting with on HF for about 2 years 
now with a small number of other like minded experimenters. I don't 
pretend that has anything to do with building or operating networks, 
however. It is pushing another corner of the envelope entirely. I do it 
within the constraints of the band plans for the spectrum on which 
I operate, and I strive to use the minimum power necessary so as
to cause minimum inconvenience to other spectrum users. Those 
are just good amateur practices.

>Perhaps it is this narrow thinking which
>has caused the GRAPES network to become disconnected from the
>larger and more extensive ham radio network? Makes sense.

AFAIK there is no larger network. Certainly there aren't any of its tentacles 
to be found  on any of the borders of our network. We're willing to switch the
packets of any adjoining network, and have them switch ours. But as far as
I can determine, the larger network to which you allude just doesn't exist.
There are some low speed links here and there, and some other organized 
networks at distant locales, but no coherent overreaching network which
can route and switch our packets.

The board of directors of GRAPES took a vote about a decade ago that we 
would not use wireline bypass strategies to link our network to other distant 
amateur networks. That decision is still in force. If we can't connect to
another 
amateur network via RF, we don't connect. It would be easy to rapidly expand 
our coverage via wireline ties, but it wouldn't fullfill our objectives of
building 
a sustainable high performance packet switched RF network.

GRAPES doesn't involve itself with user applications such as BBS systems.
We supply the RF and packet switching network infrastructure for our users. 
They run whatever applications that they wish over it. The applications level
is not our charter and not our concern (other than to provide enough speed
and throughput to handle the applications our users choose to run, of course).
This sharpening of focus allows us to see clearly what our mission is, and the
ways in which to accomplish it.

I should probably note here that I am no longer a board member, and my
statements are not official statements of GRAPES policy. But I have been
associated with the endeavor since its beginnings, and I do speak with a
certain level of knowledge about how and why we're where we are today.
I'm very proud of what GRAPES has accomplished. We have one of the
top performing packet networks in amateur radio. We've been able to
sustain it, and user interest in it, for longer than any other amateur network
of which I am aware. 

I believe we've done that by carefully observing the principles of good
network 
design and doing the detailed RF engineering required to build it from day
one. 
We had exhaustive planning meetings before committing to a network design, 
our site acquisition people did a wonderful job of obtaining permission to
locate
our equipment at suitable points, our engineering staff has been top notch,
and our 
maintenance and operations people have been dedicated and thorough. Good 
networks don't happen by random chance, nor are they built by lone wolves. 
They happen due to careful and dedicated work by many volunteers who draw 
on many different skills to do all the tasks required to make everything work 
and keep it working. I believe everyone associated with the effort takes great
pride in our accomplishments, and great satisfaction in the parts they have 
played in it. I certainly do.

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

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

Date: Sun, 10 Oct 1999 15:26:03 +0200
From: Joop van der Velden <pe1dna@amsat.org>
Subject: PACTOR or AMTOR

Bob Lewis wrote:
> I'm using an SCS PTC-II here so I'm not qualified to recommend
> anything for the sound card. I do know that I've seen sound card
> stuff for Amtor and Pactor on the Internet but I believe they were
> DOS programs. I doubt that the sound card DSP is fast enough to
> handle Pactor-II or Clover processing.

The sound card is only the D/A - A/D converter of the sound card based
amateur applications.  The DSP work is done by the main cpu of the system.

If you have a pentium running at speeds of 200-500 MHz it seems to me it is
more than fast enough to handle just about every amateur modulation used,
especially because both bandwidth and dynamic range of the audio signals to
be analyzed are quite limited.

-- 
Joop van der Velden
pe1dna@amsat.org


>.

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

Date: Sat, 9 Oct 1999 18:28:58 -0700
From: "Hank Oredson" <horedson@att.net>
Subject: PACTOR or AMTOR

Hamish Moffatt <hamish@rising.com.au> wrote in message
news:7tmsb4$hfi$1@arachne.labyrinth.net.au...
> On 20m at about 14.065 MHz I hear a lot of digital signals --
> are these PACTOR or AMTOR or something else? They sound phase shift keyed
> (like PSK31) but not continuous (bursty). I'm curious to know what
> they are so I can consider buying a modem for it.

Mostly PACTOR-II on that frequency, but occasionally PACTOR-I.
CLOVER not generally used there. A good deal of the activity in


To be continued in digest: hd_99_257E







Read previous mail | Read next mail


 25.05.2026 07:16:34lGo back Go up