Hi
Cute !!
It certainly beats firing up an R-392 to see if you can get a tick from WWV…
Bob
On Mar 11, 2018, at 5:42 PM, Tom Van Baak tvb@leapsecond.com wrote:
“Back in the day” we used WWV and the kitchen clock for that sort of thing……
Bob,
Yes, not much has changed. I use multiple methods to measure 60 Hz in order to gain confidence in the results. Besides the picPET, I've used a commercial TrueTime TFDM (Time/Frequency Deviation Meter) and also a plain old kitchen clock (synchronous motor, wall clock).
Example: I took photos of the kitchen clock precisely 30 seconds after each quarter hour. Here's the short animated GIF of that run; you can see how the wall clock wanders from 0 to 5 seconds ahead of the UTC reference clock (seen in the background):
http://leapsecond.com/pages/tec/mains-clock-ani.gif
For alert readers: the +/- 1 second jitter in the reference clock is due to drift and latency in the PC scripts used to trigger the photo capture. Also sunrise (Pacific time) can be seen in the background starting about 1300 UTC.
/tvb
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 Sun, 11 Mar 2018 14:41:23 -0500
Dana Whitlow k8yumdoober@gmail.com wrote:
I'll have to take a look around to see if there isn't something cheap that
can run
standalone so I don't have to tie up (or wear out) a whole PC for the
acquistion
process.
Blub... I should the whole mail....sorry about that.
How about this: get a uC board (e.g. STM32discovery), replace
the crystal with a 10MHz input from your frequency reference.
Use the on-chip 12bit (really just 6bit) ADC to sample the
sine wave from your mains. Do phasor measurement in software.
Probably any sampling frequency between 200Hz and 1kHz should
do the job, Which is slow enough so you can still handle the
samples with the uC alone and don't need any fancy DSP.
Attila Kinali
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
In short, the GPS to UTC time correction polynomial got screwed up.
Yes, that was an exciting time!
For newcomers to the list, the bizarre GPS 13 microsecond jump was a hot topic on time-nuts back in 26-Jan-2016. The thread starts with an observation by Paul Boven:
https://www.febo.com/pipermail/time-nuts/2016-January/095667.html
And includes detailed follow-up by Martin Burnicki:
https://www.febo.com/pipermail/time-nuts/2016-January/095692.html
https://www.febo.com/pipermail/time-nuts/2016-January/095756.html
https://www.febo.com/pipermail/time-nuts/2016-January/095714.html
https://www.febo.com/pipermail/time-nuts/2016-January/095753.html
If you have time, read the full "GPS jumps of -13.7 us?" thread from the archives:
https://www.febo.com/pipermail/time-nuts/2016-January/subject.html#95667
And also the "GPS PRN 32" thread:
https://www.febo.com/pipermail/time-nuts/2016-January/subject.html#95682
As far as monitoring mains phase -- a 13 microsecond step would be lost in the normal jitter and drift of power line timing. My 60 Hz logging was unaffected by the event because I use a cesium reference (not GPS or GPSDO).
/tvb
Hi
If you pick the “right” STM board, it can handle processing up around
a megasample. It’s internal ADC’s are more of an issue than the sample
rate. You can only do just so well on harmonics with a 12-ish bit ADC.
Even if you go crazy and get one with a display, they still are pretty cheap.
Bob
On Mar 11, 2018, at 6:13 PM, Attila Kinali attila@kinali.ch wrote:
On Sun, 11 Mar 2018 14:41:23 -0500
Dana Whitlow k8yumdoober@gmail.com wrote:
I'll have to take a look around to see if there isn't something cheap that
can run
standalone so I don't have to tie up (or wear out) a whole PC for the
acquistion
process.
Blub... I should the whole mail....sorry about that.
How about this: get a uC board (e.g. STM32discovery), replace
the crystal with a 10MHz input from your frequency reference.
Use the on-chip 12bit (really just 6bit) ADC to sample the
sine wave from your mains. Do phasor measurement in software.
Probably any sampling frequency between 200Hz and 1kHz should
do the job, Which is slow enough so you can still handle the
samples with the uC alone and don't need any fancy DSP.
Attila Kinali
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
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,
On 03/11/2018 11:25 PM, Tom Van Baak wrote:
In short, the GPS to UTC time correction polynomial got screwed up.
Yes, that was an exciting time!
As far as monitoring mains phase -- a 13 microsecond step would be lost in the normal jitter and drift of power line timing. My 60 Hz logging was unaffected by the event because I use a cesium reference (not GPS or GPSDO).
The powergrid folks saw it!
There where some hilarious things happening.
Cheers,
Magnus
Hi,
I did my recordings of grid frequency and cycle count with my homebrew
device.
https://www.tindie.com/products/DetlefS/mains-ac-frequency-meter/
http://www.dschuecker.de/
The heart is a STM ARM processor, which samples the grid voltage at 160ks/s
behind a step-down transformer, slow enough to handle the data in realtime.
It is clocked with a TCXO, off 0.4ppm. I do a sinewave-fit on any single
cycle. Measured precision on an artifical 50Hz sine wave is 1.4E-4 Hz,
which comes close to a jitter of 60ns. Precision is heavily affected by
transients and harmonics, so an aggressive digital filtering is necessary,
analog filtering is not sufficient. The step response of this filter limits
the response of the device to changing frequency.
Cycle count should not be affected by glitches. I use hysteresis and time
windowing on the sampled and filtered data for counting.
The data is presented on a RS232 interface and pumped to the cloud by a
Raspberry running a Python script.
I knew a bit about FNET but I was not aware of www.naspi.org. Are there
similar initiatives in Europe?
Cheers
Detlef
DD4WV
"time-nuts" time-nuts-bounces@febo.com schrieb am 11.03.2018 23:13:26:
Von: Attila Kinali attila@kinali.ch
An: Discussion of precise time and frequency measurement
Datum: 11.03.2018 23:30
Betreff: Re: [time-nuts] Recommendations for Mains Power Monitor / Logger
Gesendet von: "time-nuts" time-nuts-bounces@febo.com
On Sun, 11 Mar 2018 14:41:23 -0500
Dana Whitlow k8yumdoober@gmail.com wrote:
I'll have to take a look around to see if there isn't something cheap
that
can run
standalone so I don't have to tie up (or wear out) a whole PC for the
acquistion
process.
Blub... I should the whole mail....sorry about that.
How about this: get a uC board (e.g. STM32discovery), replace
the crystal with a 10MHz input from your frequency reference.
Use the on-chip 12bit (really just 6bit) ADC to sample the
sine wave from your mains. Do phasor measurement in software.
Probably any sampling frequency between 200Hz and 1kHz should
do the job, Which is slow enough so you can still handle the
samples with the uC alone and don't need any fancy DSP.
Attila Kinali
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
Reading this paper makes one wonder if there are other improvements that
can be made to increase the robustness against jamming, software bugs,
solar events
or hostile attacks to the GPS system
A suggestion:
Create a parallel terrestrial GPS system. This would be a system of
GPS transmitters
mounted on cell phone towers. They would masquerade as GPS satellites
(but unusually low
and stationary). It would be ideal if they could have unique
identifiers and be integrated
into the GPS receivers timing and location calculations as any other
satellite. If there
is no room in the existing ID space then the terrestrial node would take
over the ID of
a satellite that is below the horizon. When the satellite reappeared
the terrestrial node
would simply take over a different below the horizon satellite's ID.
Such a system could be built out as needed. It may not require any
alterations to existing
GPS receivers. It would not disrupt the operation of the existing
satellite constellation.
It would protect against attacks on the satellite system by either a
human enemy or a natural
one, the sun.
Each node need not contain an accurate time source like a cesium
standard. They could
derive timing from a neighbor. Cesium reference nodes would be
periodically placed around the
system. Timing derivations would be more accurate since the distances
would be much closer and
thereby encounter less environmental disturbance.
GPSDO units would prefer such close and stationary references vs distant
moving ones.
Pete.
On 3/11/2018 5:26 PM, Magnus Danielson wrote:
Hi Andy,
On 03/11/2018 08:40 PM, Andy Backus wrote:
Thank you for your posting, Magnus.
Your information is very interesting.
Do you mind saying a little more about the "incident" on 26-JAN-2016? I don't find reference to it in the link. And my own TE plot for then shows no obvious disturbance.
Thanks.
Please read this:
https://rubidium.dyndns.org/~magnus/papers/GPSincidentA6.pdf
In short, the GPS to UTC time correction polynomial got screwed up.
I got email from NASA, ended up having to call NASA HQ and got invited
to Washington DC to present before the US PNT advisory board.
Among the stranger things I've done in my life, but it was fun.
Cheers,
Magnus
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
On Mar 12, 2018, at 9:54 AM, Peter Reilley preilley_454@comcast.net wrote:
Reading this paper makes one wonder if there are other improvements that
can be made to increase the robustness against jamming, software bugs, solar events
or hostile attacks to the GPS system
A suggestion:
Create a parallel terrestrial GPS system. This would be a system of GPS transmitters
mounted on cell phone towers. They would masquerade as GPS satellites (but unusually low
and stationary). It would be ideal if they could have unique identifiers and be integrated
into the GPS receivers timing and location calculations as any other satellite. If there
is no room in the existing ID space then the terrestrial node would take over the ID of
a satellite that is below the horizon. When the satellite reappeared the terrestrial node
would simply take over a different below the horizon satellite's ID.
If it takes over the ID of an existing satellite, it also takes over the ephemeris and almanac
information for that satellite. There is only a very finite amount of “data space” in the transmissions
for that stuff.
Simple answer - it would have to be an independent system. You need a unique almanac for it
and unique ID numbers for the stations.
Such a system could be built out as needed. It may not require any alterations to existing
GPS receivers. It would not disrupt the operation of the existing satellite constellation.
It would protect against attacks on the satellite system by either a human enemy or a natural
one, the sun.
Each node need not contain an accurate time source like a cesium standard. They could
derive timing from a neighbor.
If you do that, you make your backup system very open to attack. Spoof one and all the
rest tracking it follow ….
Cesium reference nodes would be periodically placed around the
system. Timing derivations would be more accurate since the distances would be much closer and
thereby encounter less environmental disturbance.
Only if you distributed a lot of very good clocks and monitored them the same way as you
monitor a GPS sat. Since they are all low to the ground, that would take a very different
setup for monitoring.
GPSDO units would prefer such close and stationary references vs distant moving ones.
Ummm …… errrrr ….. not so much. A GPSDO simply locks up to “all in view”. Unless you
tell it to reject a sat, it uses it. To the degree that there is a rejection process (TRAIM), it
looks at the group solution. If the “majority time” looks ok … off we go.
======
The idea of using cell tower signals for timing was at the heart of a couple of systems. The gotcha
turned out to be that not all tower operators are created equal. Unless you have direct control
over the gear ( = you own and operate it) there is no way to keep it “correct”.
If you are going out to buy up a bunch of cell tower space, that is quite expensive. There are
other much less expensive ways to create an independent system. In fact, we already have
several alternate systems (Glonass and Galileo and BeiDou). They are already available (or will
soon be available) in the data stream of a lot of GPS modules. Working out what to do with
them is less complex than adding a “something else” system.
Bob
Pete.
On 3/11/2018 5:26 PM, Magnus Danielson wrote:
Hi Andy,
On 03/11/2018 08:40 PM, Andy Backus wrote:
Thank you for your posting, Magnus.
Your information is very interesting.
Do you mind saying a little more about the "incident" on 26-JAN-2016? I don't find reference to it in the link. And my own TE plot for then shows no obvious disturbance.
Thanks.
Please read this:
https://rubidium.dyndns.org/~magnus/papers/GPSincidentA6.pdf
In short, the GPS to UTC time correction polynomial got screwed up.
I got email from NASA, ended up having to call NASA HQ and got invited
to Washington DC to present before the US PNT advisory board.
Among the stranger things I've done in my life, but it was fun.
Cheers,
Magnus
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.
I expect 1/R^2 would prevent such a scheme from working as the
terrestrial transmitters would vary widely in signal strength in a way
that GPS satellites do not and could overload the receiver.
David N1HAC
On 3/12/18 9:54 AM, Peter Reilley wrote:
Reading this paper makes one wonder if there are other improvements that
can be made to increase the robustness against jamming, software bugs,
solar events
or hostile attacks to the GPS system
A suggestion:
Create a parallel terrestrial GPS system. This would be a system of
GPS transmitters
mounted on cell phone towers. They would masquerade as GPS
satellites (but unusually low
and stationary). It would be ideal if they could have unique
identifiers and be integrated
into the GPS receivers timing and location calculations as any other
satellite. If there
is no room in the existing ID space then the terrestrial node would
take over the ID of
a satellite that is below the horizon. When the satellite reappeared
the terrestrial node
would simply take over a different below the horizon satellite's ID.
Such a system could be built out as needed. It may not require any
alterations to existing
GPS receivers. It would not disrupt the operation of the existing
satellite constellation.
It would protect against attacks on the satellite system by either a
human enemy or a natural
one, the sun.
Each node need not contain an accurate time source like a cesium
standard. They could
derive timing from a neighbor. Cesium reference nodes would be
periodically placed around the
system. Timing derivations would be more accurate since the
distances would be much closer and
thereby encounter less environmental disturbance.
GPSDO units would prefer such close and stationary references vs
distant moving ones.
Pete.
On 3/11/2018 5:26 PM, Magnus Danielson wrote:
Hi Andy,
On 03/11/2018 08:40 PM, Andy Backus wrote:
Thank you for your posting, Magnus.
Your information is very interesting.
Do you mind saying a little more about the "incident" on
26-JAN-2016? I don't find reference to it in the link. And my own
TE plot for then shows no obvious disturbance.
Thanks.
In short, the GPS to UTC time correction polynomial got screwed up.
I got email from NASA, ended up having to call NASA HQ and got invited
to Washington DC to present before the US PNT advisory board.
Among the stranger things I've done in my life, but it was fun.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.febo.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts&data=02%7C01%7Cdavid.g.mcgaw%40dartmouth.edu%7Ca4a010b972b74eba0aa208d5890f2665%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636565620521190534&sdata=TZ0iAE4kLnnTmBVQiqp7a89631lm704lqBB4k%2FtB%2FOQ%3D&reserved=0
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.febo.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Ftime-nuts&data=02%7C01%7Cdavid.g.mcgaw%40dartmouth.edu%7Ca4a010b972b74eba0aa208d5890f2665%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636565620521190534&sdata=TZ0iAE4kLnnTmBVQiqp7a89631lm704lqBB4k%2FtB%2FOQ%3D&reserved=0
and follow the instructions there.