time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

WWV receivers?

HM
Hal Murray
Wed, Oct 26, 2016 6:54 AM

I'm all for a diversity of systems - putting all our eggs in the GPS basket
seems unwise (and I maintain WWV receivers hooked to NTP at home!)

What is available in the way of WWV receivers?  Anybody got a summary handy?

--
These are my opinions.  I hate spam.

tshoppa@gmail.com said: > I'm all for a diversity of systems - putting all our eggs in the GPS basket > seems unwise (and I maintain WWV receivers hooked to NTP at home!) What is available in the way of WWV receivers? Anybody got a summary handy? -- These are my opinions. I hate spam.
RN
Ruslan Nabioullin
Wed, Oct 26, 2016 10:11 AM

On 10/26/2016 02:54 AM, Hal Murray wrote:

I'm all for a diversity of systems - putting all our eggs in the GPS basket
seems unwise (and I maintain WWV receivers hooked to NTP at home!)

What is available in the way of WWV receivers?  Anybody got a summary handy?

Yes, diversity is generally good, as it is in a sociological context.
Despite being such a ubiquitous and critical system in all domains,
military and civilian, US and foreign, and therefore being a recipient
of extensive funding and R&D, it is a high-profile target to adversaries
by means of anti-satellite weapons, cyberattacks, ground segment
attacks, and jamming; additionally, the constellation is subject to the
natural threats that all satellites face, and the system is controlled
by a homogeneous structure of human entities, which reserve the right to
deny coverage to a subset (typically hotspots in times of conflict).  It
was a goal of my time metrology project, so I did do research in this
area, expecting to use CHU (which also adds political diversity, for
then it would be US [GPS] and Canada [CHU]) and maybe also WWV, but I
abandoned the idea in favor of allocating the bulk of the budget to
procurement of equipment and supporting equipment for my own house
standard by means of a rubidium ensemble.

Yes, standalone WWV receivers of course do exist; if one wishes to go
this route, the only practical means is by purchasing one of those
ancient (late 70s era probably) Systron Donner time code generator units
off eBay, which you'll notice has a BNC port on the back for an HF
antenna (or just the audio feed---who knows?  Documentation is scarce).
However, unless you need WWV-derived PPS, this approach is greatly
suboptimal; the best approach would be to find your desired HF
receiver(s) and connect them via sound card(s) to the NTP server(s),
using the WWV module (and/or CHU).  Besides the unknowns resulting from
documentation scarcity, this approach brings flexibility and the
benefits of the ``less is more'' philosophy, for you gain: the freedom
to decide what models of equipment to incorporate; flexibility in
channels (you can also do CHU, and even within WWV you can do 2.5, 5,
10, 15, and/or 20 MHz); and avoidance of obsolescence---remember, you're
relying on some human entity's signal, who in this case of a
seemingly-unpopular (at least nowadays) signal is under little
obligation to preserve the characteristics and even presence of such a
signal---look at what happened with the WWVB signal change, which
effectively rendered what were once nice standard frequency WWVB
receivers into paperweights.

For the radio, the best overall approach might be using $32 or so
RTL-SDRs which feature a case.  However, the reception quality of these
units is not so great, the DSP might overwhelm low-power and embedded
servers, and there might be latency issues; I'm not familiar enough with
SDRs to state for sure.  Another cheap approach is to simply use $12 or
so, incl. shipping, handheld HF receivers, though from past experience
the reception quality of them is absolutely awful and they are portable,
consumer-grade devices, meaning that there's no antenna BNC port, there
might be no power input apart from the terminals in the battery
compartment, and there are no means of elegantly rack-mounting them.  A
more costly approach is to use a general-purpose HF receiver (like
typical Icom or Yaesu units that typical amateur radio operators use) or
a professional HF receiver; unfortunately one is very limited in the
latter, which consists of, in ascending order of price: HP 3586C (a
measuring receiver actually), Ten-Tec (from the research I have done, is
generally similar to Watkins Johnson [WJ], but lacks high-reliability
specifications), and WJ.

For the sound card, it has been reported that those cheap Chinese USB
sound cards, costing <$2 each incl. shipping, are adequate; I actually
ordered a quantity-discounted lot of 5 or so of the popular variant
which contains status LEDs before changing plans, so that's the best
approach if you wish to use multiple sources or servers.

Note that for high-reliability setups, one must factor in potential
service degradation caused by civil unrest or remote equipment failure,
such as reduced station power output due to electricity shortages, loss
of some channels, or jamming by adversaries.

