discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] About threshold value in digital_correlate_access


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] About threshold value in digital_correlate_access_code_bb in gr-digital
Date: Mon, 28 Nov 2011 12:47:25 -0500

On Mon, Nov 28, 2011 at 12:44 PM, Tom Rondeau <address@hidden> wrote:
On Mon, Nov 28, 2011 at 12:26 PM, Songsong Gee <address@hidden> wrote:
I got a question about threshold value in digital_correlate_access_code_bb in gr-digital while testing benchmark_xx.py

threshold is set to 12 by default,
However, if I use threshold=12, it never calls callback function
Thus, I changed this value with larger value, like 24, 36, 64...
And then callback function is invoked, but not successfully (means, ok = False, not True is printed by benchmark_rx.py)
I think this threshold is a kind of a tolerance value when a system extracts data from a signal (packet)
So, Does it permit up to (threshold) wrong bits out of a length of access code, or a length of a packet?
Therefore, the lower threshold means the lower tolerance, is that right?

The question is,
if a recovered data has lots of wrong bits than this tolerance,
What things happen so that it cannot invoke callback function?

Of course, I can invoke the callback by modifying threshold,
but it also causes the unsuccessful packet reception.

Songsong,
This threshold value is specifying the number of bits in the access code that can be _wrong_ and still be acceptable. So we have a 64-bit access code and by default, 12 of those can be incorrect and we still accept it as a valid code to process the data as a packet.

When you set the threshold to 64, you're saying that all bits can be incorrect, so basically, everything is a packet! You're bit error rates are too high, so that with a threshold of 12, not enough bits are coming in correctly for the receiver to recognize the packet as valid, thus it never reports a packet.

Tom


Also, remember that these benchmark programs are just that, benchmarks. They are not designed for production use or a real application without work. In particular, they do not use any channel codes but use a CRC. What that means is that if ANY bit error in the ENTIRE packet is incorrect, then the CRC will be incorrect and the packet is reported as "False."

If you have to set your threshold as liberal as you are, then you're BER is way too high and you should expect errors in the packet itself. So yes, they will all be reported as false.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]