Merry 55555

[Tom Van Baak]

In case you didn't notice -- this year Christmas falls on the
beautiful looking MJD 55555.

Some of the newcomers to the group may not be familiar
with MJD (Modified Julian Date). It's used extensively in the
timing community (see http://tycho.usno.navy.mil/mjd.html).

For those of you with vintage Trak 6460 time scale generators
(see http://www.leapsecond.com/pages/trak6460) a special
treat will occur at 13:20:00 UTC* on Christmas day. The time
at the tone will be 55555.55555. Once in a lifetime.

That's 620AM local time at NIST and 820AM for USNO (send
us a video/photo from the time scale room if you can).

/tvb

* Picky astronomers in the group may want to adjust their
MJD photo by 135 milliseconds to account for today's DUT1.
(see http://maia.usno.navy.mil/ser7/ser7.dat)

[Mark Sims]

Lady Heather will display the date (but not fractional time) in MJD with /DM

[Tom Van Baak]

> Lady Heather will display the date (but not fractional time) in MJD with /DM

Anyone with a browser can try this one...
http://www.leapsecond.com/java/nixie.htm

Or the mobile phone version:
http://leapsecond.com/m/mjd.htm

/tvb

[John Ackermann N8UR]

On Dec 24, 2010, at 8:41 PM, "Tom Van Baak" <tvb-AeR/***@public.gmane.org> wrote:

>> Lady Heather will display the date (but not fractional time) in MJD with /DM
>
> Anyone with a browser can try this one...
> http://www.leapsecond.com/java/nixie.htm
>
> Or the mobile phone version:
> http://leapsecond.com/m/mjd.htm
>
> /tvb
>
And most of the pages on http://febo.com have the MJD of the page load time at the bottom of the menu bar on the left side of the page.

John

[Mark Sims]

Heather now has an option to display MJD.fraction ...  but, alas, release won't be for a while...

[Hal Murray]

> For those of you with vintage Trak 6460 time scale generators (see http://
> www.leapsecond.com/pages/trak6460) a special treat will occur at 13:20:00
> UTC* on Christmas day. The time at the tone will be 55555.55555. Once in a
> lifetime.

Neat find. Thanks for sharing.

But you can get more. How many 5s do you want?

13:20 is 13*3600 + 20*60 = 48000 seconds
48000 / 86400 is 5/9
5/9 is 0.555555555... (repeating fraction)

Does the Trak 6460 do the right with leap seconds? What is the right thing?




--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> Then the next step is to use an NTP driver that treats the 60 Hz pulses on
> DTR as the local time/frequency reference. Your PC will then run on "mains
> time" instead of UTC. Not sure how low a stratum that would be. Still, if
> you did this, then your existing NTP tools will give you all the logging and
> plots you need. Your PC is running mains; the rest of the network is UTC, so
> any time drift plots for your server will neatly indicate if TEC is working,
> or not.

I don't think any of the current drivers in NTP will do the right thing for
this project.

The PPS driver is a bit tricky. It needs help to figure out which second a
pulse corresponds to. I think there is a filter in there to reject samples
that are too far off from what it thinks is a second boundary.



--
These are my opinions, not necessarily my employer's. I hate spam.

[Tom Van Baak]

> I don't think any of the current drivers in NTP will do the right thing for
> this project.
>
> The PPS driver is a bit tricky. It needs help to figure out which second a
> pulse corresponds to. I think there is a filter in there to reject samples
> that are too far off from what it thinks is a second boundary.

Yeah, I didn't check the list of NTP drivers to see if one had
been written already, or if an existing one could be made to
work with a few lines of code. How does NTP handle the cases
where an accurate 1PPS is available but the time itself isn't?
This would be the case for most cesium or OCXO references,
or maybe even some GPS 1PPS references.

One could also use an external divide-by-60 counter to convert
60 Hz to 1 Hz -> DCD. You could get clever and send 60 Hz
to Rx as described earlier and 1 Hz to DCD on the same, or
another port, for use by the NTP PPS driver.

Or, use a software divider: let the user program that's reading
the 60 bytes/second pulse DTR once every 60 bytes, tie this
to NTP's DCD pin and -- the PC is generating its own 1PPS.

My thought was simply that since NTP is fairly well-known, it
might make a nice demo to see a power-line-sync'ed PC run
for a couple of weeks before the TEC experiment, and then
during the TEC experiment.

/tvb

[Chris Albertson]

The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.

Al it does it capture a timmer/counter when a pulse comes in. Then
fets a flag a user program can read that says "data available". The
user level programs reads the device ad gets the captured counter
value, the flag is reset. Very simple and very low overhead.

I think the counter units are nanoseconds



On Tue, Jun 28, 2011 at 1:28 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>> Then the next step is to use an NTP driver that treats the 60 Hz pulses on
>> DTR as the local time/frequency reference. Your PC will then run on "mains
>> time" instead of UTC. Not sure how low a stratum that would be. Still, if
>> you did this, then your existing NTP tools will give you all the logging and
>> plots you need. Your PC is running mains; the rest of the network is UTC, so
>> any time drift plots for your server will neatly indicate if TEC is working,
>> or not.
>
> I don't think any of the current drivers in NTP will do the right thing for
> this project.
>
> The PPS driver is a bit tricky.  It needs help to figure out which second a
> pulse corresponds to.  I think there is a filter in there to reject samples
> that are too far off from what it thinks is a second boundary.
>
>
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Tom Van Baak]

Chris,

Sounds good. Somebody that's interested or knows NTP (not me)
can be the first to set up a mains frequency timed PC, publish
fancy MRTG plots on the web, and watch the TEC test in July.

Realize this is all just for fun. TEC should have zero impact on
modern computer networks. The last system I worked with that
relied on 60 Hz power for timekeeping was a 70's PDP 11/34.

/tvb

----- Original Message -----
From: "Chris Albertson" <albertson.chris-***@public.gmane.org>
To: "Discussion of precise time and frequency measurement" <time-nuts-***@public.gmane.org>
Sent: Tuesday, June 28, 2011 4:06 PM
Subject: Re: [time-nuts] TEC party file format?


The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.

Al it does it capture a timmer/counter when a pulse comes in. Then
fets a flag a user program can read that says "data available". The
user level programs reads the device ad gets the captured counter
value, the flag is reset. Very simple and very low overhead.

I think the counter units are nanoseconds

[paul swed]

Well a funny thing happened on the way to water sprinklers, ball field
lights etc.
The silly things use motorized timers. So they will tend to drift. Though
modern sprinklers should be micro controlled to god knows what reference.
(poor is a guess)
But there are lots and lots of those controllers no one pays attention to.
Typically in office building electrical closets.


On Wed, Jun 29, 2011 at 10:53 AM, Tom Van Baak <tvb-***@public.gmane.org> wrote:

> Chris,
>
> Sounds good. Somebody that's interested or knows NTP (not me)
> can be the first to set up a mains frequency timed PC, publish
> fancy MRTG plots on the web, and watch the TEC test in July.
>
> Realize this is all just for fun. TEC should have zero impact on
> modern computer networks. The last system I worked with that
> relied on 60 Hz power for timekeeping was a 70's PDP 11/34.
>
> /tvb
>
> ----- Original Message ----- From: "Chris Albertson" <
> albertson.chris-***@public.gmane.org>
> To: "Discussion of precise time and frequency measurement" <
> time-nuts-***@public.gmane.org>
> Sent: Tuesday, June 28, 2011 4:06 PM
> Subject: Re: [time-nuts] TEC party file format?
>
>
> The Linux or BSD pulse per second interface is general enough to work for
> this.
> It does not care if the pulses are one per second or 100 per second, or 60.
>
> Al it does it capture a timmer/counter when a pulse comes in. Then
> fets a flag a user program can read that says "data available". The
> user level programs reads the device ad gets the captured counter
> value, the flag is reset. Very simple and very low overhead.
>
> I think the counter units are nanoseconds
>
>
>
> ______________________________**_________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> 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.
>

[Mark Spencer]

I thought I would try simply feeding a 60 Hz signal from the AC line into a
counter in totalize mode and logging the output several times a second with time
stamps.    I'll be curious to see how accurate this is.

I've attached a small sample of the data.



----- Original Message ----
From: Tom Van Baak <tvb-AeR/***@public.gmane.org>
To: Discussion of precise time and frequency measurement <time-nuts-***@public.gmane.org>
Sent: Wed, June 29, 2011 7:53:43 AM
Subject: Re: [time-nuts] TEC party file format?

Chris,

Sounds good. Somebody that's interested or knows NTP (not me)
can be the first to set up a mains frequency timed PC, publish
fancy MRTG plots on the web, and watch the TEC test in July.

Realize this is all just for fun. TEC should have zero impact on
modern computer networks. The last system I worked with that
relied on 60 Hz power for timekeeping was a 70's PDP 11/34.

/tvb

----- Original Message ----- From: "Chris Albertson" <albertson.chris-***@public.gmane.org>
To: "Discussion of precise time and frequency measurement" <time-nuts-***@public.gmane.org>
Sent: Tuesday, June 28, 2011 4:06 PM
Subject: Re: [time-nuts] TEC party file format?


The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.

Al it does it capture a timmer/counter when a pulse comes in.  Then
fets a flag a user program can read that says "data available".  The
user level programs reads the device ad gets the captured counter
value, the flag is reset.  Very simple and very low overhead.

I think the counter units are nanoseconds



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

[Tom Van Baak]

Mark,

That will work fine. In your data I see 124 measurements taken
over half a minute and you're getting about 14 or 15 counts per
measurement, each one is about 1/4 second. Your PC-based
time-stamps allow you to mark the time of each measurement
(or compute interval between N measurements).

There's a hiccup at line 82 and 84 that you might want to debug.

If you subtract the first from the last point you get a nice result:
delta counts: 1781 - 8 = 1773
delta time: 29.578 seconds
which gives 59.94 Hz average frequency during that half minute.

If you write a couple lines of code you can take the data as it's
being collected, break it into, say, 1 minute or 10 minute chunks
and plot how frequency varies minute to minute.

To calculate time error, take the (presumably NTP sync'd) PC time
delta, multiply it by 60 to give the number of cycles you *ideally*
expect during that interval. Subtract that from the number of cycles
you *actually* count during the same interval and that's how many
cycles were gained or lost.

If you then plot that over time (especially over several days) you
will be impressed at how well the power company does keeping
TE within a few seconds of zero.

/tvb

----- Original Message -----
From: "Mark Spencer" <mspencer12345-FFYn/***@public.gmane.org>
To: "Discussion of precise time and frequency measurement" <time-nuts-***@public.gmane.org>
Sent: Wednesday, June 29, 2011 9:55 AM
Subject: Re: [time-nuts] TEC party file format?


I thought I would try simply feeding a 60 Hz signal from the AC line into a
counter in totalize mode and logging the output several times a second with time
stamps. I'll be curious to see how accurate this is.

I've attached a small sample of the data.



----- Original Message ----
From: Tom Van Baak <tvb-AeR/***@public.gmane.org>
To: Discussion of precise time and frequency measurement <time-nuts-***@public.gmane.org>
Sent: Wed, June 29, 2011 7:53:43 AM
Subject: Re: [time-nuts] TEC party file format?

Chris,

Sounds good. Somebody that's interested or knows NTP (not me)
can be the first to set up a mains frequency timed PC, publish
fancy MRTG plots on the web, and watch the TEC test in July.

Realize this is all just for fun. TEC should have zero impact on
modern computer networks. The last system I worked with that
relied on 60 Hz power for timekeeping was a 70's PDP 11/34.

/tvb

----- Original Message ----- From: "Chris Albertson" <albertson.chris-***@public.gmane.org>
To: "Discussion of precise time and frequency measurement" <time-nuts-***@public.gmane.org>
Sent: Tuesday, June 28, 2011 4:06 PM
Subject: Re: [time-nuts] TEC party file format?


The Linux or BSD pulse per second interface is general enough to work for this.
It does not care if the pulses are one per second or 100 per second, or 60.

Al it does it capture a timmer/counter when a pulse comes in. Then
fets a flag a user program can read that says "data available". The
user level programs reads the device ad gets the captured counter
value, the flag is reset. Very simple and very low overhead.

I think the counter units are nanoseconds



_______________________________________________
time-nuts mailing list -- time-nuts-***@public.gmane.org
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-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[Hal Murray]

> So the PC itself becomes your frequency counter, with NTP providing the
> long-term timebase stability you need.

> Mains cycles-per-second become RS232 bytes-per-second. You will get, on
> average, 60 bytes per second. At the end of a "perfect" day you would have
> read 5184000 characters. In Europe, it's 4320000 (50 Hz * 86400).

I see two interesting problems with this sort of approach.

One is glitches on the line, either lightning/whatever causing extra counts,
or dropouts causing missed cycles. Does anybody know how often this sort of
stuff happens? Does anybody have scope pictures?

The other would be glitches on the PC. I can easily keep a system running
for a week or a month, but every now and then I need to move the power plug
or I get the urge to play with some software and ...

If I have a day of good data, then a break, then more good data, how long can
the break be so that I can correctly guess the number of cycles that were
missed? It depends upon how much the frequency changes. If I extrapolate
forward from before the break and back from after, the lines will intersect.
If I can estimate the error in the slope of those lines I can see what
happens if I use the high/low error cases.

One thing that might help get back in cycle sync would be to use a PIC/AVR
rather than a 555. The idea is that it can do the first layer of data
reduction, say divide by 100. That would roughly multiply the
get-back-in-sync time by 100. (assuming not much noise)

The PIC could also send out a RS-232 text message with the count in it, or
modulate the pulse width, say double the width every 10000 cycles. Mumble
there are lots of opportunities.

Another idea is that once you get the PIC debugged, you probably won't have
to reboot it because you are messing with other software on the box.

------------------

An alternative would be to feed the 60 Hz into the audio port on the PC. No
need for the 555 or whatever. The crystal driving the audio ADC is another
variable but I think that won't be a major problem.






--
These are my opinions, not necessarily my employer's. I hate spam.

[Tom Van Baak]

> I see two interesting problems with this sort of approach.
>
> One is glitches on the line, either lightning/whatever causing extra counts,
> or dropouts causing missed cycles. Does anybody know how often this sort of
> stuff happens? Does anybody have scope pictures?

The beauty of time-stamping each cycle (each byte) is that you
have a lot of data to work with to identify and correct short-term
glitches like this. Normal frequency counters are at the mercy
of glitches, but continuous time-stamping counters can, if they
want, apply heuristics to a CW sequence and easily pinpoint
cycles that are missing or doubly counted.

If course if you are missing minutes of data it may be impossible
to know for sure if you're off by a cycle or two. But to isolate bad
data over the span of a few seconds, it's easy.

> The other would be glitches on the PC. I can easily keep a system running
> for a week or a month, but every now and then I need to move the power plug
> or I get the urge to play with some software and ...

Correct. Then again, all you have to do is split the 60 Hz pulse
train to two serial ports on different PC's. Serial ports are easy
that way.

> The PIC could also send out a RS-232 text message with the count in it, or
> modulate the pulse width, say double the width every 10000 cycles. Mumble
> there are lots of opportunities.

See the start of these TEC thread(s). I'm collecting all my data
with a PIC: 60 Hz in, RS232 time-stamps out. I can send one
to you if you want to try it.

> An alternative would be to feed the 60 Hz into the audio port on the PC. No
> need for the 555 or whatever. The crystal driving the audio ADC is another
> variable but I think that won't be a major problem.

Yeah, this was mentioned earlier. It turns out the crystal isn't
a problem since all you're doing is counting 16 ms cycles within
the realtime waveform capture buffer. In this case the ADC isn't
used as much for edge timing as it is for edge counting. The
sample rate or rate stability can be very low.

/tvb

[Tom Van Baak]

> If I have a day of good data, then a break, then more good data, how long can
> the break be so that I can correctly guess the number of cycles that were
> missed? It depends upon how much the frequency changes. If I extrapolate
> forward from before the break and back from after, the lines will intersect.
> If I can estimate the error in the slope of those lines I can see what
> happens if I use the high/low error cases.

Hal,

Your logic sounds correct. Note the question of how accurately
you can predict the future time or frequency of a clock, based
on a long record of its past behavior, is exactly what the ADEV
family of statistics give you. It's all about how much or little the
frequency changes over time.

I'll send you mains data from yesterday if you want to play with
simulating missing data algorithms. I think in this case TDEV or
MTIE is the statistic you want.

I had to deal with this issue of data breaks in my relativity clock
experiment on Mt Rainier (www.leapsecond.com/great2005, for
new people on the list). In this case you have stable clocks and
because of time dilation they "slip cycles" so to speak while you
are away from home. The question is: how stable a clock do you
need to have before you are sure you can see relativistic time
dilation and not just nanoseconds of normal clock drift.

> One thing that might help get back in cycle sync would be to use a PIC/AVR
> rather than a 555. The idea is that it can do the first layer of data
> reduction, say divide by 100. That would roughly multiply the
> get-back-in-sync time by 100. (assuming not much noise)

Correct. Or divide to get 1 pulse per minute, or hour, etc. You may
laugh but even dividing by 5184000 (one pulse per day) would still
give you enough points to make a really nice plot of US mains power
timekeeping performance over a year. This illustrates the issue that
for some cases (such as this one) occasionally recording time
error (phase) is often easier and more reliable than making many
uninterrupted frequency measurements and integrating them all
to estimate net time error.

/tvb

[Hal Murray]

> How does NTP handle the cases where an accurate 1PPS is available but the
> time itself isn't? This would be the case for most cesium or OCXO
> references, or maybe even some GPS 1PPS references.

You need to get the rough time from some other source, say the network or
from GPS via the serial port.

I thought the PPS driver would ignore input pulses that are not close enough
(say 125ms or 250ms) but I can't find it in a quick scan of the code so maybe
I'm imagining things.

Note that a Cesium or OCXO will drift. Even if the drift isn't a problem,
you have to get their PPS lined up with the second ticks. GPSDOs are good.
:) [You can also measure the offset. NTP can work with that.]


> Or, use a software divider: let the user program that's reading the 60 bytes/
> second pulse DTR once every 60 bytes, tie this to NTP's DCD pin and -- the
> PC is generating its own 1PPS.

There is a shared memory driver that lets you do something like that without
any hardware. Look at the gpsd sources if you want to see how to feed it.

For things like this, ntpd has a "noselect" option for a server or refclock.
It collects all the data but doesn't use it, just puts it in log files.



--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> Either use the PC to timestamp receive buffers, or if you have a 1pps handy,
> just feed your 60 Hz signal into one channel (L) and the 1 PPS into the
> other (R).

If you have a known-good (accurate?) signal going into you audio channel, you
can compute the actual clock frequency of the audio capture path.

I think the IRIG driver in ntpd does that, and includes the offset in PPM in
the log files.



--
These are my opinions, not necessarily my employer's. I hate spam.

[Chris Albertson]

On Thu, Jun 30, 2011 at 12:54 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

> If you have a known-good (accurate?) signal going into you audio channel, you
> can compute the actual clock frequency of the audio capture path.

The problem is that it takes a long time to see a small error. If
the oscillator in the audio card is not stable then you can't do those
long term tests because the results change faster than you can measure
them
--

Chris Albertson
Redondo Beach, California

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> Realize this is all just for fun. TEC should have zero impact on modern
> computer networks.

It will be interesting to see how much gear there is out there that derives
time keeping from the line frequency.

I suspect a lot of it doesn't matter much at the second/minute level. (Who
cares if the sprinkler goes on at 6:00 or 6:02?) I suspect there is an
assumption that they have to get reset occasionally, maybe on DST changes or
when power fail or ...


> The last system I worked with that relied on 60 Hz power
> for timekeeping was a 70's PDP 11/34.

IBM 360s bumped a slot in low memory on each cycle. There was a switch
someplace to select bumping by 5 on 60 Hz systems and 6 on 50 Hz. The net
result was incrementing by 300 counts per second.


--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> Wonderful plots. Thanks for posting them. Can you tell us a little about
> your test setup? I think the group would enjoy hearing how a long-term
> experiment like this is done.

I'm using a HP-5334B running off a Z3801A. The data is collected via a
Prologix GPIB-USB gizmo.

I'm collecting data every 5 minutes.

If you ask for the frequency with a gate time of 60 seconds, you get an extra
digit or 2 in the answer. This setup is just barely good enough to see
interesting quirks in that crystal.

Back when I was getting started, I remember being able to see the frequency
change a bit when I grabbed the can with my fingers. My "lab" is not air
conditioned so the temperature varies up to 10 F during the day.

I see occasional glitches in the data. They only happen once a day or so. I
don't know where they are coming from. If they look bad enough, I edit them
out by hand.


--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> If you use 16- or 24-bit serial-parallel-latches or "port expanders" then
> you only need 2 or 3 pins of the microcontroller. Use one or more '595 or
> look at the wonderful chips by Unitrode/Allegro.

There is still the problem of updating all of the expander chips at the same
time.

Here is a possibly crazy idea: use the decimal point.

I think this recipe works:
1: figure out which digits you want to change
2: starting from the right, turn on the decimal points of those digits
3: again, starting from the right, update the digits and turn off the
decimal points
The clock "ticks" when you turn off the bottom decimal point.

When reading:
If the bottom decimal point is on, ignore the decimal points. You are in
step 2.
If the bottom decimal point is off but others are on, you are in step 3.
The digits with the decimal points on need to be bumped by one.


--
These are my opinions, not necessarily my employer's. I hate spam.

[Tom Van Baak]

> tvb-AeR/***@public.gmane.org said:
>> If you use 16- or 24-bit serial-parallel-latches or "port expanders" then
>> you only need 2 or 3 pins of the microcontroller. Use one or more '595 or
>> look at the wonderful chips by Unitrode/Allegro.
>
> There is still the problem of updating all of the expander chips at the same
> time.

Hal,

The expanders I've seen have serial-in and serial-out. So the
trick is you daisy chain the serial lines of the chips but drive
the latches in parallel. That way you can quietly shift in all N
bits and then latch one and all.

/tvb

[p***@public.gmane.org]

yes, I am working with for a timestamp on a FireWire Camera (MARLIN CAMERA)
Unfortunately no free software can timestamp frame withouth data loss.
My camera is unable to carry out an atuomatic timestamp (it is and old version).
Thank you for info
Paolo Martini




----Messaggio originale----
Da: david-taylor-***@public.gmane.org
Data: 3-nov-2011 12.02
A: <time-nuts-***@public.gmane.org>
Ogg: Re: [time-nuts] Precisione GPS based led clock

> Dear all
> I am an amateur astronomer working in the field of minor planet
> occultation.
> To arrange a precise reference time I am looking for a 1/100 sec LED
> dispaly clock GPS based. (LED is usefull for night vision)
> My idea is to use a "ebay" used master clock such as " ThunderBolt GPS
> disciplined clock" to drive a timecode display. Particulary I wish to
> realize a "PIC" based LED clock to display hour min sec and use the 10
> MHz reference to arrange an 1/10 and 1/100 sec disaply. Can anyone
> help me in finding schemes or any more flexible idea?
> thanks

A small Netbook PC locked to a good local NTP server should be able to
achieve that. Your local NTP server can be locked to GPS (ideally) or to
the Internet.

GPS devices:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
http://www.satsignal.eu/ntp/Sure-GPS.htm

The PC's screen refresh rate would be marginal for 1/00s, though. Perhaps
1/20s is more realistic.

If 1/10s is good enough, there are applications like Emerald Time for your
iPad/iPhone:

http://emeraldsequoia.com/et/index.html

Are you actually trying to timestamp a video recording or light-level
reading? Or time pressing a button?

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor-***@public.gmane.org


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

[Flemming Larsen]

A straightforward solution would be to use a string of divide-by-ten and divide-by-six BCD counters (HC390).
First divide the 10 MHz output from a GPS receiver down to 100 Hz and feed that to  the input of a
divide-by-100 counter for the 1/100 seconds display, then to a divide-by-60 for the seconds and so on.
The BCD counters would feed a series of eight CD4511 or equivalent decoders as previously suggested.
The 1 PPS output from the GPS, properly stretched, could be used to reset the 1/100 s counters and to
clock the seconds counter. Pretty straightforward and no display multiplexing, but a lot of wiring.
Getting the time from the GPS to the clock circuit would be a little more complicated, and would almost
certainly require some kind of microprocessor or PIC. One solution is to synchronize the clock to the GPS
once a day at local midnight using the reset inputs to the counters. This would be relatively simple to do with
a PIC, I would think, and would still leave the clock section alone, without the need for complicated wiring
or deciphering of the display.
I designed a similar clock, although without the 1/100 s digits display and using an OCXO rather than a GPS
receiver. In the end I used an MK50250N clock chip I purchased on eBay, same chip I used back in 1974
to build a small alarm clock. This clock chip uses a multiplexed display, which might not work with a video
recorder or camera.

-- Flemming Larsen



________________________________
Fra: "paolo.martini-1Ph4/***@public.gmane.org" <paolo.martini-1Ph4/***@public.gmane.org>

yes, I am working with for a timestamp on a FireWire Camera (MARLIN CAMERA)
Unfortunately no  free software can timestamp frame withouth data loss.
My camera is unable to carry out  an atuomatic timestamp (it is and old version).
Thank you for info
Paolo Martini

[Hal Murray]

paolo.martini-1Ph4/***@public.gmane.org said:
> yes, I am working with for a timestamp on a FireWire Camera (MARLIN CAMERA)
> Unfortunately no free software can timestamp frame withouth data loss. My
> camera is unable to carry out an atuomatic timestamp (it is and old
> version).

Will it work if you just use a single LED connected to the PPS signal from
the GPS? The idea is to count frames from the first frame where you can see
the LED. That assumes you can get within a second using other means.

Some PPS pulses are only 10 microseconds wide. If you have one of those, you
will have to use a pulse stretcher.

What is the timing like on the "shutter" of modern digital cameras? I assume
the time it is open is adjusted to adapt to the light level.

Suppose I'm running at 100 frames per second (a handy round number). That's
10 ms per frame. Is the readout double-buffered so I can have the shutter
open for most of the 10 ms and also have 10 ms to read out the frame?

If the shutter is open for most of the frame time, you can probably get
sub-frame timing by measuring the intensity of the LED.

--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> Is there an official NTP forum or newsgroup or mailing list where these
> sorts of questions can be posted and answered? I never intended for
> time-nuts to be an NTP support forum.

usenet:comp.protocols.time.ntp
which gets gatewayed (both directions, I think) to
questions-***@public.gmane.org

http://lists.ntp.org/listinfo


--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> I'm not sure how well a multi-level leap year algorithm relates Breseham's
> algorithm. I tracked down his 1965 plotter article. There might be common
> ground there.

It's the same math as a DDS.

If Breseham would land exactly on a grid point after N steps, a DDS will
have no long term drift. That means the slope of the Breseham line is N/M
where both N and M are integers. For the intermediate steps, both Breseham
and DDS come as close as possible: 1/2 grid spacing vs 1/2 clock period.

We usually think of DDS as requiring M to be a power of 2 but you don't have
to do it that way. One obvious example is to make M a power of 10 by doing
decimal adds rather than binary. That should work well with a FPGA but I
haven't done it yet. If you start with 10 MHz, that will give you perfect
hits on integer audio frequencies.





--
These are my opinions, not necessarily my employer's. I hate spam.

[Azelio Boriani]

OK for the PSOC example. At the moment I can try on a Spartan3 because I
already have a board with the OCXO. The Spartan3 has the so called DCM, a
digital clock generator that can multiply an input clock using its DDL
digital delay line.

On Thu, Feb 2, 2012 at 8:13 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> tvb-AeR/***@public.gmane.org said:
> > I'm not sure how well a multi-level leap year algorithm relates
> Breseham's
> > algorithm. I tracked down his 1965 plotter article. There might be common
> > ground there.
>
> It's the same math as a DDS.
>
> If Breseham would land exactly on a grid point after N steps, a DDS will
> have no long term drift. That means the slope of the Breseham line is N/M
> where both N and M are integers. For the intermediate steps, both Breseham
> and DDS come as close as possible: 1/2 grid spacing vs 1/2 clock period.
>
> We usually think of DDS as requiring M to be a power of 2 but you don't
> have
> to do it that way. One obvious example is to make M a power of 10 by doing
> decimal adds rather than binary. That should work well with a FPGA but I
> haven't done it yet. If you start with 10 MHz, that will give you perfect
> hits on integer audio frequencies.
>
>
>
>
>
> --
> These are my opinions, not necessarily my employer's. I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Clint Turner]

Years ago (in the 80's) I needed to lock a homebrew DDS to an accurate,
stable 10 MHz reference (a good TCXO in this case) that was set to
WWV/H. Considering that the DDS was clocked at 2^24 Hz (16.777216 MHz)
this was slightly awkward, but I did it using standard HC and 4000 logic.

The convoluted path was:

10 MHz / 625 = 16 kHz (HC40103 as a div-by-125 and an HC4017 as a
div-by-5 would work...)

16 kHz * 32 = 512 kHz (using a 4046 and 4040)

512 kHz /125 = 4096 Hz (using 40103 or similar)

From there, it was a no-brainer to compare this with the 16.777216 MHz
/ 4096 with another 4046/integrator - but the same 'HC4040 that did this
also had a tap with 32768 kHz on it.

With a fairly slow loop and a low-noise 2^24 Hz VCXO, the DDS's clock
was both clean and stable - and tuned in 1 Hz steps! A cheap and
more-common 4.194304 MHz crystal would work and I suppose that a similar
scheme could be used to lock a 32768 Hz VCXO but I've never tried to
'VCXO a tuning-fork crystal before:-)

* * *

I, too, have an older (Philips) DVR that has lost its time sync since
the analogs went dark. For a while, I used the XDS time code that
happened to be in the vertical interval of one of its standard
definition DTV PBS station's sub-channels (received on a set-top box and
modulated onto a TV channel to which the DVR would "look" for its time
code) but this has code since been dropped.

Before I discovered this, I dug up the line 21 (IIRC) code
specifications and noted that even a PIC could probably generate the
proper code, synchronized either from a GPS or a WWVB receiver. I'd
thought about putting it on multiple lines and then RF modulating it for
the DVR to see, but lost enthusiasm after I discovered the time code on
the sub-channel. Since that went away (about a year ago) I've just
remembered to set the clock once a month, not being able to quickly find
the specs for the time code again online...

73,

Clint
KA7OEI

[Azelio Boriani]

No doubt, the correct way to generate accurate clocks from an accurate
10MHz is by PLLs. There are DDS too, then there is a strange method that
uses a sort of dual (triple? Quadruple? ...) modulus. The advantage is that
you don't need another oscillator (the PLL needs a VCO) or the (co)sine
lookup and DAC combination: just divide (oddly, of course,
inserting/removing cycles every here and there). Maybe the sigma at short
tau isn't so good but in the long run it gets better. The derived clock can
be used to synchronize equipment that is not so sensitive at short taus.
This method can show how can a clock be not so good in the short term but
very good in the long term.

On Thu, Feb 2, 2012 at 11:10 PM, Clint Turner <turner-***@public.gmane.org> wrote:

> Years ago (in the 80's) I needed to lock a homebrew DDS to an accurate,
> stable 10 MHz reference (a good TCXO in this case) that was set to WWV/H.
> Considering that the DDS was clocked at 2^24 Hz (16.777216 MHz) this was
> slightly awkward, but I did it using standard HC and 4000 logic.
>
> The convoluted path was:
>
> 10 MHz / 625 = 16 kHz (HC40103 as a div-by-125 and an HC4017 as a div-by-5
> would work...)
>
> 16 kHz * 32 = 512 kHz (using a 4046 and 4040)
>
> 512 kHz /125 = 4096 Hz (using 40103 or similar)
>
> From there, it was a no-brainer to compare this with the 16.777216 MHz /
> 4096 with another 4046/integrator - but the same 'HC4040 that did this also
> had a tap with 32768 kHz on it.
>
> With a fairly slow loop and a low-noise 2^24 Hz VCXO, the DDS's clock was
> both clean and stable - and tuned in 1 Hz steps! A cheap and more-common
> 4.194304 MHz crystal would work and I suppose that a similar scheme could
> be used to lock a 32768 Hz VCXO but I've never tried to 'VCXO a tuning-fork
> crystal before:-)
>
> * * *
>
> I, too, have an older (Philips) DVR that has lost its time sync since the
> analogs went dark. For a while, I used the XDS time code that happened to
> be in the vertical interval of one of its standard definition DTV PBS
> station's sub-channels (received on a set-top box and modulated onto a TV
> channel to which the DVR would "look" for its time code) but this has code
> since been dropped.
>
> Before I discovered this, I dug up the line 21 (IIRC) code specifications
> and noted that even a PIC could probably generate the proper code,
> synchronized either from a GPS or a WWVB receiver. I'd thought about
> putting it on multiple lines and then RF modulating it for the DVR to see,
> but lost enthusiasm after I discovered the time code on the sub-channel.
> Since that went away (about a year ago) I've just remembered to set the
> clock once a month, not being able to quickly find the specs for the time
> code again online...
>
> 73,
>
> Clint
> KA7OEI
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Bill Hawkins]

Thanks for the info, Clint.

Seems like the only way to get my four Panasonic DVRs to synchronize
time is to analyze the I/O of the micro in the DVR, write interface
and HMI specs, and replace the micro with one that can talk to my
SNTP server. (Added two DVRs back when NASA was launching shuttles.)

This would have the added benefit of fixing the scheduling bugs and
make finalizing automatic for a full disk, rather than the five clicks
it takes now.

One day, the lack of sync every week will get to me, and I'll start
this project, but I don't think I'll live to finish it.

Bill Hawkins


-----Original Message-----
From: Clint Turner
Sent: Thursday, February 02, 2012 4:10 PM

-----%<----- Off subject stuff snipped

I, too, have an older (Philips) DVR that has lost its time sync since
the analogs went dark. For a while, I used the XDS time code that
happened to be in the vertical interval of one of its standard
definition DTV PBS station's sub-channels (received on a set-top box and
modulated onto a TV channel to which the DVR would "look" for its time
code) but this has code since been dropped.

Before I discovered this, I dug up the line 21 (IIRC) code
specifications and noted that even a PIC could probably generate the
proper code, synchronized either from a GPS or a WWVB receiver. I'd
thought about putting it on multiple lines and then RF modulating it for
the DVR to see, but lost enthusiasm after I discovered the time code on
the sub-channel. Since that went away (about a year ago) I've just
remembered to set the clock once a month, not being able to quickly find
the specs for the time code again online...

73,

Clint
KA7OEI

[Jim Hickstein]

> ... since the analogs went dark.

Are you near any Class-A or low-power stations? Those are still permitted to
broadcast NTSC signals. What's in their vertical interval would be a separate
question, though.

[Hal Murray]

> Remarkably, the simplest and still one of the best GPSDO I've tested was the
> 10 kHz Jupiter and analog PLL-based standard by James Miller. It performed
> superbly. It's the 4th GPSDO at: http://www.leapsecond.com/pages/gpsdo/

In hindsight, that doesn't seem too surprising.

I'm not a Juniper wizard. I could be way off here.

I'm assuming the Jupiter does phase jumps every second and uses DDS like
mechanisms within each second.

The DDS will make spurs. A simple analog filter will get rid of most of
them. What gets through will be close in. The phase jumps turn into close
in phase noise where "close" is under 1 Hz.

How would you measure that sort of phase noise?




--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> It's possible to use Bresenham with two integers 10,000,000 and 32,768 but I
> found no way to perform all the 24-bit calculations on an 8-bit PIC quick
> enough. Removing the GCD often helps but in this case the accumulator
> remains 3-bytes wide.

> To generate 32 kHz you have to toggle a pin and calculate if the next toggle
> must be 38 or 39 instructions in the future; all the math must occur within
> 37 instructions. That's why I came up with the binary leap year kind of
> algorithm; it's as close to math-less as you can get.

You missed the simple way. Table lookup. :)

The table is only 256 slots long.

That's toggling between 305 and 306 cycles. If your CPU uses N clocks per
instruction, multiply the table size by N.

In hindsight, I'm embarrassed that I didn't see this much sooner.

10,000,000 is 10^7 or 2^7 * 2^5.

32,768 is 2^15. So we need a factor of 2^8 to get back to where we started.

---------

My early introduction to the advantages of table lookup was using Fortran on
an IBM 7094. How do you calculate factorials quickly? The table is only
30-50 slots. Anything bigger generates a floating point overflow.

---------

Here is my hack python code that I had to write to see what's going on:

#!/usr/bin/python2

# Given 10 MHz, target is 32 KHz
# What sequence of DDS steps is required?
# How long is the sequence before it repeats.

import sys

Target = 32768
Input = 10000000

table = {}

X = 0
K = 0
oldI = 0

for I in range(0,Input):
X += Target
if X >= Input:
X -= Input
print "%5d %7d %5d %3d" % (K, I, X, I-oldI)
if table.has_key(X):
print "Found in table:", X
sys.exit(0)
table[X] = K
K += 1
oldI = I



--
These are my opinions, not necessarily my employer's. I hate spam.

[Orin Eman]

On Thu, Feb 2, 2012 at 7:16 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> > It's possible to use Bresenham with two integers 10,000,000 and 32,768
> but I
> > found no way to perform all the 24-bit calculations on an 8-bit PIC quick
> > enough. Removing the GCD often helps but in this case the accumulator
> > remains 3-bytes wide.
>
> > To generate 32 kHz you have to toggle a pin and calculate if the next
> toggle
> > must be 38 or 39 instructions in the future; all the math must occur
> within
> > 37 instructions. That's why I came up with the binary leap year kind of
> > algorithm; it's as close to math-less as you can get.
>
> You missed the simple way. Table lookup. :)
>
> The table is only 256 slots long.
>
> That's toggling between 305 and 306 cycles. If your CPU uses N clocks per
> instruction, multiply the table size by N.
>



Well, I thought table lookup too, but I figured a 2048 x 1 table. Easily
done with a rotating bit and 256 byte table.


Assuming clocking a PIC at 10MHz, you have 2,500,000 instructions per
second. Since there was talk about time to the next toggle, we have
2,500,000/65536 instructions between toggles, ie 38.1470... instructions.
The fraction turns out to be 301/2048, so you have to distribute 301 extra
instructions over every 2048 half-periods of the 32768Hz waveform.

Here's what I would do in a mix of C and asm:

unsigned char bitmask = 0x80;
unsigned char index = 0xFF;
unsigned char table[256] = { // Calculate using a spreadsheet or similar };
bit OutputBit;

asm {
loop:
BCF STATUS,C
RLF bitmask,F
BTFSS STATUS,C
GOTO IndexOK
RLF bitmask,F ; restore low bit from carry
INCF index,W ; on to the next byte in the table
GOTO DoLookup
IndexOK:
NOP ; equalize time in if/else cases
NOP
MOVF index,W
DoLookup:
CALL TableLookup ; Not defined here, returns value in W

ANDWF bitmask,W
BTFSS STATUS,Z
GOTO ExtraCycle ; 1 cycle if skipped, 2 if executed
ExtraCycle:
}
// Extra delay to get to 38/39 instructions (about 20 instructions if I
counted right)

OutputBit ^= 1; ; Toggle output
goto loop;

This version rotates the mask each time through and increments the index
every 8 times through. You could increment the index each time through and
rotate the mask when the index rolls over. That makes calculating the
table harder though.

No doubt I got the sense of the skips wrong or miscounted instructions
somewhere!

Orin.

[Dennis Ferguson]

On 3 Feb, 2012, at 14:15 , Orin Eman wrote:

> On Thu, Feb 2, 2012 at 7:16 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>>
>>> It's possible to use Bresenham with two integers 10,000,000 and 32,768
>> but I
>>> found no way to perform all the 24-bit calculations on an 8-bit PIC quick
>>> enough. Removing the GCD often helps but in this case the accumulator
>>> remains 3-bytes wide.
>>
>>> To generate 32 kHz you have to toggle a pin and calculate if the next
>> toggle
>>> must be 38 or 39 instructions in the future; all the math must occur
>> within
>>> 37 instructions. That's why I came up with the binary leap year kind of
>>> algorithm; it's as close to math-less as you can get.
>>
>> You missed the simple way. Table lookup. :)
>>
>> The table is only 256 slots long.
>>
>> That's toggling between 305 and 306 cycles. If your CPU uses N clocks per
>> instruction, multiply the table size by N.
>>
>
>
>
> Well, I thought table lookup too, but I figured a 2048 x 1 table. Easily
> done with a rotating bit and 256 byte table.
>
>
> Assuming clocking a PIC at 10MHz, you have 2,500,000 instructions per
> second. Since there was talk about time to the next toggle, we have
> 2,500,000/65536 instructions between toggles, ie 38.1470... instructions.
> The fraction turns out to be 301/2048, so you have to distribute 301 extra
> instructions over every 2048 half-periods of the 32768Hz waveform.

I only barely know the instruction set on those processors, but it seems
like it should be way easier than that. You know it is going to be 38 or
39 instructions, so that only question is when it should be 39. The value
of 2500000/65536 is 38.1470… in decimal, but in hex it is exactly 26.25a;
that is the 0x26 is 38 decimal while the fractional part is only 10 bits
long. This means you should be able to compute when the extra cycle is
required by keeping a 16 bit accumulator to which the fractional part
0x25a0 is added at every change and executing the extra instruction when
there is a carry out of that. The seems straight forward. If `lo' and `hi'
are the two halves of the accumulator then the working part of this becomes
something like (excusing my PIC assembler, which I mostly forget):

movl 0xa0,w // low byte of increment into w
add w,lo // add w to lo, may set carry
movl 0x25,w // high byte of increment into w
btfsc 3,0 // skip next if carry clear
add one,w // increment w by one; I'm not sure how to do that
add w,hi // add w to hi, may set carry
// if carry set here need extra instruction. Maybe this does it?
btfss 3,0 // skip if carry set
goto blorp // carry clear, don't execute next instruction
nop // the extra instruction
blorp:
// enough instructions more to make 38/39

Maybe someone who knows what they're doing can interpret that?

Dennis Ferguson

[Orin Eman]

On Fri, Feb 3, 2012 at 1:08 AM, Dennis Ferguson <dennis.c.ferguson-***@public.gmane.org
> wrote:

>
> On 3 Feb, 2012, at 14:15 , Orin Eman wrote:
>
> > On Thu, Feb 2, 2012 at 7:16 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org>
> wrote:
> >
> >>
> >>> It's possible to use Bresenham with two integers 10,000,000 and 32,768
> >> but I
> >>> found no way to perform all the 24-bit calculations on an 8-bit PIC
> quick
> >>> enough. Removing the GCD often helps but in this case the accumulator
> >>> remains 3-bytes wide.
> >>
> >>> To generate 32 kHz you have to toggle a pin and calculate if the next
> >> toggle
> >>> must be 38 or 39 instructions in the future; all the math must occur
> >> within
> >>> 37 instructions. That's why I came up with the binary leap year kind of
> >>> algorithm; it's as close to math-less as you can get.
> >>
> >> You missed the simple way. Table lookup. :)
> >>
> >> The table is only 256 slots long.
> >>
> >> That's toggling between 305 and 306 cycles. If your CPU uses N clocks
> per
> >> instruction, multiply the table size by N.
> >>
> >
> >
> >
> > Well, I thought table lookup too, but I figured a 2048 x 1 table.
> Easily
> > done with a rotating bit and 256 byte table.
> >
> >
> > Assuming clocking a PIC at 10MHz, you have 2,500,000 instructions per
> > second. Since there was talk about time to the next toggle, we have
> > 2,500,000/65536 instructions between toggles, ie 38.1470... instructions.
> > The fraction turns out to be 301/2048, so you have to distribute 301
> extra
> > instructions over every 2048 half-periods of the 32768Hz waveform.
>
> I only barely know the instruction set on those processors, but it seems
> like it should be way easier than that. You know it is going to be 38 or
> 39 instructions, so that only question is when it should be 39. The value
> of 2500000/65536 is 38.1470… in decimal, but in hex it is exactly 26.25a;
> that is the 0x26 is 38 decimal while the fractional part is only 10 bits
> long. This means you should be able to compute when the extra cycle is
> required by keeping a 16 bit accumulator to which the fractional part
> 0x25a0 is added at every change and executing the extra instruction when
> there is a carry out of that. The seems straight forward. If `lo' and `hi'
> are the two halves of the accumulator then the working part of this becomes
> something like (excusing my PIC assembler, which I mostly forget):
>
> movl 0xa0,w // low byte of increment into w
> add w,lo // add w to lo, may set carry
> movl 0x25,w // high byte of increment into w
> btfsc 3,0 // skip next if carry clear
> add one,w // increment w by one; I'm not sure how to do that
> add w,hi // add w to hi, may set carry
> // if carry set here need extra instruction. Maybe this does it?
> btfss 3,0 // skip if carry set
> goto blorp // carry clear, don't execute next instruction
> nop // the extra instruction
> blorp:
> // enough instructions more to make 38/39
>
> Maybe someone who knows what they're doing can interpret that?
>


Here you go:

movlw 0xa0
addwf lo,f
movlw 0x25
btfsc status,C
addlw 1 ; or movlw 0x26
addwf hi,f
btfss status,C
goto skip
nop
nop
skip:


Takes 9 or 10 instruction cycles. You needed an extra nop as the goto
takes two cycles, one cycle if skipped. I'd just reverse the sense as
follows:

btfsc status,C
goto skip
skip:

If carry is clear, skipping the goto takes one instruction cycle. If carry
is set, executing the goto takes two instruction cycles. Yes, the goto is
to the next inline instruction, but as far as I know, the PIC doesn't
optimise that. The entire sequence in this case would take 8 or 9
instruction cycles.

I'd forgotten the trick of using binary fixed point arithmetic with the
fractional part strategically placed at a byte boundary! I've used a
similar trick in the past to convert a binary fraction into decimal digits
- keep multiplying by 10 (a couple of shifts plus an add), pick up the
non-fractional bits as the next decimal digit, then truncate to the
remaining fractional bits.

Orin.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> I'm curious how a 10 MHz-driven high-end DDS would generate 32 kHz with the
> lowest possible jitter?

What do you mean by high-end DDS? A chip from Analog Devices or one from
Xilinx? :)

If you use a classic DDS chip with a binary adder and ROM, it will have low
jitter but the frequency will be off a tiny bit. My calculations...

24 bits:
54975 => 32767.653465
54976 => 32768.249511

32 bits:
14073748 => 32767.998054
14073749 => 32768.000382


If you use a FPGA, it's something like this:
X = X + 32768
If X >= 10000000
output clock pulse
X = X - 10000000

You get the subtract for free if you are using decimal arithmetic and ignore
the overflow. You can do it with binary addition if you pipeline things
right and put a mux in front of the adder. It either adds 32K or adds
(32K-10M).

That makes a 1 clock wide clock pulse, 100 ns at 10 MHz. If you want a
square clock, make a 2X clock and toggle a FF to divide by 2.

It will have the right long term frequency, or at least as good as the input
clock.

It will have lots of jitter. It's not Gaussian type jitter but spurs.
Peak-to-peak will be roughly one clock period.

------

I don't know how to compute the jitter on traditional (binary, ROM) DDS
chips. Peak to peak will also be roughly one clock period in the raw output,
but the output is close to a sine wave so some filtering would easily reduce
the jitter.

I'm pretty sure they have spurs and that they are smaller and farther out if
the ROM is wider and deeper.

Both DDS chips and FPGAs usually contain a PLL/DLL to get a faster internal clock rate. That would reduce jitter.

I don't know enough matlab to be able to simulate this. Another time sink when I get the time.


--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> So one has to be careful how you handle this information. There is always
> that awkward time, which we are now in, between when a future leap second
> is announced and the actual month in which it occurs. It never fails that
> some user or software misinterprets the IERS or GPS leap second announcement
> and adds a leap second at the end of one or more months prior to the correct
> one.

I just checked the user manual for the Z3801A. I didn't find anything about
when the leap second will happen.

Last time we had one, I fixed the NTP driver for the Z3801A so it would
ignore leap-pending except if the current month was June or December. I
considered doing something more complicated, but that seemed more likely to
introduce bugs.

I predict things will get "interesting" when the IERS announces the first
leap second in March or September. Anybody want to guess how many Z3801As
will still be running then?

That driver also works with the HP/Agilent 58503A. They will probably be
around longer. Symmetricom didn't drop the 58503B until 2008.




--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> If this is for a computer and NTP then you may ignore the sawtooth.

> GPS receiver sawtooth corrections are for people working at the nanosecond
> level; important when you're working with disciplining quartz or rubidium
> oscillators with stability at the 1e-12 level.

> Computer timekeeping and NTP is a million times worse than this.

I think you are off by a few orders of magnitude. A million ns is a ms.
It's easy to get NTP running much than that.

I agree that most systems running NTP are unlikely to notice the sawtooth
correction, but this is time-nuts.

Have the PTP guys gotten good enough to notice hanging bridges yet? (as the
phase of their clocks drifts)


--
These are my opinions. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> http://www.ausairpower.net/Block-IIR-M-SV-1S.jpg

What is the significance of the pointy tops of the long skinny antennas?

How about the collars at the base of them?


--
These are my opinions. I hate spam.

[Chris Albertson]

On Mon, Jun 4, 2012 at 10:18 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
> What is the significance of the pointy tops of the long skinny antennas?
>

Guessing. Terminates the end of the conductor to prevent a discontinuity
and reflection

How about the collars at the base of them?
>

Another guess: They kill multi path reflections from supporting structure

Now let's see what the experts say

Chris Albertson
Redondo Beach, California

[Jim Lux]

On 6/4/12 10:44 PM, Chris Albertson wrote:
> On Mon, Jun 4, 2012 at 10:18 PM, Hal Murray<hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>>
>> What is the significance of the pointy tops of the long skinny antennas?
>>
>
> Guessing. Terminates the end of the conductor to prevent a discontinuity
> and reflection

more likely it's for structural reasons. A lot of helical antennas are a
wire or tape on a cruciform cross section core (rather than on a tube).
You don't want that corner sticking out.
On the tube, it's easier to make a cone end, then a flat pillbox, and
you don't have the diaphragm vibration mode on the flat end.

>
> How about the collars at the base of them?
>>
>
> Another guess: They kill multi path reflections from supporting structure

or provide a better match. Or both..

An awful lot of antenna designs out there work about the same,
particularly for endfire helicals, so if you have a design that works in
one application and you want to change it, you might just scale for
size, rather than trying to come up with a completely new design.

it's like the HeliBowl antennas.. Turns out they're totally non critical
and they all work just about the same. Plastic party cup and cheap
mixing bowl, and you're in business.


Broadside short helices, particularly quad helices are a bit trickier,
especially if you're using the "one pair a bit long and the other pair a
bit short" to get the 90 degree phasing.

[Attila Kinali]

On Mon, 04 Jun 2012 23:11:14 -0700
Jim Lux <jimlux-***@public.gmane.org> wrote:

> On 6/4/12 10:44 PM, Chris Albertson wrote:
> > On Mon, Jun 4, 2012 at 10:18 PM, Hal Murray<hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
> >>
> >> What is the significance of the pointy tops of the long skinny antennas?
> >>
> >
> > Guessing. Terminates the end of the conductor to prevent a discontinuity
> > and reflection

Or maybe better adaption to free space impedance....

>
> more likely it's for structural reasons. A lot of helical antennas are a
> wire or tape on a cruciform cross section core (rather than on a tube).
> You don't want that corner sticking out.
> On the tube, it's easier to make a cone end, then a flat pillbox, and
> you don't have the diaphragm vibration mode on the flat end.

Do you mean that the end of the cruciform helix does vibrate and that a
cone that ties the end at the center is free of that vibration?

> >
> > How about the collars at the base of them?
> >>
> >
> > Another guess: They kill multi path reflections from supporting structure
>
> or provide a better match. Or both..

According to a paper on GPS i've read recently, it's to better control
the side and back lobes of the signal. The graphs showed quite some
improvement of the radiation pattern. If anyone is interested, i can
look up the name of the paper.


Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> It doesn't often matter to me if that information resides on personal
> servers, or a KO4BB wiki, or as occasional postings to the time-nuts mailing
> list. Google does the work of finding it regardless. The key point is that
> people take the time to document and share what they've learned so google
> has something interesting to find.

My 2 cents...

It really helps if there is a FAQ or Wiki type starter page. It doesn't have
to say everything. It should have many links to other web pages. The idea
is some place that is reasonably high-quality where you can get started.

Sure, google will find stuff, but you have to know what to search for. A
FAQ/Wiki starting page tells you the terms you might want to search for.

For example, if you were a beginner time-nut, how would you know that you
should search for TBolt or Thunerbolt and that if you searched for
Thunderbolt you needed to add Trimble or you would get a lot of other junk?

A glossary can also be a wonderful resource. Again, it can have links to
other info, but a quick description tells you whether that is a term you are
interested in and/or how it fits in.


--
These are my opinions. I hate spam.

[Tom Van Baak]

Hi Hal,

Good suggestions. Let me consider them.

BTW, the best time & frequency glossary on the web so far is at:
http://tf.nist.gov/general/glossary.htm
There's also an index at:
http://tf.nist.gov/general/enc-index.htm

Another newcomer must-read is this excellent T&F tutorial by NIST:
http://tf.nist.gov/phase/Properties/main.htm
"Properties of Oscillator Signals and Measurement Methods" FAQ
- What is frequency stability?
- How do I measure frequency stability?
- How do I analyze the data?
- What is an example of time domain signal processing and analysis?
- What is spectrum analysis?
- What are the problems with digitizing the data?
- How do I translate between frequency domain and time domain?
- What causes noise in a signal?

Thanks,
/tvb

Hal Murray" <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
> It really helps if there is a FAQ or Wiki type starter page. It doesn't have
> to say everything. It should have many links to other web pages. The idea
> is some place that is reasonably high-quality where you can get started.
>
> Sure, google will find stuff, but you have to know what to search for. A
> FAQ/Wiki starting page tells you the terms you might want to search for.
>
> For example, if you were a beginner time-nut, how would you know that you
> should search for TBolt or Thunerbolt and that if you searched for
> Thunderbolt you needed to add Trimble or you would get a lot of other junk?
>
> A glossary can also be a wonderful resource. Again, it can have links to
> other info, but a quick description tells you whether that is a term you are
> interested in and/or how it fits in.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> BTW, the best time & frequency glossary on the web so far is at:
> http://tf.nist.gov/general/glossary.htm
> There's also an index at:
> http://tf.nist.gov/general/enc-index.htm

That's a good example of a point I didn't make last time...

Official sites like NIST usually don't do a good job of linking out to other
sites. When they do, they often go to official or manufacturers sites rather
than informal/amateur sites.

That's not bad, but it might not help newbies find places like time-nuts when
they are trying to get started.


I should have mentioned that there is nothing wrong with having multiple
FAQ/Wiki sites run by amateurs. The trick is that they usually cross-link to
each other. If google (or dumb luck) takes you to one, that usually helps
you find the others.


--
These are my opinions. I hate spam.

[Azelio Boriani]

And don't forget those NTP people. BTW, is there an NTP packet exchange
example? That is, what is the typical "conversation" between an NTP server
and a client?

On Mon, Oct 22, 2012 at 7:28 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> tvb-AeR/***@public.gmane.org said:
> > BTW, the best time & frequency glossary on the web so far is at:
> > http://tf.nist.gov/general/glossary.htm
> > There's also an index at:
> > http://tf.nist.gov/general/enc-index.htm
>
> That's a good example of a point I didn't make last time...
>
> Official sites like NIST usually don't do a good job of linking out to
> other
> sites. When they do, they often go to official or manufacturers sites
> rather
> than informal/amateur sites.
>
> That's not bad, but it might not help newbies find places like time-nuts
> when
> they are trying to get started.
>
>
> I should have mentioned that there is nothing wrong with having multiple
> FAQ/Wiki sites run by amateurs. The trick is that they usually cross-link
> to
> each other. If google (or dumb luck) takes you to one, that usually helps
> you find the others.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

[Edgardo Molina]

Dear Azelio,

Count on me for that. I am doing my thesis in network synchronization and NTP will be the main course. I will be posting a brief of the thesis and all related information in my soon to be published web page. I dream NTP now…

Regards,



Edgardo Molina
Dirección IPTEL

www.iptel.net.mx

T : 55 55 55202444
M : 04455 20501854

Piensa en Bits SA de CV



Información anexa:




CONFIDENCIALIDAD DE INFORMACION

Este mensaje tiene carácter confidencial. Si usted no es el destinarario de este mensaje, le suplicamos se lo notifique al remitente mediante un correo electrónico y que borre el presente mensaje y sus anexos de su computadora sin retener una copia de los mismos. Queda estrictamente prohibido copiar este mensaje o hacer usode el para cualquier propósito o divulgar su en forma parcial o total su contenido. Gracias.


NON-DISCLOSURE OF INFORMATION

This email is strictly confidential and may also be privileged. If you are not the intended recipient please immediately advise the sender by replying to this e-mail and then deleting the message and its attachments from your computer without keeping a copy. It is strictly forbidden to copy it or use it for any purpose or disclose its contents to any third party. Thank you.





On Oct 22, 2012, at 3:14 AM, Azelio Boriani <azelio.boriani-***@public.gmane.org> wrote:

> And don't forget those NTP people. BTW, is there an NTP packet exchange
> example? That is, what is the typical "conversation" between an NTP server
> and a client?
>
> On Mon, Oct 22, 2012 at 7:28 AM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>>
>> tvb-AeR/***@public.gmane.org said:
>>> BTW, the best time & frequency glossary on the web so far is at:
>>> http://tf.nist.gov/general/glossary.htm
>>> There's also an index at:
>>> http://tf.nist.gov/general/enc-index.htm
>>
>> That's a good example of a point I didn't make last time...
>>
>> Official sites like NIST usually don't do a good job of linking out to
>> other
>> sites. When they do, they often go to official or manufacturers sites
>> rather
>> than informal/amateur sites.
>>
>> That's not bad, but it might not help newbies find places like time-nuts
>> when
>> they are trying to get started.
>>
>>
>> I should have mentioned that there is nothing wrong with having multiple
>> FAQ/Wiki sites run by amateurs. The trick is that they usually cross-link
>> to
>> each other. If google (or dumb luck) takes you to one, that usually helps
>> you find the others.
>>
>>
>> --
>> These are my opinions. I hate spam.
>>
>>
>>
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts-***@public.gmane.org
>> 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-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> I should also mention the choice to have John Ackermann host the list (free)
> along with all the TAPR mailing lists has proven itself again and again. Few
> entities on the web have been this solid for a decade. A couple of times a
> year we have trouble with S/N ratio, but those tend to be short lived.

Many thanks to Tom and John.



--
These are my opinions. I hate spam.

[Hal Murray]

> A fifth solution is to use a pulse delay generator like a DG535. I use this
> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
> but aren't cheap. For bargains, watch for older model programmable pulse
> delay generators by BNC (Berkeley Nucleonics Corporation).

Thanks. Those are more $$$ than I'm interested in right now, but might be a
useful tool sometime in the future.

Another approach is to use a scope: trigger on one PPS and adjust the delay
(which might be negative) and sweep speed so you can see the other PPS
signal. Maybe I'll play with this to see what sort of results I can get.


> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
> that might work. Not sure how stable they are at the ns level. But it would
> be fun to measure. If someone opens one of these please tell us if it's a
> coil of wire, some kind of LRC filter delay, or if they use those Dallas
> delay chips. Which is another solution for you -- google or eBay search for:
> silicon delay line.

You can make a reasonable delay line by using the lumped circuit
approximation for the L and C for the appropriate impedance transmission
line. I assume that's what's in the delay boxes. I should try that
sometime. Thanks for the reminder.

The delay chips I've looked at before used gate delays. I think they were
Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
didn't find out how they implemented the delays.

I think some of the clock recovery chips tune delays by tweaking the
threshold voltage.


--
These are my opinions. I hate spam.

[David]

On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
<hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>> but aren't cheap. For bargains, watch for older model programmable pulse
>> delay generators by BNC (Berkeley Nucleonics Corporation).
>
>Thanks. Those are more $$$ than I'm interested in right now, but might be a
>useful tool sometime in the future.
>
>Another approach is to use a scope: trigger on one PPS and adjust the delay
>(which might be negative) and sweep speed so you can see the other PPS
>signal. Maybe I'll play with this to see what sort of results I can get.
>
>
>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>> that might work. Not sure how stable they are at the ns level. But it would
>> be fun to measure. If someone opens one of these please tell us if it's a
>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>> delay chips. Which is another solution for you -- google or eBay search for:
>> silicon delay line.
>
>You can make a reasonable delay line by using the lumped circuit
>approximation for the L and C for the appropriate impedance transmission
>line. I assume that's what's in the delay boxes. I should try that
>sometime. Thanks for the reminder.
>
>The delay chips I've looked at before used gate delays. I think they were
>Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
>didn't find out how they implemented the delays.
>
>I think some of the clock recovery chips tune delays by tweaking the
>threshold voltage.

I have been testing just using adjustable RC delays into a logic gate
to generate pretrigger pulses for sampling oscilloscopes. Accuracy
depends on a complete reset of the capacitor and tracking between the
RC charge voltage and gate threshold voltage. Worst cast jitter for
TTL has been in the 100s of picoseconds range because of supply
voltage sensitivity. Different families of TTL and CMOS logic all
performed about the same.

Here is the jitter measurement that came from the RC logic gate delay
test:

http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg

Much better is to use a differential comparator or differential input
ECL which solves the threshold variation errors and a fast (it really
isn't all that fast) ramp generator with a precision reset. The
differential input allows the ramp rate and threshold voltage to be
linked allowing ratiometric operation to reject power supply or
reference voltage variation and noise.

My next pretrigger generator is going the differential comparator or
differential ECL route with a fast ramp and precision reset. I expect
jitter to be significantly better than 10s of picoseconds for delays
up to about 100 nanoseconds. If I get down to 10 picoseconds of
jitter, I will be happy since I have no real way to measure much below
that.

[Bob Camp]

Hi

With R-C delay generators, temperature coefficient is likely to be an issue. NPO will get you to 30 ppm/C. Most resistors will be up in the 50 or so ppm / C range. On top of that you have the contributions of what ever strays might be running around.

If you are trying to set up say a 1 us delay, you will get ~ 50 ps per degree C in your delay. That's a lot .....

Bob

On Dec 17, 2012, at 1:56 PM, David <davidwhess-***@public.gmane.org> wrote:

> On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
> <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>>
>>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>>> but aren't cheap. For bargains, watch for older model programmable pulse
>>> delay generators by BNC (Berkeley Nucleonics Corporation).
>>
>> Thanks. Those are more $$$ than I'm interested in right now, but might be a
>> useful tool sometime in the future.
>>
>> Another approach is to use a scope: trigger on one PPS and adjust the delay
>> (which might be negative) and sweep speed so you can see the other PPS
>> signal. Maybe I'll play with this to see what sort of results I can get.
>>
>>
>>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>>> that might work. Not sure how stable they are at the ns level. But it would
>>> be fun to measure. If someone opens one of these please tell us if it's a
>>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>>> delay chips. Which is another solution for you -- google or eBay search for:
>>> silicon delay line.
>>
>> You can make a reasonable delay line by using the lumped circuit
>> approximation for the L and C for the appropriate impedance transmission
>> line. I assume that's what's in the delay boxes. I should try that
>> sometime. Thanks for the reminder.
>>
>> The delay chips I've looked at before used gate delays. I think they were
>> Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
>> didn't find out how they implemented the delays.
>>
>> I think some of the clock recovery chips tune delays by tweaking the
>> threshold voltage.
>
> I have been testing just using adjustable RC delays into a logic gate
> to generate pretrigger pulses for sampling oscilloscopes. Accuracy
> depends on a complete reset of the capacitor and tracking between the
> RC charge voltage and gate threshold voltage. Worst cast jitter for
> TTL has been in the 100s of picoseconds range because of supply
> voltage sensitivity. Different families of TTL and CMOS logic all
> performed about the same.
>
> Here is the jitter measurement that came from the RC logic gate delay
> test:
>
> http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg
>
> Much better is to use a differential comparator or differential input
> ECL which solves the threshold variation errors and a fast (it really
> isn't all that fast) ramp generator with a precision reset. The
> differential input allows the ramp rate and threshold voltage to be
> linked allowing ratiometric operation to reject power supply or
> reference voltage variation and noise.
>
> My next pretrigger generator is going the differential comparator or
> differential ECL route with a fast ramp and precision reset. I expect
> jitter to be significantly better than 10s of picoseconds for delays
> up to about 100 nanoseconds. If I get down to 10 picoseconds of
> jitter, I will be happy since I have no real way to measure much below
> that.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[David]

You would not want to do this for long delays obviously. A digital
counter with the delay used as a vernier would be more appropriate
there. That gets complicated fast if the input is asynchronous.

Analog first order compensation of the temperature coefficient is
straightforward using the same techniques that are used for voltage to
frequency converters. Unfortunately, polystyrene capacitors are no
longer produced. Digital calibration might be easier to design and
would be a good idea for verification of performance anyway.

I wonder what the temperature coefficient is of the Maxim's
programmable delay lines. I do not see it in their datasheets. The
On semiconductor one I checked is greater than 1000ppm/C but its
maximum delay is 12.5 nanoseconds.

On Mon, 17 Dec 2012 14:04:54 -0500, Bob Camp <lists-***@public.gmane.org> wrote:

>Hi
>
>With R-C delay generators, temperature coefficient is likely to be an issue. NPO will get you to 30 ppm/C. Most resistors will be up in the 50 or so ppm / C range. On top of that you have the contributions of what ever strays might be running around.
>
>If you are trying to set up say a 1 us delay, you will get ~ 50 ps per degree C in your delay. That's a lot .....
>
>Bob
>
>On Dec 17, 2012, at 1:56 PM, David <davidwhess-***@public.gmane.org> wrote:
>
>> On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
>> <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>>
>>>
>>>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>>>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>>>> but aren't cheap. For bargains, watch for older model programmable pulse
>>>> delay generators by BNC (Berkeley Nucleonics Corporation).
>>>
>>> Thanks. Those are more $$$ than I'm interested in right now, but might be a
>>> useful tool sometime in the future.
>>>
>>> Another approach is to use a scope: trigger on one PPS and adjust the delay
>>> (which might be negative) and sweep speed so you can see the other PPS
>>> signal. Maybe I'll play with this to see what sort of results I can get.
>>>
>>>
>>>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>>>> that might work. Not sure how stable they are at the ns level. But it would
>>>> be fun to measure. If someone opens one of these please tell us if it's a
>>>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>>>> delay chips. Which is another solution for you -- google or eBay search for:
>>>> silicon delay line.
>>>
>>> You can make a reasonable delay line by using the lumped circuit
>>> approximation for the L and C for the appropriate impedance transmission
>>> line. I assume that's what's in the delay boxes. I should try that
>>> sometime. Thanks for the reminder.
>>>
>>> The delay chips I've looked at before used gate delays. I think they were
>>> Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
>>> didn't find out how they implemented the delays.
>>>
>>> I think some of the clock recovery chips tune delays by tweaking the
>>> threshold voltage.
>>
>> I have been testing just using adjustable RC delays into a logic gate
>> to generate pretrigger pulses for sampling oscilloscopes. Accuracy
>> depends on a complete reset of the capacitor and tracking between the
>> RC charge voltage and gate threshold voltage. Worst cast jitter for
>> TTL has been in the 100s of picoseconds range because of supply
>> voltage sensitivity. Different families of TTL and CMOS logic all
>> performed about the same.
>>
>> Here is the jitter measurement that came from the RC logic gate delay
>> test:
>>
>> http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg
>>
>> Much better is to use a differential comparator or differential input
>> ECL which solves the threshold variation errors and a fast (it really
>> isn't all that fast) ramp generator with a precision reset. The
>> differential input allows the ramp rate and threshold voltage to be
>> linked allowing ratiometric operation to reject power supply or
>> reference voltage variation and noise.
>>
>> My next pretrigger generator is going the differential comparator or
>> differential ECL route with a fast ramp and precision reset. I expect
>> jitter to be significantly better than 10s of picoseconds for delays
>> up to about 100 nanoseconds. If I get down to 10 picoseconds of
>> jitter, I will be happy since I have no real way to measure much below
>> that.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts-***@public.gmane.org
>> 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-***@public.gmane.org
>To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.

[Bob Camp]

Hi

I believe you will find that NPO's are your best bet by far for short delays.

The R's and C's on a simple semi are going to have some pretty major tempco's. If they go with a fancy process they can change that. Normally to keep things cheap they use the simple process.

Bob

On Dec 17, 2012, at 2:55 PM, David <davidwhess-***@public.gmane.org> wrote:

> You would not want to do this for long delays obviously. A digital
> counter with the delay used as a vernier would be more appropriate
> there. That gets complicated fast if the input is asynchronous.
>
> Analog first order compensation of the temperature coefficient is
> straightforward using the same techniques that are used for voltage to
> frequency converters. Unfortunately, polystyrene capacitors are no
> longer produced. Digital calibration might be easier to design and
> would be a good idea for verification of performance anyway.
>
> I wonder what the temperature coefficient is of the Maxim's
> programmable delay lines. I do not see it in their datasheets. The
> On semiconductor one I checked is greater than 1000ppm/C but its
> maximum delay is 12.5 nanoseconds.
>
> On Mon, 17 Dec 2012 14:04:54 -0500, Bob Camp <lists-***@public.gmane.org> wrote:
>
>> Hi
>>
>> With R-C delay generators, temperature coefficient is likely to be an issue. NPO will get you to 30 ppm/C. Most resistors will be up in the 50 or so ppm / C range. On top of that you have the contributions of what ever strays might be running around.
>>
>> If you are trying to set up say a 1 us delay, you will get ~ 50 ps per degree C in your delay. That's a lot .....
>>
>> Bob
>>
>> On Dec 17, 2012, at 1:56 PM, David <davidwhess-***@public.gmane.org> wrote:
>>
>>> On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
>>> <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>>>
>>>>
>>>>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>>>>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>>>>> but aren't cheap. For bargains, watch for older model programmable pulse
>>>>> delay generators by BNC (Berkeley Nucleonics Corporation).
>>>>
>>>> Thanks. Those are more $$$ than I'm interested in right now, but might be a
>>>> useful tool sometime in the future.
>>>>
>>>> Another approach is to use a scope: trigger on one PPS and adjust the delay
>>>> (which might be negative) and sweep speed so you can see the other PPS
>>>> signal. Maybe I'll play with this to see what sort of results I can get.
>>>>
>>>>
>>>>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>>>>> that might work. Not sure how stable they are at the ns level. But it would
>>>>> be fun to measure. If someone opens one of these please tell us if it's a
>>>>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>>>>> delay chips. Which is another solution for you -- google or eBay search for:
>>>>> silicon delay line.
>>>>
>>>> You can make a reasonable delay line by using the lumped circuit
>>>> approximation for the L and C for the appropriate impedance transmission
>>>> line. I assume that's what's in the delay boxes. I should try that
>>>> sometime. Thanks for the reminder.
>>>>
>>>> The delay chips I've looked at before used gate delays. I think they were
>>>> Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
>>>> didn't find out how they implemented the delays.
>>>>
>>>> I think some of the clock recovery chips tune delays by tweaking the
>>>> threshold voltage.
>>>
>>> I have been testing just using adjustable RC delays into a logic gate
>>> to generate pretrigger pulses for sampling oscilloscopes. Accuracy
>>> depends on a complete reset of the capacitor and tracking between the
>>> RC charge voltage and gate threshold voltage. Worst cast jitter for
>>> TTL has been in the 100s of picoseconds range because of supply
>>> voltage sensitivity. Different families of TTL and CMOS logic all
>>> performed about the same.
>>>
>>> Here is the jitter measurement that came from the RC logic gate delay
>>> test:
>>>
>>> http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg
>>>
>>> Much better is to use a differential comparator or differential input
>>> ECL which solves the threshold variation errors and a fast (it really
>>> isn't all that fast) ramp generator with a precision reset. The
>>> differential input allows the ramp rate and threshold voltage to be
>>> linked allowing ratiometric operation to reject power supply or
>>> reference voltage variation and noise.
>>>
>>> My next pretrigger generator is going the differential comparator or
>>> differential ECL route with a fast ramp and precision reset. I expect
>>> jitter to be significantly better than 10s of picoseconds for delays
>>> up to about 100 nanoseconds. If I get down to 10 picoseconds of
>>> jitter, I will be happy since I have no real way to measure much below
>>> that.
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts-***@public.gmane.org
>>> 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-***@public.gmane.org
>> 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-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[M. Simon]

Nice pulse delay generator:

http://www.edn.com/file/14660-Figure_1.pdf

The article that goes with it:

http://www.edn.com/design/analog/4323671/Dual-flip-flop-forms-simple-delayed-pulse-generator


The delay is analog - charging a capacitor until it crosses a threshold. So I don't know if it is good enough. But I did find it interesting. The order of the delay is 1 to 250 uSec. Faster parts would get you into shorter delays.

If you had two of these operating on a common trigger...

Simon


Engineering is the art of making what you want from what you can get at a profit.



>________________________________
> From: David <davidwhess-***@public.gmane.org>
>To: Discussion of precise time and frequency measurement <time-***@febo.com>
>Sent: Monday, December 17, 2012 6:56 PM
>Subject: Re: [time-nuts] Comparing PPS from 2 GPS units
>
>On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
><hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>>
>>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>>> but aren't cheap. For bargains, watch for older model programmable pulse
>>> delay generators by BNC (Berkeley Nucleonics Corporation).
>>
>>Thanks.  Those are more $$$ than I'm interested in right now, but might be a
>>useful tool sometime in the future.
>>
>>Another approach is to use a scope: trigger on one PPS and adjust the delay
>>(which might be negative) and sweep speed so you can see the other PPS
>>signal.  Maybe I'll play with this to see what sort of results I can get.
>>
>>
>>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>>> that might work. Not sure how stable they are at the ns level. But it would
>>> be fun to measure. If someone opens one of these please tell us if it's a
>>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>>> delay chips. Which is another solution for you -- google or eBay search for:
>>> silicon delay line.
>>
>>You can make a reasonable delay line by using the lumped circuit
>>approximation for the L and C for the appropriate impedance transmission
>>line.  I assume that's what's in the delay boxes.  I should try that
>>sometime.  Thanks for the reminder.
>>
>>The delay chips I've looked at before used gate delays.  I think they were
>>Motorola rather than Dallas.  I just poked at a few Maxim data sheets.  I
>>didn't find out how they implemented the delays.
>>
>>I think some of the clock recovery chips tune delays by tweaking the
>>threshold voltage.
>
>I have been testing just using adjustable RC delays into a logic gate
>to generate pretrigger pulses for sampling oscilloscopes.  Accuracy
>depends on a complete reset of the capacitor and tracking between the
>RC charge voltage and gate threshold voltage.  Worst cast jitter for
>TTL has been in the 100s of picoseconds range because of supply
>voltage sensitivity.  Different families of TTL and CMOS logic all
>performed about the same.
>
>Here is the jitter measurement that came from the RC logic gate delay
>test:
>
>http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg
>
>Much better is to use a differential comparator or differential input
>ECL which solves the threshold variation errors and a fast (it really
>isn't all that fast) ramp generator with a precision reset.  The
>differential input allows the ramp rate and threshold voltage to be
>linked allowing ratiometric operation to reject power supply or
>reference voltage variation and noise.
>
>My next pretrigger generator is going the differential comparator or
>differential ECL route with a fast ramp and precision reset.  I expect
>jitter to be significantly better than 10s of picoseconds for delays
>up to about 100 nanoseconds.  If I get down to 10 picoseconds of
>jitter, I will be happy since I have no real way to measure much below
>that.
>
>_______________________________________________
>time-nuts mailing list -- time-nuts-***@public.gmane.org
>To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.
>
>
>

[Bruce Griffiths]

Its actually a relatively low performance implementation of a classic
technique.
The ramp capacitor reset switch (a saturated transistor) has a
relatively slow turnoff and poorly defined reset voltage.

For shorter time delays lower capacitance current source and reset
devices are required.

Decoupling of the current sensing device in the control loop from the
current source device emitter is desirable.

ECL delay chips using this technique complete with a DAC to set the
comparator threshold used to be available.

A classic reset switch uses a current driven pair of matched shottky
diodes to ensure fast switching coupled with a relatively low offset
voltage.

Techniques to produce stable longer delays:

1) Use a stable (phase locked) gated oscillator to produce a well
defined long delay using pulse counting together with a triggered ramp +
DAC + comparator for fine adjustment.
The HP5359A delay generator is an example of this technique.

2) Use a synchroniser plus counter for the coarse delay followed by a
triggered ramp + DAC and comparator.
The synchroniser delay is measured and the result used to adjust the
fine delay to compensate for the variable synchroniser delay.
Analog techniques where the fine delay ramp is stopped and held by the
synchroniser outpt and then resumed by the digital delay output
transition have also been used.


Bruce

M. Simon wrote:
> Nice pulse delay generator:
>
> http://www.edn.com/file/14660-Figure_1.pdf
>
> The article that goes with it:
>
> http://www.edn.com/design/analog/4323671/Dual-flip-flop-forms-simple-delayed-pulse-generator
>
>
> The delay is analog - charging a capacitor until it crosses a threshold. So I don't know if it is good enough. But I did find it interesting. The order of the delay is 1 to 250 uSec. Faster parts would get you into shorter delays.
>
> If you had two of these operating on a common trigger...
>
> Simon
>
>
> Engineering is the art of making what you want from what you can get at a profit.
>
>
>
>
>> ________________________________
>> From: David<davidwhess-***@public.gmane.org>
>> To: Discussion of precise time and frequency measurement<time-nuts-***@public.gmane.org>
>> Sent: Monday, December 17, 2012 6:56 PM
>> Subject: Re: [time-nuts] Comparing PPS from 2 GPS units
>>
>> On Mon, 17 Dec 2012 10:19:43 -0800, Hal Murray
>> <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>>
>>
>>>
>>>> A fifth solution is to use a pulse delay generator like a DG535. I use this
>>>> to create high-resolution early/late 1PPS sync pulses. They show up on eBay,
>>>> but aren't cheap. For bargains, watch for older model programmable pulse
>>>> delay generators by BNC (Berkeley Nucleonics Corporation).
>>>>
>>> Thanks. Those are more $$$ than I'm interested in right now, but might be a
>>> useful tool sometime in the future.
>>>
>>> Another approach is to use a scope: trigger on one PPS and adjust the delay
>>> (which might be negative) and sweep speed so you can see the other PPS
>>> signal. Maybe I'll play with this to see what sort of results I can get.
>>>
>>>
>>>
>>>> Lastly, there are cute little delay boxes (www.ebay.com/itm/150962422699)
>>>> that might work. Not sure how stable they are at the ns level. But it would
>>>> be fun to measure. If someone opens one of these please tell us if it's a
>>>> coil of wire, some kind of LRC filter delay, or if they use those Dallas
>>>> delay chips. Which is another solution for you -- google or eBay search for:
>>>> silicon delay line.
>>>>
>>> You can make a reasonable delay line by using the lumped circuit
>>> approximation for the L and C for the appropriate impedance transmission
>>> line. I assume that's what's in the delay boxes. I should try that
>>> sometime. Thanks for the reminder.
>>>
>>> The delay chips I've looked at before used gate delays. I think they were
>>> Motorola rather than Dallas. I just poked at a few Maxim data sheets. I
>>> didn't find out how they implemented the delays.
>>>
>>> I think some of the clock recovery chips tune delays by tweaking the
>>> threshold voltage.
>>>
>> I have been testing just using adjustable RC delays into a logic gate
>> to generate pretrigger pulses for sampling oscilloscopes. Accuracy
>> depends on a complete reset of the capacitor and tracking between the
>> RC charge voltage and gate threshold voltage. Worst cast jitter for
>> TTL has been in the 100s of picoseconds range because of supply
>> voltage sensitivity. Different families of TTL and CMOS logic all
>> performed about the same.
>>
>> Here is the jitter measurement that came from the RC logic gate delay
>> test:
>>
>> http://www.banishedsouls.org/c2df3757f1/PG506/PDJ%20lolcat.jpg
>>
>> Much better is to use a differential comparator or differential input
>> ECL which solves the threshold variation errors and a fast (it really
>> isn't all that fast) ramp generator with a precision reset. The
>> differential input allows the ramp rate and threshold voltage to be
>> linked allowing ratiometric operation to reject power supply or
>> reference voltage variation and noise.
>>
>> My next pretrigger generator is going the differential comparator or
>> differential ECL route with a fast ramp and precision reset. I expect
>> jitter to be significantly better than 10s of picoseconds for delays
>> up to about 100 nanoseconds. If I get down to 10 picoseconds of
>> jitter, I will be happy since I have no real way to measure much below
>> that.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts-***@public.gmane.org
>> 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-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>

[Gerhard Hoffmann]

Am 17.12.2012 19:56, schrieb David:


> My next pretrigger generator is going the differential comparator or
> differential ECL route with a fast ramp and precision reset. I expect
> jitter to be significantly better than 10s of picoseconds for delays
> up to about 100 nanoseconds. If I get down to 10 picoseconds of
> jitter, I will be happy since I have no real way to measure much below
> that.


That should be easy to do. I did a trigger pulse & delay for a
54750A scope. You need abt. 25 nsec delay to see the trigger event.
I did it with ooold 10K ECL I still had around and a few meters of
semi rigid cable. The semi rigid is surprisingly compact when wound
on a piece of plastic tube.

There was not much difference when watching the output of an
ADCMP580 comparator, via trigger delay or via internal trigger
and waiting a few clocks with the built-in delay.

The ADCMP580 is a fine chip, btw. You get a lot of speed for
not too much money. (digikey)

I will rebuild the trigger delay over xmas, this time with
CML to remove most of a systematic error in my scope setup.

CML is much more friendly than ECL/PECL from a probing
point of view. No need to carry Vtt to the scope and have
a problematic bias tee there, or shifting the supplies
until all happens to fit...

regards, Gerhard

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> Consider also using two identical 24-bit counters. ...

That doesn't help solve the metastability issue.


--
These are my opinions. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> The hp 59309A has a talk-only mode where timestamps are output at 40 Hz; so
> that would narrow it down to 25 ms.

You can get (much?) better than 25 ms if the timestamps are locked to the
master clock or PPS.

If not, you can also get into hanging-bridge type adventures. :)


> BTW, if you're curious, look at the service manual (http://ko4bb.com/
> manuals.php). This is a pre-microprocessor age GPIB instrument that uses a
> 4096-bit ROM-based state machine (A5U2) as a CPU. Very clever, very 70's.

I was designing hardware back in those days, and writing microcode too. The
good old days really were "good", at least in my memories.

If you get more than ballpark of 20 states in your state machine, it's often
simpler to think of the problem as software rather than hardware. That
probably works better if you have some experience writing microcode.

At the hardware level, for the gear I worked on, each instruction had a
next-PC field. One trick was to implement branches by ORing bits into the
bottom bits of the next-PC. The assembler did most of the work.

For anything bigger than roughly 20 states, we would write a real assembler.
That's not a lot of work if you start from a previous example. Just change
all the keywords and matching dictionary.

4096 is 512x8, 9 address bits and 8 data bits, so you get X bits of PC and
9-X bits to branch on. You can get more branch bits by using a mux keyed off
some high-order PC bits or something like that. (That's more work for the
assembler, but the programmer doesn't have to think about it.)





--
These are my opinions. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> As far as NTP is concerned, I wonder if you've ever considered turning the
> tables on how it works. AFAIK, NTP gets an external time reference (e.g.,
> 1PPS) as an interrupt. With modern computers, this is horrible. There are
> far too may layers of h/w jitter (pipelines, multiple levels of cache, TLB
> misses, etc.) and s/w jitter (interrupt handling, spinlocks, interrupt
> masking, priority levels, etc.).

You have to have your time-nut hat on before that makes a difference.

Has anybody measured it? It should be easy to hack the kernel PPS interrupt
routine to flap a printer port signal and measure the delay between the PPS
signal and printer port.


> For best timing, perhaps a better solution is not to have NTP receive a 1PPS
> as *input* and try to pretend to measure it internally in s/w but for NTP to
> *output* a 1PPS and measure that externally with sub-microsecond h/w (like a
> picPET).

The Trimble Palisade and Acutime work that way.



--
These are my opinions. I hate spam.

[Chris Albertson]

Yes this gets measured all the time. But not this way. In the usual case
the PPS causes the nanosecond clock to be trapped and logged. The clock
has good enough stably for this that it is not a major error source.

If the system were to try and create a PPS then it would have to be based
on the nanosecond clock or a hardware count down register based on it. I
just cannot see how a count down timer interrupt can have less jitter than
a DCD line interrupt.

A few people have gotten around this by moving the computer's timing clock
off the CPU chip. Then you can use hardware latches and such that have
very predictable timing. I think this is the only way to improve the
current system. You have t remember that there is a large and active
community of researchers who have been working on this for just over 30
years now in the latest development version that are talking about
nanosecond level time keeping.

The answer to measuring is "a few microseconds" In fact if you need to
measure a time interval at that level of accurately all you need is a
standard computer with some serial ports. There is an interesting
project to monist the AC mains line frequency and the sensor is just an AC
transformer connected the the DCD pin of a serial port.

On Sat, Oct 26, 2013 at 2:47 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> You have to have your time-nut hat on before that makes a difference.
>
> Has anybody measured it? It should be easy to hack the kernel PPS
> interrupt
> routine to flap a printer port signal and measure the delay between the PPS
> signal and printer port.
>
> --

Chris Albertson
Redondo Beach, California

[Tom Van Baak]

> If the system were to try and create a PPS then it would have to be based
> on the nanosecond clock or a hardware count down register based on it. I
> just cannot see how a count down timer interrupt can have less jitter than
> a DCD line interrupt.

Right. The key is not to use count-down timers and interrupts at all. The key is no interrupts; nothing asynchronous. What you do is:

1) About once a second (it doesn't really matter), with hot cache and interrupts disabled, record the s/w time before and after you output a pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're golden.

2) Then use external h/w to timestamp that pulse at the sub-microsecond level.

3) And then you compare the s/w timestamp of when the pulse was thought to be generated against the h/timestamp of when the pulse was known to be actually received. This allows you to compare s/w "pretend" time against "actual" h/w time. This jitter-free delta is what NTP can use for its discipline algorithm, to smoothly bend s/w virtual time to match real h/w time.

> A few people have gotten around this by moving the computer's timing clock
> off the CPU chip. Then you can use hardware latches and such that have
> very predictable timing. I think this is the only way to improve the
> current system. You have t remember that there is a large and active
> community of researchers who have been working on this for just over 30
> years now in the latest development version that are talking about
> nanosecond level time keeping.

If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.

But h/w counter/capture is something no legacy PC has had AFAIK. If the new breed of SBC have this capability, NTP should show a one or two orders of magnitude jump in precision on those platforms.

/tvb

[Dennis Ferguson]

On 26 Oct, 2013, at 18:21 , Tom Van Baak <tvb-***@public.gmane.org> wrote:
> Right. The key is not to use count-down timers and interrupts at all. The key is no interrupts; nothing asynchronous. What you do is:
>
> 1) About once a second (it doesn't really matter), with hot cache and interrupts disabled, record the s/w time before and after you output a pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're golden.

That's perfect if it works like it seems it should. The problem with modern CPUs is
finding an instruction sequence that does the read-write-read in that order, allowing
each to complete before doing the next. The write is the biggest problem. Writes are
often buffered, and even when you can find an instruction which stalls until it clears
the buffer the write will also often be posted across the interconnect bus so there's
no way for the CPU to know when the write makes it to the device, let alone make it
wait until that happens.

When using the CPU cycle counter as a system clock source it is common to find that
the two reads in a read-write-read sequence are only a cycle or two different even
when you know the write is crossing an interconnect with 10's of nanoseconds of latency
(not that 10's of nanoseconds is bad...).

It is usually easier to find the magic instructions to make a read-read-read work
the way one expects, though even that can be a challenge. It is possible to do
the same output pulse thing with a read-read-read if there is a PWM peripheral to
generate the pulses. The PWM is programmed to output pulses at whatever frequency
is convenient while the read-read-read sampling is used to determine the relationship
between the PWM counter and the system clock. Of course, this requires a peripheral
which legacy PCs often don't have.


> If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
>
> But h/w counter/capture is something no legacy PC has had AFAIK. If the new breed of SBC have this capability, NTP should show a one or two orders of magnitude jump in precision on those platforms.

The TI CPU used for the Beaglebone (Black) has three. The counter being sampled
is 100 MHz.

Dennis Ferguson

[Chris Albertson]

Yes that is right. CPUs can execute instruction out of order. So you
might write Read, Write, Read but the CPU might decide to do the second
read before the write. You can ever know. Even if you use some clever
trick it will only work on the one exact model CPU you tested it with.

This is not now the CDC 6400 built in the 1960's could start on e
instruction then start up to nine more before the first one finished. As
long as some future instruction did not use the result of a previous one
the CPU would not wait for the result. You could have up to 10
instructions being executed at the same time. We tried for that but it was
hard to do. Four at once was easy.

Modern CPUs are MUCH more complex and will even do speculative executions.
and brach prediction which means they need a way to "back up", and toss out
results from wrong predictions. It is impossible to know the timing in
advance. I think hyper threading (hardware level multitasking) adds even
one more layer.



On Sat, Oct 26, 2013 at 6:49 PM, Dennis Ferguson <
dennis.c.ferguson-***@public.gmane.org> wrote:

>
> That's perfect if it works like it seems it should. The problem with
> modern CPUs is
> finding an instruction sequence that does the read-write-read in that
> order, allowing
> each to complete before doing the next.--


Chris Albertson
Redondo Beach, California

[Chris Albertson]

So basically what you are proposing is an NTP reference clock that queries
a known good external clock at semi-random intervals. The query method is
to send a pulse then read the time from the external clock.

GPS is a "push" device. It just sends data forever. What you are wanting
is a "pull" device, one that will tell you the absolute time of a pulse.
It would not be hard to build. Get a 32 bit counter that is driven by a
10MHz GPSDO. then a pulse will latch the counter. You'd need a very fast
logic family if you plan to count nanoseconds.

The query would not be once per second. NTP would use its normal method to
determine the interval, usually it is much longer than one second.

I bet there must already be an NTP ref clock that is based on query. that
could be a starting place.


the typical HP counter could work as the clock. On one channel you feed it
a PPS from your GPS the pulse from the computer goes to the other channel.
the HP buss sends back the time after the last full second. This could
be pico seconds if you have the right counter. So you could implement
this with no solder.




On Sat, Oct 26, 2013 at 4:21 PM, Tom Van Baak <tvb-***@public.gmane.org> wrote:

> > If the system were to try and create a PPS then it would have to be based
> > on the nanosecond clock or a hardware count down register based on it.
> I
> > just cannot see how a count down timer interrupt can have less jitter
> than
> > a DCD line interrupt.
>
> Right. The key is not to use count-down timers and interrupts at all. The
> key is no interrupts; nothing asynchronous. What you do is:
>
> 1) About once a second (it doesn't really matter), with hot cache and
> interrupts disabled, record the s/w time before and after you output a
> pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're
> golden.
>
> 2) Then use external h/w to timestamp that pulse at the sub-microsecond
> level.
>
> 3) And then you compare the s/w timestamp of when the pulse was thought to
> be generated against the h/timestamp of when the pulse was known to be
> actually received. This allows you to compare s/w "pretend" time against
> "actual" h/w time. This jitter-free delta is what NTP can use for its
> discipline algorithm, to smoothly bend s/w virtual time to match real h/w
> time.
>
> > A few people have gotten around this by moving the computer's timing
> clock
> > off the CPU chip. Then you can use hardware latches and such that have
> > very predictable timing. I think this is the only way to improve the
> > current system. You have t remember that there is a large and active
> > community of researchers who have been working on this for just over 30
> > years now in the latest development version that are talking about
> > nanosecond level time keeping.
>
> If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then
> there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the
> LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
>
> But h/w counter/capture is something no legacy PC has had AFAIK. If the
> new breed of SBC have this capability, NTP should show a one or two orders
> of magnitude jump in precision on those platforms.
>
> /tvb
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Björn]

Chris,

> So basically what you are proposing is an NTP reference clock that queries
> a known good external clock at semi-random intervals. The query method is
> to send a pulse then read the time from the external clock.
>
> GPS is a "push" device. It just sends data forever. What you are wanting
> is a "pull" device, one that will tell you the absolute time of a pulse.
> It would not be hard to build. Get a 32 bit counter that is driven by a
> 10MHz GPSDO. then a pulse will latch the counter. You'd need a very
> fast logic family if you plan to count nanoseconds.

This is already available even in some small mass market receivers. See
the uBlox Lea-6T and other uBlox receivers.

"Time mark of external event inputs"

This has also been available in high quality L1 receivers and L1/L2
receivers used for airborne photogrammetry.

Read the text on page 40 and onwards of the Ashtech G12 manual

http://goo.gl/Oc1htQ

The same feature is also available in all(?) the bus interface T/F cards
from Bancomm/Datum/Symmetricom/Truetime/Spectracom/KSI/Odetics etc.

"Event Time Capture. An Event Time Capture feature provides a means of
latching time for an external event input."

from

http://www.symmetricom.com/products/bus-level-timing/legacy-pci/bc635PCI-U-IRIG/


> The query would not be once per second. NTP would use its normal method
> to
> determine the interval, usually it is much longer than one second.
>
> I bet there must already be an NTP ref clock that is based on query. that
> could be a starting place.

See the Palisade refclock driver

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html

kind regards,

Björn

[Chris Albertson]

So now we can know if this works better. Does the Palisade ref clock work
better then the Atom ref clock?


On Sun, Oct 27, 2013 at 12:51 AM, "Björn" <bg-***@public.gmane.org> wrote:

> Chris,
>
> > So basically what you are proposing is an NTP reference clock that
> queries
> > a known good external clock at semi-random intervals....
>
> See the Palisade refclock driver
>
> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html
>
> kind regards,
>
> Björn
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> If your project works ok for the earth clock, the next step is a
> jaw-dropping array of 8 (9) clocks in a JPL lobby showing the differently
> ticking solar time for each planet. Use 24h clocks for best results. They
> can be had from www.clockkit.com, an excellent source of DIY quartz clock
> parts.

You forgot time zones. I think you need a matrix of clocks. The row/column
for a planet would need geographic labels.


--
These are my opinions. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> You only need enough bits to cover the worst case OCXO frequency drift or
> the worst case GPS jitter error, per second. For example, if your OCXO stays
> accurate to 1 ppm it can't possibly drift more than 1 us per second.
> Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of
> correct time. Therefore, the maximum number of 100 ns ticks you will be off
> in any second is +/-10. So even a 8-bit counter is enough. Does this make
> sense now?

Am I confused or did you forget to add the 2 errors to cover the case when
they both happen during the same second? 2 us or a count of 20 is still
tiny, even for an 8 bit counter.



--
These are my opinions. I hate spam.

[Tom Van Baak]

>> You only need enough bits to cover the worst case OCXO frequency drift or
>> the worst case GPS jitter error, per second. For example, if your OCXO stays
>> accurate to 1 ppm it can't possibly drift more than 1 us per second.
>> Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of
>> correct time. Therefore, the maximum number of 100 ns ticks you will be off
>> in any second is +/-10. So even a 8-bit counter is enough. Does this make
>> sense now?
>
> Am I confused or did you forget to add the 2 errors to cover the case when
> they both happen during the same second? 2 us or a count of 20 is still
> tiny, even for an 8 bit counter.

Hal,

Yes, thanks, for worst case, add them. Also include a +/- 1 count error for the timer/counter. In reality it might be hard to say for certain what the max oscillator or max GPS jitter is. Are the numbers min/max, or 1-sigma, or 3-sigma, etc.? I used 1 us as a very generous example. But as you see, the number of bits you need to hold the time interval error is still very small.

Chris,

A couple more comments on the Arduino...

1) Have you checked for glitches in your dual-DAC system? The Arduino API is forcing you to make two successive calls to analogWrite(). I wonder if there might be a glitch when the LSB carries/borrows into the MSB, since each PWM is configured separately. You can check this with a test version of your code that linearly sweeps through all possible DAC values and then continuously measure the output voltage with a high-res voltmeter.

2) Once you get rid of the unnecessary timer interrupt and have just the GPS 1PPS interrupt, realize that since all you do is a PID calculation and DAC update once a second, you can simply move that code to the interrupt handler. That further avoids any contention between main and interrupt code, since loop() has nothing to do.

3) Please consider using the ATmega input capture feature rather than a rising edge interrupt. The trouble with doing precise timing with interrupts is that, in AVR chips at least, there is some latency and jitter, depending if a multi-cycle instruction was in progress. You can avoid this by using hardware timer/capture registers. To find examples search for words like: Arduino timer ICR1H ICR1L

4) If you use (ICR1H) ICR1L you don't even need to use interrupts since the value is frozen until the next edge. I mean, you could poll if the code is simpler that way. Then your GPSDO is all in loop() with no interrupts at all. It's hard to get much simpler than that.

/tvb

[Chris Albertson]

A couple more comments on the Arduino...
>
> 1) Have you checked for glitches in your dual-DAC system? The Arduino API
> is forcing you to make two successive calls to analogWrite(). I wonder if
> there might be a glitch when the LSB carries/borrows into the MSB, since
> each PWM is configured separately. You can check this with a test version
> of your code that linearly sweeps through all possible DAC values and then
> continuously measure the output voltage with a high-res voltmeter.
>

The 16-bit DAC has more resolution then my Fluke volt meter. I tested the
DAC by generating triangle waves but any glitches would be hard to see.

I think what makes this work is the very heavy analog filter. It goes
into a CRC "pi" filter made with a 100K resister and two 4.7 uf caps.
The PWM on both outputs uses the same clock The the pulses are in perfect
phase

What likely does mess it up is the resisters are not precision and the step
sizes are not right.

One idea I had was to not treat this as a 16-bit value. I might thnk of it
as an 8-bit fine adjustment DAC with an 8-bit bias DAC.

I need some method to test the DAC. I running blind now.



> 2) Once you get rid of the unnecessary timer interrupt and have just the
> GPS 1PPS interrupt, realize that since all you do is a PID calculation and
> DAC update once a second, you can simply move that code to the interrupt
> handler. That further avoids any contention between main and interrupt
> code, since loop() has nothing to do.
>

I really do have to keep the interrupt handler short. The arduino does
lots in the foreground, like PWM and serial data. This that LOOK simple
like adding two numbers take time because this is an 8-bit CPU and even a
16-bit add is done is software. A multiply for the PID is way to long.
The AVR lacks even an 8x8 multiply unit and has to use shits and addition
in a loop.



> 3) Please consider using the ATmega input capture feature rather than a
> rising edge interrupt. The trouble with doing precise timing with
> interrupts is that, in AVR chips at least, there is some latency and
> jitter, depending if a multi-cycle instruction was in progress. You can
> avoid this by using hardware timer/capture registers. To find examples
> search for words like: Arduino timer ICR1H ICR1L
>
> 4) If you use (ICR1H) ICR1L you don't even need to use interrupts since
> the value is frozen until the next edge. I mean, you could poll if the code
> is simpler that way. Then your GPSDO is all in loop() with no interrupts at
> all. It's hard to get much simpler than that.
>

I'm going to eventually use the TIC which is connected to the 74HC4046 PPL
chip. I need a PPS interrupt for that. Also "loop" maybe e slow once I
add a user interface and LCD screen and I will at some point need to read
sawtooth from the GPS and I will also want to monitor the stays of the GPS

>
> /tvb
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



--

Chris Albertson
Redondo Beach, California

[Chris Albertson]

On Wed, Apr 9, 2014 at 11:18 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:

>
> tvb-AeR/***@public.gmane.org said:
> > You only need enough bits to cover the worst case OCXO frequency drift or
> > the worst case GPS jitter error, per second. For example, if your OCXO
> stays
> > accurate to 1 ppm it can't possibly drift more than 1 us per second.
> > Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of
> > correct time. Therefore, the maximum number of 100 ns ticks you will be
> off
> > in any second is +/-10. So even a 8-bit counter is enough. Does this make
> > sense now?
>
> Am I confused or did you forget to add the 2 errors to cover the case when
> they both happen during the same second? 2 us or a count of 20 is still
> tiny, even for an 8 bit counter.
>
>
I think what you are saying is that the error can be expressed in about
five bits. That is right.

But I still need to count all the cycles in the second and can't just let a
8 or 16 bit counter run free. The reason is I don't know where the
overflow happens. Overflow is not in sync with PPS.

OK this might work. I hope it does as it would allow a bit of code to be
removed. Let's see...

The system powers up, I enable the 8-bit counter and then assign an
interrupt handler to the PPS and enable the PPS interrupt and I get the
very first PPS interrupt and notice the counter vale is 67.

At the next interrupt the counter is 82

With only these two numbers 67 and 82 and knowing the counter is 8 bits how
to I know the "error" which is the number of cycles different from 5000000.

Or more simply: "after reading the 82 how to I adjust the DAC?"

If you can spell it out I'll try it. But I bet you need one more number:
the count of the times the 8-bit counter overflowed.

OK we might be able to assume a number of overflows because there are tight
bounds on the PPS and OCXO performance.

One problem is I know for sure the overflow rate is not a fixed number per
second. The 16-bit timer overflow happens 50000000/65536 times per second
and an 8-bit timer overflows 5000000/256 times per second. Neather in an
integer.

It might work, then I can get rid of counting overflows.


--

Chris Albertson
Redondo Beach, California

[Tom Van Baak]

The key is not to worry about overflows. Let them happen. Don't count them. Don't prevent them. Fixed point binary arithmetic is wonderful. Here we're only concerned with the modulus or remainder.

If a 16-bit timer is counting at 5 MHz and its value is 0xnnnn, then one second later its value will be 0xnnnn+0x4B40. This because 5000000/65536 = 76.2939453125 = 76 + 19264/65536 and 19264 = 0x4B40.

In other words, if you know the oscillator frequency is really close to 5 MHz and you know the 1PPS period is really close to 1 second, then the difference between timer now and timer a second ago will always be right around 0x4B40.

This greatly simplifies the code, as it boils down to: error = TCNT1now - TCNT1then - 0x4B40.

The decimal equivalent of this is to consider if your car had only a 2 digit odometer. If you expect to drive 123 miles every week, do you have to count odometer "overflows"? How do you tell if you drove 125 miles or 120 miles instead of 123? Easy. Just subtract successive readings and see how far you are from 23. That's the error value.

Another analogy is a wrist watch. If you need to time something that takes about 195 seconds, you can essentially ignore the hour and minute hand, and look only at the seconds hand. Your events should occur about 15 seconds on the dial apart. If it's a bit more or less than 15 seconds, that's the error value.

/tvb

----- Original Message -----
From: Chris Albertson
To: Discussion of precise time and frequency measurement
Cc: Tom Van Baak ; Hal Murray
Sent: Thursday, April 10, 2014 12:11 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8







On Wed, Apr 9, 2014 at 11:18 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:


tvb-AeR/***@public.gmane.org said:
> You only need enough bits to cover the worst case OCXO frequency drift or
> the worst case GPS jitter error, per second. For example, if your OCXO stays
> accurate to 1 ppm it can't possibly drift more than 1 us per second.
> Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of
> correct time. Therefore, the maximum number of 100 ns ticks you will be off
> in any second is +/-10. So even a 8-bit counter is enough. Does this make
> sense now?


Am I confused or did you forget to add the 2 errors to cover the case when
they both happen during the same second? 2 us or a count of 20 is still
tiny, even for an 8 bit counter.





I think what you are saying is that the error can be expressed in about five bits. That is right.


But I still need to count all the cycles in the second and can't just let a 8 or 16 bit counter run free. The reason is I don't know where the overflow happens. Overflow is not in sync with PPS.


OK this might work. I hope it does as it would allow a bit of code to be removed. Let's see...


The system powers up, I enable the 8-bit counter and then assign an interrupt handler to the PPS and enable the PPS interrupt and I get the very first PPS interrupt and notice the counter vale is 67.


At the next interrupt the counter is 82


With only these two numbers 67 and 82 and knowing the counter is 8 bits how to I know the "error" which is the number of cycles different from 5000000.


Or more simply: "after reading the 82 how to I adjust the DAC?"


If you can spell it out I'll try it. But I bet you need one more number: the count of the times the 8-bit counter overflowed.


OK we might be able to assume a number of overflows because there are tight bounds on the PPS and OCXO performance.


One problem is I know for sure the overflow rate is not a fixed number per second. The 16-bit timer overflow happens 50000000/65536 times per second and an 8-bit timer overflows 5000000/256 times per second. Neather in an integer.


It might work, then I can get rid of counting overflows.




--

Chris Albertson
Redondo Beach, California

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> Yes, I remember that I cut off the PS-2 connector before the UPS truck even
> left the neighborhood. You are then left with nice 0/+5/Tx/Rx wires, which
> is all you need for navigation and status. For 1PPS timing, in either the
> serial or USB version, unscrew the case and grab pin 20 of the IC.

I think the serial version (BU-355) already includes a wire for the PPS. I
don't have a handy pointer to the appropriate documentation. It's the
yellow/NC wire in the picture Rex provided.
http://www.usglobalsat.com/p-689-br-355-s4.aspx#images/product/large/689.jpg


I'm a bit suspicious of the S4 version but don't have any details. gpsd has
troubles with it. It feels like a firmware bug to me. The SIRF chips are
very popular. I expect things will get sorted out eventually.


--
These are my opinions. I hate spam.

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
>> You have to synchronise between the counter
>> value and what the OS understands is 'system time' in order to create a
>> retrospective timestamp for when the event occured.

> Also true.

> One solution to the problem is use two independent HW capture inputs. One
> for a GPS 1PPS and the other for your event.

> In this case the system clock does not need to be synchronized -- since it
> is used only to interpolate between the two events. The event timestamp is
> little more than adding the differential of the two most recent captures,
> which is a number from 0 to 1 second.

You haven't solved the problem yet. Now you have to synchronize the HW
capture counters.

You can probably do that with some simple but delicate initialization code.
Maybe copy the value from the counter used for the system time? At the
time-nut level, you have to worry about things like cache misses. (There may
be more fine print at that level depending upon the details of the hardware.)

You could also do it by calibrating out the difference: just feed the same
pulse into both input pins. You have to do that each time you (re)start
things. That's easy for a one-off project but adds another ugly step if you
want to do it in production. Collecting long term data moves a hobby project
a lot closer to production.




--
These are my opinions. I hate spam.

[Tom Van Baak]

>> One solution to the problem is use two independent HW capture inputs. One
>> for a GPS 1PPS and the other for your event.
>
>> In this case the system clock does not need to be synchronized -- since it
>> is used only to interpolate between the two events. The event timestamp is
>> little more than adding the differential of the two most recent captures,
>> which is a number from 0 to 1 second.

> You haven't solved the problem yet. Now you have to synchronize the HW
> capture counters.

Hi Hal,

Nope, there's no need to synchronize HW counters (against "system time" or UTC or something). That's the beauty of time-stamping or capture counters: they are free-running (at some internal CPU frequency) and share a common clock counter register from which the capture/snapshot is taken.

> You can probably do that with some simple but delicate initialization code.
> Maybe copy the value from the counter used for the system time? At the
> time-nut level, you have to worry about things like cache misses. (There may
> be more fine print at that level depending upon the details of the hardware.)

No, again that's the beauty of H/W capture counters. You completely avoid the OS or software rat's nest called system time. Only the capture registers keep perfect "system time" by virtue of their continuous h/w counting, unaffected by software, locks, interrupts, cache, TLB, or microcode latency issues.

> You could also do it by calibrating out the difference: just feed the same
> pulse into both input pins. You have to do that each time you (re)start
> things. That's easy for a one-off project but adds another ugly step if you
> want to do it in production. Collecting long term data moves a hobby project
> a lot closer to production.

The modern CPU's with capture/compare registers I've seen use a common N-bit timer register as the capture source, so there's no issue with intra-capture synchronization. What is still critical, to align with UTC for example, is inter-clock synchronization. And that's why two h/w capture counters are needed -- one for the event (LAN packet, for example) and one for the GPS/1PPS timestamp.

/tvb

[Hal Murray]

tvb-AeR/***@public.gmane.org said:
> 2) For long-term analysis, even 1 PPS is overkill. Having more data may not
> improve your oscillator drift plot at all. This is because the frequency is
> a moving target. Ever more precise measurements of a moving target are
> wasted; they don't add any clarity to the overall trend. Consider measuring
> a 10811 for a year. Do you need to follow its phase or frequency every 100
> ns? Or second? Or minute? Maybe as little as one data point per day is more
> than enough to make a perfectly accurate long-term frequency drift plot.

You need more than 1 sample per day for ADEV plots left of 100,000 K seconds.

Suppose you have lots and lots of data at, say, 1 second samples. You can
turn that into an ADEV plot. Does anybody scan the data in clumps, say a
day, to see if the short-tau picture changes over time?


--
These are my opinions. I hate spam.

[Tom Van Baak]

> You need more than 1 sample per day for ADEV plots left of 100,000 K seconds.

Correct. What I sometimes do is collect data for just a few minutes at 1000 samples per second. That's enough to make an ADEV plot for tau 0.001 to 1 or 10 seconds. Then I'll collect data for a couple of days at 1 sample per second. That gives you an ADEV plot for tau 1 to 100 k seconds. For really long-term tracking you don't need samples every millisecond or every second. This approach means you don't tie up expensive high-resolution instruments with long-term measurements. The key point here is you don't need to use the same instrument or the same sampling rate or the same resolution for short- and long-term measurements.

> Suppose you have lots and lots of data at, say, 1 second samples. You can
> turn that into an ADEV plot. Does anybody scan the data in clumps, say a
> day, to see if the short-tau picture changes over time?

Yes, Stable32 implements DAVAR (dynamic AVAR) which gives an impressive 3D ADEV plot. This is useful for timing sources where the stability, for whatever reason, changes over time.

John's TimeLab software implements another form of this: you can specify a "trace history" value. For example, instead of computing ADEV of a million points, you compute 10 ADEV's on successive groups of 100,000 points each. This is a great way to show the confidence in your statistics. It also works well on oscillators that are warming up, over hours and days.

/tvb

[Bob Camp]

Hi


> On Oct 22, 2014, at 5:57 PM, Hal Murray <hmurray-8cQiHa/C+6Go9G/***@public.gmane.org> wrote:
>
>
> tvb-AeR/***@public.gmane.org said:
>> 2) For long-term analysis, even 1 PPS is overkill. Having more data may not
>> improve your oscillator drift plot at all. This is because the frequency is
>> a moving target. Ever more precise measurements of a moving target are
>> wasted; they don't add any clarity to the overall trend. Consider measuring
>> a 10811 for a year. Do you need to follow its phase or frequency every 100
>> ns? Or second? Or minute? Maybe as little as one data point per day is more
>> than enough to make a perfectly accurate long-term frequency drift plot.
>
> You need more than 1 sample per day for ADEV plots left of 100,000 K seconds.
>
> Suppose you have lots and lots of data at, say, 1 second samples. You can
> turn that into an ADEV plot. Does anybody scan the data in clumps, say a
> day, to see if the short-tau picture changes over time?

ADEV most certainly does change with time, even for short tau’s.

Bob


>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts-***@public.gmane.org
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

[Hal Murray]

> I don't think you can use a GPS almanac from 2012.

Why not? Just pretend that the time you want is 2012+1024 weeks. You won't
be able to watch it pass through the magic rollover time, but you can verify
that it works correctly once it gets past that magic time.

--------

Crazy question department...

How stable are the orbits? If I gave you the orbit data from a time in 2012
and the data from 1024 weeks later, could you tell which was which?

--
These are my opinions. I hate spam.



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

[Hal Murray]

***@LeapSecond.com said:
> The hard part is understanding when the GPS receiver fails and when to apply
> the 1024 week correction, or not. This is made difficult or impossible if
> the receiver does not give you internal information or if you do not already
> have external information (like an alternative, independent GPS, or UTC date
> source). If you wanted to cheat you could keep an independent clock inside
> the Arduino and then add or subtract 1024 weeks until it "looked right". But
> this is complicated by power failures in either the GPS receiver or the
> Arduino. Worse yet are cold starts where the receiver doesn't know what the
> UTC-GPS correction is.

Why is that so hard?

If I understand things correctly, the time (UTC) is correct because the GPS
receiver is using the current GPS-UTC offset. But the date is off by 1024
weeks. (or some multiple of that)

All you need for "external information" is the date when the fixup software
was compiled. Call that the build-date. Then the recipe is:
t = dateAndTimeFromGPS
while t < build-date
t += 1024 weeks

That won't solve the problem forever but it will give you another 20 years,
and you can restart the timer anytime you want by rebuilding and reinstalling
the fixup software.


I think the problems with leap-seconds are also non-problems because the
broken firmware will be working with the correct/current GPS-UTC offset. I
don't remember any problems like that 2 years ago.

--
These are my opinions. I hate spam.



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

[Hal Murray]

> Good, you understand my point. You need "external information" and "That
> won't solve the problem forever" and oh, well, yeah, duh, just "rebuild and
> reinstall the fixup software" anytime there's trouble in the future.

> To me this is replacing a broken GPS receiver algorithm with a broken
> Arduino hack. You're not solving anything except pushing a problem to the
> next unsuspecting user or customer. Worse yet, now instead of being part of
> a group of N people sharing the same TymServe problem, you are a group of 1
> with both a TymServe problem and an Arduino problem.

I think I agree with everything you said, but we didn't establish the context
before we started this discussion. I was probably assuming a different
environment that you were.

There is a big difference between a time-nut with more time than money trying
to get a few more years out of some well-loved legacy gear and the IT staff
for a major bank or stock market.

There is probably an intermediate case of places like a telescope. They have
smart people and limited funds. Somebody has to decide if they kludge along
a bit longer with gear they have or spend the cash to do-it-right. I was
impressed with the ingenuity of using the PPS from one box with GPS but wrong
date to feed another box with no GPS and the date/time set by hand.


--
These are my opinions. I hate spam.



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

[Hal Murray]

***@LeapSecond.com said:
> Am I reading this right -- those GPS receivers applied the leap second 16
> seconds before they were supposed to, resulting in a double 23:59:44 instead
> of 23:59:59 and 23:59:60? So not only did they use GPS instead of UTC but
> the opted for the double second instead of a valid leap second.

That's my reading.
> 57203 86383.752 $GPRMC,235943.000,A,3726.0874,N,12212.2628,W,1.71,186.96,300615,,*1A
> 57203 86384.750 $GPRMC,235944.000,A,3726.0866,N,12212.2630,W,1.33,180.14,300615,,*1D
> 57203 86385.752 $GPRMC,235944.000,A,3726.0858,N,12212.2631,W,1.10,178.01,300615,,*13
> 57203 86386.751 $GPRMC,235945.000,A,3726.0850,N,12212.2632,W,1.18,179.98,300615,,*10


--
These are my opinions. I hate spam.



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

[Hal Murray]

> Good detective work. Yes, it sounds like a GPS 2^10 = 1024 WNRO issue, but
> no one else has ever reported this AFAIK, so it's very curious.

I've seen it on a Z3801A. I'm pretty sure I mentioned it here. That was
several years ago.

I think I had to set the time after power up but before it found any
satellites.




--
These are my opinions. I hate spam.



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

[David Gravereaux]

On 09/29/2015 12:28 AM, Hal Murray wrote:
>
>> Good detective work. Yes, it sounds like a GPS 2^10 = 1024 WNRO issue, but
>> no one else has ever reported this AFAIK, so it's very curious.
>
> I've seen it on a Z3801A. I'm pretty sure I mentioned it here. That was
> several years ago.
>
> I think I had to set the time after power up but before it found any
> satellites.


Yes, I'm sure I had seen your post when I looked around. I couldn't
apparently just set it due to the 222 "data out-of-range" error. I
can't say why the :GPS:INIT:DATE command didn't work, but the numerous
restarts eventually moved it forward.

--
***@pobox.com:~$ make war
make: *** No rule to make target `war'. Stop.

[Hal Murray]

***@LeapSecond.com said:
> I'm not sure I understand your elevation question. Are you talking about
> elevation as in mountain vs. sea level altitude? Or elevation as in
> satellite Az/El?

I was thinking of the elevation of the receiver as in mountain vs sea level.

I think the question I was trying to ask is: Do the calculations for a
consumer grade GPS include relativistic corrections for the elevation of the
receiver? How about a survey grade receiver?


***@n1k.org said:
> Most survey work is done as a “delta from known references”. It’s much like
> common view time transfer. That alone takes care of a whole raft of things.

I assume the delta includes elevation as well as lat/long. That may make
relativistic corrections insignificant.

A week or so ago, I stopped to chat with a surveyor working on a lot a block
from here. He was using old fashioned optical gear. (Standard story 42.
The house next door was built with reference to the fences. The fence was
off, so that house is actually too close to the lot line. His job was to
make sure the new house didn't get into similar troubles.)

He mentioned that GPS gear has the problem of plate motion. That's a bug if
you want to survey lot lines but a feature if you want to measure earthquake
fault creep. (Standard number is plates move about as fast as your
fingernails grow, ballpark of an inch a year. I'm a few miles from the San
Andreas.)


--
These are my opinions. I hate spam.

[Hal Murray]

***@LeapSecond.com said:
> It's not just black holes (BH) but also neutron stars (NS) ....

If anybody is interested in neutron stars, the SLAC public lecture a few
weeks ago was very good.

Supernovas: Gravity-powered Neutrino Bombs
https://www6.slac.stanford.edu/community/past-lectures/supernovas-gravity-powe
red-neutrino-bombs
http://youtube.com/watch?v=HiCRTUxgwPY

When a star runs out of fuel, it collapses. If it's in the right size range,
it turns into a neutron star. That collapse takes 1 ms and involves speeds
up to c/4 - all due to gravity. Neutron stars are so dense that it takes 10
seconds for neutrinos to diffuse out because they keep buming into stuff.
"diffuse" and neutrinos?

It will be interesting to see if/when LIGO picks one up. I assume they will
if it's near enough, but I don't want to be too near.


--
These are my opinions. I hate spam.



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

[Hal Murray]

> record the duration of each cycle directly
> 5) Double wide cycles are detectable but missed cycles are not.

What do you mean by a double wide cycle?
What do you mean by a missed cycle?
They seem like the same thing - if you miss one, the next one will be twice
as wide.

> Here are the advantages of the timestamping method:
> 5) Extra or missing cycles are easy to detect and repair with no loss of
> phase information.

I'd expect the extra or missing cycles would be easy to spot if you were
looking at the duration. The duration would either be twice normal or less
than half of normal. In the latter case, you have to figure out which is the
extra pulse.

I agree that working with time stamps seems simpler. I wonder if that's
because I got started that way and/or wanted to watch phase drift? I'll bet
durations work just as well if the data collection code remembers the round
off and includes it in the calculations for the next cycle.

To me, this is the important advantage of working with time stamps, but
that's because I was interested in tracking phase which turns into clock
error.

Cycle duration:
> 3) With period or frequency measurements, if you lose even a single reading,
> you lose track of phase (timekeeping).

Timestamps:
> 3) You get perfect long-term phase tracking, even if there is noise or
> glitches or lost or corrupted data.



--
These are my opinions. I hate spam.



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

[Tom Van Baak]

Hi Hal,

> What do you mean by a double wide cycle?
> What do you mean by a missed cycle?
> They seem like the same thing - if you miss one, the next one will be twice as wide.

Yes, sorry, I mixed up my words there. A missed cycle would be a reading that looks closer to 32 ms than 16 ms. And a double cycle is one where, for example, the negative zero crossing confuses the ZCD and you get two readings that each look like 8 ms instead of one at 16 ms. Or if there's noise you might get 2 ms and 14 ms, or 0.1 ms and 16.5 ms, etc. I've seen period counters where you get cycle slips as a result.

This effect is especially bad in 1970's era mains clocks where they would keep time by counting mains cycles. That's a case where signal conditioning is important.

Similar problems occur with a TIC when you use a GPS 1PPS as start and DUT 1PPS as stop. You can get into awkward situations where each reading takes 2 seconds instead of 1 second.

With a time-stamping counter every reading essentially includes the full history of phase, so missing or extra data doesn't change the net result. At worst you use a "picket fence" model to clean up the raw data.

By the way, a cool thing you can do with a mains time-stamping counter is check the polarity of your AC outlets. You can go around the house with a battery operated timestamping counter and depending on which way you orient the plug or which 120-0-120 leg your outlet is on, you get 8 ms shifts in the time stamps.

> I agree that working with time stamps seems simpler. I wonder if that's
> because I got started that way and/or wanted to watch phase drift? I'll bet
> durations work just as well if the data collection code remembers the round
> off and includes it in the calculations for the next cycle.

Correct, a data set of phase (or timestamps) and a data set of intervals (or duration, or period, or frequency) are mathematically equivalent and you can freely convert from one to the other, plus a constant.

You have to watch out for floating-point data formats, where you can loose precision if you are not careful, due to rounding or range. This is especially true for data files of frequency; that 1/period calculation can result in accumulation of error.

> To me, this is the important advantage of working with time stamps, but
> that's because I was interested in tracking phase which turns into clock
> error.

Right. You and I both record phase because we're treating mains as a clock. But I think other people are more interested to see strip charts of frequency over time, or histograms of frequency deviation and the like. In that case, the occasional bad data or cycle slip is not a problem. Another way to put it -- being a time nut is always harder than being a frequency nut.

/tvb

----- Original Message -----
From: "Hal Murray" <***@megapathdsl.net>
To: "Tom Van Baak" <***@leapsecond.com>; "Discussion of precise time and frequency measurement" <time-***@febo.com>
Cc: <***@megapathdsl.net>
Sent: Monday, April 11, 2016 7:04 PM
Subject: Re: [time-nuts] Building a mains frequency monitor


>> record the duration of each cycle directly
>> 5) Double wide cycles are detectable but missed cycles are not.
>
> What do you mean by a double wide cycle?
> What do you mean by a missed cycle?
> They seem like the same thing - if you miss one, the next one will be twice
> as wide.
>
>> Here are the advantages of the timestamping method:
>> 5) Extra or missing cycles are easy to detect and repair with no loss of
>> phase information.
>
> I'd expect the extra or missing cycles would be easy to spot if you were
> looking at the duration. The duration would either be twice normal or less
> than half of normal. In the latter case, you have to figure out which is the
> extra pulse.
>
> I agree that working with time stamps seems simpler. I wonder if that's
> because I got started that way and/or wanted to watch phase drift? I'll bet
> durations work just as well if the data collection code remembers the round
> off and includes it in the calculations for the next cycle.
>
> To me, this is the important advantage of working with time stamps, but
> that's because I was interested in tracking phase which turns into clock
> error.
>
> Cycle duration:
>> 3) With period or frequency measurements, if you lose even a single reading,
>> you lose track of phase (timekeeping).
>
> Timestamps:
>> 3) You get perfect long-term phase tracking, even if there is noise or
>> glitches or lost or corrupted data.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tim Shoppa]

I shared a schematic from a 70's era consumer clock 60Hz detector in the
past week. I never really noticed any of these dropping cycles or picking
up extra cycles, but I'm sure it happened. The single pole of RC low pass
filtering in front of the Schmitt trigger seems to do fine.

Tom, you shared the AD app note which showed a synchronized Schmitt-trigger
oscillator. That kind of circuit was very common in 90's era consumer
digital clocks but was usually described as "battery backup" mode in the
consumer clock labeling - those would free-run near 60Hz while unplugged
thanks to the simple locked RC oscillator.

The above applications don't care too much about phase sensitivity but do
care about dropped cycles.

I have yet to dredge up the 60Hz line-lock schematic circuit used in more
than half a century of analog scope trigger circuits. The Tek scopes had
exceptionally robust trigger circuits.

Tim N3QE

On Tue, Apr 12, 2016 at 8:25 AM, Tom Van Baak <***@leapsecond.com> wrote:

> Hi Hal,
>
> > What do you mean by a double wide cycle?
> > What do you mean by a missed cycle?
> > They seem like the same thing - if you miss one, the next one will be
> twice as wide.
>
> Yes, sorry, I mixed up my words there. A missed cycle would be a reading
> that looks closer to 32 ms than 16 ms. And a double cycle is one where, for
> example, the negative zero crossing confuses the ZCD and you get two
> readings that each look like 8 ms instead of one at 16 ms. Or if there's
> noise you might get 2 ms and 14 ms, or 0.1 ms and 16.5 ms, etc. I've seen
> period counters where you get cycle slips as a result.
>
> This effect is especially bad in 1970's era mains clocks where they would
> keep time by counting mains cycles. That's a case where signal conditioning
> is important.
>
> Similar problems occur with a TIC when you use a GPS 1PPS as start and DUT
> 1PPS as stop. You can get into awkward situations where each reading takes
> 2 seconds instead of 1 second.
>
> With a time-stamping counter every reading essentially includes the full
> history of phase, so missing or extra data doesn't change the net result.
> At worst you use a "picket fence" model to clean up the raw data.
>
> By the way, a cool thing you can do with a mains time-stamping counter is
> check the polarity of your AC outlets. You can go around the house with a
> battery operated timestamping counter and depending on which way you orient
> the plug or which 120-0-120 leg your outlet is on, you get 8 ms shifts in
> the time stamps.
>
> > I agree that working with time stamps seems simpler. I wonder if that's
> > because I got started that way and/or wanted to watch phase drift? I'll
> bet
> > durations work just as well if the data collection code remembers the
> round
> > off and includes it in the calculations for the next cycle.
>
> Correct, a data set of phase (or timestamps) and a data set of intervals
> (or duration, or period, or frequency) are mathematically equivalent and
> you can freely convert from one to the other, plus a constant.
>
> You have to watch out for floating-point data formats, where you can loose
> precision if you are not careful, due to rounding or range. This is
> especially true for data files of frequency; that 1/period calculation can
> result in accumulation of error.
>
> > To me, this is the important advantage of working with time stamps, but
> > that's because I was interested in tracking phase which turns into clock
> > error.
>
> Right. You and I both record phase because we're treating mains as a
> clock. But I think other people are more interested to see strip charts of
> frequency over time, or histograms of frequency deviation and the like. In
> that case, the occasional bad data or cycle slip is not a problem. Another
> way to put it -- being a time nut is always harder than being a frequency
> nut.
>
> /tvb
>
> ----- Original Message -----
> From: "Hal Murray" <***@megapathdsl.net>
> To: "Tom Van Baak" <***@leapsecond.com>; "Discussion of precise time and
> frequency measurement" <time-***@febo.com>
> Cc: <***@megapathdsl.net>
> Sent: Monday, April 11, 2016 7:04 PM
> Subject: Re: [time-nuts] Building a mains frequency monitor
>
>
> >> record the duration of each cycle directly
> >> 5) Double wide cycles are detectable but missed cycles are not.
> >
> > What do you mean by a double wide cycle?
> > What do you mean by a missed cycle?
> > They seem like the same thing - if you miss one, the next one will be
> twice
> > as wide.
> >
> >> Here are the advantages of the timestamping method:
> >> 5) Extra or missing cycles are easy to detect and repair with no loss of
> >> phase information.
> >
> > I'd expect the extra or missing cycles would be easy to spot if you were
> > looking at the duration. The duration would either be twice normal or
> less
> > than half of normal. In the latter case, you have to figure out which
> is the
> > extra pulse.
> >
> > I agree that working with time stamps seems simpler. I wonder if that's
> > because I got started that way and/or wanted to watch phase drift? I'll
> bet
> > durations work just as well if the data collection code remembers the
> round
> > off and includes it in the calculations for the next cycle.
> >
> > To me, this is the important advantage of working with time stamps, but
> > that's because I was interested in tracking phase which turns into clock
> > error.
> >
> > Cycle duration:
> >> 3) With period or frequency measurements, if you lose even a single
> reading,
> >> you lose track of phase (timekeeping).
> >
> > Timestamps:
> >> 3) You get perfect long-term phase tracking, even if there is noise or
> >> glitches or lost or corrupted data.
> >
> >
> >
> > --
> > These are my opinions. I hate spam.
> >
> >
> >
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

This thread about mains frequency attracted a wonderful reply from Steven Reyer, who gives permission for me to include his nostalgic design from 25 years ago -- and still working today (photos as of this morning).

Attached: Reyer-Mains-Frequency-Monitor.pdf (420 KB)

/tvb

[David]

Tektronix used transformer isolation followed by a low pass RC filter
with about a 1 kHz cutoff; this was fed directly into the trigger
source selector just like any other trigger source. There is still
enough noise present that the trigger coupling can be used to select
specific features to trigger on.

Modern DSOs often (always?) use an optocoupler circuit for isolation.
I saw an example schematic somewhere and it is pretty simple. It
produces a roughly linear output referenced to the negative or
positive peak so triggering can still occur over almost 360 degrees of
phase. I do not know what kind of low pass filtering was implemented.

On Tue, 12 Apr 2016 09:38:13 -0400, you wrote:

>...
>
>I have yet to dredge up the 60Hz line-lock schematic circuit used in more
>than half a century of analog scope trigger circuits. The Tek scopes had
>exceptionally robust trigger circuits.
>
>Tim N3QE
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob Camp]

Hi

The same “Collins Limiter” stuff that goes along with DMTD’s applies to 60 Hz power
measurement as well. There is a “magic bandwidth” that combined with a slew rate
will give you an optimum result. The gotcha is that you need to know the noise
parameters inorder to work it out. Even back in the 1960’s there was enough “stuff”
feeding crud to the power line that a general solution wasn’t going to be possible. These
days …. no way.

Bob

> On Apr 13, 2016, at 6:23 PM, David <***@gmail.com> wrote:
>
> Tektronix used transformer isolation followed by a low pass RC filter
> with about a 1 kHz cutoff; this was fed directly into the trigger
> source selector just like any other trigger source. There is still
> enough noise present that the trigger coupling can be used to select
> specific features to trigger on.
>
> Modern DSOs often (always?) use an optocoupler circuit for isolation.
> I saw an example schematic somewhere and it is pretty simple. It
> produces a roughly linear output referenced to the negative or
> positive peak so triggering can still occur over almost 360 degrees of
> phase. I do not know what kind of low pass filtering was implemented.
>
> On Tue, 12 Apr 2016 09:38:13 -0400, you wrote:
>
>> ...
>>
>> I have yet to dredge up the 60Hz line-lock schematic circuit used in more
>> than half a century of analog scope trigger circuits. The Tek scopes had
>> exceptionally robust trigger circuits.
>>
>> Tim N3QE
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Graham / KE9H]

For all you Powerline Time nuts, and maybe GPSDO time nuts, too.

Consider this new PIC. PIC16F1619
$1.60 USD, quantity one at Mouser.

It was designed to be an AC motor controller.

So has some interesting built in hardware peripherals:
Mains Zero crossing detector.
Runs up to 32 MHz master clock, which says you could time stamp with 8
MHz resolution. ~125 ns.
Hardware PID engine and Math Accelerator.
CRC engine
Band gap voltage reference
Configurable Logic Cell (for small amount of custom logic.)
Angular Timer
Signal Measurement Timer

Plus all the other normal PIC stuff: A->D, D->A, PWM, multiple other
timers,
comparators, serial, SPI and I2C communications.

I think the Angular Timer and/or Signal Measurement Timer hardware
peripherals
could be used as high accuracy 1 PPS phase detectors for GPSDO.

--- Graham

==

On Tue, Apr 12, 2016 at 7:25 AM, Tom Van Baak <***@leapsecond.com> wrote:

> Hi Hal,
>
> > What do you mean by a double wide cycle?
> > What do you mean by a missed cycle?
> > They seem like the same thing - if you miss one, the next one will be
> twice as wide.
>
> Yes, sorry, I mixed up my words there. A missed cycle would be a reading
> that looks closer to 32 ms than 16 ms. And a double cycle is one where, for
> example, the negative zero crossing confuses the ZCD and you get two
> readings that each look like 8 ms instead of one at 16 ms. Or if there's
> noise you might get 2 ms and 14 ms, or 0.1 ms and 16.5 ms, etc. I've seen
> period counters where you get cycle slips as a result.
>
> This effect is especially bad in 1970's era mains clocks where they would
> keep time by counting mains cycles. That's a case where signal conditioning
> is important.
>
> Similar problems occur with a TIC when you use a GPS 1PPS as start and DUT
> 1PPS as stop. You can get into awkward situations where each reading takes
> 2 seconds instead of 1 second.
>
> With a time-stamping counter every reading essentially includes the full
> history of phase, so missing or extra data doesn't change the net result.
> At worst you use a "picket fence" model to clean up the raw data.
>
> By the way, a cool thing you can do with a mains time-stamping counter is
> check the polarity of your AC outlets. You can go around the house with a
> battery operated timestamping counter and depending on which way you orient
> the plug or which 120-0-120 leg your outlet is on, you get 8 ms shifts in
> the time stamps.
>
> > I agree that working with time stamps seems simpler. I wonder if that's
> > because I got started that way and/or wanted to watch phase drift? I'll
> bet
> > durations work just as well if the data collection code remembers the
> round
> > off and includes it in the calculations for the next cycle.
>
> Correct, a data set of phase (or timestamps) and a data set of intervals
> (or duration, or period, or frequency) are mathematically equivalent and
> you can freely convert from one to the other, plus a constant.
>
> You have to watch out for floating-point data formats, where you can loose
> precision if you are not careful, due to rounding or range. This is
> especially true for data files of frequency; that 1/period calculation can
> result in accumulation of error.
>
> > To me, this is the important advantage of working with time stamps, but
> > that's because I was interested in tracking phase which turns into clock
> > error.
>
> Right. You and I both record phase because we're treating mains as a
> clock. But I think other people are more interested to see strip charts of
> frequency over time, or histograms of frequency deviation and the like. In
> that case, the occasional bad data or cycle slip is not a problem. Another
> way to put it -- being a time nut is always harder than being a frequency
> nut.
>
> /tvb
>
> ----- Original Message -----
> From: "Hal Murray" <***@megapathdsl.net>
> To: "Tom Van Baak" <***@leapsecond.com>; "Discussion of precise time and
> frequency measurement" <time-***@febo.com>
> Cc: <***@megapathdsl.net>
> Sent: Monday, April 11, 2016 7:04 PM
> Subject: Re: [time-nuts] Building a mains frequency monitor
>
>
> >> record the duration of each cycle directly
> >> 5) Double wide cycles are detectable but missed cycles are not.
> >
> > What do you mean by a double wide cycle?
> > What do you mean by a missed cycle?
> > They seem like the same thing - if you miss one, the next one will be
> twice
> > as wide.
> >
> >> Here are the advantages of the timestamping method:
> >> 5) Extra or missing cycles are easy to detect and repair with no loss of
> >> phase information.
> >
> > I'd expect the extra or missing cycles would be easy to spot if you were
> > looking at the duration. The duration would either be twice normal or
> less
> > than half of normal. In the latter case, you have to figure out which
> is the
> > extra pulse.
> >
> > I agree that working with time stamps seems simpler. I wonder if that's
> > because I got started that way and/or wanted to watch phase drift? I'll
> bet
> > durations work just as well if the data collection code remembers the
> round
> > off and includes it in the calculations for the next cycle.
> >
> > To me, this is the important advantage of working with time stamps, but
> > that's because I was interested in tracking phase which turns into clock
> > error.
> >
> > Cycle duration:
> >> 3) With period or frequency measurements, if you lose even a single
> reading,
> >> you lose track of phase (timekeeping).
> >
> > Timestamps:
> >> 3) You get perfect long-term phase tracking, even if there is noise or
> >> glitches or lost or corrupted data.
> >
> >
> >
> > --
> > These are my opinions. I hate spam.
> >
> >
> >
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Hal Murray]

***@LeapSecond.com said:
> Any of these methods is going to be a challenge, given their 500 ps
> requirement and their $2k budget.

How stable are surplus rubidium oscillators?

How close could you get if you brought two of them together, compared phase,
drove them to the site for a nights work, drove them back to the same
location and compared the phase again.


--
These are my opinions. I hate spam.



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

[Michael Wouters]

Not stable enough unfortunately. An ageing rate of a few parts in 10^12 per
day is typical, which translates to 100 ns. You could be brave and model
that as linear frequency drift to predict the time offset to the required
0.5 ns or so but I suspect that it could be a very frustrating exercise. We
operate a large number of rubidiums and sudden changes in frequency are
quite common.

Cheers
Michael.

On Thursday, 5 May 2016, Hal Murray <***@megapathdsl.net> wrote:

>
> ***@LeapSecond.com said:
> > Any of these methods is going to be a challenge, given their 500 ps
> > requirement and their $2k budget.
>
> How stable are surplus rubidium oscillators?
>
> How close could you get if you brought two of them together, compared
> phase,
> drove them to the site for a nights work, drove them back to the same
> location and compared the phase again.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com <javascript:;>
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Hal,

> How close could you get if you brought two of them together, compared phase,
> drove them to the site for a nights work, drove them back to the same
> location and compared the phase again.

That's essentially asking what the ADEV (or, TDEV) is for tau 1 day. Rb isn't near good enough. Neither is Cs, for that matter.

See www.leapsecond.com/tmp/5071a-12-run8-5d-10d.gif for a plot of a bunch of 5071A Cs clocks. They are compared together for 5 days to determine their relative phase and frequency offsets and then go on a 5-day trip. You can see how the phase drifts as random walk does its thing. It's way more than 500 ps per day.

That's why the OP cannot use free-running clocks. He needs some method to actively keep them in tight phase lock or passively compare them to within 500 ps in order to adjust the timestamps in post-facto.

/tvb

----- Original Message -----
From: "Hal Murray" <***@megapathdsl.net>
To: "Tom Van Baak" <***@leapsecond.com>; "Discussion of precise time and frequency measurement" <time-***@febo.com>
Cc: <***@megapathdsl.net>
Sent: Wednesday, May 04, 2016 10:30 AM
Subject: Re: [time-nuts] Fw: Optical transfer of time and frequency


>
> ***@LeapSecond.com said:
>> Any of these methods is going to be a challenge, given their 500 ps
>> requirement and their $2k budget.
>
> How stable are surplus rubidium oscillators?
>
> How close could you get if you brought two of them together, compared phase,
> drove them to the site for a nights work, drove them back to the same
> location and compared the phase again.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bruce Griffiths]

In the same vein if it takes 1000 seconds to measure the relative phase of a
pair of clocks to within 500ps then the relative ADEV of the clock pair at
1000 sec needs to be somewhat less than 5E-13.
For 100 s averaging the relative ADEV of a clock pair needs to be better than
5E-12 @ 100sec.
For 10s averaging the relative ADEV of the clock pair needs to be better than
5E-11 @ 10s.
Thus if the measurement takes too long the cost of the local clocks becomes
unaffordable.
Comparison techniques that don't require more than 10-100 sec of averaging are
preferable to keep the cost of the local clocks sufficiently low.

Bruce

On Wednesday, May 04, 2016 03:03:59 PM Tom Van Baak wrote:
> Hal,
>
> > How close could you get if you brought two of them together, compared
> > phase, drove them to the site for a nights work, drove them back to the
> > same location and compared the phase again.
>
> That's essentially asking what the ADEV (or, TDEV) is for tau 1 day. Rb
> isn't near good enough. Neither is Cs, for that matter.
>
> See www.leapsecond.com/tmp/5071a-12-run8-5d-10d.gif for a plot of a bunch of
> 5071A Cs clocks. They are compared together for 5 days to determine their
> relative phase and frequency offsets and then go on a 5-day trip. You can
> see how the phase drifts as random walk does its thing. It's way more than
> 500 ps per day.
>
> That's why the OP cannot use free-running clocks. He needs some method to
> actively keep them in tight phase lock or passively compare them to within
> 500 ps in order to adjust the timestamps in post-facto.
>
> /tvb
>
> ----- Original Message -----
> From: "Hal Murray" <***@megapathdsl.net>
> To: "Tom Van Baak" <***@leapsecond.com>; "Discussion of precise time and
> frequency measurement" <time-***@febo.com> Cc: <***@megapathdsl.net>
> Sent: Wednesday, May 04, 2016 10:30 AM
> Subject: Re: [time-nuts] Fw: Optical transfer of time and frequency
>
> > ***@LeapSecond.com said:
> >> Any of these methods is going to be a challenge, given their 500 ps
> >> requirement and their $2k budget.
> >
> > How stable are surplus rubidium oscillators?
> >
> > How close could you get if you brought two of them together, compared
> > phase, drove them to the site for a nights work, drove them back to the
> > same location and compared the phase again.
>
> _______________________________________________
> time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.