discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] RE: [Commit-gnuradio] gnuradio-core/src/lib/general g


From: Tom Rondeau
Subject: [Discuss-gnuradio] RE: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce...
Date: Wed, 28 Jun 2006 17:33:40 -0400

Yeah, I see your point. Thinking about it after I sent that email, it hit me
that you have the same (small) chance of getting a random signal that is a
perfect conjugate (or 1 or 2 off) as you have of getting an exact match to
begin with, so it all works out the same.

The original method here was supposed to allow for checking the phase
rotation seen in higher-order PSK/QAM signals for non-differentially encoded
constellations. That would have required a fundamental change to the access
code correlator, which I didn't want to just partially do because it was
going to be an incorrect method. I then backtracked to just allow BPSK phase
correction in the access code correlator because of the simplicity of doing
so.

Enough excuses, I'll fix that tonight or tomorrow morning.

I've still got to put together the best way to control the phase rotation
within the access code correlator for other non-differential modulations,
but that's still a few steps off from what needs to be done now.

Tom



> -----Original Message-----
> From: 'Eric Blossom' [mailto:address@hidden
> Sent: Wednesday, June 28, 2006 5:19 PM
> To: Tom Rondeau
> Cc: address@hidden
> Subject: Re: [Commit-gnuradio] gnuradio-core/src/lib/general
> gr_correlate_acce...
> 
> [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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]