Hi Jose, Do you see any difference between the convolutional code of Pactor and the Viterbi code in MFSK16 or Patrick's use of Viterbi code in his F versions of PSK and his FEC of DEX?
The extra thing that SCS developed early with Pactor 1 was the ability to create a correct frame from multiple tries (what they call memory ARQ) which has a similiar effect as coding gain. With Pactor 2 and 3 they get a type of diversity gain by changing the order of which tones are swapped back and forth. This is specified in their description of the P3 protocol, but I don't fully understand this and maybe this is not easy to implement. While P2 uses DBPSK, DQPSK, 8-DPSK, and 16-DPSK, P3 only uses DBPSK and DQPSK. I think that SCS discovered through trial and error that the higher constellations are too much for good HF performance. And with P3 they only use QPSK with Levels 4, 5, and 6. Level 4 uses 14 tones, Level 5 uses 16 tones and only Level 6 uses the full 18 tones. BPSK is used at the more robust protocols of Level 3 with 14 tones, Level 2 with 6 tones, spaced farther apart, and Level 1, the most robust, with tones widely spaced and as they put it, with tones at positions 5 and 12, "can be considered as equivalent to the two carriers of PACTOR-II, as they transfer the variable packet headers and the control signals." They also lock in the speed at 100 baud with P3, rather than switch between 100 and 200 baud as they did with P2. Again, I suspect that SCS discovered that the 100 baud speed was the best compromise and simplified the design of the protocol since you keep the speed the same at all times. One less thing to program? Using an asynchronous mode seems like a much better idea for sound cards and this was the approach used by SCAMP which proved how well this can work. P3's wide bandwidth means that it is not really any faster than P2 when you adjust for the bandwidth to throughput speed, or 500+ Hz BW for P2 vs. around 2400 Hz BW for P3. It seems so feasible for one knowledgeable ham to put the pieces together to create a superior sound card mode using what we already have. If it is ever proven that the wide bandwidth, high speed ALE modes using 8PSK can match P3, then those protocols could be used as an open source design, but when you look at the theoretical throughputs from various sources, they seem to suggest that these modes do not work all that well below zero dB S/N. 73, Rick, KV9U Jose A. Amador wrote: > > Pactor uses convolutional encoding with Viterbi decoding, which allows > maximum likelyhood detection. Which means that the decoder "knows", > taking into account the history of the stream what symbols are likely to > come next, instead of what a blind demodulator does. > > Interleaving is vital for HF data chennels. > > What else could be better? Turbo codes or low density parity codes could > be added, to get even closer to the Shannon limit. But it does not mean > that it will accept a narrowband channel. Latency will obviously be > higher, which will not please the hard-die keyboarders. > > With all what it carries in the bag of tricks, Pactor III is hard to > beat. A copy does not seem convenient, but why not a mimic of that? > > If a synchronous mode is not convenient with Windows and how it manages > the timers, why not an asynchronous mode? > > 73, > > Jose, CO2JA >
