theneuralbit / ece5565-harq

ece5565-harq

ece5565-harq's Issues

CRC size and generator polynamial needs to be configurable

Right now its hard-coded to a CRC-32

Need to use BPSK rather than QPSK

harq_toplevel needs to handle output vector of different length from input vector

Message from @ashrader330:

I just pushed up the changes for Reed-Solomon encoding for type I. There are a few things that you will need to know about how the RS encoder works. A RS code requires the codeword to be a certain length based on the dimension of the finite field it is created from. The codeword length is determined by 2^d-1. Right now I have the finite field dimension as 8 for one byte per symbol. This gives a codeword length of 255 symbols or 2,040 bits including data, redundancy, and CRC. I currently have 32 symbols of redundancy. The number of redundant symbols is completely arbitrary and we can change it to whatever. A (255, 223) code is pretty common apparently. This arrangement gives 1752 bits for data, 256 bits for redundancy, and 32 bits for the CRC. The codeword must ALWAYS be this size. If the input data is less than 1752 bits, the encoder will pad the rest with zeros to get the right dimensions so the math will work. Right after I pushed the changes up to GitHub, I discovered that the harq_toplevel function did not like it when the input bits vector did not match the size of the output_vector. Either we will need to pad the input or add a header to the packet to tell how much data was actually sent.

Is there any reference for the implementation process of IR-HARQ

I am trying to write IR-HARQ simulation recently. If possible, do you have any IR-HARQ implementation process? I want to learn about it. And I have a puzzle about how to calculate the BER in IR-HARQ, I observed that you seem to calculate the BER of the last retransmission in CC-HARQ, I'm a little confused about this. Thank u!