Demodulating QPSK

On Sun, 6 Apr 2008 19:38:09 -0400, "John E. Hadstate"
<jh113355@hotmail.com> wrote:

>
>"Eric Jacobsen" <eric.jacobsen@ieee.org> wrote in message 
>news:hufiv39in3a2ivkg2cb0a3ian1vdmcl042@4ax.com...
>> On Sun, 6 Apr 2008 15:21:15 -0400, "John E. Hadstate"
>> <jh113355@hotmail.com> wrote:
>>
>>>
>>>"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in
>>>message news:Im5Kj.1450$GE1.244@nlpi061.nbdc.sbc.com...
>>>>
>>>>
>>>> John E. Hadstate wrote:
>>>>> Is it possible forego the joys of the Costas loop and
>>>>> demodulate a scalar QPSK signal using a bandpass filter, a
>>>>> Hilbert transformer and the atan2(im,re) function?
>>>>>
>>>>
>>>> Yes, of course. What you described is the generalization of
>>>> the Costas loop.
>>>>
>>>
>>>Maybe I wasn't clear enough.  No feedback and no quadrature
>>>VFO.
>>>
>>>I need something more like "blind recognition" that doesn't
>>>require cooperation from the transmitter to get sync'ed.
>>
>> You can do the baseband mix and all the synchronization tasks
>> digitally if the signal is sampled at some IF.  In other 
>> words, having
>> access to IF samples means that you can perform all of the
>> demodulation steps in the traditional manner, just digitally. 
>> No
>> feedback to the analog electronics or transmitter  is 
>> required.
>>
>
>Yes, thanks.  All I have is sampled data and no feedback to 
>analog is possible.
>
>So far, my trials with Costas Loop implementations have not 
>resulted in anything useful.  Based on my experiences with a 
>software PLL, I'm afraid that once I do get it working, a 
>Costas Loop probably won't lock fast enough to demodulate the 
>first few baud of a packet, and those baud carry some critical 
>information.  Also, Costas Loop, unlike my PLL, is sensitive to 
>variations in input signal level.  I've more or less ruled-out 
>remodulators for the same reasons.

Is this for a burst demodulator?   That does make it harder, and
usually in those cases a preamble of some kind is needed to get not
only start of message detection but to help synchronize initial timing
and phase.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

"Steve Underwood" <steveu@dis.org> wrote in message 
news:ftbmsu$14p$1@nnews.pacific.net.hk...
> John E. Hadstate wrote:
>>
>>
>> I need something more like "blind recognition" that doesn't 
>> require cooperation from the transmitter to get sync'ed.
>
> Most symbol sync schemes work blind.

Yes, Gardner and I have that base covered satisfactorily for 
decimation to bits ;-)  Beyond that, if I know a training 
sequence, I can use a sliding correlation technique to get 
symbol sync.

>
> Carrier recovery can be made to work blindly without much 
> trouble.
>

That's the area where I'm looking for hints.  I don't have a 
clue about how to recover the carrier without some sort of 
feedback-driven loop.

> Only equalisation requires tricky approaches to work blindly.
>

My channel is so ratty I can't imagine trying to equalize 
anything about it.

On Apr 6, 7:56 pm, "John E. Hadstate" <jh113...@hotmail.com> wrote:
> "Steve Underwood" <ste...@dis.org> wrote in message
>
> news:ftbmsu$14p$1@nnews.pacific.net.hk...
>
> > John E. Hadstate wrote:
>
> >> I need something more like "blind recognition" that doesn't
> >> require cooperation from the transmitter to get sync'ed.
>
> > Most symbol sync schemes work blind.
>
> Yes, Gardner and I have that base covered satisfactorily for
> decimation to bits ;-)  Beyond that, if I know a training
> sequence, I can use a sliding correlation technique to get
> symbol sync.
>
>
>
> > Carrier recovery can be made to work blindly without much
> > trouble.
>
> That's the area where I'm looking for hints.  I don't have a
> clue about how to recover the carrier without some sort of
> feedback-driven loop.
>
> > Only equalisation requires tricky approaches to work blindly.
>
> My channel is so ratty I can't imagine trying to equalize
> anything about it.

One trick you can use in noncausal systems to recover the first few
bits worth of carrier is to run the Costas loop forward and then turn
around and run it backward to sample zero on the forward output. I've
used this for situations where a whole packet worth of samples is
buffered for processing. You can even narrow the BW for the reverse
pass if you like.

You can take care of the amplitude dependence of Costas PLL by using
an AGC, complex limiter, or atan(y,x) which is amplitude insensitive.

