DSPRelated.com
Forums

Synchronization of BPSK with Chirped Carrier

Started by Unknown February 10, 2009
I have a system in which I process (offline) snapshots of a low-rate
BPSK signal (~150 bps) on an AWGN background. Expected SNR of the BPSK
signal of interest is 10-12 dB. The total amount of samples available
in each snapshot varies from ~0.75 sec to ~1.5 sec, at a sample rate
of ~4800 Hz (I have 32 available samples per symbol). The message
consists of repeated messages of ~40 bits each. I need to do the best
that I can to extract one or more messages from each snapshot (there
is parity information embedded in the message, so I can tell if it is
valid; however, there is no FEC).

The catch: the BPSK carrier frequency is chirped, increasing in a
linear ramp at up to 800 Hz/sec (the actual rate is not consistent
from snapshot to snapshot, and it may vary somewhat during each
snapshot; however, it may be approximated pretty well as linear). The
trajectory of my carrier frequency, therefore, is over five times the
information rate, so compared to my data, the carrier is really
moving. I need to obviously remove that carrier trajectory in order to
successfully demodulate my bits.

I've made a stab at this problem using a third-order, type-3 Costas
loop. This seems to work "most of the time," but there are cases where
the loop fails to lock or looks to go unstable, for reasons
unbeknownst to me. Second-order loop filter design seems to be well-
understood and documented, but finding material on third-order loop
filter design has proven more difficult (the design I referred to
above came from some Master's thesis I found on the Web,
http://scholar.lib.vt.edu/theses/available/etd-113317959711591/unrestricted/etd.pdf,
section 3.3.2). Anyone have any pointers to texts/journals/etc. on the
topic?

Or, any suggestions on alternate approaches? I've considered taking
the 3-dB hit and going with DBPSK. Then, in the receiver, after the
differential decoder (delay-conjugate-multiply), the frequency ramp
will appear to be a constant frequency error instead, which I could
track out with a simpler second-order PLL. I don't want to go
noncoherent if I don't have to, though. I'm open to other techniques
also; although I don't have any real-time requirements, processing
much more complicated than the strategy I've described would be
problematic due to the limited computational resources on my target.

Thanks for any input.

Jason

cincydsp@gmail.com wrote:

> I have a system in which I process (offline) snapshots of a low-rate > BPSK signal (~150 bps) on an AWGN background. Expected SNR of the BPSK > signal of interest is 10-12 dB. The total amount of samples available > in each snapshot varies from ~0.75 sec to ~1.5 sec, at a sample rate > of ~4800 Hz (I have 32 available samples per symbol). The message > consists of repeated messages of ~40 bits each. I need to do the best > that I can to extract one or more messages from each snapshot (there > is parity information embedded in the message, so I can tell if it is > valid; however, there is no FEC). > > The catch: the BPSK carrier frequency is chirped, increasing in a > linear ramp at up to 800 Hz/sec (the actual rate is not consistent > from snapshot to snapshot, and it may vary somewhat during each > snapshot; however, it may be approximated pretty well as linear). The > trajectory of my carrier frequency, therefore, is over five times the > information rate, so compared to my data, the carrier is really > moving. I need to obviously remove that carrier trajectory in order to > successfully demodulate my bits.
Interesting problem. I would try to make the phase vs time trajectory and extract the modulation from there using the maximum likelihood approach. The cyclostationarity of the PSK modulation should help.
> I've made a stab at this problem using a third-order, type-3 Costas > loop. This seems to work "most of the time," but there are cases where > the loop fails to lock or looks to go unstable, for reasons > unbeknownst to me. Second-order loop filter design seems to be well- > understood and documented, but finding material on third-order loop > filter design has proven more difficult (the design I referred to > above came from some Master's thesis I found on the Web, > http://scholar.lib.vt.edu/theses/available/etd-113317959711591/unrestricted/etd.pdf, > section 3.3.2). Anyone have any pointers to texts/journals/etc. on the > topic?
PLL is the minor detail of the implementation. Solve the fundamental problem first.
> Or, any suggestions on alternate approaches? I've considered taking > the 3-dB hit and going with DBPSK.
BTW, at the SNR of 10..12 dB, the DBPSK vs PSK tradeoff is less then 1dB.
>Then, in the receiver, after the > differential decoder (delay-conjugate-multiply), the frequency ramp > will appear to be a constant frequency error instead, which I could > track out with a simpler second-order PLL. I don't want to go > noncoherent if I don't have to, though. I'm open to other techniques > also; although I don't have any real-time requirements, processing > much more complicated than the strategy I've described would be > problematic due to the limited computational resources on my target.
You seem to focus on the minor technicalities instead of looking at the problem as a whole. Estimate the chirp parameters then demodulate the signal. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
<cincydsp@gmail.com> wrote:

