[Top][All Lists]

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

RE: [Discuss-gnuradio] smooth transition from acquisition to tracking

From: Heckler, Gregory W. (GSFC-596.0)
Subject: RE: [Discuss-gnuradio] smooth transition from acquisition to tracking
Date: Tue, 6 May 2008 15:20:13 -0500

Have a FIFO that hold 1 millisecond chunks of IF data. Let each 1 ms chunk be tagged with a number, k. The acquisition will grab a 1 ms chunk, k, while the rest of the receiver will go ahead and process subsequent chunks on the FIFO. When the acquisition is complete, you can start a correlator at some new 1 ms chunk, k+m. You then use the Doppler frequency the acquisition returns to propagate the delay, t at chunk k, to a new delay at chunk k+m. Here is the corresponding code in my software receiver (found in correlator.cpp):

        /* Update delay based on current packet count */
        dt = packet.count - result.count;
        dt *= .001;
        dt *= (double)result.doppler*(double)CODE_RATE/(double)L1;
        result.delay += CODE_CHIPS + dt;
        result.delay = fmod(result.delay, CODE_CHIPS);

Check out my software receiver at www.gps-sdr.com. It works with the USRP and DBS-RX card in realtime.

-----Original Message-----
From: address@hidden on behalf of Achilleas Anastasopoulos
Sent: Tue 5/6/2008 11:04 AM
To: gnuradio mailing list
Subject: [Discuss-gnuradio] smooth transition from acquisition to tracking

Hi all,

I have the following question that came up in our attempt to implement
an GPS receiver.

Suppose samples are coming in from the USRP at a sampling rate of Fs
and in the beginning we grab N such samples (say 2msec worth of data) to
process them for initial acquisition of frequency/code epoch.
Now suppose that the task of acquisition is quite heavy so that it takes
   approximately time T (say for example ~10sec) to be completed.
At the end of this process we have an estimate of the code delay "tau"
In the meantime samples are accumulating on the incoming queue of our block.

We see two problems with that:
1) the queues will overflow so samples will start being dropped and
2) once the above happens, then the estimate "tau" is meaningless

One solution that I see to this is during the acquisition task to
periodically interupt the processing and consume a known ammount of data
(say equal to the code period) so that 1) does not happen and 2) we have
a way to relate the estimate "tau" to the incoming data after acquisition.

I wanted to ask
a) if we are on the right track,
b) if there is a simple method to implement such interupts, and
c) if there is an easier way to do that other than the one suggested.


Discuss-gnuradio mailing list

reply via email to

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