There is a paper called "Multiple Symbol Differential Detection of
MPSK" by Divsalar that gives a technique for deciding multiple symbols
worth of phase differences at once with performance approaching
coherent as the window gets wide.

Also worth looking into are algorithms called "Block Phase Estimation
for PSK". There might be something useful there.

John

On Apr 6, 7:12&#4294967295;pm, "John E. Hadstate" <jh113...@hotmail.com> wrote:
> "Vladimir Vassilevsky" <antispam_bo...@hotmail.com> wrote in
> messagenews:fO9Kj.339$mB3.223@nlpi068.nbdc.sbc.com...
>
>
>
>
>
>
>
> > John E. Hadstate wrote:
> >> "Vladimir Vassilevsky" <antispam_bo...@hotmail.com> wrote in
> >> message
> >>> John E. Hadstate wrote:
>
> >>>> Is it possible forego the joys of the Costas loop and
> >>>> demodulate a scalar QPSK signal using a bandpass filter, a
> >>>> Hilbert transformer and the atan2(im,re) function?
>
> >>> Yes, of course. What you described is the generalization of
> >>> the Costas loop.
>
> >> Maybe I wasn't clear enough. &#4294967295;No feedback and no quadrature
> >> VFO.
>
> > So you are looking for the feed forward algorithm. The
> > simplest approach is the differential demodulation;
>
> Thanks. &#4294967295;Google search for "differential demodulation"
> eventually led to "noncoherent demodulation" which is where I
> think I want to go.- Hide quoted text -
>
> - Show quoted text -

remember however that non-coherent differential demodulation suffers
from (I think) 3dB worse Eb/No performance...  if your system can
toleralte that then it can be a good solution

Mark

On Apr 6, 7:38&#4294967295;pm, "John E. Hadstate" <jh113...@hotmail.com> wrote:
> "Eric Jacobsen" <eric.jacob...@ieee.org> wrote in message
>
> news:hufiv39in3a2ivkg2cb0a3ian1vdmcl042@4ax.com...
>
>
>
>
>
> > On Sun, 6 Apr 2008 15:21:15 -0400, "John E. Hadstate"
> > <jh113...@hotmail.com> wrote:
>
> >>"Vladimir Vassilevsky" <antispam_bo...@hotmail.com> wrote in
> >>messagenews:Im5Kj.1450$GE1.244@nlpi061.nbdc.sbc.com...
>
> >>> John E. Hadstate wrote:
> >>>> Is it possible forego the joys of the Costas loop and
> >>>> demodulate a scalar QPSK signal using a bandpass filter, a
> >>>> Hilbert transformer and the atan2(im,re) function?
>
> >>> Yes, of course. What you described is the generalization of
> >>> the Costas loop.
>
> >>Maybe I wasn't clear enough. &#4294967295;No feedback and no quadrature
> >>VFO.
>
> >>I need something more like "blind recognition" that doesn't
> >>require cooperation from the transmitter to get sync'ed.
>
> > You can do the baseband mix and all the synchronization tasks
> > digitally if the signal is sampled at some IF. &#4294967295;In other
> > words, having
> > access to IF samples means that you can perform all of the
> > demodulation steps in the traditional manner, just digitally.
> > No
> > feedback to the analog electronics or transmitter &#4294967295;is
> > required.
>
> Yes, thanks. &#4294967295;All I have is sampled data and no feedback to
> analog is possible.
>
> So far, my trials with Costas Loop implementations have not
> resulted in anything useful. &#4294967295;Based on my experiences with a
> software PLL, I'm afraid that once I do get it working, a
> Costas Loop probably won't lock fast enough to demodulate the
> first few baud of a packet, and those baud carry some critical
> information. &#4294967295;Also, Costas Loop, unlike my PLL, is sensitive to
> variations in input signal level. &#4294967295;I've more or less ruled-out
> remodulators for the same reasons.
>
> I am also considering an architecture in which the signal is
> locked by a Costas Loop, and then the complex VFO output from
> the loop is multiplied by a delayed version of the signal to
> resolve the phase. &#4294967295;I haven't seen this architecture in the
> literature, however, so I'm not sure it's plausible.
>
> I've found a lot of material on the web over the weekend that I
> need to codgertate on (codgertate == activity performed by
> codgers when all else fails ;-).- Hide quoted text -
>
> - Show quoted text -

Hello John,

One of the cool things about a software PLL, is if your data is
buffered you can start locking your PLL midstream and run it backwards
to the start of the buffer achieving good lock there, and then going
forward through all of the data and you will have all of it exactly
demodulated. The advantage of this is you now have more lock time so
your software PLL can be set to have a lot more immunity to noise.

