Because a critical variable of the test was altered, and only for a selected mode, the test is invalid.
If you are to compare the modes validly they *must* be tested on essentially similar platforms. There was no good reason to distort the tests by inserting the specialized hardware, I believe that Pactor I will run on a sound card, only Pactor II and III are dependent on rare proprietary hardware with rare proprietary software run under a proprietary OS. One must *first* test the modes on equivalent platforms and establish a common baseline. Then one would move to specialized tweaking of the hardware and software -- allowing *experts* in each mode to do the tweaking. Equally curious to the substitution of specialized hardware exclusive to Pactor I was that the adjustment of settings for the other modes that may have improved their results was intentionally not attempted. The test parameters are so badly skewed toward Pactor I that there is nothing of value to be learned. It would not be the first time that EM folks chose the wrong app because they looked at the wrong variables. As a former employee of an EM organization and a former SEC I have looked at these matters, as have many others. K.I.S.S., and redundancy = relibility remain valid. Proprietary anything is not K.I.S.S. and makes redundancy improbable. It is a reality that disasters are unpredictable and that they rarely happen where and when one prefers. This means that maximum redundancy is critical. The use of a rare proprietary solution is a very poor choice as such creates a high probability that it will not be where one needs it and resolution of a failure in any of the critical interlocking three elements may be impossible in time to be helpful. The threshold of real-world operational effectiveness between the most highly optimized Pactor III station and other modes is not so radically huge as to justify risking the mission on the hope that such a system will be in place at both ends required and will always work. Relying on modes that are non-proprietary and will run on almost any available hardware makes far more sense under a vastly more diverse set of probable scenarios. EM is vastly better served through the enhancement of the network of commonly available modes. Such a project is under way via the LinLink project and others. IMHO. YMMV ... 73, doc KD4E > Off-list reply. Details below as posted to the STXARES Yahoo group in > January 2006. The test was to evaluate FNpsk, which has BPSK31 and > QPSK63 modes only. Olivia was not tested. Pactor 1 was not part of the > original test plan. Since Pactor 1 was considered to be the current > standard, it seemed reasonable to us to compare how well it did under > the same conditions. > > Only one question remained unanswered. What is the relative > effectiveness of Pactor between these same stations, with all other > conditions being similar? > > Two stations used SCS PTC-II controllers and one station used an AEA > PK-232, all in Pactor 1 mode, and all with the Airmail program. > Messages were easily exchanged among all three stations at the maximum > Pactor 1 speed of 200 bps. We sent messages direct, and posted messages > for other stations using Airmail's transit box feature. Only once did > we see the speed drop to 100 bps. In all cases, the message went > through, and went through accurately. > > It was never our intent to become "Myth Busters," ... > > Respectfully submitted, > > Hal Merritt, KD5HWW, ARES EC > Ken Mitchell, KD2KW, ARES DEC > Jerry Reimer, KK5CA, ARES SEC > > -- Thanks! & 73, doc, KD4E ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Projects: http://ham-macguyver.bibleseven.com Personal: http://bibleseven.com Note: UNder reconstruction due to server change. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
