Reed-Solomon encoding/decoding is a powerful way to detect and correct transmission errors. Earlier methods like
CRCs (Cyclic Redundancy Checks) could only tell you if the previous block of data contained errors. With Reed-Solomon
encoding, we can also correct those errors. Like CRCs, the mechanism involves appending a block of 'checksum' style
bytes to the end of a block of data derived from some algorithm run over that data. The process is complex and I won't
attempt to explain it here. The good news is you don't need to know how it works to be able to utilise it. The number of
errors per block of data that a Reed-Solomon checksum can correct is tuneable by how many extra bytes you want to
append. There are a range standard settings that are used throughout the communications world, but a common one -
and the one LRPT uses, is the 255,223 mode. What this means is that for a block of 255 bytes, only 223 of them are
user data, while 255-223=32 bytes are the RS block check characters.

As you might have already figured out, we can fit exactly four blocks of 255 bytes in the 1020 bytes after the ASM in our
received CADU line. Below is a diagram of the 1020 byte CVCDU area showing 892 data bytes appended with 128
R-S bytes.

Another wrinkle in the process is that of interleaving. A typical scenario is that a short burst of noise will distort a few
microseconds worth of data. So, you could lose too big a slice of data and/or RS bytes and you are no better off than
withoutany error correction ability. If you break up the 223 data bytes to be checked by selecting them from a wider
spread of bytes and then send it, when you regroup the data back into contiguous blocks for checking - any burst noise
will now have been broken up and spread over a greater span of of the byte stream. This gives the RS process a better
chance of recovering the lost data. It is simply a case of, without interleaving, you could have 40 consecutive bytes in
error in a 255 byte block of data. With interleaving, you can spread those same 40 errors across four blocks, each block
only having to correct 10 errors each. LRPT uses an interleaving factor of 4.

In our case of LRPT, the Reed-Solomon bytes are made up of the last 128 bytes of our 1024 byte CADU. The 1020
byte CVCDU zone is made up of four blocks of 255,223 R-S encoded bytes, that is 4x223 bytes of data and 4x32 R-S
symbols. The by-four interleaving spreads each 255 byte block across the whole 1020 byte line, giving us the improved
burst noise immunity.

It should be pointed out that you don't have to perform the Reed-Solomon decoding step, as the 892 bytes of data are
'in the clear' - the R-S process does not alter the bytes, it simply can be used to correct any bytes that were received in
error. If you have a good clean signal free of interference, you probably have very few errors. On the other hand, with
polar orbiting satellites near the horizon, pagers and the aircraft band and, dare I say it, home-made antennae, there is
significant gains to be made by utilising the error correction capabilities of the Reed-Solomon encoding. One major
shortcoming of these new digital data formats is that one bit in error can cause the complete failure of an entire block of
imagery data. In the case of Meteor, the image tiles are 8x96 pixels in size. The old salt and pepper noise spots in the
old analogue signal imagery is now replaced with huge rectangular slabs entirely obliterated.

Like the viterbi code, I have used the Reed-Solomon code contained in Phil Karn's Forward Error Correction library. I
have extracted the necessary components and 'Windows' it for my purposes. At the heart of it there are two routines. One
is the official CCSDS, dual conversion method, and the other is the straight through 'normal' method. LRIT uses the CCSDS
method, but for some unknown reason Meteor uses the straight through method. makes no difference to the result - I believe
the dual conversion method was invented to simplify the circuitry on-board the spacecraft. In this modern day and age,
processing power and FPGA real estate no longer present any real roadblocks...
Here is the code segment that shows my approach to decoding the four, interleaved blocks in a 1024 byte line of data.