IHTH,
Clay

p.s. You can use a complex valued PLL and avoid the double frequency
components associated with a Costas loop. This allows for everything
to be done at half of the sampling rate needed with a Costas loop
system.

On Apr 7, 10:54 am, c...@claysturner.com wrote:
> On Apr 6, 7:38 pm, "John E. Hadstate" <jh113...@hotmail.com> wrote:
>
>
>
> > "Eric Jacobsen" <eric.jacob...@ieee.org> wrote in message
>
> >news:hufiv39in3a2ivkg2cb0a3ian1vdmcl042@4ax.com...
>
> > > On Sun, 6 Apr 2008 15:21:15 -0400, "John E. Hadstate"
> > > <jh113...@hotmail.com> wrote:
>
> > >>"Vladimir Vassilevsky" <antispam_bo...@hotmail.com> wrote in
> > >>messagenews:Im5Kj.1450$GE1.244@nlpi061.nbdc.sbc.com...
>
> > >>> John E. Hadstate wrote:
> > >>>> Is it possible forego the joys of the Costas loop and
> > >>>> demodulate a scalar QPSK signal using a bandpass filter, a
> > >>>> Hilbert transformer and the atan2(im,re) function?
>
> > >>> Yes, of course. What you described is the generalization of
> > >>> the Costas loop.
>
> > >>Maybe I wasn't clear enough.  No feedback and no quadrature
> > >>VFO.
>
> > >>I need something more like "blind recognition" that doesn't
> > >>require cooperation from the transmitter to get sync'ed.
>
> > > You can do the baseband mix and all the synchronization tasks
> > > digitally if the signal is sampled at some IF.  In other
> > > words, having
> > > access to IF samples means that you can perform all of the
> > > demodulation steps in the traditional manner, just digitally.
> > > No
> > > feedback to the analog electronics or transmitter  is
> > > required.
>
> > Yes, thanks.  All I have is sampled data and no feedback to
> > analog is possible.
>
> > So far, my trials with Costas Loop implementations have not
> > resulted in anything useful.  Based on my experiences with a
> > software PLL, I'm afraid that once I do get it working, a
> > Costas Loop probably won't lock fast enough to demodulate the
> > first few baud of a packet, and those baud carry some critical
> > information.  Also, Costas Loop, unlike my PLL, is sensitive to
> > variations in input signal level.  I've more or less ruled-out
> > remodulators for the same reasons.
>
> > I am also considering an architecture in which the signal is
> > locked by a Costas Loop, and then the complex VFO output from
> > the loop is multiplied by a delayed version of the signal to
> > resolve the phase.  I haven't seen this architecture in the
> > literature, however, so I'm not sure it's plausible.
>
> > I've found a lot of material on the web over the weekend that I
> > need to codgertate on (codgertate == activity performed by
> > codgers when all else fails ;-).- Hide quoted text -
>
> > - Show quoted text -
>
> Hello John,
>
> One of the cool things about a software PLL, is if your data is
> buffered you can start locking your PLL midstream and run it backwards
> to the start of the buffer achieving good lock there, and then going
> forward through all of the data and you will have all of it exactly
> demodulated. The advantage of this is you now have more lock time so
> your software PLL can be set to have a lot more immunity to noise.
>
> IHTH,
> Clay
>
> p.s. You can use a complex valued PLL and avoid the double frequency
> components associated with a Costas loop. This allows for everything
> to be done at half of the sampling rate needed with a Costas loop
> system.

Yes, and I've even seen this help in certain multipath fading
scenarios where lock would be lost in a causal system.

John

I have a general-purpose PLL implemented as a primitive in a 
language where I can easily run signals through it, plot the 
outputs, and tweak its parameters: initial frequency, loop 
gain, loop bandwidth and I/Q filter bandwidth.  All signal 
processing is done with double precision floating point 
arithmetic and trig functions are computed using the C-RTL (not 
interpolated from table look-up), so I think we can pretty much 
rule out issues with overflow, quantization, etc.  Can someone 
help me understand what I'm observing here?

Part I:
=======

I have as set of three test files.  These files are totally 
synthetic (created digitally using the same language, no noise, 
etc.). They are described below.

File1: A 550 Hz. sine segment sampled at 48000 Hz. lasting 10 
seconds followed by 10 seconds of the negative of the same sine 
(180-degree phase shift).

File2: A 550 Hz. cosine segment sampled at 48000 Hz. lasting 2 
seconds followed by a 550 Hz. sine segment lasting two seconds 
followed by the negative of the previous cosine segment 
followed by the negative of the previous sine segment followed 
by the original cosine segment.