>I have a system in which I process (offline) snapshots of a low-rate >BPSK signal (~150 bps) on an AWGN background. Expected SNR of the BPSK >signal of interest is 10-12 dB. The total amount of samples available >in each snapshot varies from ~0.75 sec to ~1.5 sec, at a sample rate >of ~4800 Hz (I have 32 available samples per symbol). The message >consists of repeated messages of ~40 bits each. I need to do the best >that I can to extract one or more messages from each snapshot (there >is parity information embedded in the message, so I can tell if it is >valid; however, there is no FEC). > >The catch: the BPSK carrier frequency is chirped, increasing in a >linear ramp at up to 800 Hz/sec (the actual rate is not consistent >from snapshot to snapshot, and it may vary somewhat during each >snapshot; however, it may be approximated pretty well as linear). >[snip] >Or, any suggestions on alternate approaches? I've considered taking >the 3-dB hit and going with DBPSK.
It seems to me something like pulse position modulation would be very insensitive to carrier drift. Something like FOOF (Four out of fourteen) coding may work. I'm not sure what the BER of FOOF would be at your operating point; it may be inadequate for what you are doing. Steve
cincydsp@gmail.com writes:
> [...]
Jason, Wouldn't a simple square operation allow you to determine frequency? After removing carrier frequency offset, it's then just a matter of a standard PLL, if you go with coherent demodulation, or your done if differential. -- % Randy Yates % "I met someone who looks alot like you, %% Fuquay-Varina, NC % she does the things you do, %%% 919-577-9882 % but she is an IBM." %%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO http://www.digitalsignallabs.com
On Feb 11, 2:29&#4294967295;am, Randy Yates <ya...@ieee.org> wrote:
> cincy...@gmail.com writes: > > [...] > > Jason, > > Wouldn't a simple square operation allow you to determine frequency? > After removing carrier frequency offset, it's then just a matter of > a standard PLL, if you go with coherent demodulation, or your done > if differential. > -- > % &#4294967295;Randy Yates &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% "I met someone who looks alot like you, > %% Fuquay-Varina, NC &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; she does the things you do, > %%% 919-577-9882 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; but she is an IBM." > %%%% <ya...@ieee.org> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % &#4294967295; &#4294967295; &#4294967295; &#4294967295;'Yours Truly, 2095', *Time*, ELO &#4294967295;http://www.digitalsignallabs.com
Thanks for the suggestion. If the frequency offset were constant, then absolutely, that would be my method of choice. However, the slewing of the carrier relative to the sample rate is problematic. Using an FFT- based approach, I have an inherent tradeoff: I'd like to precisely know where the carrier starts out in my snapshot, in order to undo the offset and aid the Costas loop. To get a better estimate of the carrier frequency, I need a longer FFT. However, using a longer FFT requires me to use samples over a longer period of time. Over the longer period of time, the carrier drifts, resulting in a "smearing" of the FFT result. So, there's seemingly a limit to how precisely I can estimate the carrier's frequency at any given time using that technique. And, I'm still left with the requirement to track the carrier as it moves over time. Jason
On Feb 11, 8:43&#4294967295;am, cincy...@gmail.com wrote:
> On Feb 11, 2:29&#4294967295;am, Randy Yates <ya...@ieee.org> wrote: > > > cincy...@gmail.com writes: > > > [...] > > > Jason, > > > Wouldn't a simple square operation allow you to determine frequency? > > After removing carrier frequency offset, it's then just a matter of > > a standard PLL, if you go with coherent demodulation, or your done > > if differential. > > -- > > % &#4294967295;Randy Yates &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% "I met someone who looks alot like you, > > %% Fuquay-Varina, NC &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; she does the things you do, > > %%% 919-577-9882 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; but she is an IBM." > > %%%% <ya...@ieee.org> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % &#4294967295; &#4294967295; &#4294967295; &#4294967295;'Yours Truly, 2095', *Time*, ELO &#4294967295;http://www.digitalsignallabs.com > > Thanks for the suggestion. If the frequency offset were constant, then > absolutely, that would be my method of choice. However, the slewing of > the carrier relative to the sample rate is problematic. Using an FFT- > based approach, I have an inherent tradeoff: I'd like to precisely > know where the carrier starts out in my snapshot, in order to undo the > offset and aid the Costas loop. To get a better estimate of the > carrier frequency, I need a longer FFT. However, using a longer FFT > requires me to use samples over a longer period of time. Over the > longer period of time, the carrier drifts, resulting in a "smearing" > of the FFT result. So, there's seemingly a limit to how precisely I > can estimate the carrier's frequency at any given time using that > technique. And, I'm still left with the requirement to track the > carrier as it moves over time. > > Jason
since you know apriori that you have an approx linear sweep chirp, why not apply an OPEN LOOP linear de-chrip to the signal first using your best guess as to the sweep rate, and then use closed loop techniques to track the residual error. This should reduce the difficulty of the closed loop tracking. And since this is an offline process, if the residual error is still too large, you can go back and modify the "guess" and do it again until the residual error is sufficently low that the closed loop tracking can work well.... If you get to the "best possible guess" then the closed loop tracking has to handle only the residual error due to the fact that the sweep is not exactly linear. Mark
makolber@yahoo.com writes:

