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 On Thu, Jun 20, 2013 at 1:04 PM, Nemanja Savic <vlasi...@gmail.com> wrote: > 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 > > > On Thu, Jun 20, 2013 at 4:13 PM, yeran <yeran0...@hotmail.com> wrote: > >> 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: vlasi...@gmail.com >> To: yeran0...@hotmail.com; discuss-gnuradio@gnu.org >> >> >> 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 <yeran0...@hotmail.com> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> >> -- >> Nemanja Savić >> > > > > -- > Nemanja Savić > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