File3: A [cos]=[sin]=[-cos]=[-sin] segment repeated many times 
(totalling 10 seconds).  Each (cos) or (sin) segment has a 
frequency of 550 Hz. and a duration of (4/300) seconds.

I deliberately set the inital frequency of the PLL to 555 Hz. 
so I could observe its lock-up behavior.  When I process File1 
through the PLL and observe the control frequency being fed 
back to the VFO (this would be the locked frequency), I see a 
brief transient while the loop acquires lock.  Thereafter, the 
locked frequency remains steady as a rock on 550 Hz. until the 
phase changes.  Then there is another brief transient while the 
loop re-acquires lock and then the locked frequency remains 
steady as a rock on 550 Hz. through the remainder of the file.

When I process File2 through the PLL and observe the control 
frequency, the behavior is similar.  At the beginning of each 
segment there is a brief frequency transient after which the 
loop locks and remains steady until the next phase change.

When I process File3 through the PLL, there is a brief 
transient at the beginning of the file and then the loop locks 
and the control frequency remains steady.  The problem is that 
the loop locks on a frequency that is decidedly different from 
550 Hz. (say 562.5 Hz. or 547 Hz., depending on the setting of 
the loop bandwidth or the type of loop filter).

Part II:
========

I raise each sample of File1, File2, and File3 to the fourth 
power and run each file through a FIR bandpass filter with 
cutoff frequencies of 2000 Hz. and 2400 Hz. to yield File1a, 
File2a, and File3a respectively.

I observe that the spectra of File1 and File2 are sharply 
peaked at 2200 Hz. and the spectrum of File3 is somewhat 
diffuse with the component at 2200 Hz. being about 30 dB below 
its nearest neighbors.

If I run these files through the PLL, File1 and File2 lock up 
(as expected) at 2200 Hz. with no transients at the times of 
phase change.  However, File3a locks up at some frequency other 
than 2200 Hz. (and I think that frequency is about 4 times the 
lock-up frequency of File3).

I'm sure there's a reasonable explanation for what I'm 
observing.  I was thinking that the weird lockup frequency was 
related to the time-constant of the loop filter, but radically 
changing the time-constant of the loop filter doesn't have much 
effect on the observed behavior.  In particular, it seems to 
lock up on the same weird frequency no matter how I set the 
loop bandwidth.

On Apr 19, 5:59 am, "John E. Hadstate" <jh113...@hotmail.com> wrote:
> I have a general-purpose PLL implemented as a primitive in a
> language where I can easily run signals through it, plot the
> outputs, and tweak its parameters: initial frequency, loop
> gain, loop bandwidth and I/Q filter bandwidth.  All signal
> processing is done with double precision floating point
> arithmetic and trig functions are computed using the C-RTL (not
> interpolated from table look-up), so I think we can pretty much
> rule out issues with overflow, quantization, etc.  Can someone
> help me understand what I'm observing here?
>
> Part I:
> =======
>
> I have as set of three test files.  These files are totally
> synthetic (created digitally using the same language, no noise,
> etc.). They are described below.
>
> File1: A 550 Hz. sine segment sampled at 48000 Hz. lasting 10
> seconds followed by 10 seconds of the negative of the same sine
> (180-degree phase shift).
>
> File2: A 550 Hz. cosine segment sampled at 48000 Hz. lasting 2
> seconds followed by a 550 Hz. sine segment lasting two seconds
> followed by the negative of the previous cosine segment
> followed by the negative of the previous sine segment followed
> by the original cosine segment.
>
> File3: A [cos]=[sin]=[-cos]=[-sin] segment repeated many times
> (totalling 10 seconds).  Each (cos) or (sin) segment has a
> frequency of 550 Hz. and a duration of (4/300) seconds.
>
> I deliberately set the inital frequency of the PLL to 555 Hz.
> so I could observe its lock-up behavior.  When I process File1
> through the PLL and observe the control frequency being fed
> back to the VFO (this would be the locked frequency), I see a
> brief transient while the loop acquires lock.  Thereafter, the
> locked frequency remains steady as a rock on 550 Hz. until the
> phase changes.  Then there is another brief transient while the
> loop re-acquires lock and then the locked frequency remains
> steady as a rock on 550 Hz. through the remainder of the file.
>
> When I process File2 through the PLL and observe the control
> frequency, the behavior is similar.  At the beginning of each
> segment there is a brief frequency transient after which the
> loop locks and remains steady until the next phase change.
>
> When I process File3 through the PLL, there is a brief
> transient at the beginning of the file and then the loop locks
> and the control frequency remains steady.  The problem is that
> the loop locks on a frequency that is decidedly different from
> 550 Hz. (say 562.5 Hz. or 547 Hz., depending on the setting of
> the loop bandwidth or the type of loop filter).
>
> Part II:
> ========
>
> I raise each sample of File1, File2, and File3 to the fourth
> power and run each file through a FIR bandpass filter with
> cutoff frequencies of 2000 Hz. and 2400 Hz. to yield File1a,
> File2a, and File3a respectively.
>
> I observe that the spectra of File1 and File2 are sharply
> peaked at 2200 Hz. and the spectrum of File3 is somewhat
> diffuse with the component at 2200 Hz. being about 30 dB below
> its nearest neighbors.
>
> If I run these files through the PLL, File1 and File2 lock up
> (as expected) at 2200 Hz. with no transients at the times of
> phase change.  However, File3a locks up at some frequency other
> than 2200 Hz. (and I think that frequency is about 4 times the
> lock-up frequency of File3).
>
> I'm sure there's a reasonable explanation for what I'm
> observing.  I was thinking that the weird lockup frequency was
> related to the time-constant of the loop filter, but radically
> changing the time-constant of the loop filter doesn't have much
> effect on the observed behavior.  In particular, it seems to
> lock up on the same weird frequency no matter how I set the
> loop bandwidth.