> On Feb 11, 8:43&#4294967295;am, cincy...@gmail.com wrote: >> On Feb 11, 2:29&#4294967295;am, Randy Yates <ya...@ieee.org> wrote: >> >> > cincy...@gmail.com writes: >> > > [...] >> >> > Jason, >> >> > Wouldn't a simple square operation allow you to determine frequency? >> > After removing carrier frequency offset, it's then just a matter of >> > a standard PLL, if you go with coherent demodulation, or your done >> > if differential. >> > -- >> > % &#4294967295;Randy Yates &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% "I met someone who looks alot like you, >> > %% Fuquay-Varina, NC &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; she does the things you do, >> > %%% 919-577-9882 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; but she is an IBM." >> > %%%% <ya...@ieee.org> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % &#4294967295; &#4294967295; &#4294967295; &#4294967295;'Yours Truly, 2095', *Time*, ELO &#4294967295;http://www.digitalsignallabs.com >> >> Thanks for the suggestion. If the frequency offset were constant, then >> absolutely, that would be my method of choice. However, the slewing of >> the carrier relative to the sample rate is problematic. Using an FFT- >> based approach, I have an inherent tradeoff: I'd like to precisely >> know where the carrier starts out in my snapshot, in order to undo the >> offset and aid the Costas loop. To get a better estimate of the >> carrier frequency, I need a longer FFT. However, using a longer FFT >> requires me to use samples over a longer period of time. Over the >> longer period of time, the carrier drifts, resulting in a "smearing" >> of the FFT result. So, there's seemingly a limit to how precisely I >> can estimate the carrier's frequency at any given time using that >> technique. And, I'm still left with the requirement to track the >> carrier as it moves over time. >> >> Jason > > since you know apriori that you have an approx linear sweep chirp, why > not apply an OPEN LOOP linear de-chrip to the signal first using your > best guess as to the sweep rate, and then use closed loop techniques > to track the residual error. > This should reduce the difficulty of the closed loop tracking. > > And since this is an offline process, if the residual error is still > too large, you can go back and modify the "guess" and do it again > until the residual error is sufficently low that the closed loop > tracking can work well.... If you get to the "best possible guess" > then the closed loop tracking has to handle only the residual error > due to the fact that the sweep is not exactly linear.
I think this is an excellent idea, Mark. I would add the clarification that you would generate the individual frequency estimates at each sample instead of using a block of samples in the FFT. Using the FFT provides some smoothing but at the expense of smearing the sweep as was already pointed out. Actually what may work better is to determine the individual sample phases (assuming this has been Hilbert transformed down to baseband) and them model the phases as a quadratic (a linear frequency chirp would produce quadratic phases). This way you'd kill two birds with one stone: a) avoiding the noise and inter-sample frequency ambiguity that would occur from first determining frequency as delta theta and then modeling the frequency as a linear function, and b) utilizing an entire group of samples in order to improve performance (i.e., "average"). Interesting problem you have, Jason. What is the reason for the chirp carrier? -- % Randy Yates % "So now it's getting late, %% Fuquay-Varina, NC % and those who hesitate %%% 919-577-9882 % got no one..." %%%% <yates@ieee.org> % 'Waterfall', *Face The Music*, ELO http://www.digitalsignallabs.com
On Feb 11, 1:45&#4294967295;am, spop...@speedymail.org (Steve Pope) wrote:
> <cincy...@gmail.com> wrote: > >I have a system in which I process (offline) snapshots of a low-rate > >BPSK signal (~150 bps) on an AWGN background. Expected SNR of the BPSK > >signal of interest is 10-12 dB. The total amount of samples available > >in each snapshot varies from ~0.75 sec to ~1.5 sec, at a sample rate > >of ~4800 Hz (I have 32 available samples per symbol). The message > >consists of repeated messages of ~40 bits each. I need to do the best > >that I can to extract one or more messages from each snapshot (there > >is parity information embedded in the message, so I can tell if it is > >valid; however, there is no FEC). > > >The catch: the BPSK carrier frequency is chirped, increasing in a > >linear ramp at up to 800 Hz/sec (the actual rate is not consistent > >from snapshot to snapshot, and it may vary somewhat during each > >snapshot; however, it may be approximated pretty well as linear). > >[snip] > >Or, any suggestions on alternate approaches? I've considered taking > >the 3-dB hit and going with DBPSK. > > It seems to me something like pulse position modulation would be > very insensitive to carrier drift. &#4294967295;Something like FOOF (Four out > of fourteen) coding may work. &#4294967295;I'm not sure what the BER of > FOOF would be at your operating point; it may be inadequate for > what you are doing. > > Steve
Thanks for the suggestion, Steve. PPM isn't an option, as the hardware at the transmitter isn't capable of ampliude modulation (it's CW- only). Jason
On Feb 11, 9:46&#4294967295;am, Randy Yates <ya...@ieee.org> wrote:
> makol...@yahoo.com writes: > > On Feb 11, 8:43&#4294967295;am, cincy...@gmail.com wrote: > >> On Feb 11, 2:29&#4294967295;am, Randy Yates <ya...@ieee.org> wrote: > > >> > cincy...@gmail.com writes: > >> > > [...] > > >> > Jason, > > >> > Wouldn't a simple square operation allow you to determine frequency? > >> > After removing carrier frequency offset, it's then just a matter of > >> > a standard PLL, if you go with coherent demodulation, or your done > >> > if differential. > >> > -- > >> > % &#4294967295;Randy Yates &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% "I met someone who looks alot like you, > >> > %% Fuquay-Varina, NC &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; she does the things you do, > >> > %%% 919-577-9882 &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295;% &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; but she is an IBM." > >> > %%%% <ya...@ieee.org> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; % &#4294967295; &#4294967295; &#4294967295; &#4294967295;'Yours Truly, 2095', *Time*, ELO &#4294967295;http://www.digitalsignallabs.com > > >> Thanks for the suggestion. If the frequency offset were constant, then > >> absolutely, that would be my method of choice. However, the slewing of > >> the carrier relative to the sample rate is problematic. Using an FFT- > >> based approach, I have an inherent tradeoff: I'd like to precisely > >> know where the carrier starts out in my snapshot, in order to undo the > >> offset and aid the Costas loop. To get a better estimate of the > >> carrier frequency, I need a longer FFT. However, using a longer FFT > >> requires me to use samples over a longer period of time. Over the > >> longer period of time, the carrier drifts, resulting in a "smearing" > >> of the FFT result. So, there's seemingly a limit to how precisely I > >> can estimate the carrier's frequency at any given time using that > >> technique. And, I'm still left with the requirement to track the > >> carrier as it moves over time. > > >> Jason > > > since you know apriori that you have an approx linear sweep chirp, why > > not apply an OPEN LOOP linear de-chrip to the signal first using your > > best guess as to the sweep rate, and then use closed loop techniques > > to track the residual error. > > This should reduce the difficulty of the closed loop tracking. > > > And since this is an offline process, if the residual error is still > > too large, you can go back and modify the "guess" and do it again > > until the residual error is sufficently low that the closed loop > > tracking can work well.... &#4294967295;If you get to the &#4294967295;"best possible guess" > > then the closed loop tracking has to handle only the residual error > > due to the fact that the sweep is not exactly linear. > > I think this is an excellent idea, Mark. I would add the clarification > that you would generate the individual frequency estimates at each > sample instead of using a block of samples in the FFT. Using the FFT > provides some smoothing but at the expense of smearing the sweep as was > already pointed out. > > Actually what may work better is to determine the individual sample > phases (assuming this has been Hilbert transformed down to baseband) and > them model the phases as a quadratic (a linear frequency chirp would > produce quadratic phases). This way you'd kill two birds with one stone: > a) avoiding the noise and inter-sample frequency ambiguity that would > occur from first determining frequency as delta theta and then modeling > the frequency as a linear function, and b) utilizing an entire group of > samples in order to improve performance (i.e., "average").
Interesting idea. I do have the signal in complex baseband format, so transforming that to phase vs. time would be easy. Let me clarify: are you suggesting that I make many piecewise-quadratic fits of the phase of each sample, then ensemble average the calculated quadratic parameters over the length of the snapshot? Seems like it could work, but I don't have any intuition on that sort of technique; never done anything like that before. Judging from your responses, I may have gotten ahead of myself by attaching right onto the PLL-based approach. Seems like some method of tracing the phase/frequency trajectory might be more appropriate.
> Interesting problem you have, Jason. What is the reason for the chirp > carrier? > -- > % Randy Yates % "So now it's getting late, > %% Fuquay-Varina, NC % and those who hesitate > %%% 919-577-9882 % got no one..." > %%%% <ya...@ieee.org> % 'Waterfall', *Face The Music*, ELOhttp://www.digitalsignallabs.com
Rapid relative acceleration between the transmitter and receiver. Jason
>I have a system in which I process (offline) snapshots of a low-rate >BPSK signal (~150 bps) on an AWGN background. Expected SNR of the BPSK >signal of interest is 10-12 dB. The total amount of samples available >in each snapshot varies from ~0.75 sec to ~1.5 sec, at a sample rate >of ~4800 Hz (I have 32 available samples per symbol). The message >consists of repeated messages of ~40 bits each. I need to do the best >that I can to extract one or more messages from each snapshot (there >is parity information embedded in the message, so I can tell if it is >valid; however, there is no FEC). > >The catch: the BPSK carrier frequency is chirped, increasing in a >linear ramp at up to 800 Hz/sec (the actual rate is not consistent >from snapshot to snapshot, and it may vary somewhat during each >snapshot; however, it may be approximated pretty well as linear). The >trajectory of my carrier frequency, therefore, is over five times the >information rate, so compared to my data, the carrier is really >moving. I need to obviously remove that carrier trajectory in order to >successfully demodulate my bits. > >I've made a stab at this problem using a third-order, type-3 Costas >loop. This seems to work "most of the time," but there are cases where >the loop fails to lock or looks to go unstable, for reasons >unbeknownst to me. Second-order loop filter design seems to be well- >understood and documented, but finding material on third-order loop >filter design has proven more difficult (the design I referred to >above came from some Master's thesis I found on the Web, >http://scholar.lib.vt.edu/theses/available/etd-113317959711591/unrestricted/etd.pdf, >section 3.3.2). Anyone have any pointers to texts/journals/etc. on the >topic? > >Or, any suggestions on alternate approaches? I've considered taking >the 3-dB hit and going with DBPSK. Then, in the receiver, after the >differential decoder (delay-conjugate-multiply), the frequency ramp >will appear to be a constant frequency error instead, which I could >track out with a simpler second-order PLL. I don't want to go >noncoherent if I don't have to, though. I'm open to other techniques >also; although I don't have any real-time requirements, processing >much more complicated than the strategy I've described would be >problematic due to the limited computational resources on my target. > >Thanks for any input. > >Jason >
Am I right to assume the transmitted signal created by mixing a coded waveform with a chirped carrier? Since it sounds like you know the approximate chirp ramp rate, how about estimating the chirp parameters using a standard delay and multiply, etc., and then dechirping the received BPSK signal prior to demod? Dave