RE: [Discuss-gnuradio] GPS L2C transmissions?
Peter: Yeah, it really sucks. If you look at IS-GPS-200D at table 20-VIII the 6 bit SV health message has a value that indicates L2C Signal Has No Data Modulation, unfortunately the Air Force is not following their own ICD. From my knowledge all the semi-codeless tracking algorithms are heavily patented, and hence cannot be found in textbooks or in any open forum. -Original Message- From: Peter Monta [mailto:[EMAIL PROTECTED] Sent: Fri 8/8/2008 6:50 PM To: Heckler, Gregory W. (GSFC-596.0) Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GPS L2C transmissions? I can verify that there is NO DATA on any of the L2C capable SVs. Ah. I'd thought from the ICD that the only valid options were legacy data or new data. While I understand that this is all pre-operational, it would be nice to have some rough guidelines from the GPS people about what to expect with the on-orbit L2C signals over the next year or two. Check out www.gps-sdr.com for more info. Very interesting---thanks! Would you know if there are any open implementations of P/Y semicodeless? Cheers, Peter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] GPS Receiver Daughter-boards / Antennas
GPS Geeks: I ordered the Mighty Mouse 3 active GPS antenna. The spec sheet quotes +5dBi gain at zenith and -1dBi at 10 degrees. I ordered the antenna from: http://www.gpszone.ca/accessories/antennas/mm3.php The spec sheet is available from the manufacturer at: http://www.tri-m.com/products/systems/mm.html I purchased an AC/DC inverter for my car and connected the USRP, a laptop, and the Mighty Mouse 3 antenna and went cruisin'. My evaluation of the antenna (in Ebayish): A . It works great, was cheap, and works out of the box with the USRP. It has a magnet built in the base so you can throw it on your car roof without a worry. If you order it, just be sure to indicate that you require an SMA connector (the type provided with the USRP). When you connect it to the USRP/DBS-RX be sure to bias the line by shorting jumper 101 on the DBS-RX. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] DBSRX used for GPS: cycle slip
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). -Original Message- From: Chris Stankevitz [mailto:[EMAIL PROTECTED] Sent: Mon 6/2/2008 6:34 PM To: Heckler, Gregory W. (GSFC-596.0) Cc: 'discuss-gnuradio@gnu.org' Subject: Re: [Discuss-gnuradio] DBSRX used for GPS: cycle slip Gregory W Heckler wrote: 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? 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] DBSRX used for GPS: cycle slip
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. -Original Message- From: [EMAIL PROTECTED] on behalf of Chris Stankevitz Sent: Mon 6/2/2008 8:54 PM To: Heckler, Gregory W. (GSFC-596.0) Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DBSRX used for GPS: cycle slip 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] smooth transition from acquisition to tracking
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: [EMAIL PROTECTED] 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. Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
