Minimum ADC Sampling Rate / Symbol Rate for a PSK Modem with Time and Carrier Recovery.

Started by May 3, 2018
Dear DSP Gurus,
 I have to demodulate a 50 MHz wide (3 dB bandwidth) OQPSK modulates Signal.
 The Signal properties are:
OQPSK Modulated
AWGN channel
Has Doppler Shift (5 KHz/sec max) 
Pulse shaping filtered (0.35)
Viterbi+RS

 The HW I am using is:
Zero IF Receiver
ADC on I&Q channels (12 bit output)
Has a signal processor (Output is IQ corrected,DC Removed,AGC) 

The Output is:
I (12 bit), Q(12 bit), Sampling clock (X MHz)

My question is what is the minimum value of X to get a carrier/ time recovered 50
MSPS signal?

The Alternatives are:
Carrier Recovery: Costas Loop
Timing Recovery Muller-Mueller, Gardner Algorithm, Correlation

Since there is Doppler shift I guess I have to use Costas Loop first(or
Correlation), then Timing Recovery.

If I use the Gardner algorithm then the sampling rate must be 2x the symbol rate
which I wouldn't prefer.

Any Ideas?
Thank you in advance. 
<kurtulmehtap@gmail.com> wrote:

> I have to demodulate a 50 MHz wide (3 dB bandwidth) OQPSK modulates Signal.
Do you mean 50M symbols per second?
> The Signal properties are: >OQPSK Modulated >AWGN channel >Has Doppler Shift (5 KHz/sec max) >Pulse shaping filtered (0.35) >Viterbi+RS > >The HW I am using is: >Zero IF Receiver >ADC on I&Q channels (12 bit output) >Has a signal processor (Output is IQ corrected,DC Removed,AGC)
>The Output is: >I (12 bit), Q(12 bit), Sampling clock (X MHz)
>My question is what is the minimum value of X to get a carrier/ time >recovered 50 MSPS signal?
I have used oversampling ratios of 5 or 6 at a GFSK demodulator. 6 makes sense (you get the 2x for the Gardner for free), But could be expensive. You could try an OSR of 4. I haven't tried an OSR that low.
>The Alternatives are: >Carrier Recovery: Costas Loop >Timing Recovery Muller-Mueller, Gardner Algorithm, Correlation
>Since there is Doppler shift I guess I have to use Costas Loop first(or >Correlation), then Timing Recovery.
Maybe. Does your data include a preamble, or a periodic synch word? Or is it a continuous stream you wish to lock onto blind? If you have a choice, insert preambles / midambles into your data format and correlate against those first. Try feedforward approaches before trying loops. The effect of h = 0.35 is that such correlations will be somewhat weaker, and you may want to have an equalizer. As it is convolutionally encoded the soft information for Viterbi can typically be computed in the equalizer. A Forney MLSE equalizer is optimal but also costly at these datarates. A DFE is simpler and can work well. (You have not said if this is cost sensitive, hi volume, or a one-off.) Good luck Steve
> Do you mean 50M symbols per second?
Yes, sorry for the confusion.
> > > The Signal properties are: > >OQPSK Modulated > >AWGN channel > >Has Doppler Shift (5 KHz/sec max) > >Pulse shaping filtered (0.35) > >Viterbi+RS > > > >The HW I am using is: > >Zero IF Receiver > >ADC on I&Q channels (12 bit output) > >Has a signal processor (Output is IQ corrected,DC Removed,AGC) > > >The Output is: > >I (12 bit), Q(12 bit), Sampling clock (X MHz) > > >My question is what is the minimum value of X to get a carrier/ time > >recovered 50 MSPS signal?
> >Since there is Doppler shift I guess I have to use Costas Loop first(or > >Correlation), then Timing Recovery. > > Maybe. Does your data include a preamble, or a periodic synch word? > Or is it a continuous stream you wish to lock onto blind? > > If you have a choice, insert preambles / midambles into your data > format and correlate against those first. Try feedforward approaches > before trying loops. >
Its a CCSDS coded bitstream. So there is a 32 bit header. Since everything is convolutionally coded, I am not sure it that can help.
> (You have not said if this is cost sensitive, hi volume, or a > one-off.)
Its not cost effective but the ADC sampling rate is limited to 150 MHz (I and Q arms have seperate ADC's) That's why we were asking if 150 MHz sampling would be enough to get a carrier and time recovered 50 MSymbols/s stream. We were wondering if we use Costas Loop then M-M timing recovery, can we get 50 MSymbols/s using ADC 100 MHz sampling.
<kurtulmehtap@gmail.com> wrote:

>Its a CCSDS coded bitstream. So there is a 32 bit header. Since >everything is convolutionally coded, I am not sure it that can help.
Good. I think the header, even after BCC encoding, presents a constant bit-pattern to which you can correlate. It's been awhile since I've looked at CCSDS.
>Its not cost effective but the ADC sampling rate is limited to 150 MHz >(I and Q arms have seperate ADC's) >That's why we were asking if 150 MHz sampling would be enough to get a >carrier and time recovered 50 MSymbols/s stream.
I think the answer is probably, but only after doing some work on it and simulating it.
>We were wondering if we use Costas Loop then M-M timing recovery, can we >get 50 MSymbols/s using ADC 100 MHz sampling.
Are you suggesting that the ADC sample clock be recovered from a Costas loop? That is very tricky. Usually you want to sample with a free running, very stable (low jitter) clock derived from an crystal oscillator. I would give the loop approach lower odds than sampling asynchronously at 150 Ms/sec. If your performance criteria (e.g. implementation loss) are very tight then the job gets harder. Steve
> >Its a CCSDS coded bitstream. So there is a 32 bit header. Since > >everything is convolutionally coded, I am not sure it that can help. > > Good. I think the header, even after BCC encoding, presents a constant > bit-pattern to which you can correlate. It's been awhile since > I've looked at CCSDS.
So I guess we have to implement a correlator.Hopefully it will do the carrier and timing recovery. I hope the required oversampling is not that high.
> >We were wondering if we use Costas Loop then M-M timing recovery, can we > >get 50 MSymbols/s using ADC 100 MHz sampling. > > Are you suggesting that the ADC sample clock be recovered from a > Costas loop? That is very tricky. Usually you want to sample with a > free running, very stable (low jitter) clock derived from an crystal > oscillator. I would give the loop approach lower odds than sampling > asynchronously at 150 Ms/sec.
No that is not we are trying. The ADC's at the I and Q arms are sampled at a specified frequency (say 150 MHz). We were hoping to get a 50 Msymbols/s from the sampling.
> If your performance criteria (e.g. implementation loss) are very > tight then the job gets harder. > > Steve
On Sat, 5 May 2018 03:09:31 -0700 (PDT), kurtulmehtap@gmail.com wrote:

> >> >Its a CCSDS coded bitstream. So there is a 32 bit header. Since >> >everything is convolutionally coded, I am not sure it that can help. >> >> Good. I think the header, even after BCC encoding, presents a constant >> bit-pattern to which you can correlate. It's been awhile since >> I've looked at CCSDS. >So I guess we have to implement a correlator.Hopefully it will do the carrier and
timing recovery. I hope the required oversampling is not that high.
> >> >We were wondering if we use Costas Loop then M-M timing recovery, can we >> >get 50 MSymbols/s using ADC 100 MHz sampling.
Yes. It's not trivial, but it's not incredibly complicated, either. It helps if you don't need a very short acquisition time.
>> Are you suggesting that the ADC sample clock be recovered from a >> Costas loop? That is very tricky. Usually you want to sample with a >> free running, very stable (low jitter) clock derived from an crystal >> oscillator. I would give the loop approach lower odds than sampling >> asynchronously at 150 Ms/sec. > >No that is not we are trying. The ADC's at the I and Q arms are sampled at a
specified frequency (say 150 MHz). We were hoping to get a 50 Msymbols/s from the sampling.
>> If your performance criteria (e.g. implementation loss) are very >> tight then the job gets harder. >> >> Steve >
The short answer to your question is, yes, you can fully recover OQPSK if it is sampled at 2x the symbol rate. It isn't necessarily easy, but it can definitely be, and has been, done. If you can increase the sample rate, all the better, but it's not going to start to get much easier unless or until the sample rate gets to about 4x the symbol rate or higher.
> The short answer to your question is, yes, you can fully recover OQPSK > if it is sampled at 2x the symbol rate. It isn't necessarily easy, > but it can definitely be, and has been, done. If you can increase the > sample rate, all the better, but it's not going to start to get much > easier unless or until the sample rate gets to about 4x the symbol > rate or higher.
Can you point to a paper or an implementation that can recover the OQPSK signal at sampling rate 2x the symbol rate. Non-Integer ratios will also do as we have 2x-2.5x symbol rate ADC sampling.
> The short answer to your question is, yes, you can fully recover OQPSK > if it is sampled at 2x the symbol rate. It isn't necessarily easy, > but it can definitely be, and has been, done. If you can increase the > sample rate, all the better, but it's not going to start to get much > easier unless or until the sample rate gets to about 4x the symbol > rate or higher.
Can you point to a paper or an implementation that can recover the OQPSK signal at sampling rate 2x the symbol rate. Non-Integer ratios will also do as we have 2x-2.5x symbol rate ADC sampling.
<kurtulmehtap@gmail.com> wrote:

(Eric writes)

>> The short answer to your question is, yes, you can fully recover OQPSK >> if it is sampled at 2x the symbol rate. It isn't necessarily easy, >> but it can definitely be, and has been, done. If you can increase the >> sample rate, all the better, but it's not going to start to get much >> easier unless or until the sample rate gets to about 4x the symbol >> rate or higher.
>Can you point to a paper or an implementation that can recover the OQPSK >signal at sampling rate 2x the symbol rate. Non-Integer ratios will also >do as we have 2x-2.5x symbol rate ADC sampling.
Most people want more oversampling than 2x, as Eric said. I believe you started out saying you could do 3x. You might want to go with that. The problem is the signal, even with heavy h=0.35 Gaussian filtering, still has excess bandwidth. If your OSR is too low, then that energy just shows up as noise and you can't use it and it just degrades the operating point. But you can recover a bitstream. But in CCSDS operating point is key. You need the maximum range and fidelity to (or from) your space platform which is a high value instrument so you don't want to undersample should this compromise you in any way. You might want to put a stake in the ground at 3X, 150 Msample/sec. What I'm saying is, you don't want to underdesign. Tangentially I worked on two of these links, for ISS. I believe the baud rates were 25 ms/sec and 150 ms/sec, but it's a little fuzzy in my memory. Good luck. Steve
On Tue, 8 May 2018 06:02:31 -0700 (PDT), kurtulmehtap@gmail.com wrote:

> >> The short answer to your question is, yes, you can fully recover OQPSK >> if it is sampled at 2x the symbol rate. It isn't necessarily easy, >> but it can definitely be, and has been, done. If you can increase the >> sample rate, all the better, but it's not going to start to get much >> easier unless or until the sample rate gets to about 4x the symbol >> rate or higher. > >Can you point to a paper or an implementation that can recover the OQPSK signal at
sampling rate 2x the symbol rate. Non-Integer ratios will also do as we have 2x-2.5x symbol rate ADC sampling. I think many comm texts that cover PSK synchronization cover the basics. With OQPSK the main aggravation is that the carrier phase and symbol timing are not independent, so that makes acquisition tricky. Once acquired, however, OQPSK is essentially QPSK with one of the I/Q channels delayed by 1/2 symbol. From that point, it can be treated as a QPSK receiver if the 1/2 symbol delay is included, and all of the synchronization for *maintaining* lock is the same as QPSK. If you are steering the symbol timing digitally, you will need an interpolating filter which is steered with the Timing Error Detector, which can be M-M or Gardner, with the caveat that care must be taken during acquisition. Steering the carrier phase digitally is pretty straightforward with respect to implementations for other PSK signalling, i.e., pretty much the same stuff. OQPSK is also similar to many types of CPM, like MSK/TFM/GMSK/etc., so texts covering those may be helpful as well. The main trickiness will be in resampling the signal to the symbol rate (or 2x the symbol rate) with an interpolating filter steered by a TED and loop filter, and managing acquisition/initial synchronization. If there is a preamble then acquisition may be straightforward with correlators matched to the preamble.