-Ruslan

On 10/26/2016 02:54 AM, Hal Murray wrote: > > tshoppa@gmail.com said: >> I'm all for a diversity of systems - putting all our eggs in the GPS basket >> seems unwise (and I maintain WWV receivers hooked to NTP at home!) > > What is available in the way of WWV receivers? Anybody got a summary handy? Yes, diversity is generally good, as it is in a sociological context. Despite being such a ubiquitous and critical system in all domains, military and civilian, US and foreign, and therefore being a recipient of extensive funding and R&D, it is a high-profile target to adversaries by means of anti-satellite weapons, cyberattacks, ground segment attacks, and jamming; additionally, the constellation is subject to the natural threats that all satellites face, and the system is controlled by a homogeneous structure of human entities, which reserve the right to deny coverage to a subset (typically hotspots in times of conflict). It was a goal of my time metrology project, so I did do research in this area, expecting to use CHU (which also adds political diversity, for then it would be US [GPS] and Canada [CHU]) and maybe also WWV, but I abandoned the idea in favor of allocating the bulk of the budget to procurement of equipment and supporting equipment for my own house standard by means of a rubidium ensemble. Yes, standalone WWV receivers of course do exist; if one wishes to go this route, the only practical means is by purchasing one of those ancient (late 70s era probably) Systron Donner time code generator units off eBay, which you'll notice has a BNC port on the back for an HF antenna (or just the audio feed---who knows? Documentation is scarce). However, unless you need WWV-derived PPS, this approach is *greatly* suboptimal; the best approach would be to find your desired HF receiver(s) and connect them via sound card(s) to the NTP server(s), using the WWV module (and/or CHU). Besides the unknowns resulting from documentation scarcity, this approach brings flexibility and the benefits of the ``less is more'' philosophy, for you gain: the freedom to decide what models of equipment to incorporate; flexibility in channels (you can also do CHU, and even within WWV you can do 2.5, 5, 10, 15, and/or 20 MHz); and avoidance of obsolescence---remember, you're relying on some human entity's signal, who in this case of a seemingly-unpopular (at least nowadays) signal is under little obligation to preserve the characteristics and even presence of such a signal---look at what happened with the WWVB signal change, which effectively rendered what were once nice standard frequency WWVB receivers into paperweights. For the radio, the best overall approach might be using $32 or so RTL-SDRs which feature a case. However, the reception quality of these units is not so great, the DSP might overwhelm low-power and embedded servers, and there might be latency issues; I'm not familiar enough with SDRs to state for sure. Another cheap approach is to simply use $12 or so, incl. shipping, handheld HF receivers, though from past experience the reception quality of them is absolutely awful and they are portable, consumer-grade devices, meaning that there's no antenna BNC port, there might be no power input apart from the terminals in the battery compartment, and there are no means of elegantly rack-mounting them. A more costly approach is to use a general-purpose HF receiver (like typical Icom or Yaesu units that typical amateur radio operators use) or a professional HF receiver; unfortunately one is very limited in the latter, which consists of, in ascending order of price: HP 3586C (a measuring receiver actually), Ten-Tec (from the research I have done, is generally similar to Watkins Johnson [WJ], but lacks high-reliability specifications), and WJ. For the sound card, it has been reported that those cheap Chinese USB sound cards, costing <$2 each incl. shipping, are adequate; I actually ordered a quantity-discounted lot of 5 or so of the popular variant which contains status LEDs before changing plans, so that's the best approach if you wish to use multiple sources or servers. Note that for high-reliability setups, one must factor in potential service degradation caused by civil unrest or remote equipment failure, such as reduced station power output due to electricity shortages, loss of some channels, or jamming by adversaries. -Ruslan
NS
Nick Sayer
Wed, Oct 26, 2016 12:46 PM

If you’re in North America, a CHU receiver is a lot easier to make than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a one-chip solution 20 years ago when I made one in college. On the software side, you’ll want a serial line discipline kernel module of some sort that timestamps the incoming characters. The result is as good as HF radio will get you, which is to say probably 2 or 3 orders of magnitude minimum worse than GPS.

IMHO the diversity of which you speak is exactly what NTP delivers. I believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks with Cesium clocks could conceivably do the same to provide independent standards.

On Oct 25, 2016, at 11:54 PM, Hal Murray hmurray@megapathdsl.net wrote:

