DBSRX used for GPS: cycle slip

GNU Radio
1

Hi,

I am seeing sudden freq shifts at the local oscillator on the order of
~500Hz which make it impossible to track GPS.

We suspect under certain conditions there are cycle slips in the DBSRX
PLL.

Questions:

  1. Can someone provide a schematic of the DBSRX in pdf or tell me how to
    read the one at http://www.gnuradio.org/trac/browser/usrp-hw/trunk/dbsrx

  2. What are the R and C values of the analog PLL filter on the DBSRX?

Thank you,

Chris

2

Chris S. wrote:

I am seeing sudden freq shifts at the local oscillator on the order of
~500Hz which make it impossible to track GPS.

It appears that this problem happens on only one of my two DBSRX boards.

Chris

3

Chris S. wrote:

  1. Can someone provide a schematic of the DBSRX in pdf or tell me how to
    read the one at http://www.gnuradio.org/trac/browser/usrp-hw/trunk/dbsrx

I found that I can open the .ps version.

Thanks,

Chris

4

Chris S. wrote:

Chris S. wrote:

I am seeing sudden freq shifts at the local oscillator on the order
of ~500Hz which make it impossible to track GPS.

It appears that this problem happens on only one of my two DBSRX boards.

What are your PLL settings? If you minimize the R divide ratio, you can
eliminate this. The larger R divide will put you further from right on
frequency, but the DDC will put you right back in the right place.

Matt

5

Matt E. wrote:

What are your PLL settings? If you minimize the R divide ratio, you
can eliminate this. The larger R divide will put you further from
right on frequency, but the DDC will put you right back in the right
place.

Yes. You can also try setting the frequency to 1575 rather than
1575.42;
this results in more favorable PLL settings by default, and then one can
remove the frequency offset at baseband as a separate frequency
translation
step.

How sudden are the shifts and how often do they happen? Do they look
like frequency spikes (phase steps) or frequency steps (phase ramps)?
If the dbsrx PLL were to slip occasionally, I guess one would expect
the former, not the latter. Could try feeding the dbsrx with a nice
strong tone from a signal generator to get a better view of its phase
purity once it’s been through the entire USRP chain.

Some TCXOs suffer from sudden jumps over temperature, but this
doesn’t match your experience, since the TCXO is on the motherboard
and would affect both dbsrx’s equally.

Cheers,
Peter M.

6

Chris:

So you are not tracking the signal in the traditional sense, only
looking at the frequency and delay estimate of your FFT acquisition. How
far spaced are your Doppler bins in the FFT acquisition? If you are
using a 1 ms integration time, and hence a 500 Hz bin spacing, if the
signal’s true Doppler is towards the middle of a bin it is ambiguous
which bin the peak power will reside in due to noise. I have observed
that the USRP’s clock is jittery (PLL tracking is only possible by
opening up the bandwidth beyond the recommend 18 Hz for a 3rd order
PLL), however I have never observed a 500 Hz instantaneous jump in
frequency (which would cause all of the channels to dump). Do you have
tracking data with multiple SVs which also point to a 500 Hz frequency
jump?

–
[email protected]
NASA Goddard Space Flight Center
AETD - Mission Engineering and Systems Analysis
Component and Hardware Systems Branch
Mail Code 596, Greenbelt Rd.
Greenbelt, MD 20771
(301) 286-6565
(301) 286-3823 (fax)

7

Peter M. wrote:

How sudden are the shifts and how often do they happen? Do they look

They are sudden (happen within 10 ms) and they happen about once a
second. I visualize them by continuously acquiring a GPS signal and
watching the peak move along the freq axis in the 3D plot of frequency
vs. chip offset vs. power

These are the DBSRX (MAX211x) parameters as they are in Greg Heckler’s
c++ driver:

d_fdac = 127
d_gc2 = 31
d_diag = 5
d_div2 = 1
d_n = 6304
d_m = 2
d_dl = 0
d_ade = 0
d_adl = 0
d_osc = 3
d_cp = 1
d_r_int = 3

Chris

8

Chris:

I was referring to the Doppler estimate output by your PLL over time
(traditional tracking), whereas
you indicated that you were looking at repeated acquisition attempts. If
the jump is visible in all satellites than I
agree with your suspicion of the DBSRX card. Note that the ref frequency
you pass from the mainboard to the
DBSRX daughtercard cannot be too high, I made that same mistake a long
while back. The ref clock divisor must 16 or greater
(ie the reference frequency is 4 MHz or lower).

9

Gregory W Heckler wrote:

PLL), however I have never observed a 500 Hz instantaneous jump in
frequency (which would cause all of the channels to dump). Do you have
tracking data with multiple SVs which also point to a 500 Hz frequency
jump?

Greg,

  1. Our acq doppler bins are spaced 100Hz apart. The sudden jump is
    1000Hz (10 bins). As I said earlier, this problem only occurs on one of
    my DBSRX boards. On the “faulty” DBSRX board, the problem exists for
    all satellites. If it turns out the DBSRX board is not faulty, it could
    indicate that the parameters I’m passing to the DBSRX/MAX211x are on the
    “hairy edge” of being stable for the chip.

  2. I have also noticed USRP’s jittery clock. However, my 2nd order PLL
    is able to track it. One thing that concerns me about your setup is
    that you are sampling at 2Msps complex – the bare minimum according to
    Nyquist. FYI I am using 4Msps.

  3. I do not know what you mean by this: “So you are not tracking the
    signal in the traditional sense, only looking at the frequency and delay
    estimate of your FFT acquisition.” – perhaps you can rephrase?

Chris

10

Heckler, Gregory W. (GSFC-596.0) wrote:

I was referring to the Doppler estimate output by your PLL over time
(traditional tracking), whereas
you indicated that you were looking at repeated acquisition attempts.

Greg,

While performing traditional tracking with a PLL using “prompt”
accumulations, I noticed my PLL could not keep track. As a debugging
tool I conducted repeated acquisitions and it was there I noticed that
the freq was suddently changing – aha the source of my PLL problem!

This image should give you an idea of what we are doing. It’s a matlab
plot of various outputs from our traditional tracker.

http://img233.imageshack.us/img233/4064/gpswm9.gif

Thanks, I will take a look at the frequency being passed to DBSRX.

Chris

11

Have you ruled out the USRP overflowing? I have had that problem bite me
too. It causes all of the tracking
channels to dump in my receiver, but I could see how it could also cause
a jump in the frequency estimate
(delay in time domain == shift in frequency domain) coming out of your
FFT acquisition.

12

Heckler, Gregory W. (GSFC-596.0) wrote:

Have you ruled out the USRP overflowing? I have had that problem bite me
too. It causes all of the tracking
channels to dump in my receiver, but I could see how it could also cause
a jump in the frequency estimate
(delay in time domain == shift in frequency domain) coming out of your
FFT acquisition.

Hi Greg,

I ruled out a USRP overflow for two reasons:

  1. When I recorded the data, there was no indication of overflow

  2. When I perform a “continuous acquisition”, the frequency jumps, but
    the C/A offset does not. When data is lost, the C/A offset will jump
    also.

However, I do have a dataset with missing data that gave no indication
data was lost during the collect. I’m chatting about this in another
thread “Losing data during long collects”

CHris