[time-nuts] GPS / GNSS front-end board

Peter Monta pmonta at gmail.com
Wed Jun 6 16:32:16 UTC 2012


Hi Michael,

> What is the function of the clock/PPS inputs?

They could be used to compare a master station clock with the GPS
signals.  It seems like a good idea to put the clock and PPS through
the same path as the satellite signals.  The goal was to permit a good
comparison between GPS and any clock one cares to supply---if, at the
system level, one wants to use the data to discipline this clock, that
would be straightforward enough I guess.  I think it depends on the
application as to whether to adopt a postprocessing mindset or to
correct in real time.

By the way, the FPGA would not be using these 10 MHz and PPS samples
for any internal purpose; indeed they are optional inputs.  They would
be forwarded to Ethernet just like the satellite signals, and it's up
to a downstream processor to estimate the difference between the two.
That way the FPGA is very simple, but nevertheless supplies a
sufficient statistic for any downstream computation.

> In any case, I'm curious as to why these are piped
> into an ADC instead of being used to clock the system (10mhz) and as an
> async input to a hypothetical phase comparator in the FPGA (PPS).

I'm a little leery of piping things directly to the FPGA for jitter
reasons.  The ADCs are really good here, but the FPGA, because of all
the digital noise wandering about on the die, can have tens or
hundreds of ps of jitter.  Also, if the PPS is sent to the FPGA, there
are limited means of interpolating the PPS edge to finer resolution
than one FPGA clock cycle.  One could sample the PPS with a fast clock
multiplied up from some other system clock, but the Spartan-6 internal
multipliers max out out at around 350 MHz, limiting resolution to 3 ns
(or 1.5 ns with a DDR IOB).  I think one could interpolate the ADC
values of the PPS edge to better than that.  (There are various heroic
schemes of sending signals through the carry chain or other delay
resource, sampling that, and recovering a more accurate time, but
they're riskier and require calibration.)

> Of course I'm primarily
> interested in turning this type of frontend into a robust timing source,
> particularly if all of the GPSDO functionality can be fit into the existing
> FPGA.

That would be a significant task, putting the whole GNSS receiver into
the FPGA, and would probably require a bigger chip.  Maybe some
compromise approach, such as putting correlators and tracking loops on
the FPGA but supplying assistance information from outside.

> I'm not entirely savvy as to what additions would be required to make this
> design more useful for an embedded timing system. A bus that could bring the
> data stream to a companion board with FPGA and/or MCU for doing fixes
> without having to pass through Ethernet would be very helpful. That way
> people with interesting ideas can just fab a board to stick on a header and
> do their thing without a full gigabit Ethernet stack, which essentially
> means a FPGA is required on the other side.

Yes, there are various good options for implementing the receiver
processing.  For the near term I'll be happy to get a few hours of
L1/L2/L5 on disk, produce a nice RINEX file, and do some
postprocessing.  But for a real-time processor, I have this hazy
notion of maybe broadcasting the Ethernet to a collection of ARM
chips.  That would be a lot less bulky than a pile of PCs, even the
nifty new micro motherboards one can get these days, but still would
offer a convenient software environment (Linux, etc.) and the SSE-like
instructions for fast correlators, which are offered with the recent
ARM cores like Cortex-A8 and A9.

Cheers,
Peter




More information about the Time-nuts_lists.febo.com mailing list