| |
PA2AGA > HDDIG 10.10.99 21:38l 213 Lines 7694 Bytes #-9723 (0) @ EU
BID : HD_99_256B
Read: GUEST
Subj: HamDigitalDigest 99/256B
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0SIF<DB0HSK<PI8DRS<PI8DAZ<PI8GCB<PI8WNO<
PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991010/1602Z @:PI8VNW.#ZH2.NLD.EU #:7124 [HvHolland] FBB7.00g $:HD_99_256
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA21054 ; Sun, 10 Oct 99 15:36:43 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00016327 ; Sun, 10 Oct 99 16:32:53 MET
Date: Sun, 10 Oct 99 16:31:58 MET
Message-Id: <hd_99_256B>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/256B
X-BBS-Msg-Type: B
534 Shannon Way | We break it |
Lawrenceville, GA | Guaranteed |
>.
------------------------------
Date: Sat, 09 Oct 1999 11:25:11 -0400
From: Gary Coffman <ke4zv@bellsouth.net>
Subject: Let's look at real numbers for TNC software sales
On Sun, 3 Oct 1999 22:27:34 -0700, "Hank Oredson" <horedson@att.net> wrote:
>
>Gary Coffman <ke4zv@bellsouth.net> wrote in message
>news:Xw34NxHJf+EF064afvXkDcnPO0tB@4ax.com...
>
>> >"... well engineered .." makes no sense. The paths are what they are.
>> >They go, for example, from my house to your house.
>>
>> That's where they end up, perhaps after several intermediate relay hops.
>> But each hop path has to be properly engineered. That means proper siting,
>> proper link margin, and proper consideration of multipath issues. This
>isn't
>> Olde Tyme Radio, we don't have to make the entire trip in one hop. Digital
>> networks are naturally suited to automatic relay.
>
>> >This is the long haul case we are talking about. You don't *normally*
>> >put large dishes or large yagi arrays anywhere except on your own
>> >property. Way too hard to maintain if they are not local. Exceptions
>> >exist of course, but I've never personally encountered one.
>>
>> Nor have I. With an adequate number of properly engineered relay sites,
>
>Gary,
>
>Do you intentionally misread?
>We were talking about a single link.
>A path between two stations.
>Between exactly two relay points.
>One of those hops in the network.
Yes, I understood that. What you don't seem to understand is that
if the numbers work out to an unreasonable solution, as in the cases
you've given, you don't do that single link. You do a different topology
instead that will give acceptable numbers. That will involve more than
one hop, but total network performance will improve.
>> however, there is never a need for such large antenna structures
>
>> >For the long haul case, it is rare that the path is line of sight.
>> >Usually it is a scatter path of some nature.
>> >Example: the troposcatter path from the Lowell, MA area to
>> >Southern NJ on 2M 1200 baud. Worked quite well for us when
>> >we used it. KW and 4 long yagis in NJ, 200W and two long yagis
>> >in MA. Antennas at 170 and 120 feet above local terrain.
>>
>> Incredible. I bet you were *real* popular with the other people
>> trying to use that segment of the band across at least 3 states.
>> And for nothing more than a half duplex 1200 baud link at that.
>
>Yes, totally terrible that we should carry on a QSO on 2 meters over
>a long haul path. My oh my. Better see the "coordinator" and see if it
>is ok to call CQ using high power on 2M SSB, find someone to talk
>to a few states away, and then decide to play with digital communication
>over that path. Oh dear! Next thing you know one will have to get
>permission to work Aurora or Troposcatter, much less EME!
>
>You seem to have misread "... when we used it ..." and pretended
>that I said "Network link always up."
You presented it as a network link, and the context of the discussion,
as you reminded me in another post, is network links. Network links
are coordinated (at least they are if one wants to be responsible),
and such monster troposcatter links wouldn't be coordinated because
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.
>Curious: why do you bother to post these messages here?
>Trying to convince hams to give up ham radio?
I'm trying to explain how to do ham radio effectively and responsibly
in compliance with both the spirit and letter of good network engineering
practice. If the sort of chaos one finds on Ch 19 is what you want, I'd
respectfully suggest you move your activities there.
Gary
Gary Coffman KE4ZV | You make it |mail to ke4zv@bellsouth.net
534 Shannon Way | We break it |
Lawrenceville, GA | Guaranteed |
>.
------------------------------
Date: Sat, 09 Oct 1999 15:49:41 GMT
From: rmcconne.NOSPAM@lightlink.com (Robert McConnell)
Subject: New RTTY software for Windows 95/98/NT
Why in the world would you need a 133MHz machine to handle less than
300 bits per second? Anything faster than an XT should be able to do
it. Are you perhaps inporting a lot of bloatware from the compiler and
its library?
Next question: when will the Linux and DR-DOS versions be ready?
Bob McConnell
N2SPP
On Fri, 08 Oct 1999 15:03:07 +0700, Sergei Podstrigailo <amx@i.am>
wrote:
>Hi, All!
>
>I want to attract your attention to my new software - TrueTTY V0.10.
>
>It is program to decode radioteletype (RTTY) via sound card to text.
>No additional hardware required - your need only receiver
>and computer (5x86-133 or better) with sound card.
>Windows 95/98/NT. I plan to implement transmit feature in next
>versions.
>
>73!
>Sergei,
>UA9OSV
>.
------------------------------
Date: Sat, 09 Oct 1999 12:51:39 -0400
From: Ralph Mowery <rmowery@dialpoint.net>
Subject: New RTTY software for Windows 95/98/NT
Windows overhead ????? I wrote a program to be a dumb terminal for an
8080 computer running at 2 mhz about 15 or so years ago.
The old Apples and RAdio Shack computers and Comadore ones would do it
also.
Robert McConnell wrote:
>
> Why in the world would you need a 133MHz machine to handle less than
> 300 bits per second? Anything faster than an XT should be able to do
> it. Are you perhaps inporting a lot of bloatware from the compiler and
> its library?
>
> Next question: when will the Linux and DR-DOS versions be ready?
>
> Bob McConnell
> N2SPP
>
> On Fri, 08 Oct 1999 15:03:07 +0700, Sergei Podstrigailo <amx@i.am>
> wrote:
>
> >Hi, All!
> >
> >I want to attract your attention to my new software - TrueTTY V0.10.
> >
> >It is program to decode radioteletype (RTTY) via sound card to text.
> >No additional hardware required - your need only receiver
> >and computer (5x86-133 or better) with sound card.
> >Windows 95/98/NT. I plan to implement transmit feature in next
> >versions.
> >
> >73!
> >Sergei,
> >UA9OSV
>.
------------------------------
Date: Sat, 9 Oct 1999 16:31:17 GMT
From: nomail@pe1chl.demon.nl (Rob Janssen)
Subject: New RTTY software for Windows 95/98/NT
Robert McConnell <rmcconne.NOSPAM@lightlink.com> wrote:
>Why in the world would you need a 133MHz machine to handle less than
>300 bits per second? Anything faster than an XT should be able to do
>it.
If you read the description, you see it works from a soundcard. So it gets
somewhat more than 300 bits per second: probably about 8000 samples per
second, each sample 8 or 16 bits. That is more like 64-128 kbits/s.
Too much for an XT, but it should certainly be possible on a 486.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
To be continued in digest: hd_99_256C
Read previous mail | Read next mail
| |