[pskmail] Thoughts on Forward Error Correction

From: William <va3udp@xxxxxx>
To: pskmail@xxxxxxxxxxxxx
Date: Thu, 6 Nov 2008 16:45:34 +0100
Here are some of my recent thoughts on forward error correction and
encoding schemes. I put them out here hoping that they might cause
some discussion about the physical layer encodings used by pskmail,
with a view to greater reliability and throughput.

About the best design document, complete with detailed reasoning,
for a FEC scheme that I have found is the AO40 telemetry spec
here: http://www.ka9q.net/ao40/

It is a block level coding technique so not necessarily suitable
for interactive sessions. Basically there is parity information
generated by a Reed-Solomon code and the data is then scrambled to
discourage too many adjacent zero bytes and then spread out in
the time domain with a convolutional encoding.

In terms of information carried per bit over a lossy channel, I
understand Reed-Solomon encoding to approach the Shannon limit
theoretical maximum. The only known scheme that does better are
Turbo Codes which are patent encumbered.

So why does, for example, fldigi, not implement any mode with
RS FEC? I am speculating, but I think it is because it is
designed for interactive use. Sending data in fixed block sizes
of 64, 128, 256 bytes is not so useful for that. But it *is*
useful for bulk data transfer such as email messages.

I think THOR22 is better than no FEC but sub-optimal for bulk
transfers as it is designed for interactive sessions.

Even so, a FEC scheme like the above is useful when readability
is marginal or variable but are a waste of bits when readability
is good. In the latter case, simple ARQ such as is implemented
now is proably best. Is it possible to have the system adapt,
to be able to tell what type of error detection/correction is
best? HARQ is a scheme that does just that. See

http://en.wikipedia.org/wiki/HARQ

It is used in UMTS cellular data networks. Running pskmail with
THOR22 can be considered Type 1 HARQ, that is, using FEC
and ARQ at the same time. More efficient, but more complicsted
would be Type 2 HARQ, adapting to prevailing conditions,
with a better FEC coding.

Beyond that, what about schemes like Q15X25 that essentially
transmit multiple narrow data streams to multiply throughput?
Necessarily wideband at this point, occupying in the
neighbourhood of 2kHz, but at about 10x the data rate. Would
it make sense to do the signalling as now but for bulk data
transfer QSY to a sub-band where 2kHz signals are allowed
and more quickly transfer the bulk data?

Would an encoding scheme like the above be useful or
desireable? Any thoughts?

73 de William EA5/VE2WSW
va3udp /@/ rac.ca
[pskmail] Thoughts on Forward Error Correction

Other related posts:
