Correlator in gnuradio

Hi everyone,

I’m trying to learning the algorithm of the correlator in
generic_mod_demod.py. Then use the similar algorithm in my own block.

In the file digital_correlate_access_code_bb.cc, according to my
understanding, the original algorithm is compare each bit of the 8-Byte
access code with the default 8-Byte access code. If the wrong bits is
less than 12 bits (the threshold), then it is decided as “access code
found”.

I wrote a file to detect access code, too. I compared each of the 8-Byte
with the default access code. If the correct bits is more than (64bits -
12 bits), then it is decided to be found.

But when I us my program, when decoding the same data, I can always
found more than the original method. For instance, when I use
benchmark’s original method, I can get n_rcvd=570 pkt, which means in
the generic_mod_demod correlator, 570 access code are found. But my
program found 577.

Has anybody been study the correlator block before? and see if there is
a misunderstanding in my work?

Thanks in advance!

Ada

Well, I was studying correlator, and it’s pretty straight forward
approach.
If you specify threshold of k bits, then it will output 0x3 every time
it
finds pattern that differs from given preamble at max. k bits. Maybe you
can provide some more information. In my designs I usually use threshold
0.

Best
Nemanja

Well, I don’t really know why you don’t get the same n_rcvd as default
benchmark. I have never seen that benchmark.
Maybe you have some silly “error” when checkin number of wrong bits.
Make
flowgraph with both your and default correlator and see what’s going on.
I
would probably do that.

Nemanja

Hi Nemanja,

Thanks for your kind reply!

I’m trying to design a program which will achieve the same result as the
default benchmark, because I’ll use the default benchmark in some part
of the program too. So I use the default threshold 12. I want to make
sure that is means that in the 8 Byte access code, at maximum 12 bits
can be wrong for gnuradio to “find the pkt”. Is this correct?

Specifically, I defined a list ‘ac’ which is exactly the 64-bit access
code. And then compare each of the received 64-bit data with the
relevant bit in ac. If they match more than 64-12=52 bits, one packet
is found.

But the test result is that using this code will always find more than
the n_rcvd number of packets in default benchmark. (in benchmark, n_rcvd
is the total number of packets found).

Looking forward to your further suggestions! Thanks a lot!

Best,
Ada

Date: Thu, 20 Jun 2013 08:52:09 +0200
Subject: Re: [Discuss-gnuradio] correlator in gnuradio
From: [email protected]
To: [email protected]; [email protected]

Well, I was studying correlator, and it’s pretty straight forward
approach. If you specify threshold of k bits, then it will output 0x3
every time it finds pattern that differs from given preamble at max. k
bits. Maybe you can provide some more information. In my designs I
usually use threshold 0.

Best
Nemanja

On Wed, Jun 19, 2013 at 10:21 PM, yeran [email protected] wrote:

Hi everyone,

I’m trying to learning the algorithm of the correlator in
generic_mod_demod.py. Then use the similar algorithm in my own block.

In the file digital_correlate_access_code_bb.cc, according to my
understanding, the original algorithm is compare each bit of the 8-Byte
access code with the default 8-Byte access code. If the wrong bits is
less than 12 bits (the threshold), then it is decided as “access code
found”.

I wrote a file to detect access code, too. I compared each of the 8-Byte
with the default access code. If the correct bits is more than (64bits -
12 bits), then it is decided to be found.

But when I us my program, when decoding the same data, I can always
found more than the original method. For instance, when I use
benchmark’s original method, I can get n_rcvd=570 pkt, which means in
the generic_mod_demod correlator, 570 access code are found. But my
program found 577.

Has anybody been study the correlator block before? and see if there is
a misunderstanding in my work?

Thanks in advance!

Ada


Discuss-gnuradio mailing list

[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Just a sanity check here… let’s say your access code is 001100 and
your
threshold is 3. Then you receive 0001010000.
So clearly the received access code is “001010” with 2 errors. As bits
stream through you’ll have more than one instance where there are <= 3
bit
errors (output is 0023210000), which would explain your result if you’re
not watching out for this. Have you checked the output to make sure
something like this isn’t happening with your implementation?

If that’s not the issue do you have any qa check with your block? If
none
of this helps then maybe posting your code somewhere will help.

-Nathan