On Tue, 19 Nov 2013 16:13:43 -0600, "matt d" <98932@dsprelated> wrote:
>>On Tue, 19 Nov 2013 11:41:06 -0600, "matt d" <98932@dsprelated> wrote:
>
>>
>>A "shortened" code implies that the data field has been shortened from
>>the native code. e.g., the very common (204, 188) Reed-Solomon code
>>with 8-bit symbols, used in DVB and many other places, is shortened
>>from a native (255, 239) code. I'm not quite sure what the 13 is for
>>in your (24, 12, 13) code, as it is unlikely to be be t if n-k is 12.
>>I'm also having trouble reconciling your earlier statement about 39
>>symbols being deleted for the shortening. As a result I'm a little
>>unsure about your notational convention, but if your shortened code is
>>(24,12), the native code (or mother code or whatever you want to call
>>it) may be (31, 19) or something like that.
>
>The notation I am using is (N,K,D) N=number of symbols, K=number of parity
>symbols, D=distance. the code is shortened from the length of 63. So the
>native code was (63,51,13).
>
>>The difference is usually zero-stuffed in both the encoder and
>>decoder. Since you are using a library I would first guess that the
>>decoder is built to work on the native code rather than a specific
>>shortened code, but I'm unfamiliar with the library. In other words,
>>maybe the library decoder is expecting the zero-stuffed (31, 19)
>>mother code?
>>
>unfortunately i have no library for the decoding. and i am trying to use
>Simon Rockliff's rs.c to do the decoding.
That's the library I was referring to. In other words, you're using
somebody else's implementation, which I'd first assume was generic,
i.e., doesn't assume shortening. My assumption there could be wrong,
though, and the implementation may be smart enough to sort out
shortening if configured correctly. In that case, you're at the
mercy of the assumptions made in the implementation, but you may be
able to sort out what those were if the code documentation doesn't
make it explicit.
> but i have seen the same
>encoding process in python code.
Same as what? Are you sure they're the same?
> it builds the 24 symbol codeword like
>this:
>
>def rs_24_12_13_encode(data):
> matrix = (
>(1,0,0,0,0,0,0,0,0,0,0,0,062,044,003,025,014,016,027,003,053,004,036,047),
>(0,1,0,0,0,0,0,0,0,0,0,0,011,012,011,011,016,064,067,055,001,076,026,073),
>(0,0,1,0,0,0,0,0,0,0,0,0,003,001,005,075,014,006,020,044,066,006,070,066),
>(0,0,0,1,0,0,0,0,0,0,0,0,021,070,027,045,016,067,023,064,073,033,044,021),
>(0,0,0,0,1,0,0,0,0,0,0,0,030,022,003,075,015,015,033,015,051,003,053,050),
> (0,0,0,0,0,1,0,0,0,0,0,0,001,041,027,056,076,064,021,053,004,025,001,012),
> (0,0,0,0,0,0,1,0,0,0,0,0,061,076,021,055,076,001,063,035,030,013,064,070),
> (0,0,0,0,0,0,0,1,0,0,0,0,024,022,071,056,021,035,073,042,057,074,043,076),
> (0,0,0,0,0,0,0,0,1,0,0,0,072,042,005,020,043,047,033,056,001,016,013,076),
> (0,0,0,0,0,0,0,0,0,1,0,0,072,014,065,054,035,025,041,016,015,040,071,026),
> (0,0,0,0,0,0,0,0,0,0,1,0,073,065,036,061,042,022,017,004,044,020,025,005),
> (0,0,0,0,0,0,0,0,0,0,0,1,071,005,055,003,071,034,060,011,074,002,041,050))
> assert data < 2**72
> codeword = [0,] * 24
> for i in range(24):
> for j in range(12):
> hexbit = (data >> ((11 - j) * 6)) & 0x3f
> codeword[i] ^= gf6mult(hexbit, matrix[j][i])
> return codeword
>------end code--------
>
>looks to me like a 12 6-bit integers (maybe in an array with 12
>posititions??) are multiplied by this 12x24 matrix to produce the 24 6-bit
>symbols to create the 24 hex-bit codeword. i don't see anything about
>padding with zeros.
Note that the left 12 columns make up an identity matrix (for the data
field). If the data field identity matrix were extended upward 39
more rows (that's the 39 6-bit symbols that got deleted) so that the
identity matrix was 51x51 instead of 12x12, you'd have the whole
encoder (assuming you had the parity field to go with it). Since the
encoder appears to be implemented with just the rightmost 12 rows, you
don't see the others, which implies that they're zeros.
This means that either a) you can configure the decoder for the full
(63, 51) code, replace the 39 6-bit zeroes for each received codeword,
and decode it as the native code, or b) confirm that the decoder you
have really does know how to either do a) automatically or decode the
shortened code properly. You can probably test it with a) and then
see if you can get to b).
Unless somebody here is familiar with the implementation you're using
you'll have to sort that out yourself or ask the author or somebody
else familiar with it. Perhaps there's documentation with the code
that helps with that.
>>>the generator polynomial for the (24,12,13) shortened Reed-Solomon code
>>>is:
>>>
>>>g(x) = 50 + 41x + 02x^2 + 74x^3 + 11x^4 + 60x^5 + 34x^6 + 71x^7 + 03x^8
>+
>>>55x^9 + 05x^10 + 71x^11 + x^12
>>>the coefficients are in octal while the exponents are in decimal. The
>(KxN
>>>or 12x24) generator matrix is constructed from the polynomial. in this
>>>case the natural expression for the generator matrix uses hex bit
>symbols.
>>>
>Any ideas will be much appreciated! Thanks for the discussion!
>
>Regards
>Matt D
>------------------------------------
>
>
>_____________________________
>Posted through www.DSPRelated.com
Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com