| |
PA2AGA > HDDIG 03.06.00 00:28l 177 Lines 7510 Bytes #-9459 (0) @ EU
BID : HD_2000_154B
Read: GUEST
Subj: HamDigitalDigest 2000/154B
Path: DB0AAB<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0SHG<DB0SM<PI8DAZ<PI8GCB<PI8HGL
Sent: 000602/1758Z @:PI8HGL.#ZH1.NLD.EU #:46823 [Den Haag] FBB $:HD_2000_154B
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Fri, 02 Jun 00 18:51:08 MET
Message-Id: <hd_2000_154B>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
restrictions in conflict with FCC R&R)
rec.radio.amateur.space (satellites, meteor scatter, EME)
rec.radio.amateur.misc (any amateur topic not covered in the above groups)
(At least two other English language radio hierarchies exist, prefixed
with "uk" (United Kingdom), and "aus" (Australia), in place of "rec.")
Again, cross-posting should rarely be necessary. Many times, a long-
running thread results from a single cross-posted article, and its
content drifts further and further away from being "on-topic" in the
various NGs which receive each and every followup.
For more detailed information, see "Guide to the Rec.radio Newsgroups"
posted on the 15th of each month.
Jeffrey Herman, KH6O
------------------------------
Date: Fri, 02 Jun 2000 02:24:33 +0200
From: Nico Palermo <nicopal@microtelecom.it>
Subject: Looking for Nico Palermo - YAM modem creator
Hello Bruce,
you haven't been pushy.
Simply, I'm very busy with my job and reply just occasionally to all the
YAM-related e-mail.
I apologize for this practice, but it's not so easy to handle a
world-wide interest by a single man, nor I was prepared to receive it.
I remember that when I developed the YAM (July 1997), I asked Andreas
Gal (the author of the popular "TFX" TNC emulator) the sources of his
software in order to add support for the new modem. He never sent them
me and only after some months I got them, thanks to the initiative of
Peter Guelzow, DB2OS.
Only after a while I could understand Andreas' behaviour.
Maybe tomorrow you will develop something new and receive twenty, fourty
or one hundred e-mails per day. By then you will discover how hard could
it be to reply even to one of them, taking care of your God, your family
and your job at the same time.
73s de Nico, IV3NWV.
W3NJ wrote:
>
> I've been trying to get in touch with Nico Palermo in Italy to purchase some
of
> his YAM packet modem boards. I've sent him email but have not received any
> responses. Has any one heard from him?
>
> Thanks es 73
>
> de Bruce- W3NJ
------------------------------
Date: Thu, 01 Jun 2000 07:52:15 -0500
From: JoAnne Maenpaa <QA1955@email.mot.com>
Subject: N0ZO no longer supports Keyboard inputs!
Hi Rob and all,
> It is not TCP/IP technogogy that is slow, it is the modem technology
> used by hams that is making it appear slow. Most packet users today
> still use the 1200 bps AFSK modem that was chosen more than 15 years
> ago as a quick way to get things running. Even the fact that the
> modem chips were discontinued by the manufacturers one by one has not
> awakened them.
I fully agree that 1200 baud is the cause for the slowness. And, back
then, when packet radio and TCP/IP were introduced we had to start some-
where. In fact, one previous assignment I received at work to develop
system requirements for cellular packet data was directly related to
my earlier ham radio background. Now I had the challenge of "doing it"
at 800, 900, and 1900MHz, trying to keep the link up at 64K, and finding
a way to bill the end-user. There is a new generation of congestion
problems just beginning to be addressed ... 64K vs. 1.2K is not the
cause ... now its where did that million people trying to access the
network at the same time come from? :-)
I'm as guilty of this as the next ham, which is in ham radio we still
spend a lot of time concentrating on the link layer. We now have the
links in place (more or less). The next value-added proposition is to
build up the application layer. This is not directly amateur radio re-
lated so I'm not sure we'd find many to sign on to develop applications
linkable via the TCP/IP infrastructure.
Most of the reason I keep my amateur radio license now is due to my
volunteer work with a local county emergency management agency. We've
been looking for applications to link remote sites such as shelters
and staging areas back to the emergency operating center. A few exist
(ARESData); these also are a good beginning. Trying to track which
people are at any given shelter, or how much construction equipment
or food is at a staging area is a database application problem and not
really too interesting for the average ham.
When an incident commander wants to know if he/she has enough food to
feed the people at a shelter he/she won't really care if the answer
comes back via 1200 baud TCP/IP. The application layer provided the
answer.
Take care,
--
JoAnne WB9JEJ
------------------------------
Date: Thu, 01 Jun 2000 14:39:37 GMT
From: "Hank Oredson" <horedson@att.net>
Subject: N0ZO no longer supports Keyboard inputs!
"JoAnne Maenpaa" <QA1955@email.mot.com> wrote in message
news:39365C7F.817AA5D3@email.mot.com...
> Hi Rob and all,
>
> > It is not TCP/IP technogogy that is slow, it is the modem technology
> > used by hams that is making it appear slow. Most packet users today
> > still use the 1200 bps AFSK modem that was chosen more than 15 years
> > ago as a quick way to get things running. Even the fact that the
> > modem chips were discontinued by the manufacturers one by one has not
> > awakened them.
>
> I fully agree that 1200 baud is the cause for the slowness. And, back
> then, when packet radio and TCP/IP were introduced we had to start some-
> where. In fact, one previous assignment I received at work to develop
> system requirements for cellular packet data was directly related to
> my earlier ham radio background. Now I had the challenge of "doing it"
> at 800, 900, and 1900MHz, trying to keep the link up at 64K, and finding
> a way to bill the end-user. There is a new generation of congestion
> problems just beginning to be addressed ... 64K vs. 1.2K is not the
> cause ... now its where did that million people trying to access the
> network at the same time come from? :-)
>
> I'm as guilty of this as the next ham, which is in ham radio we still
> spend a lot of time concentrating on the link layer. We now have the
> links in place (more or less). The next value-added proposition is to
> build up the application layer. This is not directly amateur radio re-
> lated so I'm not sure we'd find many to sign on to develop applications
> linkable via the TCP/IP infrastructure.
Mainly there is no need to build those applications. They already exist.
When I "do packet radio" mostly I use Outlook Express, various ftp
and telnet clients, IE5 or Netscape 4.73, etc. etc. This capability has
been there from the first availability of tcp/ip over packet radio in 1984.
> Most of the reason I keep my amateur radio license now is due to my
> volunteer work with a local county emergency management agency. We've
> been looking for applications to link remote sites such as shelters
> and staging areas back to the emergency operating center. A few exist
> (ARESData); these also are a good beginning. Trying to track which
> people are at any given shelter, or how much construction equipment
> or food is at a staging area is a database application problem and not
> really too interesting for the average ham.
>
> When an incident commander wants to know if he/she has enough food to
> feed the people at a shelter he/she won't really care if the answer
> comes back via 1200 baud TCP/IP. The application layer provided the
To be continued in digest: hd_2000_154C
Read previous mail | Read next mail
| |
