There is already a degree of Huffman-type compression in PSK31 via the Varicode, where the number of bits per symbol depends on symbol frequency.
Compression that depends on the text that went before it could be more efficient, but would lead to total loss of the following text in the ecent of an uncorrected error. In order to prevent that loss, you have to be able to resync quickly to recover from errors. PSK31 does this with the character stop bits, limiting the damage to one letter. (I.e., the block size is 1 char.) Allowing references further would need to be combined with at least a block mechanism, so that the RX side would know to restart. For example CCIT G3 Fax uses run-length coding within a lone, limiting damage to an area of a line, G4 fax, designed for ISDN which was expectted to be less noisy, uses a back-reference that can refer to repeating regions within a group of 4 lines, limiting the damage to 4 lines. (Also the greater compression allows the use of higher resolution images, making the lines smaller too.) It isn't immediately clear how to apply this slight increase in block size to PSK, since I don't see any easy boundaries other than characters. ECC of some sort on the blocks would make the compression more useful, so you wouldn't lose a whole block. An ACK/NACK mechanism (ARQ) could help make use of the ECC info, and since you could depend on the receipt of previous blocks you could count on references between them. So, it is a slippery slope away from keyboarding. Leigh/WA5ZNU On Sat, 13 Jan 2007 7:11 am, KV9U wrote: > On a separate note, how feasible is it to incorporate L-Z/Huffman > combined compression in any data mode, including keyboard mode?
