[time-nuts] GPSDO TC
Magnus Danielson
magnus at rubidium.dyndns.org
Fri Jan 9 00:14:32 UTC 2009
Lux, James P skrev:
>> -----Original Message-----
>> From: time-nuts-bounces at febo.com
>> [mailto:time-nuts-bounces at febo.com] 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
More information about the Time-nuts_lists.febo.com
mailing list