I implemented the reed-solomon coding scheme in gr-atsc onto benchmark_tx.py
and benchmark_rx.py. Following describes the results I got:
1, The transmitter can transmit reed-solomon coded stream with no problem. The
receiver just keeps on waiting for the packets. There is no response at the
receiver.
2, To fit the needs of USRP and the format of atsc data segment, the entire
packet before the reed-solomon coding is packed in this way:
MPEG_SYNC_BYTE+transport error byte+preamble+access code+header+ some padding
(pad it into 256 bytes)+payload+ some padding+...+crc+..., the length of packet
size is 1098, so after packing process, there are 6 data segments sent out in
each packet.
3, I uncommented the assert(in[i].pli.regular_seg_p()) in atsc_rs_decoder.cc
and atsc_derandomizer.cc because without uncommenting them, the corresponding
error message will pop out the moment I run the benchmark_rx.py -f 2400M.....
command at the receiver side.
4, I simulated this system in my laptop without connecting to any USRPs, and
the result showed that the reed-solomon performance is apparently much better
than that without reed-solomon.
Based on my limited knowledge, there might be two reasons: one is because of
erasing the assert(in[i].pli.regular_seg_p()) phrase, but I don't think it is
the culprit since the similer simulation did not indicate anying wrong with
that method; the second one is MPEG_SYNC_BYTE+transport error byte ruined the
correlating process of access code because it seemed that there were 3 preamble
out there, but I am not sure about my conclusion.
I don't know what makes my receiving process down. Is that because of the
MPEG_SYNC_BYTE in front of the preamble code? I really hope someone could give
me some help on this problem! Thanks a lot!!! :)
Bill
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
