[time-nuts] NUT4NT: Four-channel All-frequency GNSS RF-to-Bits

[Bob Camp]

HI

> On Aug 13, 2016, at 8:32 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 
> On Sat, Aug 13, 2016 at 11:53 PM, Bob Camp <kb8tq at n1k.org> 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.
> 
> 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).


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

> 
> From there you can have arbitrarily complex processing on the host--
> 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.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.