Exploring GPS with Software Defined Radio

The source must flow.

Entries Comments


GUI Here We Come

13 August, 2008 (01:08) | Software Receiver | 10 comments

I have the initial baby steps of a wxWidgets based GUI in the code now. All the GUI currently accomplishes is to replicate the ncurses display with a tabbed interface. To build the GUI program goto the gps-sdr/gui directory and type “make”. Be sure to check out the build guide to get the required wxWidgets packages before doing so! If it builds, start up the receiver with the -gui argument, this will disable the ncurses display and write the telemetry over a named pipe, then start up the gui app. It should connect and start dumping out information. As always, feel free to ask questions, and if anyone has requested features post them in the appropriate place on the wiki.

New Stuff

6 August, 2008 (12:05) | Software Receiver | 4 comments

I uploaded a new chunk of recorded data (20 seconds in length). The old data set was bunk, as it had the GPS IF frequency set at 604 kHz, whereas I moved the receiver’s IF frequency to 0 Hz several weeks ago. Running the receiver on the new data should indicate the presence of SV’s 22, 30, 31, and 32. There was also a bug in the post process code that incorrectly set the agc_scale value, which is probably why many of you have had a hard time running the receiver in post-process mode. Also, I added a page for bugs on the Wiki, PLEASE dont be shy and write any bugs you might find there.

Wiki, Oh How You Tempt Me

4 August, 2008 (22:21) | General | 1 comment

I am in the process of building a wiki, obviously check out the link on the right. I’d also like to give a shoutout. To those who have tried to get the receiver to work (unsuccesfully), whomever replies to this post first to my email, mp3phile at gmail.com, with the subject “GPS-SDR Help” I will work with over email and/or IM until the receiver works with your setup. Of course I have to throw out a couple of caveats: you should own a USRP & DBS-RX daughtercard, your computer should have a recent install of Ubuntu (>7.04) and be less than 2 years old (I’m looking for <2 yr old processor and > 1GB of RAM), and you should have an active GPS antenna with a decent sky-view. Also, I am working ALOT of overtime right now to meet a deadline, so I may not available until after 9 PM EDT until mid-August. This request will both help you (an end user), and me. As the developer sometimes it is hard to run into the problems an end user might encounter because I always use the receiver in the “right” way :). I hope I get a reply!

Mac OSX Request

1 August, 2008 (12:01) | Software Receiver | No comments

Someone tried to compile the receiver on a Mac OSX system, but could not get passed the compilation of fft.cpp, and so requested a pure C++ implementation of this code. I update the git repository with this requested feature. To enable please uncomment the “#define NO_SIMD” line found at the top fft.cpp, this will swap the SIMD fft code with pure C++ fft code. If you have more troubles, drop me a line!

Long Time, No See

27 July, 2008 (14:14) | Software Receiver | No comments

I’ve been on vacation and have been shirking both work and this website. Some interesting things are happening with the receiver, however. A co-op (cooperative education student) has been working for me this summer, and his project was to add an L2C capability to the receiver. He has done very well, and is putting the finishing touches on adding an L2C correlator/tracking channel into the receiver. I upgraded the usrp code to allow a dual dbs-rx capability. Once I have accepted his code and pulled it into the main distro I will make an announcement on this page. I also have a question, if I were to write a nice gui for the receiver what package does anyone recommend? I have looked in wxWidgets and fltk. If anyone has any experience give me a yell.

To all of you having troubles running the receiver I might know the problem. One issue is that I changed the center IF frequency from 604 kHz to 0 Hz. I discovered that the USRP creates a phase imbalance between the I & Q data as the center IF frequency deviates from baseband. Please do not use the USRP_Uno code linked on the website. Rather use USRP code found in ~/gps-sdr/usrp (the executable is usrp_gps), this has been pushed to the git repository in the last week, so please update your source as need. This code should work by default with the 64 MHz stock USRP (it samples at 4 Msps and resamples to 2.048 Msps). Please type ./usrp_gps -help to see the available arguments to this code. Also the dual board capability that is included with usrp_gps.cpp is not yet pulled into the main receiver, so do not try to use those options just yet.

I added threaded comments to the blog, which should help answering questions.

Gone Mobile

23 June, 2008 (16:54) | Software Receiver | 15 comments

