Those who have considered implementing Pactor 2 and/or 3 report two
challenges:
1. The documentation provided is insufficient
2. The turnaround time requirements demand an operating system with
real-time scheduling capabilities that Windows does not provide
#1 might be overcome by an intense reverse engineering effort, but #2
reduces the total available market to a point where #1 is moot: either the
application must be written to run natively on Linux or some other realtime
OS (small user base), or the application must run on a dedicated processor
in a relatively expensive outboard box (small user base).
Most people smart enough to write good software are smart enough to not be
motivated by a dare alone.
73,
Dave, AA6YQ
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Demetre SV1UY
Sent: Friday, January 04, 2008 4:49 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Licensing of Pactor modes
--- In digitalradio@yahoogroups.com <mailto:digitalradio%40yahoogroups.com>
, "Jose A. Amador" <[EMAIL PROTECTED]> wrote:
>
>
> I have attempted to ignore what matters only to those under the FCC
> jurisdiction. Seems that this anti-Winlink regurgitation is an
> unavoidable evil...
>
> Going to the facts: Kantronics did not implement memory ARQ for Pactor
> in their early KAM's. So, they were inferior to the real stuff, the SCS
> Z-80 Pactor Controller.
>
> PacComm sold a Pactor controller, but they had marginal profits in
> general, as they did not offsource the production of their units, as
AEA
> did.
>
> Jose, CO2JA
>
> ---
Hi Jose,
Going back to the facts I forgot to mention that even if Kantronics
and some other makers tried to reverse engineer PACTOR 1 more than 10
years ago, as some seem to support in this list and also claiming at
the same time that PACTOR 1 was OPEN (which might have been), they
never managed to do it properly. Don't forget that a British software
writer (G4BMK) managed to implement PACTOR 1 properly using a terminal
unit, not a sound card, and in a DOS computer (I have bought his
program BMKmulti and it works as good as SCS's PACTOR 1 implementation).
This is probably the reason why SCS decided to keep to themselves
PACTOR 2 and 3 and not to license it to anyone, although I am not sure
if anyone ever asked for a license of PACTOR 2 and 3 following ther
failure to implement PACTOR 1. If the best companies could not
implement properly PACTOR 1 can you imagine what a mess they would do
with PACTOR 2, never mind 3. So I cannot see why some fellow amateurs
complain against SCS keeping their code to themselves. They do not do
the same with other software writers.
I dare and urge the software writers if they are any good to try and
contact SCS and ask if they can implement PACTOR 2 and 3. It would be
great if they could offer the efficiency of PACTOR 2 even in a
soundcard program, but I think they can't.
If SCS is such a bad company and they will not license PACTOR 2 or 3
(and I personally do not blame them for doing so) why can't they try
and write an ARQ SOundcard Program that can go as fast as even PACTOR
2? Never mind PACTOR 3, which many people class as a commercial product!
At the moment I can only see PSKmail that performs only as good as
PACTOR 1, thanks to Per PA0R, which is better than nothing at all.
Also I saw lately NBEMS trying to do the same as PSKmail although I
like PSKmail much more than NBEMS.
Both can be called "The poor man's Winlink2000", but really they leave
a lot to be desired as far as speed and good behaviour in bad HF
propagation is concerned.
73 de Demetre SV1UY