tshoppa@gmail.com said:

I'm all for a diversity of systems - putting all our eggs in the GPS basket
seems unwise (and I maintain WWV receivers hooked to NTP at home!)

What is available in the way of WWV receivers?  Anybody got a summary handy?

--
These are my opinions.  I hate spam.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

If you’re in North America, a CHU receiver is a lot easier to make than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a one-chip solution 20 years ago when I made one in college. On the software side, you’ll want a serial line discipline kernel module of some sort that timestamps the incoming characters. The result is as good as HF radio will get you, which is to say probably 2 or 3 orders of magnitude minimum worse than GPS. IMHO the diversity of which you speak is exactly what NTP delivers. I believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks with Cesium clocks could conceivably do the same to provide independent standards. > On Oct 25, 2016, at 11:54 PM, Hal Murray <hmurray@megapathdsl.net> wrote: > > > tshoppa@gmail.com said: >> I'm all for a diversity of systems - putting all our eggs in the GPS basket >> seems unwise (and I maintain WWV receivers hooked to NTP at home!) > > What is available in the way of WWV receivers? Anybody got a summary handy? > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
CA
Chris Albertson
Wed, Oct 26, 2016 5:05 PM

I started to set up a WWV based reference clock.  As for a receiver SDR is
the best way to go but I built a tunnel front end.  It is easy to do
because it needs to only work at ne specify frequency so you can use a
crystal filter with norrow bandwidth.  The SDR receiver did direct
conversion that sampled in quadrature using a stereo sound card type
interface.  I disagree that even the cheap sound cards are good enough.
Get one that does 24-bit sample because they have enough dynamic range so
they can still work without a human operator tuning a gain knob.

The part I did not do was to modify the NTP reference clock drivers to
accept audio feed from Jack Audio.  This would allow internal software to
route audio between applications and not have to use multiple sound cards
and analog cables which seems silly.

Other projects came up and I figure it the world ends and the Internet goes
dark and GPS fails I can still know what time it is by watching the sun set
over the ocean every day.

Actually I've disconnected the GPS from my NTP server and notice only a 5
millisecond error on average using just pool servers

On Wed, Oct 26, 2016 at 5:46 AM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

If you’re in North America, a CHU receiver is a lot easier to make than
WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a
one-chip solution 20 years ago when I made one in college. On the software
side, you’ll want a serial line discipline kernel module of some sort that
timestamps the incoming characters. The result is as good as HF radio will
get you, which is to say probably 2 or 3 orders of magnitude minimum worse
than GPS.

IMHO the diversity of which you speak is exactly what NTP delivers. I
believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks
with Cesium clocks could conceivably do the same to provide independent
standards.

On Oct 25, 2016, at 11:54 PM, Hal Murray hmurray@megapathdsl.net

wrote:

I'm all for a diversity of systems - putting all our eggs in the GPS

basket

seems unwise (and I maintain WWV receivers hooked to NTP at home!)

What is available in the way of WWV receivers?  Anybody got a summary

handy?

--
These are my opinions.  I hate spam.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

and follow the instructions there.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

--

Chris Albertson
Redondo Beach, California

I started to set up a WWV based reference clock. As for a receiver SDR is the best way to go but I built a tunnel front end. It is easy to do because it needs to only work at ne specify frequency so you can use a crystal filter with norrow bandwidth. The SDR receiver did direct conversion that sampled in quadrature using a stereo sound card type interface. I disagree that even the cheap sound cards are good enough. Get one that does 24-bit sample because they have enough dynamic range so they can still work without a human operator tuning a gain knob. The part I did not do was to modify the NTP reference clock drivers to accept audio feed from Jack Audio. This would allow internal software to route audio between applications and not have to use multiple sound cards and analog cables which seems silly. Other projects came up and I figure it the world ends and the Internet goes dark and GPS fails I can still know what time it is by watching the sun set over the ocean every day. Actually I've disconnected the GPS from my NTP server and notice only a 5 millisecond error on average using just pool servers On Wed, Oct 26, 2016 at 5:46 AM, Nick Sayer via time-nuts < time-nuts@febo.com> wrote: > If you’re in North America, a CHU receiver is a lot easier to make than > WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - it was a > one-chip solution 20 years ago when I made one in college. On the software > side, you’ll want a serial line discipline kernel module of some sort that > timestamps the incoming characters. The result is as good as HF radio will > get you, which is to say probably 2 or 3 orders of magnitude minimum worse > than GPS. > > IMHO the diversity of which you speak is exactly what NTP delivers. I > believe NIST and USNO run NTP servers that aren’t sourced from GPS. Folks > with Cesium clocks could conceivably do the same to provide independent > standards. > > > On Oct 25, 2016, at 11:54 PM, Hal Murray <hmurray@megapathdsl.net> > wrote: > > > > > > tshoppa@gmail.com said: > >> I'm all for a diversity of systems - putting all our eggs in the GPS > basket > >> seems unwise (and I maintain WWV receivers hooked to NTP at home!) > > > > What is available in the way of WWV receivers? Anybody got a summary > handy? > > > > > > -- > > These are my opinions. I hate spam. > > > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California
PK
Poul-Henning Kamp
Thu, Oct 27, 2016 7:20 AM

