[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable BER
From: |
Kunal Kandekar |
Subject: |
Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable BER |
Date: |
Sun, 14 Aug 2011 11:01:30 -0400 |
That sounds right to me too. Look at these files to get an idea:
$GR/gnuradio-core/src/python/gnuradio/blks2impl/pkt.py
$GR/gnuradio-core/src/python/gnuradio/packet_utils.py
$GR/gnuradio-core/src/python/gnuradio/src/lib/general/gr_correlate_access_code_bb.cc
$GR/gnuradio-examples/python/digital/receive_path.py
To calculate the BER accurately, I can think of two ways. You can simply discount any packets that are lost as if they were never sent, and measure the BER of only the packets that are received. Averaged over enough packets I think the resulting BER should be pretty accurate.
Alternatively (or in addition), to increase the chances of receiving more packets, you can use a longer access_code parameter or set the "threshold" parameter high in the call to blks2.demod in receive_path.py, e.g. --
blks2.demod_pkts(self._demod_class(**demod_kwargs), access_code=your_access_code, callback=self._rx_callback, threshold=your_threshhold_value)
As I understand the source code, the "threshold" parameter sets the number of wrong bits the correlator will allow in the access code when detecting a packet. However, allowing more errors will also increase the chances of false positives, which will result in entire packets being detected and decoded incorrectly, skewing your BER significantly. So you may also need to use a longer access code to increase the chances of finding the packet correctly.
Kunal
On Tue, Aug 9, 2011 at 11:54 PM, Marcus D. Leech
<address@hidden> wrote:
On 08/09/2011 11:12 PM, shantharam balasubramanian wrote:
> Hello Tom, Marcus and Martin,
>
> Thanks a lot for your replies. One of the objective of our experiment
> is find to the capacity of a path, i.e, we want to transmit a random
> binary sequence between two USRP nodes. We want to find the maximum
> data transfer rate (in bit/sec) with a "small" bit error rate /
> probability of error.
> Tom said, "The way things are in our benchmark code, a single bit
> error means that an entire packet is lost." Based on this statement, I
> have the following questions:
>
> 1. From Tom's reply, it seems like the benchmark_Rx and benchmark_Tx
> programs already have error correction coding blocks in themselves.
> Therefore, it is hard for us to calculate the bit error rate and find
> the capacity of the path. Is there any program in gnuradio repository
> that does not employ error correction codes?
>
The benchmark stuff doesn't, as far as I know, have FEC in it.
> 2. In our experiments, we have received packets that has some bit
> error rate (e.g. 15% bit error rate, 20% bit error rate, etc.). If a
> single bit error means that an entire packet is lost, do you know why
> that phenomenon occurs? (i.e. some packets get lost but some other
> packets have small erroneous bits)
>
> Your feedback will be very appreciated.
>
> Thanks
>
>
>
I think Tom was referring to single-bit errors in the so-called "access
code" at the beginning of the
frame. If there are bit errors there, then the frame is necessarily
discarded, since it's not
*recognized* as a valid frame.
But apart from that, if the frame sequence is valid, then the packet is
"recognized", and punted up
through the RX packet callback mechanism, which means there could
still be bit errors in the
payload section of the packet. In the "real world" this would still
cause the packet to be discarded
entirely, because the FCS (CRC-32, usually) at the end of the packet
wouldn't validate, and somewhere
between the PHY and MAC layer, it would get discarded.
This is all from my having spent 10 minutes looking at the code--I don't
have as deep an understanding
of it as Tom.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, (continued)
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Daniel Zeleznikar, 2011/08/07
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Martin Braun, 2011/08/08
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, shantharam balasubramanian, 2011/08/08
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Tom Rondeau, 2011/08/09
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Marcus D. Leech, 2011/08/09
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Colby Boyer, 2011/08/09
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, John Orlando, 2011/08/09
- Re: [Discuss-gnuradio] Introducing noise/ considerable BER, Robert McGwier, 2011/08/10
- Message not available
- Message not available
- [Discuss-gnuradio] Fwd: Introducing noise/ considerable BER, shantharam balasubramanian, 2011/08/09
- Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable BER, Marcus D. Leech, 2011/08/09
- Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable BER,
Kunal Kandekar <=