Having a diversity of refclocks is important for any real NTP
implementation. There is a strong tendency towards a GPS monoculture and
the implementers must work against it.

Support for WWV in ntpd using the wwv_audio refclock is very good and
delivers jitters substantially less than a millisecond. I have been using
this for over a decade.

ntpd also supports CHU.

Here is a recent article showing how to use the BPSK format of WWVB:
http://www.arrl.org/files/file/QEX_Next_Issue/2015/Nov-Dec_2015/Magliacane.pdf

Tim N3QE

On Sun, Feb 28, 2016 at 2:09 AM, Sanjeev Gupta ghane0@gmail.com wrote:

Hi

Ok, I think we have a bit of a terminology issue here.

The new WWVB format is troublesome for older gear that looks at carrier
phase as a source of precision timing. The NTP driver does not do this.

The new WWVB format is fine for any gear that recovers time from the
AM modulation on the carrier. This is what the NTP driver does do.

Simply put - WWVB and NTP work just as well today as they did 20 years
ago.

As a “future project”, adding a driver to NTP to work with the bitstream from
the new phase modulation would be a nice thing. At the moment the number
of receivers capable of handling this modulation is pretty small. I would
wait until there is at least one commercial product on the market before
a driver is written.

Bob

On Sun, Feb 28, 2016 at 9:45 PM, Tim Shoppa tshoppa@gmail.com wrote:

Thank you.  In particular, WWV, as compared to WWVB.

Is there an on-web reference that I can document, so that the NTPSec
developers can decide on if and how to support WWV.

--
Sanjeev Gupta
+65 98551208    http://www.linkedin.com/in/ghane

On Sun, Feb 28, 2016 at 10:57 PM, Bob Camp kb8tq@n1k.org wrote:

This is a very clear phrasing, thanks.

My understanding is that existing commercially-available equipment that
recovers time from the AM carrier provides an accuracy on the order of a
milli-second.  Anything better required tracking phase.

So, what would the (NTP with current WWVB equipment) accuracy and jitter be?

I appreciate that we seem to be moving towards a GPS-monoculture, but how
close is the (NTP with WWVB AM) to the 50 microseconds number?

--
Sanjeev Gupta
+65 98551208    http://www.linkedin.com/in/ghane

On Sun, Feb 28, 2016 at 03:09:32PM +0800, Sanjeev Gupta wrote:

I'm not sure I would make that assumption.  Given recent attacks

on NTP (that will ultimately require a new protocol to fix), the ability
of more upstream references is better than fewer.

Stripping things out that would provide more sources of trusted

time appears to be at odds with making NTP "more secure."

So the common, cheaper receivers that just looked at the AM 

envelope are unaffected.  Higher grade, phase tracking receivers were
affected, but can be modified to restore the carrier, and thus are
still operable.

WWV and WWVH have worked pretty much the same way they do now

for decades; I have running WWV and WWVH refclocks, even the TrueTime
TL_3 (in REFCLOCK_TRUE.)

Where this gets sticky is there is support for older receivers

(say, OMEGA and the like), in the same refclocks (continuing to use
TRUE as an example here.)

So, you could safely remove the bits pertaining to OMEGA, but

I'd retain the WWV, WWVB, TCU, and XL-DC support.)  Since the XL-DC
is a GPS, I suppose you could implement support for it in gpsd.

Other, older refclocks are in a similar state, where one

vendor used more or less the same serial protocol regardless of
what the actual reference was.

What are you trying to do?  Kill the refclocks entirely, or

just pare them down to essentials?

Cheers,

--msa 

Sanjeev Gupta <ghane0@...> writes:

In fact, the new scheme may actually help with accurate ON-TIME
determination.  Currently, I have a proof-of-concept research system
running that routinely keeps time to well within the rather broad 100 uS
range when compared to GPS. This system does not yet use the phase
information, but uses other techniques to extract the ON-TIME information
from the signal (which still has to be corrected for propagation delays.)
Future work will include using the phase information and I am confident
this will only improve the results.

signals,

While the proof-of-concept system is not being used for a refclock for
NTP, it is able to keep time as described above and FREQUENCY to the under
1 E-10 range. I am still working to improve that and hope to verify it in
a way directly traceable to NIST.

James Flynn
California State University Northridge

On 2/28/16 7:07 AM, Sanjeev Gupta wrote:

What you're looking at (unless you're very close to WWV or WWVH) is the
uncertainty in the skywave path through the ionosphere.

A reference to what WWV radiates as a signal?
http://www.nist.gov/pml/div688/grp40/wwv.cfm

http://tf.nist.gov/general/pdf/1383.pdf

On Sun, Feb 28, 2016 at 2:09 AM, Sanjeev Gupta ghane0@gmail.com wrote:

I'm a bit confused by your question and the responses.

There are (I believe) three audio drivers supporting WWV, CHU and IRIG.
These drivers are receiver agnostic.  If you can get audio they work.  The
documented accuracy for WWV is within 1 millisecond of the time pulse.

There are multiple drivers supporting WWV/CHU/DCF.  These are for specific
families of RF receivers which produce a digital stream of some sort (e.g.
ISA bus communication).

Presumably the latter are what you're looking at as obsolete (e.g.
Truetime, Traconix, Chronolog, Ultralink etc. [and my apologies if any of
these are not obsolete]).

Perhaps you could clarify your intent.

Hi

WWVB and WWV (like any radio uncorrected radio system) has fairly predictable shifts
associated with the day / night ionosphere. One could fix that issue with a table
based on station location. I do not know of any library of code that does that already.

The next “layer” of trouble comes from how the low cost receivers are implemented. The
common issue is local noise. The common solution is a narrowband crystal filter in front
of the receiver. The bandwidth of that filter (and to some extent it’s temperature dependance) place
a “best case” limit on performance in the 10’s to 100’s of ms range depending on the
exact details. There are higher performance receivers (but not a lot of them) that do get into
the single digit ms range. At that point the propagation issue mentioned above needs some
work.

Further complicating things is the distance factor. A user in Denver with ground wave “view”
of the transmitter will do much better than the numbers above. A user in Miami or Bangor ME
may be very lucky to get close to the numbers above on an intermittent basis.

For time transfer, you have “carrier phase ambiguity” due to the day night propagation shifts. Simply
put the time delay to the transmitter caused the received signal to vary by more than one cycle. That
makes it a less than ideal source of time. For precision use, a WWVB system often does a
carrier measure at a single time per day. The phase data is averaged over may days to make
a precision estimate. This works ok for a frequency based (think GPSDO) type system). For autonomous
timing it’s not a practical solution.

Bob