Reference clocks.

[Dan Poirot]

TL;DR

TOTALLY distracted by this:
	https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
	http://rtlsdr.org/start 
	https://www.reddit.com/r/RTLSDR/wiki/compatibility 


What is it that you CAN'T do with a USB stick these days...

- dan



-----Original Message-----
From: devel [mailto:devel-bounces at ntpsec.org] On Behalf Of Amar Takhar
Sent: Friday, April 08, 2016 3:30 PM
To: Hal Murray <hmurray at megapathdsl.net>
Cc: devel at ntpsec.org
Subject: Re: Reference clocks.

On 2016-04-08 13:20 -0700, Hal Murray wrote:
> 
> verm at darkbeer.org said:
> > OK that's good news at least.  I haven't looked into many of the 
> > refclock drivers.  Thanks for the info.
> 
> Keep in mind that many of the drivers have sub-drivers or modes.

Right, I will use code coverage to ensure we're covering all the possible
paths.


> The obvious example is the parse driver which is an umbrella for 
> several drivers.

Yes, just having one of those will cover much of the code.


> The Palisade driver has several modes to support different
hardware/firmware.

It's going to depend on how much unreached code there is it may be OK to
just use one for now.


> The NMEA driver can use the PPS or not.  If it is using PPS, it's hard to 
> tell how well the serial port is working.  Mumble.

I wonder how will this will work using the PPS via GPIO system I'm working
on.  
Should be fine and it should be far, far more reliable than serial.


Another method to get a lot of code coverage is to write shims between each 
driver and a general time interface so we can mock the API for each device.
Not 
sure how feasible that is as some of them are radically different.  May not
be 
worth it at all in the end.


Amar.
_______________________________________________
devel mailing list
devel at ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel