The correlator of benchmark_rx.py looks dose not work well

Hi everyone,
When I start to assemble //‘gnuradio/examples/digital/benchmark_tx.py’
and ////‘gnuradio/examples/digital/benchmark_rx.py’, //I found there is
no output from the ‘rx_callback’ function defined in benchmark_rx.py. I
inspected it further and found no message is stored in the
/‘framer_sink’/. I got rid of the ‘USPR’ part from both transmitter and
receiver ports, then just connect the remainder parts such as
modulator,demodulator,correlator and framer_sink. There is also no any
message in the framer_sink. I wrote my own test-bench in which I made a
packet with the /‘packet_utils.make_packet’/ tool and transmitted the
packet to the modulator(/blks2.mod_pkts/),then connect to the
demodulator(/‘dbpsk_demod’ class of dbpsk.py)/ and correlator
(/gr.correlate_access_code_bb(access_code, threshold)/). I watched the
input and output of the correlator and found that the correlator looks
does nothing but just delays the input for 64 bits. The input and output
data are as below:
input:
(0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 1,
1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0,
1, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0,
0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0,
1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0,
1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0,
1, 0, 0, 0, 1, 1, 0, 0, 1, 0, 0, 0)
The input length is 228
output:
(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0,
1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 0, 1, 1,
1, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0,
1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0,
1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0)
The output length is 228
We can see that the output of the correlator is just 64 bits delayed
string of the input and there even has an error bit of ‘2’ in the
string. Because the input vector has been delayed, the original last 64
bits are eliminated.
As my understanding the correlator which input is 1 bit per input byte
should do the access_code detection and then output a string of 2 bits
per byte. The data following the access_code would be detected and so
could be seen as effective data to send to the framer_sink. But my
factual output of the correlator is not like that. Could anybody tell me
why? My gnuradio version is gnuradio-3.3.0.

BR,
Zhonghua

Sorry, forgot to reply to list:

On Fri, Aug 26, 2011 at 5:16 AM, Zhonghua [email protected] wrote:

‘packet_utils.make_packet’* tool and transmitted the packet to the
modulator(blks2.mod_pkts),then connect to the demodulator(‘dbpsk_demod’
class of dbpsk.py)
and correlator (gr.correlate_access_code_bb(access_code,
threshold)
). I watched the input and output of the correlator and found
that the correlator looks does nothing but just delays the input for 64
bits. The input and output data are as below:

It’s actually working exactly as designed. The correlate_access_code_bb
block outputs the original 1-bit-per-byte data and sets the second bit
to
“1” when it finds a correlator match.

–n

On Fri, Aug 26, 2011 at 10:41 AM, Nick F. [email protected] wrote:

the remainder parts such as modulator,demodulator,correlator and
block outputs the original 1-bit-per-byte data and sets the second bit to
1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0,
1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0,
As my understanding the correlator which input is 1 bit per input byte
should do the access_code detection and then output a string of 2 bits per
byte. The data following the access_code would be detected and so could be
seen as effective data to send to the framer_sink. But my factual output of
the correlator is not like that. Could anybody tell me why? My gnuradio
version is gnuradio-3.3.0.

BR,
Zhonghua

The delay is in the filters in both transmit and receive paths, so
that is expected. They are FIR filters, so the group delay is well
behaved and known, depending on the number of taps that are used.

You can use the benchmark_loopback.py test, which doesn’t use any
radio hardware but instead has a simulated channel. That should work
for you.

Tom