In message 5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com, Nick Sayer via time-
nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

-------- In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer via time- nuts writes: >If you’re in North America, a CHU receiver is a lot easier to make >than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - >it was a one-chip solution 20 years ago when I made one in college. We have CPUs and sounds-cards these days... Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF station you want: You can track GPS and four (possibly 8) VLF/HF stations at the same time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
NS
Nick Sayer
Sat, Oct 29, 2016 5:36 AM

That single-chip version is going to have a LOT less (and less variable) latency than an SDR.

On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:


In message 5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com, Nick Sayer via time-
nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR. > On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer via time- > nuts writes: > >> If you’re in North America, a CHU receiver is a lot easier to make >> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - >> it was a one-chip solution 20 years ago when I made one in college. > > We have CPUs and sounds-cards these days... > > Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF > station you want: You can track GPS and four (possibly 8) VLF/HF > stations at the same time. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.
BC
Bob Camp
Sat, Oct 29, 2016 1:03 PM

Hi

Let’s see…. WWV (not WWVB) gets here via a variety of propagation mechanisms
that vary over the day. According to NIST (who probably know :) that puts a random timing
variation of ~1 ms on the signal. Since some modes get me a signal and others don’t, there
is no real reason to assume it is random. It can easily be an offset that varies month to month.

Net result, forget about the chip delays. The signal already has a bunch of built in variability
that will swamp anything in the silicon.

https://www.nist.gov/pml/time-and-frequency-division/nist-radio-broadcasts-frequently-asked-questions-faq

Also in the same data is the fact that the “as transmitted” signal is good to 100 ns. That’s plenty good
enough for the system as described. It also is a pretty modest number for a GPS timing module. One
would guess that the number is a bit better than 100 ns (it is NIST after all). It also does not directly
compare to the GPS number since there are UTC offset numbers there as well. Bottom line is that
there inevitably are numbers like that buried in the system once you get past the 1 ms.

Bob

On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts time-nuts@febo.com wrote:

That single-chip version is going to have a LOT less (and less variable) latency than an SDR.

On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:


In message 5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com, Nick Sayer via time-
nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi Let’s see…. WWV (not WWVB) gets here via a variety of propagation mechanisms that vary over the day. According to NIST (who probably know :) that puts a random timing variation of ~1 ms on the signal. Since some modes get me a signal and others don’t, there is no real reason to assume it is random. It can easily be an offset that varies month to month. Net result, forget about the chip delays. The signal already has a bunch of built in variability that will swamp anything in the silicon. https://www.nist.gov/pml/time-and-frequency-division/nist-radio-broadcasts-frequently-asked-questions-faq Also in the same data is the fact that the “as transmitted” signal is good to 100 ns. That’s plenty good enough for the system as described. It also is a pretty modest number for a GPS timing module. One would guess that the number is a bit better than 100 ns (it is NIST after all). It also does not directly compare to the GPS number since there are UTC offset numbers there as well. Bottom line is that there inevitably *are* numbers like that buried in the system once you get past the 1 ms. Bob > On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts <time-nuts@febo.com> wrote: > > That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR. > >> On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> >> -------- >> In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer via time- >> nuts writes: >> >>> If you’re in North America, a CHU receiver is a lot easier to make >>> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - >>> it was a one-chip solution 20 years ago when I made one in college. >> >> We have CPUs and sounds-cards these days... >> >> Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF >> station you want: You can track GPS and four (possibly 8) VLF/HF >> stations at the same time. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> phk@FreeBSD.ORG | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
PS
paul swed
Sat, Oct 29, 2016 2:15 PM

