Lux, James P skrev: >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Poul-Henning Kamp >> Sent: Thursday, January 08, 2009 3:27 PM >> To: Discussion of precise time and frequency measurement >> Subject: Re: [time-nuts] GPSDO TC >> >> >> >> And timekeeping lends itself well to experiment with this, >> not the least because getting it wrong doesn't smash anything >> valuable :-) > > But you might show up early or late for dinner, which could have dire > consequences.
True. I was more expecting that when you get it wrong, GPS satellites starts falling from the sky, and they are pretty expensive things to smash flat into the atmosphere. >> For instance, one thing to think about in the context of >> GPSDO's is that in addition to the PPS signal, we also have >> all the other information. >> >> For intance it would make sense to loosen the PLL a bit when >> satellites enter and leave the solution, because that often >> moves the GPS signal a few nanoseconds abrubtly, which is >> enough to throw most PLLs into thinking you had a phase jump. > > > This brings up an interesting question. A lot of the discussion here is > about taking an off the shelf GPS receiver of one sort or another, and > then putting something around it to "improve" the system. A goodly part > of what's in the "around it" is essentially deconvolving (conceptually) > the peculiarities of the receiver. > > These days, it's not that hard to build the RF section of a GPS receiver, > and one can do the processing in an FPGA and attached CPU. Is there an > "open source" signal processing chain (i.e. to acquire and track the PN > codes, and generate the raw observables, and then to do the timing/nav > solution)? If such a thing exists, or can be created, then you can do a > fancier nav solution that explicitly accounts for all the satellites and > weights them differently as they appear and disappear. I happens to have some VHDL code lying around. However, the digital front-end is not that much magic involved with. The real work is in the tracking-processing, for which I have some partial C code lying around and there is open source code available. If someone gives me a good RF frontend we could fool around some. > Navsys sells a product that generates GPS signals by simulation and then > you load them into a USRP and play them with Gnuradio. They also sell the > receiver software. > Here's a review of Matlab toolboxes: > http://www.constell.org/Downloads/gpsmatlab.article.pdf > > Xilinx has an article: > http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p50-53_dsp-gps.pdf > That describes a GPS receiver implemented using SystemGenerator, etc., but I > suspect that they're not distributing the source code. > > There's this paper, too: > http://old.gps.aau.dk/downloads/IONGNSS2005_BorreAkos_paper.pdf > > Here's someone who did it as a project in school: > http://cegt201.bradley.edu/projects/proj2008/gps/ > He tried to convert the Matlab from Akos, et al., to C++ We are a few that has a GNSS Sampler, which is basically a GPS frontend hooked to a USB chip and you do correlation etc in the computer. It is a bit of a challenge to get it to track in real time thought there are those that do that. >> There is also the complex 12h signal in most GPS receivers >> PPS, should that be notched out of the PLL so that it will >> not react to offsets that have a 12h period ? (obviously >> only in stationary >> applications.) >> >> So many things to try, so little time... > > Indeed... > > > But hey.. Why not start hooking up a USRP or Xilinx Eval board.. Let's do that... some day. Cheers, Magnus _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
