[time-nuts] GPSDO TC

[Magnus Danielson]

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