| |
PA2AGA > HDDIG 01.06.00 03:31l 171 Lines 7313 Bytes #-9462 (0) @ EU
BID : HD_2000_152A
Read: GUEST
Subj: HamDigitalDigest 2000/152A
Path: DB0AAB<DB0SL<DB0RGB<DB0MRW<DB0SON<DB0ERF<DB0SHG<DB0SM<PI8DAZ<PI8GCB<
PI8HGL
Sent: 000531/2253Z @:PI8HGL.#ZH1.NLD.EU #:46046 [Den Haag] FBB $:HD_2000_152A
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Thu, 01 Jun 00 00:21:12 MET
Message-Id: <hd_2000_152A>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
Ham-Digital Digest Wed, 31 May 2000 Volume 2000 : Issue 152
Today's Topics:
!!Re: N0ZO no longer supports Keyboard inputs!
Calling New Zealand
Corrected Email Address (Using Digipan 1.1 to Key Kenwood Radio)
DCC for 2000 (2 msgs)
DigiPan Receive Audio Hint Needed
DSP settings for PSK31 (2 msgs)
Encoding / Vocoding question
Kam Plus and GPS Tracker special info from Kantronics.
N0ZO no longer supports Keyboard inputs! (10 msgs)
PSK31 Audio Connection
TCP/IP not welcome (was Re: N0ZO no longer supports Keyboard inputs!) (2 msgs)
Using Digipan 1.1 to Key Kenwood Radio
Where's the love for WinPSK? (2 msgs)
Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives/ham-digital".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
Loop-Detect: Ham-Digital:2000/152
----------------------------------------------------------------------
Date: Tue, 30 May 2000 23:53:51 -0400
From: "Rob" <Pse@NoEmail.Com>
Subject: !!Re: N0ZO no longer supports Keyboard inputs!
Hi Rick,
Yes, the problem rests with the NON STANDARD Pactor implementation in the
PK232 and PK900. The PK-232 and PK-900 sends a serial number of the EPROM
whenever it receives the WRU character embedded in a binary file sent from
the other station the PACTOR. To my knowledge, NO other TNC does this.
I just read the WINLINK archives on listbot.com. I think you are referring
to Timewave's suggestion that the WINLINK station just ignore the serial
number received from the PK-232 or PK-900 (in response to receiving the WRU
character from the WINLINK station which is part of the binary message sent
from the WINLINK station).
In my view, that is not a great solution. When receiving a binary file, the
PK232 and PK-900 should NEVER seize the link and send data in response to
receiving the WRU character.
It REALLY slows down the binary transfers!!!
In Pactor, the WRU feature is completely unnecessary since the Pactor
protocol provides the callsign of the other station. I do not believe the
WRU feature is EVEN part of the Pactor protocol. In my view, the WRU
PACTOR feature in the PK-232 and PK-900 is really a bug not a feature.
The PK-232 or PK-900 does not exhibit similar behaviour in Packet. Why
does it do so in Pactor?? Perhaps, AEA implemented this "bug" to discourage
people from illegally burning their own EPROMS.
In my view, it would be MUCH better if Timewave realises that AEA made a
mistake in implementing the Pactor protocol and capitalises on the
opportunity to remove this PACTOR "bug" in the next release of the
PK-232/PK-900 firmware. It would really speed up binary transfers! It
should be very easy to fix.
With the PK900, I believe you can turn off the WRU feature (with one of the
USEBIT's) in ASCII mode but I believe the USEBIT setting has no effect when
the PK-900 receives a WRU character in the binary transfer mode. This
looks like another bug.
In my view, it would be better and simpler if Timewave completely removed
the WRU feature in the PK232 and PK900 in the PACTOR mode. I can see NO
reason for implementing the WRU feature in PACTOR. As I mentioned, I do NOT
believe that the WRU feature is EVEN part of the pactor protocol. When you
link with another station in Pactor, the PACTOR protocol provides the other
station's callsign. WRU is completely unnecessary. I have NOT seen ANY
other TNC manufacturer implement the WRU feature for Pactor.
Typically, the WRU feature is an optional feature for the AMTOR mode. It
provides BBS's a method to automatically obtain the other station's callsign
since the AMTOR protocol only provides a 4 or 7 character SELCAL. Most
TNC's (e.g. KAM) only implement the WRU feature for AMTOR.
If you don't want to remove the WRU feature in PACTOR, then optionally
provide separate USEBIT's to turn off and on the WRU feature independently
for AMTOR and PACTOR. But make sure when the WRU feature is turned off in
PACTOR, it is completely turned off during binary transfers.
In my view, Timewave should seriously consider fixing the AEA bugs and
implementing the PACTOR protocol properly (at least for binary transfer's in
Pactor!) in their next release of firmware for the PK-232 and PK-900. It
should be VERY easy to fix.
Many PK232 and PK900 owners will thank you!
73's
Rob
"Rick Ruhl" <ricker@cssincorp.com> wrote in message
news:dIZY4.135734$681.2503005@news-east.usenetserver.com...
Rob,
Both Randy Gawtry and I worked with Hans Kessler and Jim Coreman on how to
do the binary transfer modes in Pactor with the PK-232/900/2232/232. One of
the issues was that the PK-232/900/2232 sends out a serial number when a WRU
is sent (it's something that was put in during the last days of AEA and no
one seems to know why). We gave them the method that is used in PakRatt to
avoid this issue and I assume they decided not to support that, but just the
ASCII mode transfers.
PcPakRatt has been doing YAPP binary tranfers for years with the PK-232, as
well as the next version of PKTerm, which will support YAPP in Pactor.
--
Rick Ruhl
President, Creative Services Software
http://www.cssincorp.com
"Rob" <Pse@NoEmail.Com> wrote in message
news:vdSY4.3580$qS3.9230@tor-nn1.netcom.ca...
> Hi Jerry,
>
> I always thought that the PK-232 could send and receive binary files in
> PACTOR. The PK-900 can send and receive binary files in PACTOR using
either
> a terminal mode program or a host mode program.
>
> Surely, the PK-232 can at least send and receive binary files using a host
> mode program?? Is my understanding wrong?
>
> Perhaps the problem is with AIRMAIL. It sounds like AIRMAIL does not
> support the PK-232's hostmode.
>
> I agree with others that I don't like the idea of FORCING Hams to use
> particular client software to link up with a BBS. In my view, the WINLINK
> BBS's should continue to accept simple commands using ANY TNC with ANY
> client software. (I have no problems with HAM's who want to use AIRMAIL.
> But it should be an option)
>
> For portable use, I like using a small portable dumb terminal that runs on
a
> couple of AA batteries. These terminal are very inexpensive these days
and
> are VERY durable with NO moving parts like hard drives etc.
>
> You also don't have to worry about damaging an expensive laptop when
hiking,
> camping etc. Unfortunately, I can't access some of the WINLINK BBS's with
> this dumb terminal NO MATTER what TNC I am using.
>
> I am not going to buy a second hand laptop for my hiking and camping trips
To be continued in digest: hd_2000_152B
Read previous mail | Read next mail
| |