So, work is killing me lately, but I have made one significant accomplishment, I have taken the receiver mobile! After reading a bunch of questions about GPS antennas I made myself the guinea pig. 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). As always, some plots:

1) Estimated CN0’s
2) Nav Status

Notice the dropouts in the 10-12 minute range. This is when I drove underneath a nice dense area of trees. I had the extended correlations disabled (ie only a 1 ms correlation) so the receiver did not keep lock on those SVs during the signal fade. There is definitely some work to be done. One issue is after a signal dropout and a reacquisition it takes ~10 seconds before the SV is usable (it has to do the bit lock and frame lock process over again), this is unnacceptable. I should be able to predict the SV’s state with less than 1 ms of error, hence be able to initialize the 1ms and 20 ms counters correctly. But overall I am pretty damned happy, the thing actually works!


View Larger Map

Teaser

3 June, 2008 (00:49) | General | 2 comments

Antennas side by side

The new antenna arrived (foreground). I will post results as soon as I produce something conclusive.

Doxygen

27 May, 2008 (20:31) | General | 5 comments

Hey everyone, a new version of the receiver has been posted at GitHub, link to the right as always. Also, please check out the “Documentation!!!” link, it will take you to the Doxygenated source code, easily searchable, browseable, and hopefully comprehensible. Messages floating on the GNURadio mailing list have indicated that people are searching for a good antenna to use. I just ordered a small patch antenna from the web, when I receive it I will post a review of the antenna and compare it to the antenna I use currently (a several hundred dollar antenna for aircraft, its nice working in a professional RF lab!).

http://www.tri-m.com/products/systems/mm.html

Revision Control

12 May, 2008 (21:05) | Software Receiver | 11 comments

To get away from posting .gz files I now have the source under revision control using Git, the same revision control system used for the Linux kernel. I’m not a fan of of CVS/SVN personally and found this alternative. The source is hosted at Git hub, under the project “gps-sdr”. You can either download a tarball from the website or use Git itself to “clone” the latest source code. After installing Git execute the following command to get the latest source code:

git clone git://github.com/gps-sdr/gps-sdr.git

BTW, the latest version is

05/12/2008 3.0.14a

After reading more about the DBS-RX I changed the default values in usrp_sdr.cpp. By widening the Max2118’s filter from 2 MHz to 10 MHz the phase noise in the down-conversion greatly decreases. Previously the max CN0 that would be estimated was 46 dB-Hz, now CN0’s on the order of 53 dB-Hz are estimated. Also a partial mplementation of almanac decoding is complete, changes found in ephemeris.cpp.

Screenshot

4 May, 2008 (20:52) | Software Receiver | 11 comments

screenshot1.png

Lets start at the top. The first line gives feedback on the FIFO’s status. The first entry displays how many 1 ms nodes are left in the FIFO, 999 representing the FIFO is empty. If the receiver starts to bog down this will decrease. The next value presents how many milliseconds in total have been processed. The third value is the AGC scale factor, basically a divisor that holds the number of overflows in each ms to a constant number. The final value is the number of overflow in the last ms.

The next block shows the tracking channel status. From left to right, the channel number, SV assigned to the channel, the integration length (in ms), the value of the acceleration accumulator in the PLL/FLL, the Doppler value in Hz, the CN0 estimate in dB-Hz, the bit edge, tracking locks, I2+Q, and finally the number of seconds this SV has been tracked. The tracking lock display has the following codes:

pBFN12345

f/p: FLL or PLL tracking

B: bit lock

F: frame lock

N: this channel is being used for navigation

12345: the last decoded subframe

The next block displays some info about the navigation, again from left to right, the channel number, SV assigned to the channel, time used in SV position calculation, SV ECEF X velocity, ECEF Y velocity, ECEF Z velocit, pseudorange (seconds), and finally pseudorange residual (meters).

The latest acquisition result is display in the next line, the labels in the screenshot should be self explanitory. Acq type is STRONG (1 ms) or MEDIUM (10 ms).

The navigation display should be easily understood. One thing is missing from the screenshot, after the last line, when an SV’s ephemeris is succesfully decoded the SV number will appear in comma delimited list. This will not happen for those running the receiver on the 10 second snapshot of data I posted, but those who succesfully run the receiver on top of the USRP in real-time should see it. As always, I appreciate all of the questions and feedback.  

« Older entries