Good thread. Thanks for the clue on the kiwiSDR. I went to the sites and
lots of fun playing with the receivers. As an example hearing LORAN C in
the Asia region.
Certainly seems the receiver is pretty sensitive and capable. Went hunting
for various low frequency timing signals such as JJY and the submarine
crusher signals. All were heard.
I agree with Bobs comments that the signal at WWV range can be all over the
place and though seasonal effects can be a somewhat accounted for the
reality is, its still pretty random. The changes can occur slowly or
rapidly.
Regards
Paul
WB8TSL

On Sat, Oct 29, 2016 at 9:03 AM, Bob Camp kb8tq@n1k.org wrote:

Hi

Let’s see…. WWV (not WWVB) gets here via a variety of propagation
mechanisms
that vary over the day. According to NIST (who probably know :) that puts
a random timing
variation of ~1 ms on the signal. Since some modes get me a signal and
others don’t, there
is no real reason to assume it is random. It can easily be an offset that
varies month to month.

Net result, forget about the chip delays. The signal already has a bunch
of built in variability
that will swamp anything in the silicon.

https://www.nist.gov/pml/time-and-frequency-division/nist-
radio-broadcasts-frequently-asked-questions-faq

Also in the same data is the fact that the “as transmitted” signal is good
to 100 ns. That’s plenty good
enough for the system as described. It also is a pretty modest number for
a GPS timing module. One
would guess that the number is a bit better than 100 ns (it is NIST after
all). It also does not directly
compare to the GPS number since there are UTC offset numbers there as
well. Bottom line is that
there inevitably are numbers like that buried in the system once you get
past the 1 ms.

Bob

On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts <

That single-chip version is going to have a LOT less (and less

variable) latency than an SDR.

On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp phk@phk.freebsd.dk

wrote:

via time-

nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by

incompetence.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

and follow the instructions there.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

Good thread. Thanks for the clue on the kiwiSDR. I went to the sites and lots of fun playing with the receivers. As an example hearing LORAN C in the Asia region. Certainly seems the receiver is pretty sensitive and capable. Went hunting for various low frequency timing signals such as JJY and the submarine crusher signals. All were heard. I agree with Bobs comments that the signal at WWV range can be all over the place and though seasonal effects can be a somewhat accounted for the reality is, its still pretty random. The changes can occur slowly or rapidly. Regards Paul WB8TSL On Sat, Oct 29, 2016 at 9:03 AM, Bob Camp <kb8tq@n1k.org> wrote: > Hi > > Let’s see…. WWV (not WWVB) gets here via a variety of propagation > mechanisms > that vary over the day. According to NIST (who probably know :) that puts > a random timing > variation of ~1 ms on the signal. Since some modes get me a signal and > others don’t, there > is no real reason to assume it is random. It can easily be an offset that > varies month to month. > > Net result, forget about the chip delays. The signal already has a bunch > of built in variability > that will swamp anything in the silicon. > > https://www.nist.gov/pml/time-and-frequency-division/nist- > radio-broadcasts-frequently-asked-questions-faq > > Also in the same data is the fact that the “as transmitted” signal is good > to 100 ns. That’s plenty good > enough for the system as described. It also is a pretty modest number for > a GPS timing module. One > would guess that the number is a bit better than 100 ns (it is NIST after > all). It also does not directly > compare to the GPS number since there are UTC offset numbers there as > well. Bottom line is that > there inevitably *are* numbers like that buried in the system once you get > past the 1 ms. > > Bob > > > On Oct 29, 2016, at 1:36 AM, Nick Sayer via time-nuts < > time-nuts@febo.com> wrote: > > > > That single-chip version is going to have a *LOT* less (and less > variable) latency than an SDR. > > > >> On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > >> > >> -------- > >> In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer > via time- > >> nuts writes: > >> > >>> If you’re in North America, a CHU receiver is a lot easier to make > >>> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - > >>> it was a one-chip solution 20 years ago when I made one in college. > >> > >> We have CPUs and sounds-cards these days... > >> > >> Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF > >> station you want: You can track GPS and four (possibly 8) VLF/HF > >> stations at the same time. > >> > >> -- > >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > >> phk@FreeBSD.ORG | TCP/IP since RFC 956 > >> FreeBSD committer | BSD since 4.3-tahoe > >> Never attribute to malice what can adequately be explained by > incompetence. > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >
CA
Chris Albertson
Sat, Oct 29, 2016 6:21 PM

