[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re: [Commit-gnuradio] gnuradio-core/src/lib/general g
From: |
'Eric Blossom' |
Subject: |
[Discuss-gnuradio] Re: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce... |
Date: |
Wed, 28 Jun 2006 14:18:59 -0700 |
User-agent: |
Mutt/1.5.9i |
[Moved to list, following my own recommendation ;)]
Regarding: searching for normal and conjugated match in
gr_correlate_access_code.
On Wed, Jun 28, 2006 at 05:03:09PM -0400, Tom Rondeau wrote:
>
> >
> > This is OK, but there's a much simpler, and faster way to handle the
> > problem.
> >
> > There's no need to check for the conjugate directly, or to run
> > multiple shift registerrs. Just look at the hamming distance. E.g.,
> > a perfect match of the conjugate will have the maximum hamming
> > distance, whereas a perfect match of the normal access will be 0.
>
> But if we have a threshold value for the conjugate, (max-threshold) would
> trigger on a number of wrong solutions, wouldn't it? We would pass anything
> up that has between 52 and 64 bit errors in the access code.
If you're doing simultaneous detection of the normal & conjugate by any
method, you've got the same problem. Note that this is a good reason
*not* to enable both normal and conjugate when using DPSK.
Say the access code was 10 long, and the threshold was 2.
When detecting both, the map goes like this:
hamming dist result
------------ -----
0 Normal match (perfect)
1 normal match (one off)
2 normal match (two off)
3 --
4 --
5 --
6 --
7 --
8 conj match (two off)
9 conj match (one off)
10 conj match (perfect)
Eric
- [Discuss-gnuradio] Re: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce...,
'Eric Blossom' <=