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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
80e825d1e631c4d6681b39c0176c2f85?d=identicon&s=25 unknown (Guest)
on 2009-05-11 01:53
(Received via mailing list)
Hello,

I did 3 more experiments to test the performance of Reed Solomon in
gr.atsc, but I got some contradictory results. I don't know what else I
can do on this. Hope Dr. Corgan could help me this time.

1,I did a simulation with Reed-Solomon coding scheme on my laptop and
add std::cout << nerrors_corrrected << std::endl;, it functioned very
well. When the number of errors is less than 10, the number will be
output, otherwise, it will output -1, which means there are more than 10
symbols corrupted.

2,I added that coding scheme into packet_utils.py (I coded the
payload+crc). While ten packets were sent out from the TX and all of the
received packets were true (ok = True), the nerrors_corrected were all
-1, which were supposed to be 0.

3, I also checked whether the output of the RS encoder matched the input
of the RS decoder, and the answer is YES, which means the packet before
decoding was a correct packet, and the nerrors_corrected should not be
-1!

I think I did all of what I can......, but the result is really
confusing me.

Dr. Corgan, could u give me a little help?

Bill

--- On Sat, 5/9/09, Bill Stevenson <bill.stevenson07@yahoo.com> wrote:

From: Bill Stevenson
 <bill.stevenson07@yahoo.com>
Subject: Re: [Discuss-gnuradio] a question about Reed-Solomon in
GNURadio!
To: "Bill Stevenson" <bill.stevenson07@yahoo.com>
Cc: discuss-gnuradio@gnu.org
Date: Saturday, May 9, 2009, 12:44 AM

Hi!

I have successfully implemented the Reed-Solomon coding scheme in
gr.atsc on USRP, the receiver can receive packets now. But after running
tons of experimentation and comparing the performance between DQPSK
without coding and DQPSK with Reed-Solomon, I cannot observe any
performance improvement of the DQPSK with Reed-Solomon scheme. For the
same PDR and BER, the RSSIs which are read using
 probe.level() are similar, and Reed-Solomon did show any correcting
effect.

Does the reed-solomon in gr.atsc take effect? I coded the payload+crc
part. Thanks!

Bill

--- On Fri, 5/1/09, Bill Stevenson <bill.stevenson07@yahoo.com> wrote:

From: Bill Stevenson <bill.stevenson07@yahoo.com>
Subject: [Discuss-gnuradio]
 a question about Reed-Solomon in GNURadio!
To: discuss-gnuradio@gnu.org
Date: Friday, May 1, 2009, 2:41 AM

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




-----Inline Attachment Follows-----
This topic is locked and can not be replied to.