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:
-
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?
-
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
On 08/09/2011 11:12 PM, shantharam balasubramanian wrote:
- 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.
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
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
Hello Marcus,
You sent the forwarded email a few months ago.
The benchmark stuff doesn’t, as far as I know, have FEC in it. I think
Tom was referring to single-bit errors in the so-called “accesscode”
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.
We implemented a CRC checking block in the benchmark_rx code using
binascii.crc32 python code. We observed a very interesting thing in
the following portion of the benchmark_rx code:
def rx_callback(ok, payload):
global n_rcvd, n_right
(pktno,) = struct.unpack(’!H’, payload[0:2])
if ok:
n_right += 1
Whenever the packet was received as 'OK' (i.e. 'OK = True') and
n_right increased, the packet also passed our CRC check. Every packet
that did not pass our CRC check was also not received as ‘OK’ (i.e.
‘OK = False’ in those packets). Our CRC checking portion is completely
independent of the main benchmark_rx code. We just look at the
received data and see if there is any bit error or not.
Now, if the above the mentioned portion of the code does not do CRC
checking on its own, how does it completely match with our CRC based
results? Does it mean that errors occur in bursts. Therefore, whenever
there is any single bit error in the data, there are errors in the
header as well ??
Your feedback will be very appreciated.
Thanks,
Shantharam
n_right +=1
Whenever the packet was received as ‘OK’ (i.e. ‘OK = True’) and n_right
increased, the packet also passed our CRC check. Every packet that did not pass
our CRC check was also not received as ‘OK’ (i.e. ‘OK = False’ in those packets).
Our CRC checking portion is completely independent of the main benchmark_rx code.
We just look at the received data and see if there is any bit error or not.
Now, if the above the mentioned portion of the code does not do CRC checking on
its own, how does it completely match with our CRC based results? Does it mean
that errors occur in bursts. Therefore, whenever there is any single bit error in
the data, there are errors in the header as well ??
Your feedback will be very appreciated.
I’ll let other people who are more familiar with the code comment. My
comments from months ago were from a cursory inspection of
code that I don’t use, or have any particular vested-interest in.