RX only wouldn't need to worry about turnaround times.. Hmmm.... Leigh/WA5ZNU On Fri, 4 Jan 2008 5:23 pm, Dave AA6YQ wrote: > 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, "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 > >
