| |
PA2AGA > HDDIG 01.06.00 15:12l 172 Lines 7350 Bytes #-9461 (0) @ EU
BID : HD_2000_152F
Read: GUEST
Subj: HamDigitalDigest 2000/152F
Path: DB0AAB<DB0SL<DB0RGB<DB0MRW<DB0ERF<DB0SHG<DB0SM<PI8DAZ<PI8GCB<PI8HGL
Sent: 000531/2352Z @:PI8HGL.#ZH1.NLD.EU #:46286 [Den Haag] FBB $:HD_2000_152F
From: PA2AGA@PI8HGL.#ZH1.NLD.EU
To : HDDIG@EU
Date: Thu, 01 Jun 00 00:21:20 MET
Message-Id: <hd_2000_152F>
From: pa2aga@pe1mvx.ampr.org
To: hd_broadcast@pa2aga.ampr.org
X-BBS-Msg-Type: B
their word.
However, I don't think many hams or mariners would be willing to spend $50 for
a firmware upgrade just to work around an issue that can be worked around in
software. The installed base is what is important, and personally I feel that
since Winlink is free, it's silly for someone to have to pay for 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
To be continued in digest: hd_2000_152G
Read previous mail | Read next mail
| |
