Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)
Forgot to Cc: the maillist, sorry. So, FYI:
---------- Forwarded message ----------
Date: Thu, 15 Mar 2012 16:31:14 +0100 (CET)
From: Marek Peca marek@duch.cz
To: David J Taylor david-taylor@blueyonder.co.uk
Subject: Re: [time-nuts] WWVB BPSK Receiver Project?
Hello,
I would perhaps be interested in something which would pick up our local 60
KHz transmissions, and having a USB interface would be OK. However, all my
systems are Windows, so whatever software was produced would have to work on
Windows.
Of course I mean it should pick your 60kHz, as well as other systems known to
me: Japanese 40kHz, 60kHz, Swiss 75kHz, British 60kHz and possibly others.
Highly unsure about Russian 25kHz, even do not know, whether it is still on
air.
Yes, it should work on any USB audio capable OS, ie. Linux, Windows, MacOS etc.
I take it that you are thinking of all the detection and processing in the
PC? I would prefer as much processing as possible to be in the device, and
that it perhaps output serial data over the USB port, looking like a GPS. Is
that too much to ask?
Well, I will tell you, what I would like to do in larger picture:
- first, deliver simple USB audio sampling unit with 77.5kHz-proven ferrite
rod preamplifier, ready to work with 40..80kHz signals at least;
every processing within PC / Gnuradio framework;
BUT
- be ready to upgrade a firmware of the board to do all the PRBS BPSK tracking
etc. within the board's MCU and deliver at least 1pps output, preferably also
sinewave LF-locked output (range 100kHz..1MHz) for further processing.
So, I mean, the board will work in PC-based SDR mode in first iteration, and
after all the processing will be proven by multiple users, we can then switch
to better firmware, which will do basic tasks even without the PC.
I think I can provide basic firmware by myself, for more elaborate things it
seems to me the best solution is to start our common open-source project.
However, the board's MCU will accept anyone's firmware, anyway.
Please, tell me your oppinion.
I would like to know, whether to put some time into development,
so if there are really some people, who would appreciate such a
LF-SDR-USB kit.
Best regards,
Marek
On Thu, 15 Mar 2012 20:02:31 +0100 (CET)
Marek Peca marek@duch.cz wrote:
Of course I mean it should pick your 60kHz, as well as other systems known to
me: Japanese 40kHz, 60kHz, Swiss 75kHz, British 60kHz and possibly others.
Highly unsure about Russian 25kHz, even do not know, whether it is still on
air.
HBG has been switched of earlier this year. So DCF77 and Alison are the
only time LF senders left in continental europe.
- first, deliver simple USB audio sampling unit with 77.5kHz-proven ferrite
rod preamplifier, ready to work with 40..80kHz signals at least;
every processing within PC / Gnuradio framework;
After the discussion here, i had a similar idea. I want to use the
STM32F4xx for something bigger and bought two discovery boards to get
used to them. But i didn't know what i want to do... it should be something
usefull.. at least half way usefull. And the discussion here prodded
me that i could do a SDR DCF77 with that. A 160MHz 32bit uC with hardware
single precision floatingpoint is way more than fast enough to handle that :-)
If i've time, i sketch the HW this weekend and build it as soon as i've
time... And then it's just software :-)
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
On Thu, 15 Mar 2012 22:51:55 +0100
Attila Kinali attila@kinali.ch wrote:
Of course I mean it should pick your 60kHz, as well as other systems known to
me: Japanese 40kHz, 60kHz, Swiss 75kHz, British 60kHz and possibly others.
Highly unsure about Russian 25kHz, even do not know, whether it is still on
air.
HBG has been switched of earlier this year. So DCF77 and Alison are the
only time LF senders left in continental europe.
Err,, it's Allouis. Don't ask me where that Alison came from...
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
On Thu, Mar 15, 2012 at 2:51 PM, Attila Kinali attila@kinali.ch wrote:
After the discussion here, i had a similar idea. I want to use the
STM32F4xx for something bigger and bought two discovery boards to get
used to them. But i didn't know what i want to do... it should be something
usefull.. at least half way usefull. And the discussion here prodded
me that i could do a SDR DCF77 with that. A 160MHz 32bit uC with hardware
single precision floatingpoint is way more than fast enough to handle that :-
You might want to choose a platform that can run either dttsp or
Gnuradio/GRC or else you will be writing from scratch. You will spend
weeks doing what could be done in hours. Look at these
http://dttsp.sourceforge.net/
http://www.oz9aec.net/index.php/gnu-radio/grc-examples
Chris Albertson
Redondo Beach, California
In message Pine.LNX.4.64.1203152001370.3542@tesla, Marek Peca writes:
Yes, it should work on any USB audio capable OS, ie. Linux, Windows, MacOS etc.
I would like to recommend against this approach for a number of reasons.
First, yes, while you can do undersampling and such, it puts very high
requirements on your analog filters.
The reason I use 1MSPS is that it allows me to use a very sloppy low-pass
filter filter which just cuts off somewhere around 150-200 kHz, and do
everything else in software.
This means that I have no phase/group-delay distortion in the analog
part that I need to compensate in software.
It also means that I don't have to change hardware to play with different
signals, they're all there, all the time, for instance the stuff under
http://phk.freebsd.dk/Leap/
is pulled out that way.
If I, based on my design, were to design a gadget for doing VLF
time-nuts stuff, it would be:
Floating Input trafo with center-tap for powering antenna
16 bit 1MSPS ADC
ARM chip
10MHz clock input
1PPS sync input
1PPS sync output
(DAC output for {Rb|Ocxo}DO use ?)
1-4MB RAM
USB2 interface
Sending 2MB/s through a serial port profile is not a big problem
for USB2 or for that matter for an operating system, so you can
easily grap full spectrum and play with your your PC, and once you
have made some of it work, you can compile the same code and and
download it to the ARM chip, and use the serial port only for
stats/summary/(Tek4010-graphs) or you can use another USB profile
or whatever.
The ARM chip is plenty powerful to do pretty much anything you
are to on its own once you give it the code to do so.
--
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.
On Thu, 15 Mar 2012 22:27:53 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
If I, based on my design, were to design a gadget for doing VLF
time-nuts stuff, it would be:
Floating Input trafo with center-tap for powering antenna
16 bit 1MSPS ADC
ARM chip
10MHz clock input
1PPS sync input
1PPS sync output
(DAC output for {Rb|Ocxo}DO use ?)
How good would that DAC need to be?
1-4MB RAM
over a 256kB RAM it's get pretty thin if you want to stay in the uC
busines. Unless you want to use an ARM9 or better with external SDRAM
and Flash. But those are mostly BGA (very few QFP chips out there) and
they are assumed to run Linux or Windows CE on them... Support for bare
metal stuff is pretty thin.
On the other hand, if you dont have to support an OS and work on the
bare metal, you can get away with very little RAM. 128k is a damn lot
if you have to fill it with usefull data structures ;-)
USB2 interface
Which would mean you need a pretty recent chip as HighSpeed USB has not
been introduced into the uC world for more than 2 years or so.
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
On 3/15/12 3:24 PM, Chris Albertson wrote:
On Thu, Mar 15, 2012 at 2:51 PM, Attila Kinaliattila@kinali.ch wrote:
After the discussion here, i had a similar idea. I want to use the
STM32F4xx for something bigger and bought two discovery boards to get
used to them. But i didn't know what i want to do... it should be something
usefull.. at least half way usefull. And the discussion here prodded
me that i could do a SDR DCF77 with that. A 160MHz 32bit uC with hardware
single precision floatingpoint is way more than fast enough to handle that :-
You might want to choose a platform that can run either dttsp or
Gnuradio/GRC or else you will be writing from scratch. You will spend
weeks doing what could be done in hours. Look at these
http://dttsp.sourceforge.net/
documentation for dttsp is less than wonderful
seems to be a bit more diverse usage for gnuradio, so more examples and
documentation
Chris Albertson
Redondo Beach, California
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.
On 3/15/12 3:27 PM, Poul-Henning Kamp wrote:
In messagePine.LNX.4.64.1203152001370.3542@tesla, Marek Peca writes:
Yes, it should work on any USB audio capable OS, ie. Linux, Windows, MacOS etc.
I would like to recommend against this approach for a number of reasons.
First, yes, while you can do undersampling and such, it puts very high
requirements on your analog filters.
The reason I use 1MSPS is that it allows me to use a very sloppy low-pass
filter filter which just cuts off somewhere around 150-200 kHz, and do
everything else in software.
and if you have any sort of processing behind the 1MSPS, you can do a
simple digital filter and decimate.
This means that I have no phase/group-delay distortion in the analog
part that I need to compensate in software.
It also means that I don't have to change hardware to play with different
signals, they're all there, all the time, for instance the stuff under
http://phk.freebsd.dk/Leap/
is pulled out that way.
If I, based on my design, were to design a gadget for doing VLF
time-nuts stuff, it would be:
Floating Input trafo with center-tap for powering antenna
16 bit 1MSPS ADC
ARM chip
10MHz clock input
1PPS sync input
1PPS sync output
(DAC output for {Rb|Ocxo}DO use ?)
1-4MB RAM
USB2 interface
Sending 2MB/s through a serial port profile is not a big problem
for USB2 or for that matter for an operating system, so you can
easily grap full spectrum and play with your your PC, and once you
have made some of it work, you can compile the same code and and
download it to the ARM chip, and use the serial port only for
stats/summary/(Tek4010-graphs) or you can use another USB profile
or whatever.
The ARM chip is plenty powerful to do pretty much anything you
are to on its own once you give it the code to do so.
On Thu, Mar 15, 2012 at 8:45 PM, Jim Lux jimlux@earthlink.net wrote:
documentation for dttsp is less than wonderful
http://www.oz9aec.net/index.**php/gnu-radio/grc-exampleshttp://www.oz9aec.net/index.php/gnu-radio/grc-examples
seems to be a bit more diverse usage for gnuradio, so more examples and
documentation
dttsp has by far the larger in-use user based because it is the engine used
by PowerSDR by Flex Radio. It is also used by the HPSDR group. See these
links
http://www.flex-radio.com/
http://openhpsdr.org/
But you are right in that using dttsp is something that might take a long
tome to learn. The above user group tends to have many "appliance users"
and a few programers so learning is not so much of an issue
GNU Radio is popular in Universities where as soon as something works they
toss it out. It's quite a bit easier to program or if you like there is
GRC that allows visual programming. I think this is better because it
allows a wider number of people to contribute.
My suggestion to use a platform where these two libraries run was really to
say that you should not write this on bare hardware. It's a good way to
paint yourself into a corner and have to start over to add some new feature
we can't think of today.
Chris Albertson
Redondo Beach, California
On 3/15/12 9:41 PM, Chris Albertson wrote:
On Thu, Mar 15, 2012 at 8:45 PM, Jim Luxjimlux@earthlink.net wrote:
documentation for dttsp is less than wonderful
http://www.oz9aec.net/index.**php/gnu-radio/grc-exampleshttp://www.oz9aec.net/index.php/gnu-radio/grc-examples
seems to be a bit more diverse usage for gnuradio, so more examples and
documentation
dttsp has by far the larger in-use user based because it is the engine used
by PowerSDR by Flex Radio. It is also used by the HPSDR group. See these
links
http://www.flex-radio.com/
http://openhpsdr.org/
But you are right in that using dttsp is something that might take a long
tome to learn. The above user group tends to have many "appliance users"
and a few programers so learning is not so much of an issue
If there are more than half a dozen people actually using dttsp, in the
sense of modifying it, or doing something other than creating a UI for
it, I'd be pretty surprised. It's pretty much a product of the two main
authors. As you say, the learning curve is exceedingly steep,
especially if you want to understand the architecture and internal
structure. You could probably go in and do "spot changes" without
breaking too much, but any sort of radical change (like adding a new
demodulator) would be a pretty big challenge.
The fact that it's the core of PowerSDR means that over the years, it's
had a lot of customization for that particular application. Someone
trying to decode PSK WWVB isn't going to be interested in the latency of
the CW keyer or the performance of the automated notch filter.
GNU Radio is popular in Universities where as soon as something works they
toss it out. It's quite a bit easier to program or if you like there is
GRC that allows visual programming. I think this is better because it
allows a wider number of people to contribute.
it's much more "componentized" and the source of the components is broader.
Probably not as "finished" as something like PowerSDR, but much easier
to bite off small chunks.
For simple tasks, there are also tools like DL4YHF(?) spectrumlab.
http://www.qsl.net/d/dl4yhf/spectra1.html
it has:
Decoder for some time-code transmitters: MSF(60kHz), HBG(75kHz), DCF77
(77.5kHz) can now be used to set your PC clock to a high accuracy. All
you need is your longwave receiver and the soundcard.
Modulator and decoder for some 'experimental' digital communication
modes like PSK31, BPSK, QPSK, FSK, multi-tone HELL, MSK (minimum shift
keying since 2004-12), transmission and reception of letters with a
small 'terminal' window.
I've used it a lot for a variety of tasks (a Doppler radar, for one thing)
My suggestion to use a platform where these two libraries run was really to
say that you should not write this on bare hardware. It's a good way to
paint yourself into a corner and have to start over to add some new feature
we can't think of today.
Another idea, if you have access (e.g. student licenses or thru work) is
Matlab/Simulink and real-time-workshop.
All the building blocks are there, you just hook them up.
Pretty pricey if you're not in the educational bucket, though. And
Octave doesn't really have all the cool toolboxes that Matlab does.
In message 20120315234624.a2da94430a247d235ca68b4f@kinali.ch, Attila Kinali w
rites:
How good would that DAC need to be?
Depends on the level of ambition ?
1-4MB RAM
over a 256kB RAM it's get pretty thin if you want to stay in the uC
busines. Unless you want to use an ARM9 or better with external SDRAM
and Flash. But those are mostly BGA (very few QFP chips out there) and
they are assumed to run Linux or Windows CE on them... Support for bare
metal stuff is pretty thin.
There is no problem running bare-metal on ARM9's, I've done it.
But heck, it would be even better if you could load an OS on it, and
still get your bits through.
On the other hand, if you dont have to support an OS and work on the
bare metal, you can get away with very little RAM. 128k is a damn lot
if you have to fill it with usefull data structures ;-)
Well, if you want to do full-FRI averaging for a loran-chain, you need
something like 99600*2 * 4 = 800Kb. If you want to do the full-hour
averaging the WWVB doc talks about or DCF77 full-second phase-code,
you need 2 MB for just the buffer.
USB2 interface
Which would mean you need a pretty recent chip as HighSpeed USB has not
been introduced into the uC world for more than 2 years or so.
USB2, not USB3.
--
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 CABbxVHvjaXnaP-KZPn6XDUwA22LbOKFFaFh35M8u_fJUup42+A@mail.gmail.com
, Chris Albertson writes:
But you are right in that using dttsp [...] GNU Radio
If the objective here is time-nuttery, both of these are badly suited
because they are built to extract the rapidly changing information,
not for long averages of carrier phase.
--
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.
Moin!
On Fri, 16 Mar 2012 07:09:05 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message 20120315234624.a2da94430a247d235ca68b4f@kinali.ch, Attila Kinali writes:
On the other hand, if you dont have to support an OS and work on the
bare metal, you can get away with very little RAM. 128k is a damn lot
if you have to fill it with usefull data structures ;-)
Well, if you want to do full-FRI averaging for a loran-chain, you need
something like 99600*2 * 4 = 800Kb. If you want to do the full-hour
averaging the WWVB doc talks about or DCF77 full-second phase-code,
you need 2 MB for just the buffer.
Hmm... do you mean you want to store all samples of an hour and then
avarage over it? I think it would be better to just store phase offset
points for every second and then avarage over this. That would require
much less storage.
USB2 interface
Which would mean you need a pretty recent chip as HighSpeed USB has not
been introduced into the uC world for more than 2 years or so.
USB2, not USB3.
I'm not talking about SuperSpeed. USB2 support has been around for
quite some time in ARM7 class uC. But USB2 does not mean you support
a certain speed, just the data structures follow the revised standard.
Yes, USB2 introduced the HighSpeed mode (the 480Mbit/s), but below
ARM9/MIPS class CPUs it wasn't supported until about 2-3 years ago.
AFAIK the Atmel SAM3U was one of the first Cortex-M3 with HighSpeed
support available in volumes... and that was IIRC late 2009, early 2010.
And the number of uC's with HighSpeed support isn't that large yet.
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
In message 20120316085256.9e25deaeee4f7f86179891b1@kinali.ch, Attila Kinali w
rites:
Hmm... do you mean you want to store all samples of an hour and then
avarage over it?
That would be the ideal way to do it, since it would make one heck of
a comb filter and eliminate pretty much anything else.
--
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.
Hi
Could you generate a "lead" and a "lag" estimate of the signal (in addition
to your "center") and integrate against each of them on the fly? If so you
would need a lot less memory. I seem to recall you tried something like
this on the one of the Loran receivers.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Poul-Henning Kamp
Sent: Friday, March 16, 2012 4:23 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)
In message 20120316085256.9e25deaeee4f7f86179891b1@kinali.ch, Attila
Kinali w
rites:
Hmm... do you mean you want to store all samples of an hour and then
avarage over it?
That would be the ideal way to do it, since it would make one heck of
a comb filter and eliminate pretty much anything else.
--
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.
In message B8FA03DC1DD84A588A317B314A6FCB7B@vectron.com, "Bob Camp" writes:
Could you generate a "lead" and a "lag" estimate of the signal (in addition
to your "center") and integrate against each of them on the fly? If so you
would need a lot less memory. I seem to recall you tried something like
this on the one of the Loran receivers.
The reason to use the lead/center/lag model, is that you have a moving
signal you need to track, but for timenuts purposes the signal is not
going to move more than a few microseconds over an hour, so it is
probably a better strategy to just average the heck out of the signal.
It is not even clear to me that the phase-coding helps frequency
reception at all, I tried it with the very strong phase-coding of
DCF77 and there was no statistical significance relative to heavy
duty carrier averaging.
But it clearly helps a lot with phase-determination, and for that
lead/center/lag is the way to go, but you may still want to average
for a minute, then resolve the phase using the phase-modulation,
rather than run it in real-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.
Hi
One assumption is that you will indeed be capturing / averaging for several
days. I'd include some sort of model for sunrise / sunset shifts (might be
just "ignore for the next hour").
Another assumption is that your local reference is close enough and stable
enough to make a multi day average meaningful.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Poul-Henning Kamp
Sent: Friday, March 16, 2012 9:03 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)
In message B8FA03DC1DD84A588A317B314A6FCB7B@vectron.com, "Bob Camp"
writes:
Could you generate a "lead" and a "lag" estimate of the signal (in addition
to your "center") and integrate against each of them on the fly? If so you
would need a lot less memory. I seem to recall you tried something like
this on the one of the Loran receivers.
The reason to use the lead/center/lag model, is that you have a moving
signal you need to track, but for timenuts purposes the signal is not
going to move more than a few microseconds over an hour, so it is
probably a better strategy to just average the heck out of the signal.
It is not even clear to me that the phase-coding helps frequency
reception at all, I tried it with the very strong phase-coding of
DCF77 and there was no statistical significance relative to heavy
duty carrier averaging.
But it clearly helps a lot with phase-determination, and for that
lead/center/lag is the way to go, but you may still want to average
for a minute, then resolve the phase using the phase-modulation,
rather than run it in real-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.
In message 34C510BB3C6449B89AC4F7FBC20F46DA@vectron.com, "Bob Camp" writes:
One assumption is that you will indeed be capturing / averaging for several
days. I'd include some sort of model for sunrise / sunset shifts (might be
just "ignore for the next hour").
Some of my best results had 8 buffers each used for 3 hours and
all timenuttery based on 24 hour differences from these buffers.
Another assumption is that your local reference is close enough and stable
enough to make a multi day average meaningful.
Well, the above technique got me a new offset estimate every three hours
and that did a pretty good job on both OCXO and Rb disciplining.
--
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.
Hi
My main concern on short averages is the relatively long path from WWVB to
most of the target audience. The day / night phase shift is fairly
significant over a long path. That's something I would want to process out.
Since it (hopefully) is predictable, it's just another thing to feed into
the signal estimation side of the process.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Poul-Henning Kamp
Sent: Friday, March 16, 2012 12:27 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] WWVB BPSK Receiver Project? (fwd)
In message 34C510BB3C6449B89AC4F7FBC20F46DA@vectron.com, "Bob Camp"
writes:
One assumption is that you will indeed be capturing / averaging for several
days. I'd include some sort of model for sunrise / sunset shifts (might be
just "ignore for the next hour").
Some of my best results had 8 buffers each used for 3 hours and
all timenuttery based on 24 hour differences from these buffers.
Another assumption is that your local reference is close enough and stable
enough to make a multi day average meaningful.
Well, the above technique got me a new offset estimate every three hours
and that did a pretty good job on both OCXO and Rb disciplining.
--
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.
In message F8AC6C21EB1140B384332CB89B642FEF@vectron.com, "Bob Camp" writes:
My main concern on short averages is the relatively long path from WWVB to
most of the target audience. The day / night phase shift is fairly
significant over a long path.
So do I relative to DCF77 which I used for my experiments.
The point about having 8 buffers per day is that you only compare
03:00-05:59 to 03:00-05:59 the previous or the next day, so the
sun-effects almost entirely cancel out.
--
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.