On 06/05/2012 11:03 AM, Peter Monta wrote:

Very impressive. Since I discovered time-nuts this is exactly what I
wanted to make, and you've gone and done all the hard stuff. If you're
planning on doing a bulk run, count me in.

What is the function of the clock/PPS inputs? 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.  This can be done either by clocking the GPS receiver
from the disciplined clock (e.g. Trimble Thunderbolt), or by using
independent clocks and estimating the resulting quantization error (most
timing-oriented receiver-only modules). In a from-scratch design I don't
think there's any reason not to use the disciplined clock, but there
could be lurking correlation problems. 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 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.

Disclaimer: I know very little about actually implementing a GPS
receiver, and about RF in general, but I know a cool project when I see
one and this has a lot of the elements needed for a fully open-source
timing receiver. Looking forward to further developments, and if there's
another list you're more active on do let me know.

-- m. tharp

On Tue, 5 Jun 2012 08:03:53 -0700
Peter Monta pmonta@gmail.com wrote:

Very cool! I like it! And i imediatly buy one as soon as you produce some :-)

I had a cursory look at the schematics and i would propose the following
changes:

• Connect all free pins of the FPGA to a 2.54mm header pin connector
  This would make extensions to the system a lot simpler.
  Up to the point of using a simple uC board for a full fledged
  GPSDO system. Additonally put onto this connecter an unused output
  of the LMK03806 and some power supply pins.

• The XC6SLX9 is <10USD more expensive than the SLX6. I think the added
  value of having twice as much "real estate" would justify the additional
  price.

• Connect the enable pin of the OSC1 to a 2-pin header, so it can be
  disabled with a simple jumper. And put a SMA connector into the path
  between OSC1 and the LMK03806 (probably not mounted by default) in order
  to make using an external clock source easier.

I assume that you are running the ADCs in multiplexed mode and the FPGA
at 128MHz clock?

How about design tools for the FPGA? As far as i can tell, the ISE WebPack
does not support the Spartan 6 family.

		Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On 06/05/2012 03:31 PM, Attila Kinali wrote:

Some vendors don't even stock the SLX6, including Digi-Key! Agreed
though, it would be neat if a CPU capable of doing fixes could be fit
onto the FPGA alongside. Might be impractical though, a DSP would
probably be more appropriate. Still, from what I can tell a FPGA makes a
decent PPS-level phase comparator. You can even gang them up with a
phase-shifted clock to get finer resolution.

WebPack does support XC6, or at least the mid-range parts and below. I
have a XC6SLX45 dev board and have no problems generating bitstreams.

-- m. tharp

On Tue, 05 Jun 2012 13:48:17 -0400
Michael Tharp gxti@partiallystapled.com wrote:

Get yourself a copy of "A software defined GPS and Galileo Receiver"
by Borre et. al.[1] It explains how GPS signals are structured,
received and decoded in a quite simple language. It is nearly a
step by step receip on how to build a complete receiver.

		Attila Kinali

[1] http://www.springerlink.com/content/w5151k87k3043l63/

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On Tue, 05 Jun 2012 15:40:48 -0400
Michael Tharp gxti@partiallystapled.com wrote:

Yes, there are at least half a dozen ways i can think of to use this
board in combination with other boards or various uC and DSPs. And
everyone has their own pet uC/DSP/board that he'd like to use.
Thus i think some easily accessible header pins would be better than
putting a uC directly on the board.

Cool. It thought it was strange that the WebPack FAQ listed only spartan3.
But i couldnt find any other reference listing the supported FPGAs.

		Attila Kinali

		

--
Why does it take years to find the answers to
the questions one should have asked long ago?

On Tue, 5 Jun 2012 21:31:32 +0200
Attila Kinali attila@kinali.ch wrote:

Addendum:

Could you also add just the option of a power splitter at the input?
This would allow to use one antenna while using a cheaper SMB mounted
power splitter instead of one connected using SMA connectors.

Something easily available and "cheap", like the stuff from minicircuits
like the SCN-3-16 would be fine i guess.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

Hi Michael,

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.

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.)

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.

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

On Tue, Jun 5, 2012 at 12:53 PM, Attila Kinali attila@kinali.ch wrote:

I just accessed the book on SpringerLink and it looks fantastic.
Fortunately my company's library lets me have full access to the text
of the book. However, it does not appear that they let me download the
matlab code that comes on the CD that comes with the book. do you know
if it's available somewhere?

--
--Eric

Eric Garner

Hi Attila,

Sure, that sounds reasonable---I'll do that.  But just a caution that
it will need some work to realize a fully-fledged GPSDO, even with an
external microcontroller board.  At a minimum, the FPGA would need
NCOs, code generators, correlators, and tracking loops, which people
are free to do of course.

The LX9 is pin-compatible, so substituting it in would be no problem
(actually I have a few).  The current design easily fits in the LX4,
though.  I guess it would be up to the user which chip to supply.  I
did consider using a BGA footprint, which would allow some of the
larger FPGAs in the family, but BGAs are not very prototype-friendly.
(Nor are QFNs with exposed pad, for that matter, but there was no
alternative there.)

I was thinking to do a resistor-programmable option to either use the
10 MHz or the TCXO as input to the LMK03806.  I'm not sure there's a
huge advantage to using a more stable clock, though.  The TCXO is
probably plenty good enough for keeping the carrier PLLs in
lock---it's a fairly high-end TCXO which is not cheap ($18).  Using
the 10 MHz (or 100 MHz) does have the merit of potentially saving the
cost of the TCXO, but many users would probably want a board that just
works, without a lot of external doodads to hook up.

Yes.  Actually the FPGA runs at 64 MHz and the I/O cells are used in
DDR mode so that a sample is taken on both rising and falling edge.

Cheers,
Peter