| |
PA2AGA > HDDIG 01.06.00 15:19l 200 Lines 7362 Bytes #-9461 (0) @ EU
BID : HD_2000_152H
Read: GUEST
Subj: HamDigitalDigest 2000/152H
Path: DB0AAB<DB0FSG<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0SHG<DB0OBK<DB0SM<PI8DAZ<
PI8GCB<PI8HGL
Sent: 000601/0016Z @:PI8HGL.#ZH1.NLD.EU #:46288 [Den Haag] FBB $:HD_2000_152H
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Thu, 01 Jun 00 00:21:23 MET
Message-Id: <hd_2000_152H>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
a firmware upgrade just to use free software.
And it really doesn't slow down the transfers if implemented correctly. We
did some in house testing with it, and found with YAPP an Pactor, we'd get
75% throughput in most cases, and this was with large files. I think the
issue may be with the F6FBB protocol, which wasn't designed for Pactor (it's
a packet based protocol).
Also, you could work around it by using the transparency characters... this
way, the TNC would never even get a <CTRL-E> and wouldn't trigger the WRU.
I guess it's easier to work around things in software, than ask an end user
to upgrade their firmware which would cost them $$$$.
And yes, 1.5 of PKterm which will support YAPP with the current proms, will
be a free update for our userbase.
--
Rick Ruhl
President, Creative Services Software
http://www.cssincorp.com
"Rob" <Pse@NoEmail.Com> wrote in message
news:F10Z4.3937$qS3.10742@tor-nn1.netcom.ca...
> 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
> > etc. They are simply not very durable.
> >
> > I thought one of the purposes of WINLINK was to allow portable stations
to
> > send and receive Internet EMAIL. I guess it was really designed for
more
> > permanent portable stations (like Marine Mobile). What a PITY!
> >
> > 73's
> > Rob
> >
> > Perhaps
> > "Jerry Flanders" <jflanders2@home.com> wrote in message
> > news:39333958.373843085@news...
> > > On April 23, k4cjx announced that WL2K will now work in the ASCII
To be continued in digest: hd_2000_152I
Read previous mail | Read next mail
| |
