Forum: GNU Radio a question about Reed-Solomon in GNURadio!

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Bill S. (Guest)
on 2009-05-01 06:42
(Received via mailing list)
I implemented the reed-solomon coding scheme in gr-atsc onto and Following describes the results I

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 and because without uncommenting
them, the corresponding error message will pop out the moment I run the -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!!! :)

This topic is locked and can not be replied to.