OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
PA2AGA > HDDIG    20.09.00 23:29l 193 Lines 6903 Bytes #999 (0) @ EU
BID : HD_2000_254D
Read: DC1TMA GUEST
Subj: HamDigitalDigest 2000/254D
Path: DB0AAB<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0BRI<DB0HAG<DB0ACH<PI8JOP<PI8ZAA<
      PI8HGL
Sent: 000920/1904Z @:PI8HGL.#ZH1.NLD.EU #:16272 [Den Haag] FBB $:HD_2000_254D
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To  : HDDIG@EU
Date: Sun, 17 Sep 00 16:39:06 MET

Message-Id: <hd_2000_254D>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B


I see Steve is up to his usual level of useful commentary.
You have any interest in Ham Radio Steve?

Want to take part in some HF multicast experiments?

Would CLOVER or PACTOR (or AMTOR for that matter)
FEC be a good way to go?

--

   ...  Hank

http://horedson.home.att.net

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

Date: Sat, 16 Sep 2000 13:08:00 -0500
From: "Steve Sampson \(K5OKC\)" <ssampson@nospam.radio-link.net>
Subject: HF multicast protocols.

Bark! Bark! Bark!

"Charles Brabham" says:
> Remember that a LandLine Lids' favorite way to undermine
> legitimate digital efforts by Hams is to insist upon jacking up the content
> level until the system is hopelessly overloaded. - THAT's why the @WW
> "problem" got out of hand in the first place! - So stick with @WW only,
> despite inevitable pressure from various LandLine Lid types to do otherwise.

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

Date: Sat, 16 Sep 2000 17:55:54 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: HF multicast protocols.

"Charles Brabham" <n5pvl@swb.net> wrote in message
news:e%Nw5.430$5X4.23766@nnrp3.sbc.net...
>
> "Hank Oredson" <horedson@att.net> wrote in message
> news:wsLw5.31024$M37.769057@bgtnsc07-news.ops.worldnet.att.net...
>
> >
> > So CLOVER FEC would work ok for that use.
> >
> > The issue is how to find the 10-15 stations interested in setting up and
> > network and playing with the protocols. For the original packet network,
> > it took me more than 9 months, and many hundreds of phone calls and
> > letters to get things going. Once the first 5 or 6 were signed up, and the
> > protocol was finalized, it got a bit easier since they helped recruit more
> > stations :-) I'm not interested in doing that again ...
>
> That's the problem with using CLOVER for this purpose... There are few
> owners of CLOVER equipment who would be interested in going into "receive
> only" mode for an extended period of time. If somebody came up with a
> soundcard compatible CLOVER monitoring program (especially if it worked in
> DOS) then you would have a much easier time getting volunteers.

Lots of folks might be interested. Let's see if any actually are.

> Cathryn's suggestion of using PSK31 sounds much more likely to succeed, for
> that reason. There are already hundreds of PSK31 stations out there, and
> nobody had to invest big bucks to get any of them up and running. With a
> much larger user base to work with, your chances of assembling a decent
> startup group rise proportionately.

There is a lot more code to write to use PSK31. For CLOVER almost
all the needed code exists, and at least one author has indicated an interest.

> Multicast's efficiency is directly related to the number of receiving
> stations per transmitter. Anything that drives up the number of receiving
> stations also drives up multicast's efficiency and utility.

Yes.

> Stick with @WW bulletins. If you start adding lots of nonessential
> "goodies", you are throwing away valuable update time and reducing your
> ability to move the @WW traffic. Once it's established that you are moving
> @WW really well, that would be the time to consider adding or not adding
> additional content. Remember that a LandLine Lids' favorite way to undermine
> legitimate digital efforts by Hams is to insist upon jacking up the content
> level until the system is hopelessly overloaded. - THAT's why the @WW
> "problem" got out of hand in the first place! - So stick with @WW only,
> despite inevitable pressure from various LandLine Lid types to do otherwise.

Using CLOVER FEC, there should not be much problem handling
everything that is available to handle. I'm doing it now in ARQ mode,
to 5 different stations. Some of them might be interested.

--

   ...  Hank

http://horedson.home.att.net

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

Date: Sat, 16 Sep 2000 16:23:00 -0500
From: "Steve Sampson \(K5OKC\)" <ssampson@nospam.radio-link.net>
Subject: HF multicast protocols.

"Hank Oredson" says:

> You have any interest in Ham Radio Steve?

Yes.  But WW BBS has no merit, technically or socially. 
So if that is the end product, you have cheated the public in their
allocations to us.

> Want to take part in some HF multicast experiments?
> 
> Would CLOVER or PACTOR (or AMTOR for that matter)
> FEC be a good way to go?

I agree with Cathryn that PSK31 is the proper way to go.  The
software and hardware are endemic to the digital part of the hobby.

Not only that, but a fine Windows DLL is available to use for the
low level part: http://www.qsl.net/ae4jy/pskcoredll.htm by AE4JY.

One thing to keep in mind, is that most computers can decode
multiple PSK31 signals with CPU to spare.  Thus, you could use
diversity reception/transmission, rather than FEC.

Now comes the hard part.  Everyone want to have their callsign in
the header, so who gets elected transmit operators?  If Elmer gets
pissed off, he will start his own group just to see his callsign in
every message.

I think there should be a dramatic change in the mail header.  The
mail header does NOT need to show the path. A mail header that
is longer than the mail message is unproductive.

What may occur, is that a station in Seattle may transmit all day,
and a station in Phoenix picks this up.  It send this via VHF/UHF
to a buddy across town who transmits all day and night, which
is picked up by a station in Montana who hears both of the
stations all day, who sends this to a buddy across town...  etc, etc.

Let us propose to kill any header ideas of the past, and rethink
that issue.  This is not a network that can be traversed forward
and backward.  The path means nothing. What kind of mail header
should there be?

Off the top of my head, I would think a generic part of the standard
email header would be enough.  Adopting the state.ham.us or
province.ham.ck would add some sort of routing by country
capability.  I don't think ampr.org is a viable tool any longer.

There you go, bark! at that Chuckles...

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

Date: Sat, 16 Sep 2000 11:22:17 -0500
From: "Steve Sampson \(K5OKC\)" <ssampson@nospam.radio-link.net>
Subject: multicast (was internet repeater linking)

X-Complaints-To: newsabuse@supernews.com
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4029.2901
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901
To: ham-digital@ucsd.edu

Hee Hee, BBS or die eh?

What a dweeb...

Bark!  Bark! Bark!

"Charles Brabham" says:
> 
> The "BBS crap" you disparage is the messages and bulletins that thousands of
> HAMS care to exchange with each other.


To be continued in digest: hd_2000_254E





Read previous mail | Read next mail


 24.12.2025 11:36:41lGo back Go up