| |
PA2AGA > HDDIG 20.09.00 23:25l 201 Lines 7707 Bytes #999 (0) @ EU
BID : HD_2000_256C
Read: DC1TMA GUEST
Subj: HamDigitalDigest 2000/256C
Path: DB0AAB<DB0FSG<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0BRI<DB0HAG<DB0ACH<PI8JOP<
PI8ZAA<PI8HGL
Sent: 000920/1852Z @:PI8HGL.#ZH1.NLD.EU #:16248 [Den Haag] FBB $:HD_2000_256C
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Tue, 19 Sep 00 20:17:27 MET
Message-Id: <hd_2000_256C>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
> You might
> > be surprised to find out how many modified VHF amateur radios are
> being used on
> > the VHF and UHF business bands - without power limits.
>
> People get scared off by licenses. They want ready-to-go, turn-key
> applications.
I believe you either did not understand my comment or chose to ignore it.
My point, simply, is that the 2W power limit of MURS is already being flauted
by the scad of users that use modified amateur radios for Part 90 operation.
You're touting the power limit as an advantage and I'm noting that the power
limit holds little stength.
> > > 2) Like it or not, people WANT commercial content. I don't see what
> > > you are complaining about now; first you were bitching about hams
> using
> > > the Internet as a backbone, because of all that "commercial"
> content.
> > > Now the FCC has provided us with a solution, you are bitching about
> > > that.
> >
> > The FCC has long permitted commercial data, in the Part 90 service
> (for example).
> > Just fill out a license and buy type-accepted gear. It hasn't set
> the world on
> > fire. MURS will not, either. It is not a substitute for amateur
> radio.
>
> Like I said - people don't want to deal with licenses. The also don't
> want to pay a lot of money. FRS radios cost as little as $20 at Wal-
> Mart - if MURS radios can come anywhere near this number, it WILL be a
> success.
Agreed, there are some inexpensive FRS radios. However, these are extremely
simple radios without a connector for an external antenna or audio.
> > > Face the facts, Hank - the world has changed.
> >
> > Hank might have some zany ideas, all that Pacific Northwest moisture
> seems to have
> > gone to his head sometimes :-), but I believe he's right on about
> this topic.
> >
> > Stewart, you're excited about MURS. Have you ever listened to those
> frequencies?
> > I don't think you'll be as excited after all the voice users start
> jamming your data
> > network.
>
> That is the first thing you've said that is of interest.
Well, I take it you haven't actually listened to the "color-dot" frequencies?
The FCC proposed the MURS to deal with the fact that unlicensed use of the
color-dot channels was far out of hand.
Dana K6JQ
dana@source.net
------------------------------
Date: Mon, 18 Sep 2000 15:04:48 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: TCP/IP Address
"Paul Keinanen" <keinanen@sci.fi> wrote in message
news:4jbbssgv2fqjin9f5t0o10kvcug6ai1vet@4ax.com...
> On Mon, 18 Sep 2000 01:30:12 GMT, horseshoestew@my-deja.com wrote:
>
>
> >The trick is to come up with applications that are useful at 1200bps.
> >That's what I'm working on.
>
> DX-cluster and APRS are just that type of applications that can live
> with 1200 bit/s, in which messages are usually generated at so low
> rates that the link is idle between messages and there is only a small
> risk that queues are formed at one end of a link. Applications that by
> design require queueing (e.g. store and forward) destroy the
> responsiveness of any interactive applications, unless some QoS
> concept is used to prioritise the traffic by a frame by frame basis.
Please don't confuse "applications" with "interactive applications".
> Applications similar to GSM cellular phone SMS (Short Message Service)
> or DX-cluster "talk" functions in which 1 .. 3 lines of text is
> delivered in more or less real time so that an interactive discussion
> can be maintained. But even in this case the link loading should be
> kept low even during peak hours to maintain a usable response time at
> these extremely slow half duplex links if more than one link is
> involved in the transfer.
Several "chat" applications have been available for about 10 years.
All I'm familiar with do what you mention above, and more.
--
... Hank
http://horedson.home.att.net
------------------------------
Date: Mon, 18 Sep 2000 15:00:01 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: TCP/IP Address
"Rob Janssen" <nomail@rob.knoware.nl> wrote in message
news:slrn8sblar.qv.nomail@linux.pe1chl.ampr.org...
> Hank Oredson <horedson@att.net> wrote:
>
> >> Yes, at least two of them. From SV1AGW and from the Flexnet group.
> >> These don't need the hackery you propose, they just implement a network
> >> interface that runs packet protocols (just like the Linux solution).
>
> >Have looked at both.
>
> >Did not see how they handled the nntp <-> bulletin
> >and smtp/pop3 <-> personal message translations.
>
> As usual, Hank is discussing in circles again. First he wants examples of
> how TCP/IP applications can be used with packet radio, and once you give
> them he starts talking oldfashioned packet radio protocols again!
Rob, to make any such operation useful, things must interoperate.
> Who would ever want this translation in the client software?
Who was talking about client software?
> In a TCP/IP network, the clients are talking to corresponding services
> on the network and server systems. Your BBS will be running INN and
> sendmail (plus probably a POP3/IMAP server), no hamradio BBS stuff.
And how will it then interoperate with the existing services?
Without that interoperation, it won't work.
> When there has to be any gatewaying, it will be done by the BBS system,
> not the user software. Of course.
"the BBS system" ... "user software".
This is the same old song that we have heard for years.
Why must these be different things?
> >Have you looked at SNOS to see what is needed?
>
> I have never had a DOS-based system at home. Sorry.
> My system is now running Linux, and I have NET running for the conversions.
> I have not seen the need for anything different yet.
I didn't ask you whether you ran it, but whether you looked at it
to learn what problem it solved, and why.
> >> There was a painful gap between the introduction of Windows 95 and the
> >> usability of its TCP/IP networking on amateur packet radio. One would
> >> have expected the TNC manufacturers to step in with a TNC with modified
> >> firmware to provide a PPP interface on the ASYNC end while running IP
over
> >> AX.25 on the radio. Then, it would have been possible to use the
standard
> >> dialup networking of Windows 95 with amateur radio, with the addition of
> >> only a small control-panel program to perform some settings of the TNC.
>
> >There is a good deal more required. We are in complete agreement of
> >course on the direction taken by the TNC manufacturers. I've talked
> >to two of them, and their response was essentially that making changes
> >like this is very expensive (I agree) and that there is little market
> >pressure to make those changes (I also agree).
>
> As others have noted, for the Internet market boxes like this are available
> in many forms. And the software that would be needed in a TNC like this is
> mostly available for free.
> Integration to a product that can be sold may cost some money, and of
> course it is easier to keep your customers dumb and not let them taste any
> networking, or they will become hooked.
So your claim is that NET/ROM is not "networking", APRS is not "networking",
DX cluster is not "networking"? Didn't think you were a tcp/ip bigot.
> This worked well when the alternative was telephone BBSes, essentially the
> same stuff as the packet radio system.
> Too bad they then got the Internet, and saw the light. That meant the end
> of telephone BBSes, and ultimately the end of packet radio as well.
To be continued in digest: hd_2000_256D
Read previous mail | Read next mail
| |
