Private:leung

Summary of accomplishments by Gordon Leung.

24 May 2010

Test cases without padding, but with erasures: (Errors are introduced after encoding)

• Introduced 0, 16, 32, 33, 48, 64, 65 errors in an App Data row => Worked as expected.
• Introduced 0, 16, 32, 33, 48, 64 errors in a RS Data row => Worked as expected.
• Introduced 0, 32, 33, 64, 65 errors in a row of the MPE-FEC frame (App Data + RS Data) => Worked as Expected

Given erasure data, the total number of errors fixable within any block of data is now 64 regardless of position.

Test cases with padding and with erasures: (Testing this was a bit more tricky)

• Introduced 1 padding column with 32, 33, 64, and 65 continuous errors in App Data table => Worked as expected.
• Introduced 32 padding columns with 32, 33, 64, and 65 continuous errors in App Data table => Worked as expected.
• Introduced 64 padding columns with 32, 33, 64, 65, 128, and 129 continuous errors in App Data table => Worked as expected.

Basically, the padding columns are ignored and marked as reliable. The max number of correctable errors given erasure data and ignoring padded columns per block still stands at 64.

Correcting 64 errors is the BEST that can be done for our RS code.

Puncturing is possible without changes to the library.

Everything seems to be working according to the Standard except padding. Will look into it.

UPDATE: Padding will work according to the Standard if we ignore the padding parameter given in the library.

Read over the FEC standard

Reading FEC-related code from FATCAPS implementation.

Next Steps: Define FecHdr class

UPDATE: need feedback on proposed FecHdr design

17 May 2010

• Learning C++
• Learning Unix
• Compiled FEC library on Linux. It does not work on Windows. Also, you must disable compiler optimization.
• Complied C++ code that uses the library to encode and decode random data stored in memory.

The library encodes and decodes an MPE-FEC frame one row at a time.

Test cases without padding: (Errors are introduced after encoding)

• Introduced 0, 16, 32, 33, 38 continuous errors in each row of the App Data table => Worked as expected.
• Introduced 16, 32, 33, 38 errors spaced apart from each other in a App Data table row => Worked as expected.
• Introduced 0, 16, 32, 33, 38 continuous errors in each row of the RS table => Worked as expected.
• Introduced 16, 32, 33, 38 errors spaced apart from each other in a RS table row => Worked as expected.
• Introduced 16,17 continuous errors in both the App Data table and RS table => Worked as expected.
• Introduced 16,17 errors spread apart in both the App Data table and RS table => Worked as expected.

All of these test cases point to the fact that the current number of max errors fixable in a block of data is 32 regardless of where the errors occur in the block. With CRC, it should be possible to correct up to 64 errors. I don't know whether CRC is implemented in the system.

The library handles padding slightly differently than the Standard Specification. The library assumes the padding columns are on the leftmost of the App Data table whereas the Standard assumes the padding columns are on the rightmost of the App Data table. The library's padding parameter seems to work as expected.

Test cases with padding:

• Introduced 1 padding column with 32 and 33 continuous errors in App Data table => Worked as expected
• Introduced 32 padding columns with 64 and 65 continuous errors in App Data table => Worked as expected

Basically, the padding columns are ignored and marked as reliable. The max number of correctable errors ignoring padded columns per block still stands at 32.

Next Steps: Test with some text file. Need function to write data into the MPE-FEC frame.

UPDATE: Testing with a text file does not seem necessary anymore. Having data stored in an array is sufficient for testing.