discuss-gnuradio
[Top][All Lists]
Advanced

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

RE: [Discuss-gnuradio] No BPSK modulator?


From: Tom Rondeau
Subject: RE: [Discuss-gnuradio] No BPSK modulator?
Date: Tue, 27 Feb 2007 22:21:23 -0500

> -----Original Message-----
> From: Eric Blossom [mailto:address@hidden
> Sent: Tuesday, February 27, 2007 5:46 PM
> To: Tom Rondeau
> Cc: 'gnuradio mailing list'
> Subject: Re: [Discuss-gnuradio] No BPSK modulator?
> 
> On Tue, Feb 27, 2007 at 05:07:31PM -0500, Tom Rondeau wrote:
> > > -----Original Message-----
> > > From: address@hidden
> [mailto:discuss-
> > > address@hidden On Behalf Of Trond Danielsen
> > > Sent: Tuesday, February 27, 2007 10:46 AM
> > > To: gnuradio mailing list
> > > Subject: [Discuss-gnuradio] No BPSK modulator?
> > >
> > > Hi,
> > >
> > > Is there a reason why there is no "ordinary" n-PSK modulator and
> > > demodulator available, only the differential one? If not, I'll modify
> > > the existing one and submit a patch.
> >
> > It's not so much that there isn't a non-differential BPSK modulator,
> it's
> > that there is no demod for it. Basically, we have to be able to
> determine
> > the phase orientation of the incoming signal in some way to know what
> our
> > phase is. In BPSK, this is simple, and this was the original reason why
> > gr_correlate_access_code_bb had a d_flip variable in it, so that when
> the
> > phase inversion was detected, it would decode it properly.
> >
> > However, this was never a good solution and ended up hurting us because
> > sometimes we'd trigger this flip with random data, which would screw up
> the
> > packets. This was the reason the SSH sessions would crash and why
> Johnathan
> > made the original fix in the whitener.
> >
> > The solution to this is to use the correlator to detect the phase, but
> let
> > the next guy down the line understand what to do with it. We probably
> want
> > to send a control signal out to set the phase derotation and trigger the
> > access code found state at the same time, specifically, in the simple
> framer
> > state machine.
> 
> You could use bit 2 of the output stream of
> gr_correlate_access_code_bb to encode the "I've seen the inverted
> pattern".  Then anybody who cared could look at it and take action if
> they wanted to, but it wouldn't interfere with any existing code.
> 
> Eric

Yes, I realize that, but I'm not a huge fan of doing it this way, quite
frankly. It's a bit more inefficient to use multiple output streams for
this, but by putting the flag inside the data stream seems to obfuscate the
system. I'd much rather open a separate control stream to pass this kind of
information around. This would, of course, require reworking the block (or
adding a new one to avoid any conflicts), so if there is a consensus to add
more information, sure. I would suggest, though, that we might use at least
3 bits for this to support up to 8 phase rotations for 8PSK (which makes me
curious, does anyone use non-differential 8PSK?).

Also, is there a clever way of figuring out the phase rotation from the
access code without going through the permutations? For BPSK we only need to
test two, the access code and its bitwise compliment, but for QPSK we have
four and 8PSK has eight possible phases. At least with QAM, we should be
able to just use 4, so I think 8 is the maximum we would ever need to
account for.

Tom






reply via email to

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