File3 has rectangular windows of length 4/300 for
sinusoids of period 1/550, or about 7.33 cycles.
Thus you could be seeing your PLL locking to the
spectral content of windowing artifacts produced
by your sinusoid fragments being non-periodic in
their windows.  Window artifacts (or "leakage")
is not centered when the number of periods per
window is "small".  You might check by examining
the spectrum from an FFT of your file3.



IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M

"Ron N." <rhnlogic@yahoo.com> wrote in message 
news:ad880e6f-7914-4640-aa13-eea407a2ab83@i36g2000prf.googlegroups.com...
>
> File3 has rectangular windows of length 4/300 for
> sinusoids of period 1/550, or about 7.33 cycles.
> Thus you could be seeing your PLL locking to the
> spectral content of windowing artifacts produced
> by your sinusoid fragments being non-periodic in
> their windows.  Window artifacts (or "leakage")
> is not centered when the number of periods per
> window is "small".  You might check by examining
> the spectrum from an FFT of your file3.
>

Good catch!  I'll check that out on Monday.

Thanks.

"John E. Hadstate" <jh113355@hotmail.com> wrote in message 
news:Y4idneGes7ZgcZTVnZ2dnUVZ_qmlnZ2d@supernews.com...
>I have a general-purpose PLL implemented as a primitive in a 
>language where I can easily run signals through it, plot the 
>outputs, and tweak its parameters: initial frequency, loop 
>gain, loop bandwidth and I/Q filter bandwidth.

I noticed something today.  If I feed my PLL an unmodulated 
sine wave or a frequency modulated sine wave, it will acquire 
lock and track precisely over a very wide range of initial 
frequency errors and loop gain/bandwidth settings.  However, if 
I feed in a QPSK-modulated signal [SIN=COS=-SIN=-COS=...] the 
acquisition and tracking ability falls to pieces.  Where I 
could easily acquire and track an FSK signal at 2000+/-200 Hz. 
from a starting point of 1500 Hz., with the QPSK-modulated 
signal, I can only acquire lock within +/- 1 Hz at 2400 Hz. 
Having obtained lock, I can see the demodulated data on the 
filtered I and Q arms out of the product mixer.

Does this correspond with anyone else's experience?  If so, 
what were you able to do about expanding the acquisition range?

I should mention that to get this to work at all, I introduced 
a kludge into the basic quadrature PLL.  After getting the I/Q 
phase angle, I decide which quadrant I'm in and use the center 
of that quadrant as the "Phase Setpoint".  I then use the 
difference between the measured I/Q phase angle and the phase 
setpoint as an error signal to adjust the VFO's phase offset 
(driving the demodulated I/Q phase to the center of the 
quadrant).  I also square this error and combine the result 
with a fixed gain factor when calculating adjustments to the 
VFO's frequency.  The net effect of this is that when the loop 
is locked in the center of one quadrant, a sudden jump to the 
center of another quadrant will not cause much change in the 
VFO's frequency (because the squared phase error is near zero) 
and it will stay phase-locked on the new baud.

I am not married to this kludge and would happily try a better 
solution, especially if it expands the range over which I can 
acquire lock.  Any suggestions?