Re: [Discuss-gnuradio] The correlator of benchmark_rx.py looks dose not work well

[Tom Rondeau]

On Fri, Aug 26, 2011 at 10:41 AM, Nick Foster <address@hidden> wrote:
> Sorry, forgot to reply to list:
>
> On Fri, Aug 26, 2011 at 5:16 AM, Zhonghua <address@hidden> wrote:
>>
>> 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:
>
> 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
>
>>
>> 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


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