Are you sure the single chip receiver is not itself an SDR?  Maybe using a
little 8-bit uP inside?  I don't know.

In any case the jitter on the SDR depends on the sample rate clock.  If you
use a decent audio interface the clocks are not bad.  A little 4-pin
crystal oscillator controls the sampling.  Compared to the propagation
delay the quality of that crystal is a not a big deal.

On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

That single-chip version is going to have a LOT less (and less variable)
latency than an SDR.

On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp phk@phk.freebsd.dk

wrote:

via time-

nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by

incompetence.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

--

Chris Albertson
Redondo Beach, California

Are you sure the single chip receiver is not itself an SDR? Maybe using a little 8-bit uP inside? I don't know. In any case the jitter on the SDR depends on the sample rate clock. If you use a decent audio interface the clocks are not bad. A little 4-pin crystal oscillator controls the sampling. Compared to the propagation delay the quality of that crystal is a not a big deal. On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts < time-nuts@febo.com> wrote: > That single-chip version is going to have a *LOT* less (and less variable) > latency than an SDR. > > > On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > > > > -------- > > In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer > via time- > > nuts writes: > > > >> If you’re in North America, a CHU receiver is a lot easier to make > >> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - > >> it was a one-chip solution 20 years ago when I made one in college. > > > > We have CPUs and sounds-cards these days... > > > > Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF > > station you want: You can track GPS and four (possibly 8) VLF/HF > > stations at the same time. > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by > incompetence. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California
NS
Nick Sayer
Sat, Oct 29, 2016 7:25 PM

No, no, no.

The single chip in this case is an AFSK decoder. You still have to have an ordinary HF AM radio.

On Oct 29, 2016, at 11:21 AM, Chris Albertson albertson.chris@gmail.com wrote:

Are you sure the single chip receiver is not itself an SDR?  Maybe using a little 8-bit uP inside?  I don't know.

In any case the jitter on the SDR depends on the sample rate clock.  If you use a decent audio interface the clocks are not bad.  A little 4-pin crystal oscillator controls the sampling.  Compared to the propagation delay the quality of that crystal is a not a big deal.

On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts <time-nuts@febo.com mailto:time-nuts@febo.com> wrote:
That single-chip version is going to have a LOT less (and less variable) latency than an SDR.

On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk mailto:phk@phk.freebsd.dk> wrote:


In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com mailto:5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>, Nick Sayer via time-
nuts writes:

If you’re in North America, a CHU receiver is a lot easier to make
than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud -
it was a one-chip solution 20 years ago when I made one in college.

We have CPUs and sounds-cards these days...

Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF
station you want:  You can track GPS and four (possibly 8) VLF/HF
stations at the same time.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


time-nuts mailing list -- time-nuts@febo.com mailto:time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--

Chris Albertson
Redondo Beach, California

No, no, no. The single chip in this case is an AFSK decoder. You still have to have an ordinary HF AM radio. > On Oct 29, 2016, at 11:21 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > > Are you sure the single chip receiver is not itself an SDR? Maybe using a little 8-bit uP inside? I don't know. > > In any case the jitter on the SDR depends on the sample rate clock. If you use a decent audio interface the clocks are not bad. A little 4-pin crystal oscillator controls the sampling. Compared to the propagation delay the quality of that crystal is a not a big deal. > > On Fri, Oct 28, 2016 at 10:36 PM, Nick Sayer via time-nuts <time-nuts@febo.com <mailto:time-nuts@febo.com>> wrote: > That single-chip version is going to have a *LOT* less (and less variable) latency than an SDR. > > > On Oct 27, 2016, at 12:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk <mailto:phk@phk.freebsd.dk>> wrote: > > > > -------- > > In message <5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com <mailto:5A002554-8D90-4C75-95DA-21DB45D61E95@kfu.com>>, Nick Sayer via time- > > nuts writes: > > > >> If you’re in North America, a CHU receiver is a lot easier to make > >> than WWV/WWVH. The CHU timecode is just BEL 103 AFSK at 300 baud - > >> it was a one-chip solution 20 years ago when I made one in college. > > > > We have CPUs and sounds-cards these days... > > > > Also: The KiwiSDR is nearly perfect hardware, no matter which VLF/HF > > station you want: You can track GPS and four (possibly 8) VLF/HF > > stations at the same time. > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@febo.com> > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts> > and follow the instructions there. > > > > -- > > Chris Albertson > Redondo Beach, California