On Thu, Aug 4, 2016 at 11:08 PM, Daniel Mendes dmendesf@gmail.com wrote:

A shame, it looks like it can be externally clocked, but I don't see a
way to get in and measure a PPS signal.

Considering the increasingly frequent jamming I see doing a multiband
CRPA timing receiver sounds like a fun project; but I'm not quite
seeing how to do really overkill timing with this device. :)

I guess on the NT1065 you'd want use the clk with a counter to capture
the position of a PPS or external reference with respect the the
sample clock?... and hopefully the signal processing chain from clock
to the ADC has a constant delay?

This board just seems to be the RF front end for a GNSS receiver. You then
have to do the whole business of acquiring and tracking the code, and then
do the PVT solution, at which point you can make your own 1 PPS.

Cheers
Michael

On Sunday, 14 August 2016, Gregory Maxwell gmaxwell@gmail.com wrote:

Hi

It’s not real clear what the second chip on the board does. If it is just a bit to Ethernet converter
then you are dealing with 2 bit data out of each of the four channels. You aren’t just doing tracking
in that case ….4 channels at 2 bits -> 8 bits per clock. Clock at 38 to 100 MHz. That could turn out
to be a very crowded Ethernet connection.

Bob

On Sat, Aug 13, 2016 at 11:53 PM, Bob Camp kb8tq@n1k.org wrote:

I assume it's like the GNSS firehose (
http://pmonta.com/blog/2012/06/04/gnss-firehose/ ) or the other
existing GNSS SDR receivers: The device samples some bandpass around
the relevant GNSS frequency(/ies), sends a digitized signal for you to
despread and track.

2bits * 4ch * 20MHz * 2 (nyquist) = 320Mbit/sec, no big deal for
gigabit ethernet or USB3 (or even USB2 for that matter, at least
ignoring overheads).

but from that setup you can't easily produce a PPS signal-- the host
will operate asynchronously with the signal, with lots of delay and
jitter.

I've long though a better design for a GPSDO is instead of having the
GPS produce a PPS, you have the GPS contain a TIC and feed it a PPS,
and capture those timestamps along with the gps observations.  The GPS
solution would then also include the observed offset.  Beyond
eliminating the extra complexity of sawtooth correction, this could
produce better results under some signal conditions because averaging
error signal produced from single fixes will not always produce the
same result as running a larger model over more observations (because
the errors can be multimodal). (besides-- for precise timing against
an local atomic standard... you probably don't want to perturb the
local clock, but instead track corrections to some reference time.)

In either case (PPS out or PPS in) I believe some actual hardware
support is needed to tie the PPS pulses to the GPS sampling clock, in
any of these SDR GPS approaches... though I think not much.

HI

Except if you look at the actual clock rates they show for the samplers, they
are talking about rates that are closer to 100 MHz than to 50 MHz.  That’s just
the raw data before you stuff AGC info and all the rest of the junk into the data stream.

Bob