Re: [time-nuts] Need Time Help

[David J Taylor]

From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims

Lady Heather has support for setting the system clock from the GPS receiver. 
The next release has support for analyzing and compensating for the GPS / 
system / com port message delay.  It does not use the 1PPS signal.


It can get the Windoze clock to under 40 msecs (two times the typical 
Windoze 16 msec clock interval).   It can reset the system clock on command, 
periodically, or whenever the GPS time and system time diverge by more than 
x milliseconds.  However it does not have the finesse of NTP that guarantees 
on monotonically increasing system clock... it just "jam syncs" the clock to 
the GPS time.  I know there are people using it for EME work in the field 
where there is no net connection available for NTP, etc.

==

Mark,

You may be able to do much better than 40 ms if you can use the recent 
GetSystemTimePreciseAsFileTime function.


 https://msdn.microsoft.com/en-us/library/windows/desktop/hh706895(v=vs.85).aspx

What I do in my own software is to define a function named like: 
GetSystemTimePrecise  and code that so that when running on Win-8 and later 
it uses the new function and when on earlier Windows it uses the earlier 
GetSystemTimeAsFileTime.  NTP uses this function and it works extremely 
well.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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

Re: [time-nuts] Need Time Help

[David C. Partridge]

Mark,

Do you have a likely date for the availability of the new release (other than 
RSN)?

Cheers
Dave

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims
Sent: 04 October 2016 18:40
To: time-nuts@febo.com
Subject: [time-nuts] Need Time Help

Lady Heather has support for setting the system clock from the GPS receiver.  
The next release has support for analyzing and compensating for the GPS / 
system / com port message delay.  It does not use the 1PPS signal.   

It can get the Windoze clock to under 40 msecs (two times the typical Windoze 
16 msec clock interval).   It can reset the system clock on command, 
periodically, or whenever the GPS time and system time diverge by more than x 
milliseconds.  However it does not have the finesse of NTP that guarantees on 
monotonically increasing system clock... it just "jam syncs" the clock to the 
GPS time.  I know there are people using it for EME work in the field where 
there is no net connection available for NTP, etc.   

Plus the next release can give you the moon az/el/phase/age/ rise+transit+set 
times and draw a pretty picture of the moon at its current az/el and give you 
your location in Maidenhead, UTM, NATO, etc coordinates.
___
time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

Re: [time-nuts] Need Time Help

[Alberto di Bene]

On 10/6/2016 8:10 PM, Wes wrote:


Although I personally ceased pursuing this activity many years ago, there remain
some of us, who are not Luddites, but still believe that "Deep Search Decoding"
is a questionable practice, no matter how it is rationalized.



"Deep Search Decoding" of the JT modes is exactly equivalent to the mental deep 
search
of common call signs done by the CW addicts when receiving just a partial call 
sign, trying
to figure who could be that operator, examining in their brain the list of the 
most probable
persons active in CW EME...Nothing more, nothing less...

But this is a discussion best suited for the Moon-Net list, where it happened 
umpteen times...

73  Alberto  I2PHD




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

Re: [time-nuts] Need Time Help

[jimlux]

On 10/6/16 11:15 AM, William H. Fite wrote:

Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.



Except that here, the popular metrics (AVAR, Phase Noise, etc.) are 
"smaller is better" so the bragging rights go to the list member 
claiming 1E-16 over, say, the relatively feeble 1E-6.



When you get to those sorts of levels, too, it's a lot of attention to 
the details that lets you get there.


It's like GPS: getting 10 meter accuracy is easy
Getting 1 meter is tougher but still straightforward

But getting to centimeters, all of a sudden there's all these factors 
that are insignificant at the 10 meter level but all significant at the 
centimeter level: solid earth tides, ionospheric issues, multipath, etc.


And what's great about this group is that there are people on the list 
who have been bitten by probably every thing that can go wrong (not one 
person had ALL of them, but spanning the group) or could be speculated 
to go wrong.





On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts 
wrote:



To be fair, this is at least partly because asking a relatively simple
question here routinely turns into a dissertation defense.


On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:

Hi

That’s very typical in a lot of forums. The OP tosses up a question and

then pretty much vanishes.

My observation is that roughly 80% of the “I have a question” threads

work that way.

I’ve never been able to figure out if it is an expectation that all

answers will arrive in an hour or two

or if the OP is simply reading along and sees no reason to providing

more information to the group.

Either way, I’m pretty sure that the focus of the answers is not all

that great a week after the last input.


Bob


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







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

Re: [time-nuts] Need Time Help

[William H. Fite]

Very true, Tom! I stand corrected.

On Thu, Oct 6, 2016 at 2:50 PM, Tom Van Baak  wrote:

> Bill,
>
> Some of the key topics of this hobby are -- what did it cost, absolute
> time error, relative frequency instability, and phase noise. In these cases
> the goal of time nuts is always "mine is smaller than yours".
>
> /tvb
>
> - Original Message -
> From: "William H. Fite" 
> To: "Nick Sayer" ; "Discussion of precise time and
> frequency measurement" 
> Sent: Thursday, October 06, 2016 11:15 AM
> Subject: Re: [time-nuts] Need Time Help
>
>
> Indeed, Nick. And more than a little (usually) courteous one upmanship
> couched in terms of being helpful by correcting all previous posters. This
> gentlemanly "mine is bigger than yours" phenomenon is part of what makes
> this group fun to read.
>
> On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts <
> time-nuts@febo.com
> > wrote:
>
> > To be fair, this is at least partly because asking a relatively simple
> > question here routinely turns into a dissertation defense.
> >
> > > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> > >
> > > Hi
> > >
> > > That’s very typical in a lot of forums. The OP tosses up a question and
> > then pretty much vanishes.
> > > My observation is that roughly 80% of the “I have a question” threads
> > work that way.
> > > I’ve never been able to figure out if it is an expectation that all
> > answers will arrive in an hour or two
> > > or if the OP is simply reading along and sees no reason to providing
> > more information to the group.
> > > Either way, I’m pretty sure that the focus of the answers is not all
> > that great a week after the last input.
> > >
> > > Bob
> >
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
Intelligence has never been proof against stupidity.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Tom Van Baak]

Bill,

Some of the key topics of this hobby are -- what did it cost, absolute time 
error, relative frequency instability, and phase noise. In these cases the goal 
of time nuts is always "mine is smaller than yours".

/tvb

- Original Message - 
From: "William H. Fite" 
To: "Nick Sayer" ; "Discussion of precise time and frequency 
measurement" 
Sent: Thursday, October 06, 2016 11:15 AM
Subject: Re: [time-nuts] Need Time Help


Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.

On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts  wrote:

> To be fair, this is at least partly because asking a relatively simple
> question here routinely turns into a dissertation defense.
>
> > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> >
> > Hi
> >
> > That’s very typical in a lot of forums. The OP tosses up a question and
> then pretty much vanishes.
> > My observation is that roughly 80% of the “I have a question” threads
> work that way.
> > I’ve never been able to figure out if it is an expectation that all
> answers will arrive in an hour or two
> > or if the OP is simply reading along and sees no reason to providing
> more information to the group.
> > Either way, I’m pretty sure that the focus of the answers is not all
> that great a week after the last input.
> >
> > Bob
>

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

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

Often the dive into the fine details is all that is left without guidance from 
the OP. After a few days (here or elsewhere) it can get pretty deep ….

Bob


> On Oct 6, 2016, at 2:03 PM, Nick Sayer via time-nuts  
> wrote:
> 
> To be fair, this is at least partly because asking a relatively simple 
> question here routinely turns into a dissertation defense.
> 
>> On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
>> 
>> Hi
>> 
>> That’s very typical in a lot of forums. The OP tosses up a question and then 
>> pretty much vanishes. 
>> My observation is that roughly 80% of the “I have a question” threads work 
>> that way. 
>> I’ve never been able to figure out if it is an expectation that all answers 
>> will arrive in an hour or two 
>> or if the OP is simply reading along and sees no reason to providing more 
>> information to the group.
>> Either way, I’m pretty sure that the focus of the answers is not all that 
>> great a week after the last input.  
>> 
>> Bob
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Need Time Help

[William H. Fite]

Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.

On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts  wrote:

> To be fair, this is at least partly because asking a relatively simple
> question here routinely turns into a dissertation defense.
>
> > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> >
> > Hi
> >
> > That’s very typical in a lot of forums. The OP tosses up a question and
> then pretty much vanishes.
> > My observation is that roughly 80% of the “I have a question” threads
> work that way.
> > I’ve never been able to figure out if it is an expectation that all
> answers will arrive in an hour or two
> > or if the OP is simply reading along and sees no reason to providing
> more information to the group.
> > Either way, I’m pretty sure that the focus of the answers is not all
> that great a week after the last input.
> >
> > Bob
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
Intelligence has never been proof against stupidity.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Wes]

On 10/5/2016 7:40 PM, Chris Albertson wrote:

There was a time when HAMs where the ones pushing radio technology
forward.  Maybe these guys are doing that and building a digital EME
network on VHF?  We don't know.
Actually, we do know.  Regarding my earlier comments, I believe at the time 
(mid-1970) those of us pursuing EME _were_ pushing the technology forward.

We can guess but typically when you start wanting precise time
synchronization it is because of something like TDMA (time division
multiple access) to a shared resource.
Not so.  What is now common is the use of "JT" modes.  JT modes have a number of 
variations but what they have in common is they were developed by Nobel Prize 
winner, Dr. Joe Taylor, who has freely given the software to the ham radio 
community.  See: http://physics.princeton.edu/pulsar/K1JT/JT65.pdf


Although I personally ceased pursuing this activity many years ago, there remain 
some of us, who are not Luddites, but still believe that "Deep Search Decoding" 
is a questionable practice, no matter how it is rationalized.


Nevertheless, the referenced paper should explain the need for precise 
timekeeping.

On Wed, Oct 5, 2016 at 9:47 AM, Wes  wrote:


If you are working "real" EME where you, and not a computer plus lookup
table, are coping the signals, none of these precise timing issues exist.

Wes  N7WS



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

Re: [time-nuts] Need Time Help

[Nick Sayer via time-nuts]

To be fair, this is at least partly because asking a relatively simple question 
here routinely turns into a dissertation defense.

> On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> 
> Hi
> 
> That’s very typical in a lot of forums. The OP tosses up a question and then 
> pretty much vanishes. 
> My observation is that roughly 80% of the “I have a question” threads work 
> that way. 
> I’ve never been able to figure out if it is an expectation that all answers 
> will arrive in an hour or two 
> or if the OP is simply reading along and sees no reason to providing more 
> information to the group.
> Either way, I’m pretty sure that the focus of the answers is not all that 
> great a week after the last input.  
> 
> Bob

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

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

That’s very typical in a lot of forums. The OP tosses up a question and then 
pretty much vanishes. 
My observation is that roughly 80% of the “I have a question” threads work that 
way. 
I’ve never been able to figure out if it is an expectation that all answers 
will arrive in an hour or two 
or if the OP is simply reading along and sees no reason to providing more 
information to the group.
Either way, I’m pretty sure that the focus of the answers is not all that great 
a week after the last input.  

Bob


> On Oct 6, 2016, at 3:33 AM, Mike Cook  wrote:
> 
> Given the number of replies to the OP, most pointed but others drifting OT, 
> it is remarkable that there has been no comment or feedback from Larry. He 
> has slung his bottle and gone away it seems.  
> 
> 
>> Le 5 oct. 2016 à 23:58, Bob Camp  a écrit :
>> 
>> Hi
>> 
>> Given that this is for intermittent EME use, it’s not a system that has uber
>> reliability as a requirement. Once you get the antenna up in a reasonable 
>> location
>> a GPS is going to be pretty stable and reliable. If you have an EME array 
>> running, adding a GPS antenna to it probably not a big deal. 
>> 
>> If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
>> boxes still seem to be out there for < $100 ….
>> 
>> Bob
>> 
>>> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
>>> 
>>> Yo Bob!
>>> 
>>> On Wed, 5 Oct 2016 07:14:30 -0400
>>> Bob Camp  wrote:
>>> 
 If you buy a GPS receiver and get it set up for timing …. just use
 it. Then there is no need for NTP at all….
>>> 
>>> Assuming your GPS never farts and always has a good lock.  A pretty
>>> good assumption, but not a perfect one.
>>> 
>>> RGDS
>>> GARY
>>> ---
>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>>> g...@rellim.com  Tel:+1 541 382 8588
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to 
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> "The power of accurate observation is commonly called cynicism by those who 
> have not got it. »
> George Bernard Shaw
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Need Time Help

[Mike Cook]

Given the number of replies to the OP, most pointed but others drifting OT, it 
is remarkable that there has been no comment or feedback from Larry. He has 
slung his bottle and gone away it seems.  


> Le 5 oct. 2016 à 23:58, Bob Camp  a écrit :
> 
> Hi
> 
> Given that this is for intermittent EME use, it’s not a system that has uber
> reliability as a requirement. Once you get the antenna up in a reasonable 
> location
> a GPS is going to be pretty stable and reliable. If you have an EME array 
> running, adding a GPS antenna to it probably not a big deal. 
> 
> If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
> boxes still seem to be out there for < $100 ….
> 
> Bob
> 
>> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
>> 
>> Yo Bob!
>> 
>> On Wed, 5 Oct 2016 07:14:30 -0400
>> Bob Camp  wrote:
>> 
>>> If you buy a GPS receiver and get it set up for timing …. just use
>>> it. Then there is no need for NTP at all….
>> 
>> Assuming your GPS never farts and always has a good lock.  A pretty
>> good assumption, but not a perfect one.
>> 
>> RGDS
>> GARY
>> ---
>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>>  g...@rellim.com  Tel:+1 541 382 8588
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Re: [time-nuts] Need Time Help

[Hal Murray]

albertson.ch...@gmail.com said:
> The problem is harder then most people think. To avoid jumps in time either
> forward or backwards the software must be something that runs continuously
> and monitors your clock vs. one or more reference clocks.   Logically there
> is no other way. 

I think it depends upon what you mean by "software" and "runs continuously".

The usual way to avoid jumps is for the kernel to do all the work.  You tell 
it how much to adjust.  It tweaks the seconds per tick slightly, waits until 
the adjustment has finished, then undoes the tweak.  With that API, you don't 
need any user software running continuously.


-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] Need Time Help

[Chris Albertson]

There was a time when HAMs where the ones pushing radio technology
forward.  Maybe these guys are doing that and building a digital EME
network on VHF?  We don't know.

We can guess but typically when you start wanting precise time
synchronization it is because of something like TDMA (time division
multiple access) to a shared resource.

On Wed, Oct 5, 2016 at 9:47 AM, Wes  wrote:

> If you are working "real" EME where you, and not a computer plus lookup
> table, are coping the signals, none of these precise timing issues exist.
>
> Wes  N7WS
>
>
> On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
>
>> I must admit to being rather puzzled at the sub microsecond timing
>> requirement as I use ntp to set the W7 clock in my computer and have not
>> had any issues. In fact less than one second is OK for the usual two minute
>> periods that are required to allow for the Faraday rotation. Although I use
>> a GPSDO for a frequency reference I find JT software reasonably tolerant of
>> frequency.  As I may be missing something I would welcome observations on
>> how important the period timing requirement is, you never know I might get
>> more contacts.
>>
>> Regards
>>
>> Peter
>>
>>
>> On 05/10/2016 12:50, Graham / KE9H wrote:
>>
>>> For the group. This ham is trying to work EME. Earth-Moon-Earth
>>> propagation
>>> path. Aka, "moonbounce."
>>>
>>> He is trying to time synchronize a system, where the other station he is
>>> communicating
>>> with can be any other place on the Earth that can also see the Moon.
>>>
>>> So the system time sync is for a little bit tougher case than a local
>>> area
>>> network.
>>>
>>> --- Graham
>>>
>>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

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

Re: [time-nuts] Need Time Help

[Chris Albertson]

First off you are right, NTP does not run well as it can with only a single
reference.   But that is a general statement and assumes there is some
error in a reference clock.   Certainly if using Internet pool servers as
reference clocks you want to have 5 to 7 of them.  But GPS is so darn good
that NTP will be unable to find the difference between any two GPS
receivers.   GPS is a special case.Remember the NTP can use about a
dozen different kinds of reference clocks, even if today only a few are
used in practice.  (really who uses WWV as a standard for their computer
anymore?)


Of course there are other ways of getting time into a Windows PC then using
NTP.  The most primitive thing possible is to simply "jam set" the PC clock
from a NEMA sentence.  This can be as much as a full second "off" and has a
50% chance of making your PC clock run backward (if it was fast rather then
slow)  but LOADS of software offer to do just this, Lady Heather included.

But if you want something that avoids all those problems and makes the
clock perform reasonable at all times then there really are two options NTP
and PTP.  If you are using a GPS as a reference Either if OK,

The problem is harder then most people think. To avoid jumps in time either
forward or backwards the software must be something that runs continuously
and monitors your clock vs. one or more reference clocks.   Logically there
is no other way.  The correction process must be continuously.   PTP and
NTP do this well enough that I doubt anyone would bother to write something
to compete with them.

Between the two PTP performs best in the special case that you own all of
the hardware on both ends and the communications network.

Most casual users can live with a system that "jam-sets" the clock as they
are just reading the display and don't care if  (say) 14:45:30.345 happens
AFTER 14:45:30.355But if you are doing something like trying to aim a
telescope such a thing will cause it to jump and ruin a time exposure.
But I doubt an EME antenna needs to be pointed with the same arc second
level precision.

The BEST way to get GPS time into a computer, and this is how, I think the
world record accuracy was done is to use a GPSDO in place of the cheap
crystal on the motherboard and then spend many hours comparing the
computer's clock to GPS, sorry I lost the link to this  But this method
gets you fractions of microseconds.  The worst way is to parse NEMA
sentences and jam-set them into the clock.  This gets you to roughly one
second, more or less.

On Wed, Oct 5, 2016 at 8:19 AM, Chris Caudle  wrote:

> On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> > If you buy a GPS receiver and get it set up for timing, just use it.
> > Then there is no need for NTP at all.
>
> Is there another way to get computer system time set from a GPS receiver
> other than NTP?
> In the case that the system clock is controlled by GPSDO and the seconds
> delineated by PPS, there should be no need for the NTP clock discipline
> code, but I am not aware of any way to inform the NTP daemon that no
> disciplining is needed.  Presumably the code should determine that
> eventually.
>
> In the case that the system clock is free running, the clock discipline is
> still needed, but I found a note in one of the NTP documents (that I can
> no longer locate at the moment) that stated something to the effect that
> NTP did not run well as it could with a single reference, which would seem
> to directly affect the case where a GPS receiver is the only reference.
> That document had only that short note, no details on why or specifics of
> behavior.
>
> --
> Chris Caudle
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

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

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

Given that this is for intermittent EME use, it’s not a system that has uber
reliability as a requirement. Once you get the antenna up in a reasonable 
location
a GPS is going to be pretty stable and reliable. If you have an EME array 
running, adding a GPS antenna to it probably not a big deal. 

If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
boxes still seem to be out there for < $100 ….

Bob

> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
> 
> Yo Bob!
> 
> On Wed, 5 Oct 2016 07:14:30 -0400
> Bob Camp  wrote:
> 
>> If you buy a GPS receiver and get it set up for timing …. just use
>> it. Then there is no need for NTP at all….
> 
> Assuming your GPS never farts and always has a good lock.  A pretty
> good assumption, but not a perfect one.
> 
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>   g...@rellim.com  Tel:+1 541 382 8588
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Need Time Help

[Tim Shoppa]

I agree that the built in Microsoft tools are SNTP only and will not work
at the 15ms level.

I have had excellent success with Windows PC's of many vintages, from XP
through Windows 10, using Meinberg NTPD and the "pool.ntp.org" timeservers.

Tim N3QE

On Tue, Oct 4, 2016 at 12:41 AM, Larry Hower  wrote:

> Hello to the List:
>
> After a long and bitter struggle with XP and WIN 10, I am writing to ask
> for some help in solving some problems we have been having in our attempt
> to establish a very accurate time reference for use in EME activities.
>
> We are hoping to achieve less than 5ms deviation, although anything below
> 15ms will be adequate for now.
>
> Specifically, we want to use a universal reference that will enable amateur
> radio operators in different parts of the world to start and stop their
> transmissions within a few milliseconds of a specific time. For example, I
> transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
>
> We are using WSJT-X software. We use standard receivers plus we have tried
> a few SDRs.
>
> Sorry for the oversimplified example but I want to make sure we are all on
> the same page.
>
> As background:
>
> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
>
> 2. We have used MS clock tools, including use of Boulder time servers,
> tried both host name and IP address, without reaching the goal.
>
> 3. We have set up some Serial GPS units with PPS and some USB GPS receivers
> (no PPS) and can get to about 0.2 sec but it is not trusted or close
> enough.
>
> 4. We have set up a network time server with similar results.
>
> 5. Deviation is measured using WSJT-X
>
> -
>
> *Standard Receivers*
>
> ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
> reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
>
>
> *SDRs*
>
> We believe that SDR processing can insert a delay of varying length,
> depending on the software, bandwidth, etc. Our SDR tests seem to have a
> delay of as much as 0.5 sec. And with sometimes variable results. We will
> see how SDRs can be used after we resolve the current issues.
>
>
> *Some time related hardware details*
>
> *1. Global Star 4 USB and Serial Connections*
>
> http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
>
> We have 4 of these. Two are older models with serial connections. We have
> serial ports on some computers (XP and a new high-end laptop running WIN
> 10) so we are able to activate the PPS option. Two of the GStar are newer
> models with USB connections which are not able to use the PPS option.
>
> We have tried NEMATime and NEMATime 2 software on this hardware without
> reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> sec. Drifts.  Deviation is measured using WSJT-X.
>
>
> *2. TimeNet NTP Device*
>
> http://www.veracityglobal.com/products/networked-video-integ
> ration-devices/timenet.aspx
>
> We have one of these TimNet units and it has been set up at 2 different
> locations on differing computers according to user instructions. We are
> using the TimNet software as DL'd recently from their web site. We get GPS
> “lock” and Time “lock” shown in the user panel but we do not have faith
> that this is carried into the system clock. Occasionally the "lock"
> indicators go blank but the time seems to be updated when the software is
> strted again (the updated is operation is show at the correct time.  We
> think the app needs some work. Deviation is measured using WSJT-X.  See
> later details.
>
>
> *Setup*
>
> The G Star units have been installed at 2 separate locations, tested using
> WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
>
> Similar tests with a TimeNet unit at one end and G Stars at the other end.
>
> G Star units were installed on the XP laptops with the PPS option enabled
> and running WSJT-X. These XP units seem to have their time “in sync”. See
> following.
>
>
> *WSJT-X*
>
> We are not sure what, if any, internal delays there are attributable to
> this software. We have been using the same version/build at both ends for
> the tests. The software displays in 0.1 sec increments but will show 0.0sec
> when things appear to be working well. We do not know the actual level of
> precision of the WSJT-X software time measurements. I undersand that WSJT-X
> “reads” the system clock at the start of a period (TX or RX) and displays
> what it finds as the time deviation from the local system clock.
>
>
> *WIN XP*
>
> There are 2 laptops running XP. They seem to match each other re time using
> WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
> sure that they are working properly but they need to be more accurate
> (<15ms).
>
>
> *WIN 10*
>
> Installed on a number of desktop and laptop computers. Many efforts were
> made to make these system clocks reference the GPS devices.
>
> We became aware that the WIN Time/

Re: [time-nuts] Need Time Help

[Gary E. Miller]

Yo Bob!

On Wed, 5 Oct 2016 07:14:30 -0400
Bob Camp  wrote:

> If you buy a GPS receiver and get it set up for timing …. just use
> it. Then there is no need for NTP at all….

Assuming your GPS never farts and always has a good lock.  A pretty
good assumption, but not a perfect one.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpf6Fw_gOABQ.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Gary E. Miller]

Yo Chris!

On Wed, 5 Oct 2016 10:19:10 -0500
"Chris Caudle"  wrote:

> On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> > If you buy a GPS receiver and get it set up for timing, just use it.
> > Then there is no need for NTP at all.  
> 
> Is there another way to get computer system time set from a GPS
> receiver other than NTP?

gpsd.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpeJCQxwmJ7C.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Jay Grizzard]

On 2016-10-05 10:22 , Jay Grizzard wrote:

Because NTP normally never actually sets you clock to match a server's
clock.   It adjusts the RATE of your clock so the it cruises on the middle
of the pack of vetted servers.


To be nitpicky, it doesn't actually track towards the median, it tracks
towards a weighted average that takes into account the jitter and root
distance of each peer.

To pick a more meaningful nit, though, the above only happens if none of
your peers are set to 'prefer'. If you have a peer set to 'prefer' (and that
peer survives the clustering algorithm), ntp will track that peer and only
that peer. A *lot* of people have a preferred peer set, so this seems worth
mentioning.

(In general I find that as long as my preferred peer is stable, that I get
much better time having it set that way... otherwise, you get frequency shifts
as peers come and go from the set of selected peers. Preferring a single
stable peer gives me a more stable frequency, but I still list plenty of
other peers to allow for sanity checking of the preferred peer.)



Also your modem is likely not causing an asymmetric delay.  That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router.  The modem likely has the same time of flight in both
directions.


On a connection with active downloads, the modem is almost definitely
causing an asymmetric delay. Especially with bufferbloat being so
common these days, all it takes to give hugely asymmetric performance is
to download a file from a site with a faster pipe than you have.

On my cablemodem at home (55Mbit down, 10Mbit up), if I turn off congestion
management (which is a feature in the custom firmware on my router that is
NOT at all standard/common on mainstream hardware), my incoming latency
will jump to something around 1000ms(!) if I download at max bandwidth,
while my outgoing latency hangs out in the single-digit ms range.

(this is, sadly, the norm today)

On a connection that isn't downloading at the full speed of the connection,
though, your assertion is correct. It just needs that very large asterisk
attached to it. ;)

-j


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

Re: [time-nuts] Need Time Help

[Mark Spencer]

In practice I'm not convinced the timing requirements for the JT modes in 
question are even more than a single order of magnitude more severe than the 
when I have been timing 15 second sequences on my wrist watch during manual non 
computer aided weak signal operations.  To recap if some one has data or direct 
personal experience to make the case that extreme levels of timing accuracy 
will help I'd be interested in seeing this.

That being said I do believe it makes sense to fully use what ever timing 
resources one has access to.

All the best
Mark S

Sent from my iPhone

> On Oct 5, 2016, at 9:47 AM, Wes  wrote:
> 
> If you are working "real" EME where you, and not a computer plus lookup 
> table, are coping the signals, none of these precise timing issues exist.
> 
> Wes  N7WS
> 
>> On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
>> I must admit to being rather puzzled at the sub microsecond timing 
>> requirement as I use ntp to set the W7 clock in my computer and have not had 
>> any issues. In fact less than one second is OK for the usual two minute 
>> periods that are required to allow for the Faraday rotation. Although I use 
>> a GPSDO for a frequency reference I find JT software reasonably tolerant of 
>> frequency.  As I may be missing something I would welcome observations on 
>> how important the period timing requirement is, you never know I might get 
>> more contacts.
>> 
>> Regards
>> 
>> Peter
>> 
>> 
>>> On 05/10/2016 12:50, Graham / KE9H wrote:
>>> For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
>>> path. Aka, "moonbounce."
>>> 
>>> He is trying to time synchronize a system, where the other station he is
>>> communicating
>>> with can be any other place on the Earth that can also see the Moon.
>>> 
>>> So the system time sync is for a little bit tougher case than a local area
>>> network.
>>> 
>>> --- Graham
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Wes]

If you are working "real" EME where you, and not a computer plus lookup table, 
are coping the signals, none of these precise timing issues exist.


Wes  N7WS

On 10/5/2016 6:18 AM, Peter Torry via time-nuts wrote:
I must admit to being rather puzzled at the sub microsecond timing requirement 
as I use ntp to set the W7 clock in my computer and have not had any issues. 
In fact less than one second is OK for the usual two minute periods that are 
required to allow for the Faraday rotation. Although I use a GPSDO for a 
frequency reference I find JT software reasonably tolerant of frequency.  As I 
may be missing something I would welcome observations on how important the 
period timing requirement is, you never know I might get more contacts.


Regards

Peter


On 05/10/2016 12:50, Graham / KE9H wrote:

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham 


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

Re: [time-nuts] Need Time Help

[Chris Caudle]

On Wed, October 5, 2016 6:14 am, Bob Camp wrote:
> If you buy a GPS receiver and get it set up for timing, just use it.
> Then there is no need for NTP at all.

Is there another way to get computer system time set from a GPS receiver
other than NTP?
In the case that the system clock is controlled by GPSDO and the seconds
delineated by PPS, there should be no need for the NTP clock discipline
code, but I am not aware of any way to inform the NTP daemon that no
disciplining is needed.  Presumably the code should determine that
eventually.

In the case that the system clock is free running, the clock discipline is
still needed, but I found a note in one of the NTP documents (that I can
no longer locate at the moment) that stated something to the effect that
NTP did not run well as it could with a single reference, which would seem
to directly affect the case where a GPS receiver is the only reference. 
That document had only that short note, no details on why or specifics of
behavior.

-- 
Chris Caudle


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

Re: [time-nuts] Need Time Help

[Mark Spencer]

Yes I'd be curious in knowing more about this as well.  I've often observed 
time differences from other stations of several tenths of a second when running 
the JT modes on HF.  Although I am beginner at EME I have made a couple of EME 
(earth moon earth) JT65 contacts on VHF without taking any special measures to 
sync the time on a Windows XP machine beyond using the built in features of the 
operating system to sync to my own local time server which was in turned synced 
to the 1 pps output of a GPS timing receiver.

I've also made FSK441 contacts (another related form of amateur radio digital 
communications) in the field without any time reference besides the free 
running clock in my Windows xp laptop.  If there is a significant performance 
improvement to be had with these modes by having time nuts levels of timing 
precision on my computers I'd be very interested to know more.  

All the best 
Mark S

Sent from my iPhone

> On Oct 5, 2016, at 6:18 AM, Peter Torry via time-nuts  
> wrote:
> 
> I must admit to being rather puzzled at the sub microsecond timing 
> requirement as I use ntp to set the W7 clock in my computer and have not had 
> any issues. In fact less than one second is OK for the usual two minute 
> periods that are required to allow for the Faraday rotation. Although I use a 
> GPSDO for a frequency reference I find JT software reasonably tolerant of 
> frequency.  As I may be missing something I would welcome observations on how 
> important the period timing requirement is, you never know I might get more 
> contacts.
> 
> Regards
> 
> Peter
> 
> 
>> On 05/10/2016 12:50, Graham / KE9H wrote:
>> For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
>> path. Aka, "moonbounce."
>> 
>> He is trying to time synchronize a system, where the other station he is
>> communicating
>> with can be any other place on the Earth that can also see the Moon.
>> 
>> So the system time sync is for a little bit tougher case than a local area
>> network.
>> 
>> --- Graham
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Peter Torry via time-nuts]

I must admit to being rather puzzled at the sub microsecond timing 
requirement as I use ntp to set the W7 clock in my computer and have not 
had any issues. In fact less than one second is OK for the usual two 
minute periods that are required to allow for the Faraday rotation. 
Although I use a GPSDO for a frequency reference I find JT software 
reasonably tolerant of frequency.  As I may be missing something I would 
welcome observations on how important the period timing requirement is, 
you never know I might get more contacts.


Regards

Peter


On 05/10/2016 12:50, Graham / KE9H wrote:

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham




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

Re: [time-nuts] Need Time Help

[Graham / KE9H]

For the group. This ham is trying to work EME. Earth-Moon-Earth propagation
path. Aka, "moonbounce."

He is trying to time synchronize a system, where the other station he is
communicating
with can be any other place on the Earth that can also see the Moon.

So the system time sync is for a little bit tougher case than a local area
network.

--- Graham

==

On Wed, Oct 5, 2016 at 6:14 AM, Bob Camp  wrote:

> Hi
>
> If you buy a GPS receiver and get it set up for timing …. just use it.
> Then there is no
> need for NTP at all….
>
> Bob
>
> > On Oct 5, 2016, at 12:33 AM, Chris Albertson 
> wrote:
> >
> > On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp  wrote:
> >
> >> Hi
> >>
> >> If:
> >>
> >> 1) You are a typical Ham in a home environment
> >> 2) All the servers are “out there” on the internet
> >> 3) You have any of the normal modems feeding your home
> >>
> >> You have a very basic issue in terms of path delay. All the servers you
> >> can access
> >> have the *same* asymmetric delay. In that case, no matter how many
> servers
> >> you
> >> add to the ensemble, the situation never gets better. You are always
> stuck
> >> with the
> >> (likely unknown) uplink / downlink delay difference of your modem.
> Exactly
> >> what
> >> that number is depends a *lot* on the modern and the system feeding the
> >> modem.
> >> It is *very* possible to see static delay asymmetry well beyond the 5 ms
> >> that the OP is after.
> >> On most systems there is also a dynamic asymmetry that is related to
> >> loading. That
> >> just makes things harder to work out …..
> >>
> >
> > But this is easy to measure, you buy a GPS receiver and use that as an
> 8th
> > or 6th reference clock along with the 5 or 7 Internet servers then you
> look
> > at the difference between GPS and the Internet servers.  The Internet
> > servers do much better than you'd think.  Not as good as GPS but really
> > good.  Why?
> >
> > Because NTP normally never actually sets you clock to match a server's
> > clock.   It adjusts the RATE of your clock so the it cruises on the
> middle
> > of the pack of vetted servers.  It adjusts your clock over a long period
> to
> > it has the benefit of averaging out lots of random behavior.   The result
> > is that you can keep within a few milliseconds of the GPS even with tens
> of
> > millisecond of delay in the communication path.
> >
> > For people new to NTP, the algorithm has it's hands the system clocks
> > "fast/Slow? lever and never normally moves the clocks hands directly
> >
> > And all those Internet servers do NOT have the same asymmetric delay.
> Well
> > they might but that would be a pathological case.  Typically delays
> really
> > are more symmetric than not (one way trip really is 1/2 the round trip)
> > The clocks that don't meet this assumption are found and removed from the
> > pool.   It works because the dells are NOT the same but random  Ans like
> I
> > said, it is easy enough to measure.  You can see that peer offsets are
> all
> > over the map
> >
> > Also your modem is likely not causing an asymmetric delay.  That modern
> > wetter is is the old phone kind or a fiber optic system only takes you to
> > the fist router.  The modern likely has the same time of flight in both
> > directions.   The delay is cause by a queue some place of packets that
> are
> > aggregated from many users.  These are random  but sort of predictable.
> A
> > packet going across a continent or will see more of this then going to a
> > nearby server
> >
> >
> >> Bob
> >>
> >>> On Oct 4, 2016, at 9:05 PM, Chris Albertson  >
> >> wrote:
> >>>
> >>> The problem, I think with your Internet sync's NTP servers is you are
> >> only
> >>> using one server S.  The most common practice is to use 3 to 5 with 5
> >> being
> >>> about the right number.   If you get Ntp enough Internet servers to
> work
> >>> with it can detect problem like asymmetric path lengths which I'm sure
> is
> >>> you problem.
> >>>
> >>> NTP solved the problem that stumped a few people back in the 1970's of
> >> how
> >>> to sync two clocks when there is a long delay and not constant in there
> >>> communications path.  (Of course the problem is simple if the delay is
> >>> known and well measured)  But the solution required the the average
> path
> >>> delay is the same going in each direction.  worse no software can't
> know
> >>> there is an asymmetric delay.  Well not unless it is using a few
> servers.
> >>> NTP basically finds then ignores the "problem servers".
> >>>
> >>> PTP solves the problem by requiring that all the network hardware has
> >>> special time stamp ability that is designed to work with PTP.  This
> >>> hardware is rare unless the user provides it.  So PTP can't really work
> >> on
> >>> the public Internet.
> >>>
> >>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
> >>> Internet servers, but pick 5 of them or even 7.  and make sure they are
> >>> dispersed and not all at the same place.
> >>>
> >>> On Tue, Oc

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

If you buy a GPS receiver and get it set up for timing …. just use it. Then 
there is no
need for NTP at all….

Bob

> On Oct 5, 2016, at 12:33 AM, Chris Albertson  
> wrote:
> 
> On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> If:
>> 
>> 1) You are a typical Ham in a home environment
>> 2) All the servers are “out there” on the internet
>> 3) You have any of the normal modems feeding your home
>> 
>> You have a very basic issue in terms of path delay. All the servers you
>> can access
>> have the *same* asymmetric delay. In that case, no matter how many servers
>> you
>> add to the ensemble, the situation never gets better. You are always stuck
>> with the
>> (likely unknown) uplink / downlink delay difference of your modem. Exactly
>> what
>> that number is depends a *lot* on the modern and the system feeding the
>> modem.
>> It is *very* possible to see static delay asymmetry well beyond the 5 ms
>> that the OP is after.
>> On most systems there is also a dynamic asymmetry that is related to
>> loading. That
>> just makes things harder to work out …..
>> 
> 
> But this is easy to measure, you buy a GPS receiver and use that as an 8th
> or 6th reference clock along with the 5 or 7 Internet servers then you look
> at the difference between GPS and the Internet servers.  The Internet
> servers do much better than you'd think.  Not as good as GPS but really
> good.  Why?
> 
> Because NTP normally never actually sets you clock to match a server's
> clock.   It adjusts the RATE of your clock so the it cruises on the middle
> of the pack of vetted servers.  It adjusts your clock over a long period to
> it has the benefit of averaging out lots of random behavior.   The result
> is that you can keep within a few milliseconds of the GPS even with tens of
> millisecond of delay in the communication path.
> 
> For people new to NTP, the algorithm has it's hands the system clocks
> "fast/Slow? lever and never normally moves the clocks hands directly
> 
> And all those Internet servers do NOT have the same asymmetric delay.  Well
> they might but that would be a pathological case.  Typically delays really
> are more symmetric than not (one way trip really is 1/2 the round trip)
> The clocks that don't meet this assumption are found and removed from the
> pool.   It works because the dells are NOT the same but random  Ans like I
> said, it is easy enough to measure.  You can see that peer offsets are all
> over the map
> 
> Also your modem is likely not causing an asymmetric delay.  That modern
> wetter is is the old phone kind or a fiber optic system only takes you to
> the fist router.  The modern likely has the same time of flight in both
> directions.   The delay is cause by a queue some place of packets that are
> aggregated from many users.  These are random  but sort of predictable.  A
> packet going across a continent or will see more of this then going to a
> nearby server
> 
> 
>> Bob
>> 
>>> On Oct 4, 2016, at 9:05 PM, Chris Albertson 
>> wrote:
>>> 
>>> The problem, I think with your Internet sync's NTP servers is you are
>> only
>>> using one server S.  The most common practice is to use 3 to 5 with 5
>> being
>>> about the right number.   If you get Ntp enough Internet servers to work
>>> with it can detect problem like asymmetric path lengths which I'm sure is
>>> you problem.
>>> 
>>> NTP solved the problem that stumped a few people back in the 1970's of
>> how
>>> to sync two clocks when there is a long delay and not constant in there
>>> communications path.  (Of course the problem is simple if the delay is
>>> known and well measured)  But the solution required the the average path
>>> delay is the same going in each direction.  worse no software can't know
>>> there is an asymmetric delay.  Well not unless it is using a few servers.
>>> NTP basically finds then ignores the "problem servers".
>>> 
>>> PTP solves the problem by requiring that all the network hardware has
>>> special time stamp ability that is designed to work with PTP.  This
>>> hardware is rare unless the user provides it.  So PTP can't really work
>> on
>>> the public Internet.
>>> 
>>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
>>> Internet servers, but pick 5 of them or even 7.  and make sure they are
>>> dispersed and not all at the same place.
>>> 
>>> On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali  wrote:
>>> 
 On Tue, 4 Oct 2016 15:41:58 +1100
 Larry Hower  wrote:
 
> Ultimately we want sub-millisecond accuracy.
 
 If you want to go that way, you will have to leave windows as
 this operating system does not offer the facilities to get down
 to such a low levelUnless you calibrate the whole path by injecting
 a time pulse into the signal path like Jim Lux and TvB suggested
 
 With linux you can get systems synchronized to better than 1ms by
 using a PTP server in the local network or by directly using PPS.
 This should get yo

Re: [time-nuts] Need Time Help

[Chris Albertson]

On Tue, Oct 4, 2016 at 6:52 PM, Bob Camp  wrote:

> Hi
>
> If:
>
> 1) You are a typical Ham in a home environment
> 2) All the servers are “out there” on the internet
> 3) You have any of the normal modems feeding your home
>
> You have a very basic issue in terms of path delay. All the servers you
> can access
> have the *same* asymmetric delay. In that case, no matter how many servers
> you
> add to the ensemble, the situation never gets better. You are always stuck
> with the
> (likely unknown) uplink / downlink delay difference of your modem. Exactly
> what
> that number is depends a *lot* on the modern and the system feeding the
> modem.
> It is *very* possible to see static delay asymmetry well beyond the 5 ms
> that the OP is after.
> On most systems there is also a dynamic asymmetry that is related to
> loading. That
> just makes things harder to work out …..
>

But this is easy to measure, you buy a GPS receiver and use that as an 8th
or 6th reference clock along with the 5 or 7 Internet servers then you look
at the difference between GPS and the Internet servers.  The Internet
servers do much better than you'd think.  Not as good as GPS but really
good.  Why?

Because NTP normally never actually sets you clock to match a server's
clock.   It adjusts the RATE of your clock so the it cruises on the middle
of the pack of vetted servers.  It adjusts your clock over a long period to
it has the benefit of averaging out lots of random behavior.   The result
is that you can keep within a few milliseconds of the GPS even with tens of
millisecond of delay in the communication path.

For people new to NTP, the algorithm has it's hands the system clocks
"fast/Slow? lever and never normally moves the clocks hands directly

And all those Internet servers do NOT have the same asymmetric delay.  Well
they might but that would be a pathological case.  Typically delays really
are more symmetric than not (one way trip really is 1/2 the round trip)
 The clocks that don't meet this assumption are found and removed from the
pool.   It works because the dells are NOT the same but random  Ans like I
said, it is easy enough to measure.  You can see that peer offsets are all
over the map

Also your modem is likely not causing an asymmetric delay.  That modern
wetter is is the old phone kind or a fiber optic system only takes you to
the fist router.  The modern likely has the same time of flight in both
directions.   The delay is cause by a queue some place of packets that are
aggregated from many users.  These are random  but sort of predictable.  A
packet going across a continent or will see more of this then going to a
nearby server


> Bob
>
> > On Oct 4, 2016, at 9:05 PM, Chris Albertson 
> wrote:
> >
> > The problem, I think with your Internet sync's NTP servers is you are
> only
> > using one server S.  The most common practice is to use 3 to 5 with 5
> being
> > about the right number.   If you get Ntp enough Internet servers to work
> > with it can detect problem like asymmetric path lengths which I'm sure is
> > you problem.
> >
> > NTP solved the problem that stumped a few people back in the 1970's of
> how
> > to sync two clocks when there is a long delay and not constant in there
> > communications path.  (Of course the problem is simple if the delay is
> > known and well measured)  But the solution required the the average path
> > delay is the same going in each direction.  worse no software can't know
> > there is an asymmetric delay.  Well not unless it is using a few servers.
> > NTP basically finds then ignores the "problem servers".
> >
> > PTP solves the problem by requiring that all the network hardware has
> > special time stamp ability that is designed to work with PTP.  This
> > hardware is rare unless the user provides it.  So PTP can't really work
> on
> > the public Internet.
> >
> > You CAN do very well, to just a few Millisecond using NTP sync'ing to
> > Internet servers, but pick 5 of them or even 7.  and make sure they are
> > dispersed and not all at the same place.
> >
> > On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali  wrote:
> >
> >> On Tue, 4 Oct 2016 15:41:58 +1100
> >> Larry Hower  wrote:
> >>
> >>> Ultimately we want sub-millisecond accuracy.
> >>
> >> If you want to go that way, you will have to leave windows as
> >> this operating system does not offer the facilities to get down
> >> to such a low levelUnless you calibrate the whole path by injecting
> >> a time pulse into the signal path like Jim Lux and TvB suggested
> >>
> >> With linux you can get systems synchronized to better than 1ms by
> >> using a PTP server in the local network or by directly using PPS.
> >> This should get you in the order of better than 100µs probaly 20-30µs.
> >>
> >> BTW: A word of advice against using NTP servers over the internet
> >> for accurate time distribution. I recently set-up two NTP servers
> >> to be used as stratum 2 servers (server A and B). Both synchronize
> >> to the same stratum 1

Re: [time-nuts] Need Time Help

[Paul]

On Tue, Oct 4, 2016 at 9:05 PM, Chris Albertson 
wrote:

> The problem, I think with your Internet sync's NTP servers is you are only
> using one server S.  The most common practice is to use 3 to 5 with 5 being
> about the right number.   If you get Ntp enough Internet servers to work
> with it can detect problem like asymmetric path lengths which I'm sure is
> you problem.
>

NTPD cannot find asymmetric delays.  The NTP protocol assumption continues
to be symmetric delays with random delay spikes that can discarded.
However despite that the resultant jitter and offset from asymmetry should
be on the order of milliseconds (O(1ms)).  As the OP has seen not using PPS
swamps all other errors -- NMEA (et.al.) errors are O(100ms) unless you
have a well designed unit e.g. a JL Fury.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

If:

1) You are a typical Ham in a home environment
2) All the servers are “out there” on the internet
3) You have any of the normal modems feeding your home

You have a very basic issue in terms of path delay. All the servers you can 
access 
have the *same* asymmetric delay. In that case, no matter how many servers you
add to the ensemble, the situation never gets better. You are always stuck with 
the
(likely unknown) uplink / downlink delay difference of your modem. Exactly what 
that number is depends a *lot* on the modern and the system feeding the modem. 
It is *very* possible to see static delay asymmetry well beyond the 5 ms that 
the OP is after.
On most systems there is also a dynamic asymmetry that is related to loading. 
That
just makes things harder to work out …..

Bob

> On Oct 4, 2016, at 9:05 PM, Chris Albertson  wrote:
> 
> The problem, I think with your Internet sync's NTP servers is you are only
> using one server S.  The most common practice is to use 3 to 5 with 5 being
> about the right number.   If you get Ntp enough Internet servers to work
> with it can detect problem like asymmetric path lengths which I'm sure is
> you problem.
> 
> NTP solved the problem that stumped a few people back in the 1970's of how
> to sync two clocks when there is a long delay and not constant in there
> communications path.  (Of course the problem is simple if the delay is
> known and well measured)  But the solution required the the average path
> delay is the same going in each direction.  worse no software can't know
> there is an asymmetric delay.  Well not unless it is using a few servers.
> NTP basically finds then ignores the "problem servers".
> 
> PTP solves the problem by requiring that all the network hardware has
> special time stamp ability that is designed to work with PTP.  This
> hardware is rare unless the user provides it.  So PTP can't really work on
> the public Internet.
> 
> You CAN do very well, to just a few Millisecond using NTP sync'ing to
> Internet servers, but pick 5 of them or even 7.  and make sure they are
> dispersed and not all at the same place.
> 
> On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali  wrote:
> 
>> On Tue, 4 Oct 2016 15:41:58 +1100
>> Larry Hower  wrote:
>> 
>>> Ultimately we want sub-millisecond accuracy.
>> 
>> If you want to go that way, you will have to leave windows as
>> this operating system does not offer the facilities to get down
>> to such a low levelUnless you calibrate the whole path by injecting
>> a time pulse into the signal path like Jim Lux and TvB suggested
>> 
>> With linux you can get systems synchronized to better than 1ms by
>> using a PTP server in the local network or by directly using PPS.
>> This should get you in the order of better than 100µs probaly 20-30µs.
>> 
>> BTW: A word of advice against using NTP servers over the internet
>> for accurate time distribution. I recently set-up two NTP servers
>> to be used as stratum 2 servers (server A and B). Both synchronize
>> to the same stratum 1 server (server S), but are at different ISPs
>> and thus use different paths. NTP on both A and B reports the following
>> values (current snapshot, values are representative):
>> 
>> Linkdelay   offset  jitter
>> A-S 4.2050.020   0.081
>> B-S 2.1120.039   0.079
>> A-B 0.606   -0.877   3.192 (as reported by A)
>> 
>> I.e. even though A and B use the same server S as reference, the
>> time difference between both servers is 800-900µs. I am not sure
>> where this path asymmetry comes from, but my guess would be on
>> the connectivity of A (there are two groups of stratum 2 it syncs
>> to and one of them shows the same ~900µs offset). I also do not
>> know why the jitter between A and B is so large even though the
>> delay is pretty low (seems to be a weirdness at a router inbetween).
>> 
>> 
>>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
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Need Time Help

[Chris Albertson]

The problem, I think with your Internet sync's NTP servers is you are only
using one server S.  The most common practice is to use 3 to 5 with 5 being
about the right number.   If you get Ntp enough Internet servers to work
with it can detect problem like asymmetric path lengths which I'm sure is
you problem.

NTP solved the problem that stumped a few people back in the 1970's of how
to sync two clocks when there is a long delay and not constant in there
communications path.  (Of course the problem is simple if the delay is
known and well measured)  But the solution required the the average path
delay is the same going in each direction.  worse no software can't know
there is an asymmetric delay.  Well not unless it is using a few servers.
NTP basically finds then ignores the "problem servers".

PTP solves the problem by requiring that all the network hardware has
special time stamp ability that is designed to work with PTP.  This
hardware is rare unless the user provides it.  So PTP can't really work on
the public Internet.

You CAN do very well, to just a few Millisecond using NTP sync'ing to
Internet servers, but pick 5 of them or even 7.  and make sure they are
dispersed and not all at the same place.

On Tue, Oct 4, 2016 at 2:34 PM, Attila Kinali  wrote:

> On Tue, 4 Oct 2016 15:41:58 +1100
> Larry Hower  wrote:
>
> > Ultimately we want sub-millisecond accuracy.
>
> If you want to go that way, you will have to leave windows as
> this operating system does not offer the facilities to get down
> to such a low levelUnless you calibrate the whole path by injecting
> a time pulse into the signal path like Jim Lux and TvB suggested
>
> With linux you can get systems synchronized to better than 1ms by
> using a PTP server in the local network or by directly using PPS.
> This should get you in the order of better than 100µs probaly 20-30µs.
>
> BTW: A word of advice against using NTP servers over the internet
> for accurate time distribution. I recently set-up two NTP servers
> to be used as stratum 2 servers (server A and B). Both synchronize
> to the same stratum 1 server (server S), but are at different ISPs
> and thus use different paths. NTP on both A and B reports the following
> values (current snapshot, values are representative):
>
> Linkdelay   offset  jitter
> A-S 4.2050.020   0.081
> B-S 2.1120.039   0.079
> A-B 0.606   -0.877   3.192 (as reported by A)
>
> I.e. even though A and B use the same server S as reference, the
> time difference between both servers is 800-900µs. I am not sure
> where this path asymmetry comes from, but my guess would be on
> the connectivity of A (there are two groups of stratum 2 it syncs
> to and one of them shows the same ~900µs offset). I also do not
> know why the jitter between A and B is so large even though the
> delay is pretty low (seems to be a weirdness at a router inbetween).
>
>
> 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
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

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

Re: [time-nuts] Need Time Help

[Attila Kinali]

On Tue, 4 Oct 2016 15:41:58 +1100
Larry Hower  wrote:

> Ultimately we want sub-millisecond accuracy.

If you want to go that way, you will have to leave windows as
this operating system does not offer the facilities to get down
to such a low levelUnless you calibrate the whole path by injecting
a time pulse into the signal path like Jim Lux and TvB suggested

With linux you can get systems synchronized to better than 1ms by
using a PTP server in the local network or by directly using PPS.
This should get you in the order of better than 100µs probaly 20-30µs.

BTW: A word of advice against using NTP servers over the internet
for accurate time distribution. I recently set-up two NTP servers
to be used as stratum 2 servers (server A and B). Both synchronize
to the same stratum 1 server (server S), but are at different ISPs
and thus use different paths. NTP on both A and B reports the following
values (current snapshot, values are representative):

Linkdelay   offset  jitter
A-S 4.2050.020   0.081
B-S 2.1120.039   0.079
A-B 0.606   -0.877   3.192 (as reported by A)

I.e. even though A and B use the same server S as reference, the 
time difference between both servers is 800-900µs. I am not sure
where this path asymmetry comes from, but my guess would be on
the connectivity of A (there are two groups of stratum 2 it syncs
to and one of them shows the same ~900µs offset). I also do not
know why the jitter between A and B is so large even though the
delay is pretty low (seems to be a weirdness at a router inbetween).


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

Re: [time-nuts] Need Time Help

[Chris Albertson]

I think to sum up what has been written

1) USB connection will not work well for timing
2) Notebook computers dont work well for timing
3) A good NTP server on your LAN can get you "close" to what you need even
on PC notebooks
4) With effort and a real serial port and after downloading a copy of NTP
and configuring it even Windows desktop system can do better than 1 milli
second. But if your typical user is not really knowable about PCs he will
have trouble with this
5) Any Linux system, even the tiny Pi. can perform very well (orders of
magnitude better than your requirement) and serve a large number of
computers on a LAN.

I think if you are stuck with running Windows on a notebook that lacks
serial ports the best way to get timing information into that machine is
via the Ethernet port (not WiFi, wired Ethernet)  But;d a local NTP server.
  (cost under $100 including GPS and antenna)

If you have a desktop Windows PC with a real serial port (not USB) and a
user who can install software and edit text baed configuration files and
make cables then you can connect a GPS directly to the computer and it will
work as well as you need




On Tue, Oct 4, 2016 at 1:51 AM, Pete Stephenson  wrote:

> On 10/4/2016 6:41 AM, Larry Hower wrote:
> > Hello to the List:
>
> Hi and welcome!
>
> > After a long and bitter struggle with XP and WIN 10, I am writing to ask
> > for some help in solving some problems we have been having in our attempt
> > to establish a very accurate time reference for use in EME activities.
>
> You have a much higher budget for amateur radio gear than I do if you're
> doing EME. I'm envious. :)
>
> > We are hoping to achieve less than 5ms deviation, although anything below
> > 15ms will be adequate for now.
>
> This should be quite feasible, even with Windows.
>
> That said, is such precision really necessary? I know that JT65 and JT9
> both require "good" time sync, but is millisecond-level precision
> needed? I've had good results for terrestrial contacts with time
> differences ranging from 0.0 to 1.0 seconds. EME might require tighter
> sync, of course.
>
> > Specifically, we want to use a universal reference that will enable
> amateur
> > radio operators in different parts of the world to start and stop their
> > transmissions within a few milliseconds of a specific time. For example,
> I
> > transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> > transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
>
> GPS should be that "universal" (really, planetary) reference.
>
> > 1. We are using desktops and laptops in separate locations running XP or
> > Win 10.
> >
> > 2. We have used MS clock tools, including use of Boulder time servers,
> > tried both host name and IP address, without reaching the goal.
>
> No surprise. The built in Microsoft timekeeping software is "good
> enough" for typical computing purposes (within a second or two) but
> isn't really sufficient for your purposes.
>
> Desktops will be easy, assuming they have a serial port or a serial
> header on the computer itself. If the desktop only has a serial header,
> a cheap adapter like
>  dp/B001Y1F0HW/>
> will connect the header to a standard serial connector.
>
> Laptops might be harder. Using NTP software to a good NTP server on the
> internet should get you within a few milliseconds. Synced to a good NTP
> server on the LAN with the server using GPS+PPS should get you within a
> millisecond.
>
> > 3. We have set up some Serial GPS units with PPS and some USB GPS
> receivers
> > (no PPS) and can get to about 0.2 sec but it is not trusted or close
> enough.
> >
> > 4. We have set up a network time server with similar results.
> >
> > 5. Deviation is measured using WSJT-X
>
> > We believe that SDR processing can insert a delay of varying length,
> > depending on the software, bandwidth, etc. Our SDR tests seem to have a
> > delay of as much as 0.5 sec. And with sometimes variable results. We will
> > see how SDRs can be used after we resolve the current issues.
>
> This isn't really surprising. If the SDRs are connected via USB, there's
> additional delays and jitter inherent in that connection.
>
> > *Some time related hardware details*
> >
> > *1. Global Star 4 USB and Serial Connections*
> >
> > http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
> >
> > We have 4 of these. Two are older models with serial connections. We have
> > serial ports on some computers (XP and a new high-end laptop running WIN
> > 10) so we are able to activate the PPS option. Two of the GStar are newer
> > models with USB connections which are not able to use the PPS option.
> >
> > We have tried NEMATime and NEMATime 2 software on this hardware without
> > reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> > sec. Drifts.  Deviation is measured using WSJT-X.
>
> The BU-353-S4 lacks a PPS line to precisely 

Re: [time-nuts] Need Time Help

[Pete Stephenson]

On 10/4/2016 6:41 AM, Larry Hower wrote:
> Hello to the List:

Hi and welcome!

> After a long and bitter struggle with XP and WIN 10, I am writing to ask
> for some help in solving some problems we have been having in our attempt
> to establish a very accurate time reference for use in EME activities.

You have a much higher budget for amateur radio gear than I do if you're
doing EME. I'm envious. :)

> We are hoping to achieve less than 5ms deviation, although anything below
> 15ms will be adequate for now.

This should be quite feasible, even with Windows.

That said, is such precision really necessary? I know that JT65 and JT9
both require "good" time sync, but is millisecond-level precision
needed? I've had good results for terrestrial contacts with time
differences ranging from 0.0 to 1.0 seconds. EME might require tighter
sync, of course.

> Specifically, we want to use a universal reference that will enable amateur
> radio operators in different parts of the world to start and stop their
> transmissions within a few milliseconds of a specific time. For example, I
> transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.

GPS should be that "universal" (really, planetary) reference.

> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
> 
> 2. We have used MS clock tools, including use of Boulder time servers,
> tried both host name and IP address, without reaching the goal.

No surprise. The built in Microsoft timekeeping software is "good
enough" for typical computing purposes (within a second or two) but
isn't really sufficient for your purposes.

Desktops will be easy, assuming they have a serial port or a serial
header on the computer itself. If the desktop only has a serial header,
a cheap adapter like

will connect the header to a standard serial connector.

Laptops might be harder. Using NTP software to a good NTP server on the
internet should get you within a few milliseconds. Synced to a good NTP
server on the LAN with the server using GPS+PPS should get you within a
millisecond.

> 3. We have set up some Serial GPS units with PPS and some USB GPS receivers
> (no PPS) and can get to about 0.2 sec but it is not trusted or close enough.
> 
> 4. We have set up a network time server with similar results.
> 
> 5. Deviation is measured using WSJT-X

> We believe that SDR processing can insert a delay of varying length,
> depending on the software, bandwidth, etc. Our SDR tests seem to have a
> delay of as much as 0.5 sec. And with sometimes variable results. We will
> see how SDRs can be used after we resolve the current issues.

This isn't really surprising. If the SDRs are connected via USB, there's
additional delays and jitter inherent in that connection.

> *Some time related hardware details*
> 
> *1. Global Star 4 USB and Serial Connections*
> 
> http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
> 
> We have 4 of these. Two are older models with serial connections. We have
> serial ports on some computers (XP and a new high-end laptop running WIN
> 10) so we are able to activate the PPS option. Two of the GStar are newer
> models with USB connections which are not able to use the PPS option.
> 
> We have tried NEMATime and NEMATime 2 software on this hardware without
> reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> sec. Drifts.  Deviation is measured using WSJT-X.

The BU-353-S4 lacks a PPS line to precisely signal the start of each
second. (At least the specific one I have for mapping doesn't have that
option.) Although you may get somewhat better precision using the SiRF
binary stream, your deviation is about what I'd expect for a USB
receiver with NMEA output.

Simply put, without PPS you probably won't get closer than 250ms unless
you're quite lucky. Doubly so if you're using PPS-over-USB.

> *2. TimeNet NTP Device*
> 
> http://www.veracityglobal.com/products/networked-video-integ
> ration-devices/timenet.aspx
> 
> We have one of these TimNet units and it has been set up at 2 different
> locations on differing computers according to user instructions. We are
> using the TimNet software as DL'd recently from their web site. We get GPS
> “lock” and Time “lock” shown in the user panel but we do not have faith
> that this is carried into the system clock. Occasionally the "lock"
> indicators go blank but the time seems to be updated when the software is
> strted again (the updated is operation is show at the correct time.  We
> think the app needs some work. Deviation is measured using WSJT-X.  See
> later details.

I wonder if you'll get better results using Meinberg's Windows port of
NTPd:  -- you should
be able to configure it to query your TimNet device and get reasonably
good precision.

M

Re: [time-nuts] Need Time Help

[Rob Kimberley]

Suggest you try the following which I use on Win10 with great success

https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable

and

https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm

Rob K



-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of dl...@yahoo.de 
via time-nuts
Sent: 04 October 2016 07:57
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Need Time Help

Hello Larry,
for Windows i know only one piece of software that is able to set the system 
clock within a few milliseconds.  Dimension4. 
http://www.thinkman.com/dimension4/features.htm

Since I have not yet even measured it i can not tell if it meets your 
specifications.

Maybe you give it a try. 

Chris
DL3HC

- Nachricht beantworten -
Von: "Larry Hower" 
An: 
Betreff: [time-nuts] Need Time Help
Datum: Di., Okt. 4, 2016 06:41

Hello to the List:

After a long and bitter struggle with XP and WIN 10, I am writing to ask for 
some help in solving some problems we have been having in our attempt to 
establish a very accurate time reference for use in EME activities.

We are hoping to achieve less than 5ms deviation, although anything below 15ms 
will be adequate for now.

Specifically, we want to use a universal reference that will enable amateur 
radio operators in different parts of the world to start and stop their 
transmissions within a few milliseconds of a specific time. For example, I 
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.

We are using WSJT-X software. We use standard receivers plus we have tried a 
few SDRs.

Sorry for the oversimplified example but I want to make sure we are all on the 
same page.

As background:

1. We are using desktops and laptops in separate locations running XP or Win 10.

2. We have used MS clock tools, including use of Boulder time servers, tried 
both host name and IP address, without reaching the goal.

3. We have set up some Serial GPS units with PPS and some USB GPS receivers (no 
PPS) and can get to about 0.2 sec but it is not trusted or close enough.

4. We have set up a network time server with similar results.

5. Deviation is measured using WSJT-X

-

*Standard Receivers*

ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc reference. 
We have frequency accuracy of 1 to 2 Hertz at 10GHz.


*SDRs*

We believe that SDR processing can insert a delay of varying length, depending 
on the software, bandwidth, etc. Our SDR tests seem to have a delay of as much 
as 0.5 sec. And with sometimes variable results. We will see how SDRs can be 
used after we resolve the current issues.


*Some time related hardware details*

*1. Global Star 4 USB and Serial Connections*

http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg

We have 4 of these. Two are older models with serial connections. We have 
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer 
models with USB connections which are not able to use the PPS option.

We have tried NEMATime and NEMATime 2 software on this hardware without 
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3 sec. 
Drifts.  Deviation is measured using WSJT-X.


*2. TimeNet NTP Device*

http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx

We have one of these TimNet units and it has been set up at 2 different 
locations on differing computers according to user instructions. We are using 
the TimNet software as DL'd recently from their web site. We get GPS “lock” and 
Time “lock” shown in the user panel but we do not have faith that this is 
carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is 
strted again (the updated is operation is show at the correct time.  We think 
the app needs some work. Deviation is measured using WSJT-X.  See later details.


*Setup*

The G Star units have been installed at 2 separate locations, tested using 
WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.

Similar tests with a TimeNet unit at one end and G Stars at the other end.

G Star units were installed on the XP laptops with the PPS option enabled and 
running WSJT-X. These XP units seem to have their time “in sync”. See following.


*WSJT-X*

We are not sure what, if any, internal delays there are attributable to this 
software. We have been using the same version/build at both ends for the tests. 
The software displays in 0.1 sec increments but will show 0.0sec when things 
appear to be working well. We do not know the actual level of precision of the 
WSJT-X software time measurements. I undersand that WSJT-X “reads” the system 
clock at the start of a period (TX or RX) and displays what it finds as the 
time dev

Re: [time-nuts] Need Time Help

[Tom Van Baak]

Hi Larry,

You are using a bunch of h/w and s/w together and you want each piece to 
maintain precise time.

Would it be possible for you to inject a very short GPS 1PPS pulse or GHz tone 
into your antenna feed?

That will cause a slight blip in your raw data which your processing s/w can 
then use to self-calibrate the absolute time of all samples as often as once a 
second. This allows your PC and OS to be data processors (which they are good 
at) and not precision timekeepers (which they are not good at). It also solves 
the latency issues with your SDR h/w and s/w.

I've done something similar with PC sound cards. Instead of having the OS 
pretend it's a timekeeper you just put a 1PPS into the R channel and your data 
stream into the L channel. It's trivial to then correlate the two and nail down 
the absolute time of the samples at the microsecond level. The beauty is that 
it completely avoids the problems of PC timekeeping. It works with any laptop 
and any operating system at any temperature and it also solves the accuracy and 
latency problems that even NTP on Linux doesn't solve.

/tvb

- Original Message - 
From: "Larry Hower" 
To: 
Sent: Monday, October 03, 2016 9:41 PM
Subject: [time-nuts] Need Time Help


Hello to the List:

After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.

We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.

Specifically, we want to use a universal reference that will enable amateur
radio operators in different parts of the world to start and stop their
transmissions within a few milliseconds of a specific time. For example, I
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.

We are using WSJT-X software. We use standard receivers plus we have tried
a few SDRs.

Sorry for the oversimplified example but I want to make sure we are all on
the same page.

As background:

1. We are using desktops and laptops in separate locations running XP or
Win 10.

2. We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal.

3. We have set up some Serial GPS units with PPS and some USB GPS receivers
(no PPS) and can get to about 0.2 sec but it is not trusted or close enough.

4. We have set up a network time server with similar results.

5. Deviation is measured using WSJT-X

-

*Standard Receivers*

ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.


*SDRs*

We believe that SDR processing can insert a delay of varying length,
depending on the software, bandwidth, etc. Our SDR tests seem to have a
delay of as much as 0.5 sec. And with sometimes variable results. We will
see how SDRs can be used after we resolve the current issues.


*Some time related hardware details*

*1. Global Star 4 USB and Serial Connections*

http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg

We have 4 of these. Two are older models with serial connections. We have
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer
models with USB connections which are not able to use the PPS option.

We have tried NEMATime and NEMATime 2 software on this hardware without
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
sec. Drifts.  Deviation is measured using WSJT-X.


*2. TimeNet NTP Device*

http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx

We have one of these TimNet units and it has been set up at 2 different
locations on differing computers according to user instructions. We are
using the TimNet software as DL'd recently from their web site. We get GPS
“lock” and Time “lock” shown in the user panel but we do not have faith
that this is carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is
strted again (the updated is operation is show at the correct time.  We
think the app needs some work. Deviation is measured using WSJT-X.  See
later details.


*Setup*

The G Star units have been installed at 2 separate locations, tested using
WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.

Similar tests with a TimeNet unit at one end and G Stars at the other end.

G Star units were installed on the XP laptops with the PPS option enabled
and running WSJT-X. These XP units seem to have their time “in sync”. See
following.


*WSJT-X*

We are not sure what, if any, internal delays there are attributable to
this software. We have been using the same version/build at both ends for
the tests. The software displays in 0.1 sec incr

Re: [time-nuts] Need Time Help

[jimlux]

On 10/4/16 6:26 AM, Graham / KE9H wrote:

Larry:

You have multiple problems, with the way you are trying to define
"time-error."

I think you are defining it as the time error of the signal coming out of
your receivers/decoders.

You are blending all the error/delay sources together, and you need to
break them apart, since each one will have a different solution, or method
of management

First, the reflector has already jumped in and helped you with the
definition of absolute time.  You can get single digit millisecond accuracy
(with some caviats and bewares) from NTP, for stations at different
locations.  You should be able to get single digit microsecond accuracy (or
better) with an appropriate GPS based timing systems. You can not get these
levels of accuracy out of the native time system on Windows. That is more
like single digit seconds.

Second, you have some serious signal processing latency delays in your
receivers/demodulators/decoders.  Depending on how the designer has dealt
with streaming and buffering, particularly with the (buffered) connections
between the stages, these processing latency delays may be constant or
variable, or perhaps adjustable.  The Windows Sound system is horrible from
a latency/stability standpoint. You are probably feeding your back-end
demodulators/decoders through it. You will need to break apart your system
(transmit and receive) into modules or stages, and characterize each one
for latency. Beware of (uncontrolled) buffers at the interfaces. You
generally need to pick a reference point, such as the antenna port, and
correct everything to that reference point.

Third, you seem to be running a portion of the (SDR) receivers and the
demodulators/decoders on computers with Operating Systems. (Like WIndows
OS, which is NOT a real-time operating system.)  That means that the
response time of the system to a request for computing resources can be
quite variable. (microseconds to tens of milliseconds typical, with rare
excursions into the single digit seconds.)  The solution to this problem is
to either run on a very lightly loaded computer, or switch to a real time
OS, such as Linux with a real-time kernel. This does not cure the problem,
but does put bounds on it.

--- Graham / KE9H





One way that seems to work fairly well, as long as you can post process 
(or your "turnaround latency" can be in the "seconds" bucket).. is to 
record a time reference signal that is added to the original RF signal. 
A pilot tone, or a modulated tone, somewhat away from your desired 
signal, generated by a high quality time reference (maybe you have an 
XO, and you phase modulate it with the 1pps from your GPS receiver).


Then, in your downconverted, digitized, and filtered data, you look for 
the time reference and use that as what you need, rather than trying to 
back out all the (non-deterministic) delays through the audio processing 
chain.


By the way, Windows *can* be very good on synchronizing audio: otherwise 
audio and video wouldn't play together in media, high performance gaming 
wouldn't work, etc.  The problem is that it is a royal, giant, pain to 
get it to work.  You need a lot of knowledge and experience with exactly 
how Windows handles the media streams, all those countless APIs, etc. 
And it is different for each version of Windows.  (Realistically, Linux 
and Mac OS X are no better: the nature of the difficulties is different, 
but they're still there)




The typical amateur radio spectrogram program or demodulator probably 
doesn't do that: they use a simple FIFO pipeline, and make no claim that 
what's on the screen matches what's at the antenna at a particular 
instant, as long as the order and duration is correct eventually.  If 
you're decoding CW with CW skimmer or decoding PSK31, you probably 
aren't doing full break-in between the dots and dashes or characters: a 
few tenths of a second random lag doesn't make any difference 
(especially since the signal you're receiving is over a 
non-deterministic delay skywave path)



My philosophy (and the one that wound up embedded in our design of a 
Software Defined Radio framework for space radios) is that software 
handles the *management* of timing critical processing implemented in a 
FPGA.  Sample accurate timing is done basically in hardware, and 
software (running on whatever OS - we use RTEMS which is pretty good 
Real Time, but...) talks to the hardware using a model which says, in 
effect, don't try to synchronize across this interface at resolutions 
finer than 1 millisecond.  (For non Real Time OS, I'd try for 10s of 
milliseconds)


For a simple instance, we latch a a free running counter driven from an 
OCXO with the GPS 1pps. That's in hardware.  The software just has to 
guarantee that it reads the latch at least once a second and we can 
collect the data we're interested in. If it can't guarantee that, that 
it can figure out what happened if we miss a latch event (i.e. the count 
looks like it inc

Re: [time-nuts] Need Time Help

[dl3hc]

Hello Larry,
for Windows i know only one piece of software that is able to set the system 
clock within a few milliseconds.  Dimension4. 
http://www.thinkman.com/dimension4/features.htm

Since I have not yet even measured it i can not tell if it meets your 
specifications.

Maybe you give it a try. 

Chris
DL3HC

- Nachricht beantworten -
Von: "Larry Hower" 
An: 
Betreff: [time-nuts] Need Time Help
Datum: Di., Okt. 4, 2016 06:41

Hello to the List:

After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.

We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.

Specifically, we want to use a universal reference that will enable amateur
radio operators in different parts of the world to start and stop their
transmissions within a few milliseconds of a specific time. For example, I
transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.

We are using WSJT-X software. We use standard receivers plus we have tried
a few SDRs.

Sorry for the oversimplified example but I want to make sure we are all on
the same page.

As background:

1. We are using desktops and laptops in separate locations running XP or
Win 10.

2. We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal.

3. We have set up some Serial GPS units with PPS and some USB GPS receivers
(no PPS) and can get to about 0.2 sec but it is not trusted or close enough.

4. We have set up a network time server with similar results.

5. Deviation is measured using WSJT-X

-

*Standard Receivers*

ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.


*SDRs*

We believe that SDR processing can insert a delay of varying length,
depending on the software, bandwidth, etc. Our SDR tests seem to have a
delay of as much as 0.5 sec. And with sometimes variable results. We will
see how SDRs can be used after we resolve the current issues.


*Some time related hardware details*

*1. Global Star 4 USB and Serial Connections*

http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg

We have 4 of these. Two are older models with serial connections. We have
serial ports on some computers (XP and a new high-end laptop running WIN
10) so we are able to activate the PPS option. Two of the GStar are newer
models with USB connections which are not able to use the PPS option.

We have tried NEMATime and NEMATime 2 software on this hardware without
reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
sec. Drifts.  Deviation is measured using WSJT-X.


*2. TimeNet NTP Device*

http://www.veracityglobal.com/products/networked-video-integ
ration-devices/timenet.aspx

We have one of these TimNet units and it has been set up at 2 different
locations on differing computers according to user instructions. We are
using the TimNet software as DL'd recently from their web site. We get GPS
“lock” and Time “lock” shown in the user panel but we do not have faith
that this is carried into the system clock. Occasionally the "lock"
indicators go blank but the time seems to be updated when the software is
strted again (the updated is operation is show at the correct time.  We
think the app needs some work. Deviation is measured using WSJT-X.  See
later details.


*Setup*

The G Star units have been installed at 2 separate locations, tested using
WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.

Similar tests with a TimeNet unit at one end and G Stars at the other end.

G Star units were installed on the XP laptops with the PPS option enabled
and running WSJT-X. These XP units seem to have their time “in sync”. See
following.


*WSJT-X*

We are not sure what, if any, internal delays there are attributable to
this software. We have been using the same version/build at both ends for
the tests. The software displays in 0.1 sec increments but will show 0.0sec
when things appear to be working well. We do not know the actual level of
precision of the WSJT-X software time measurements. I undersand that WSJT-X
“reads” the system clock at the start of a period (TX or RX) and displays
what it finds as the time deviation from the local system clock.


*WIN XP*

There are 2 laptops running XP. They seem to match each other re time using
WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
sure that they are working properly but they need to be more accurate
(<15ms).


*WIN 10*

Installed on a number of desktop and laptop computers. Many efforts were
made to make these system clocks reference the GPS devices.

We became aware that the WIN Time/Date GUI was not always driving the
setting down into the system clo

Re: [time-nuts] Need Time Help

[David J Taylor]

From: Graham / KE9H

Larry:
[]
First, the reflector has already jumped in and helped you with the
definition of absolute time.  You can get single digit millisecond accuracy
(with some caviats and bewares) from NTP, for stations at different
locations.  You should be able to get single digit microsecond accuracy (or
better) with an appropriate GPS based timing systems. You can not get these
levels of accuracy out of the native time system on Windows. That is more
like single digit seconds.
[]
--- Graham / KE9H
==

Graham,

I showed graphs of five Windows systems using a PPS feed this morning all 
keeping time to within a millisecond, far better than "single digit 
seconds".


 http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

Note that PC Alta shows a transient following a reboot, and the PPS feed has 
since been stolen from PC Bacchus around 13:00 UTC so that I can carry out 
some tests comparing USB PPS with Wi-Fi network syncing.


Your other points are well taken.

73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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

Re: [time-nuts] Need Time Help

[Graham / KE9H]

Larry:

You have multiple problems, with the way you are trying to define
"time-error."

I think you are defining it as the time error of the signal coming out of
your receivers/decoders.

You are blending all the error/delay sources together, and you need to
break them apart, since each one will have a different solution, or method
of management

First, the reflector has already jumped in and helped you with the
definition of absolute time.  You can get single digit millisecond accuracy
(with some caviats and bewares) from NTP, for stations at different
locations.  You should be able to get single digit microsecond accuracy (or
better) with an appropriate GPS based timing systems. You can not get these
levels of accuracy out of the native time system on Windows. That is more
like single digit seconds.

Second, you have some serious signal processing latency delays in your
receivers/demodulators/decoders.  Depending on how the designer has dealt
with streaming and buffering, particularly with the (buffered) connections
between the stages, these processing latency delays may be constant or
variable, or perhaps adjustable.  The Windows Sound system is horrible from
a latency/stability standpoint. You are probably feeding your back-end
demodulators/decoders through it. You will need to break apart your system
(transmit and receive) into modules or stages, and characterize each one
for latency. Beware of (uncontrolled) buffers at the interfaces. You
generally need to pick a reference point, such as the antenna port, and
correct everything to that reference point.

Third, you seem to be running a portion of the (SDR) receivers and the
demodulators/decoders on computers with Operating Systems. (Like WIndows
OS, which is NOT a real-time operating system.)  That means that the
response time of the system to a request for computing resources can be
quite variable. (microseconds to tens of milliseconds typical, with rare
excursions into the single digit seconds.)  The solution to this problem is
to either run on a very lightly loaded computer, or switch to a real time
OS, such as Linux with a real-time kernel. This does not cure the problem,
but does put bounds on it.

--- Graham / KE9H

==

On Tue, Oct 4, 2016 at 7:03 AM, Bob Camp  wrote:

> Hi
>
> As others have mentioned, you have two strikes against you:
>
> 1) Modern laptops *love* power saving. That makes them poor time keepers
> at the millisecond level. It takes some well thought out software in the
> OS to
> keep track of all the strange things they do.
>
> 2) Windows XP is getting a bit old and tired. It’s internals were done
> long ago
> on hardware very different than what we have today. It has a lot of
> limitations.
>
> Between the two, you will always struggle. An RTOS would do much better
> than
> XP for timing. Virtually all of the more modern OS’s (some of them free)
> will
> handle timing better than XP does. That’s not to say the laptop will not
> ultimately
> limit what you can do.
>
> There are a few more strikes when you try do do NTP over a residential
> internet
> connection. Cable modems and the like are not designed for high accuracy
> timing.
>
> By far the best solution is to get timing from a GPS. Even a cheap on,
> running over
> a lousy cable will get you into the 1 us region if it’s a modern unit.
> That is way
> better than the 5 ms that you are after. Moving it around on a local LAN
> with
> good cabling isn’t going to degrade it by much over 1 ms, even using NTP.
>
> One alternative to the whole “computers are a mess” issue is to simply put
> the
> GPS into the same hardware that is receiving / transmitting the signals .
> There
> are a *lot* of GPS modules on the market that will put out an accurate PPS
> signal.
> Depending on how picky you are, they are in the $10 to $50 range. Let the
> local
> hardware do the job rather than network the whole thing. Local hardware
> running
> a reasonable OS is in the $30 to $100 range, again depending on features.
> Given
> that you probably already have the price of a small car tied up in antenna
> systems,
> this isn’t that crazy a cost.
>
> Bob
>
>
> > On Oct 4, 2016, at 12:41 AM, Larry Hower  wrote:
> >
> > Hello to the List:
> >
> > After a long and bitter struggle with XP and WIN 10, I am writing to ask
> > for some help in solving some problems we have been having in our attempt
> > to establish a very accurate time reference for use in EME activities.
> >
> > We are hoping to achieve less than 5ms deviation, although anything below
> > 15ms will be adequate for now.
> >
> > Specifically, we want to use a universal reference that will enable
> amateur
> > radio operators in different parts of the world to start and stop their
> > transmissions within a few milliseconds of a specific time. For example,
> I
> > transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> > transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
> >
> > We are using WSJT-X software. We

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

As others have mentioned, you have two strikes against you:

1) Modern laptops *love* power saving. That makes them poor time keepers 
at the millisecond level. It takes some well thought out software in the OS to 
keep track of all the strange things they do. 

2) Windows XP is getting a bit old and tired. It’s internals were done long ago
on hardware very different than what we have today. It has a lot of 
limitations. 

Between the two, you will always struggle. An RTOS would do much better than 
XP for timing. Virtually all of the more modern OS’s (some of them free) will 
handle timing better than XP does. That’s not to say the laptop will not 
ultimately 
limit what you can do. 

There are a few more strikes when you try do do NTP over a residential internet 
connection. Cable modems and the like are not designed for high accuracy
timing. 

By far the best solution is to get timing from a GPS. Even a cheap on, running 
over
a lousy cable will get you into the 1 us region if it’s a modern unit. That is 
way
better than the 5 ms that you are after. Moving it around on a local LAN with 
good cabling isn’t going to degrade it by much over 1 ms, even using NTP. 

One alternative to the whole “computers are a mess” issue is to simply put the 
GPS into the same hardware that is receiving / transmitting the signals . There 
are a *lot* of GPS modules on the market that will put out an accurate PPS 
signal. 
Depending on how picky you are, they are in the $10 to $50 range. Let the local 
hardware do the job rather than network the whole thing. Local hardware running 
a reasonable OS is in the $30 to $100 range, again depending on features. Given
that you probably already have the price of a small car tied up in antenna 
systems, 
this isn’t that crazy a cost. 

Bob


> On Oct 4, 2016, at 12:41 AM, Larry Hower  wrote:
> 
> Hello to the List:
> 
> After a long and bitter struggle with XP and WIN 10, I am writing to ask
> for some help in solving some problems we have been having in our attempt
> to establish a very accurate time reference for use in EME activities.
> 
> We are hoping to achieve less than 5ms deviation, although anything below
> 15ms will be adequate for now.
> 
> Specifically, we want to use a universal reference that will enable amateur
> radio operators in different parts of the world to start and stop their
> transmissions within a few milliseconds of a specific time. For example, I
> transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
> 
> We are using WSJT-X software. We use standard receivers plus we have tried
> a few SDRs.
> 
> Sorry for the oversimplified example but I want to make sure we are all on
> the same page.
> 
> As background:
> 
> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
> 
> 2. We have used MS clock tools, including use of Boulder time servers,
> tried both host name and IP address, without reaching the goal.
> 
> 3. We have set up some Serial GPS units with PPS and some USB GPS receivers
> (no PPS) and can get to about 0.2 sec but it is not trusted or close enough.
> 
> 4. We have set up a network time server with similar results.
> 
> 5. Deviation is measured using WSJT-X
> 
> -
> 
> *Standard Receivers*
> 
> ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
> reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
> 
> 
> *SDRs*
> 
> We believe that SDR processing can insert a delay of varying length,
> depending on the software, bandwidth, etc. Our SDR tests seem to have a
> delay of as much as 0.5 sec. And with sometimes variable results. We will
> see how SDRs can be used after we resolve the current issues.
> 
> 
> *Some time related hardware details*
> 
> *1. Global Star 4 USB and Serial Connections*
> 
> http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
> 
> We have 4 of these. Two are older models with serial connections. We have
> serial ports on some computers (XP and a new high-end laptop running WIN
> 10) so we are able to activate the PPS option. Two of the GStar are newer
> models with USB connections which are not able to use the PPS option.
> 
> We have tried NEMATime and NEMATime 2 software on this hardware without
> reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> sec. Drifts.  Deviation is measured using WSJT-X.
> 
> 
> *2. TimeNet NTP Device*
> 
> http://www.veracityglobal.com/products/networked-video-integ
> ration-devices/timenet.aspx
> 
> We have one of these TimNet units and it has been set up at 2 different
> locations on differing computers according to user instructions. We are
> using the TimNet software as DL'd recently from their web site. We get GPS
> “lock” and Time “lock” shown in the user panel but we do not have faith
> that this is carried into the system clock. Occasionally the "lock"
> indicators go blank but the time seems to be 

Re: [time-nuts] Need Time Help

[Clint Jay]

What's being transmitted?

If it's a repetitive message would it be possible to inhibit transmission
using an external time source, perhaps a PIC or even a Pi inhibiting the
"PTT", leaving the windows box in control of what's transmitted or do the
Windows boxes have to communicate with each other via some back channel?

On 4 Oct 2016 08:30, "Chris Albertson"  wrote:

> On Mon, Oct 3, 2016 at 9:41 PM, Larry Hower  wrote:
>
> >
> >
> > 1. We are using desktops and laptops in separate locations running XP or
> > Win 10.
> >
>
> Assuming you have decent GPS receivers with an un-obstructed view of the
> sky with 1 pulse per second output and you have let the GPS run long enough
> to track enough satellites  then...  The pulse typically has a standard
> deviation on the order of some tens of nanoseconds.   So that is not your
> problem.  It is software., well mostly.  Also computers that manage power
> like notebooks are not going to give good timing performance no matter what
> you try.
>
> MS Windows is not the best choice for running NTP.   You can do it.  and
> many people have gotten results better then 1 millisecond.  But
> If you are willing to give up the use of MS Windows.  Then tens of
> microseconds is not hard.
>
> Little $35 credit card sized computers (Raspberry Pi) running Linux and NTP
> with a GPS input are easy to get an order of magnitude better than your
> requirement.
>
> So are you stuck with windows.  f so it can work with some rather complex
> setup.   If you can select another OS then you get out of the box
> sub-millisecond performance with little effort
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Need Time Help

[David J Taylor]

From: Hal Murray

david-tay...@blueyonder.co.uk said:

You can use a GPS puck or equivalent with PPS output to get the sort of
accuracy you need.  ..:


PPS output is only half the battle.  You also have to get it into the system
that needs it.

A modem control signal on an old fashioned serial port (not USB) is the
classic approach.  Unfortunately, many modern systems, especially laptops,
don't have serial ports.

GPIO pins on things like a Raspberry Pi also work well.

PPS over USB adds the USB polling interval to the error budget.  It will
probably work well enough if the goal is under 15 ms.


Hal,

Agreed, PPS over USB isn't ideal, but possibly the extra jitter in the 
context of a Windows system isn't too bad.  On desktop systems I've been 
able to add a 3rd-party serial PCIe card and get excellent results.


On laptops I've usually been able to get well under a millisecond over 
Wi-Fi:


 http://www.satsignal.eu/mrtg/performance_ntp.php#wifi

apart from one rather cheap-and-nasty system which I won as a prize.  I 
wonder why they were giving that unit away!!  The secret is, perhaps, the 
new API introduced in Windows-8 (with some pushing from Dave Hart, I 
suspect) which allows much more precise retrieval of the Windows time, and 
is used by NTP when possible.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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

Re: [time-nuts] Need Time Help

[Martin Burnicki]

You can find some information here :
https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf
Please note the resolution of the system time in Win XP is only about 16 ms. 
The NTP service tries to extrapolate the system time to yield better 
resolution, but applications suffer from 16 ms anyway. 

Martin 

Am 4. Oktober 2016 06:41:58 MESZ, schrieb Larry Hower :
>Hello to the List:
>
>After a long and bitter struggle with XP and WIN 10, I am writing to
>ask
>for some help in solving some problems we have been having in our
>attempt
>to establish a very accurate time reference for use in EME activities.
>
>We are hoping to achieve less than 5ms deviation, although anything
>below
>15ms will be adequate for now.
>
>Specifically, we want to use a universal reference that will enable
>amateur
>radio operators in different parts of the world to start and stop their
>transmissions within a few milliseconds of a specific time. For
>example, I
>transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
>transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
>
>We are using WSJT-X software. We use standard receivers plus we have
>tried
>a few SDRs.
>
>Sorry for the oversimplified example but I want to make sure we are all
>on
>the same page.
>
>As background:
>
>1. We are using desktops and laptops in separate locations running XP
>or
>Win 10.
>
>2. We have used MS clock tools, including use of Boulder time servers,
>tried both host name and IP address, without reaching the goal.
>
>3. We have set up some Serial GPS units with PPS and some USB GPS
>receivers
>(no PPS) and can get to about 0.2 sec but it is not trusted or close
>enough.
>
>4. We have set up a network time server with similar results.
>
>5. Deviation is measured using WSJT-X
>
>-
>
>*Standard Receivers*
>
>ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
>reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
>
>
>*SDRs*
>
>We believe that SDR processing can insert a delay of varying length,
>depending on the software, bandwidth, etc. Our SDR tests seem to have a
>delay of as much as 0.5 sec. And with sometimes variable results. We
>will
>see how SDRs can be used after we resolve the current issues.
>
>
>*Some time related hardware details*
>
>*1. Global Star 4 USB and Serial Connections*
>
>http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
>
>We have 4 of these. Two are older models with serial connections. We
>have
>serial ports on some computers (XP and a new high-end laptop running
>WIN
>10) so we are able to activate the PPS option. Two of the GStar are
>newer
>models with USB connections which are not able to use the PPS option.
>
>We have tried NEMATime and NEMATime 2 software on this hardware without
>reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
>sec. Drifts.  Deviation is measured using WSJT-X.
>
>
>*2. TimeNet NTP Device*
>
>http://www.veracityglobal.com/products/networked-video-integ
>ration-devices/timenet.aspx
>
>We have one of these TimNet units and it has been set up at 2 different
>locations on differing computers according to user instructions. We are
>using the TimNet software as DL'd recently from their web site. We get
>GPS
>“lock” and Time “lock” shown in the user panel but we do not have faith
>that this is carried into the system clock. Occasionally the "lock"
>indicators go blank but the time seems to be updated when the software
>is
>strted again (the updated is operation is show at the correct time.  We
>think the app needs some work. Deviation is measured using WSJT-X.  See
>later details.
>
>
>*Setup*
>
>The G Star units have been installed at 2 separate locations, tested
>using
>WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
>
>Similar tests with a TimeNet unit at one end and G Stars at the other
>end.
>
>G Star units were installed on the XP laptops with the PPS option
>enabled
>and running WSJT-X. These XP units seem to have their time “in sync”.
>See
>following.
>
>
>*WSJT-X*
>
>We are not sure what, if any, internal delays there are attributable to
>this software. We have been using the same version/build at both ends
>for
>the tests. The software displays in 0.1 sec increments but will show
>0.0sec
>when things appear to be working well. We do not know the actual level
>of
>precision of the WSJT-X software time measurements. I undersand that
>WSJT-X
>“reads” the system clock at the start of a period (TX or RX) and
>displays
>what it finds as the time deviation from the local system clock.
>
>
>*WIN XP*
>
>There are 2 laptops running XP. They seem to match each other re time
>using
>WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are
>fairly
>sure that they are working properly but they need to be more accurate
>(<15ms).
>
>
>*WIN 10*
>
>Installed on a number of desktop and laptop computers. Many efforts
>were
>made to make these system clocks reference the GPS devices.
>
>We 

Re: [time-nuts] Need Time Help

[Hal Murray]

david-tay...@blueyonder.co.uk said:
> You can use a GPS puck or equivalent with PPS output to get the sort of
> accuracy you need.  ..: 

PPS output is only half the battle.  You also have to get it into the system 
that needs it.

A modem control signal on an old fashioned serial port (not USB) is the 
classic approach.  Unfortunately, many modern systems, especially laptops, 
don't have serial ports.

GPIO pins on things like a Raspberry Pi also work well.

PPS over USB adds the USB polling interval to the error budget.  It will 
probably work well enough if the goal is under 15 ms.





-- 
These are my opinions.  I hate spam.



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

Re: [time-nuts] Need Time Help

[Chris Albertson]

On Mon, Oct 3, 2016 at 9:41 PM, Larry Hower  wrote:

>
>
> 1. We are using desktops and laptops in separate locations running XP or
> Win 10.
>

Assuming you have decent GPS receivers with an un-obstructed view of the
sky with 1 pulse per second output and you have let the GPS run long enough
to track enough satellites  then...  The pulse typically has a standard
deviation on the order of some tens of nanoseconds.   So that is not your
problem.  It is software., well mostly.  Also computers that manage power
like notebooks are not going to give good timing performance no matter what
you try.

MS Windows is not the best choice for running NTP.   You can do it.  and
many people have gotten results better then 1 millisecond.  But
If you are willing to give up the use of MS Windows.  Then tens of
microseconds is not hard.

Little $35 credit card sized computers (Raspberry Pi) running Linux and NTP
with a GPS input are easy to get an order of magnitude better than your
requirement.

So are you stuck with windows.  f so it can work with some rather complex
setup.   If you can select another OS then you get out of the box
sub-millisecond performance with little effort


-- 

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

Re: [time-nuts] Need Time Help

[David J Taylor]

Hello to the List:

After a long and bitter struggle with XP and WIN 10, I am writing to ask
for some help in solving some problems we have been having in our attempt
to establish a very accurate time reference for use in EME activities.

We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.
[]
I ask for advice on how we can use the above gear or other gear or other
software to have our setup deliver better than 15ms accuracy.

Ultimately we want sub-millisecond accuracy.

Any help will be very much appreciated.  Thanks in advance for anything you
can advise.

73,

Larry Hower

VK7WLH

W0LH


Larry,

You can use a GPS puck or equivalent with PPS output to get the sort of 
accuracy you need.  I've written up some notes here:


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

and you can see the results here for Windows 2000 and Windows-10 systems (I 
no longer have an XP system with GPS/PPS reference):


 http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

0.5 ms is easily achieved, although it's desirable to keep the systems 
running 24 x 7 (or started well in advance) and as constant a temperature as 
you can reasonably achieve helps.


If you want, you could also build or buy an external NTP reference based on 
GPS/PPS, such as a Raspberry Pi or the LeoNTP server, and then sync the PCs 
over the LAN or Wi-Fi, but the results won't be as good as a PPS input 
direct to the PC:


 http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html
 https://store.uputronics.com/index.php?route=product/product&product_id=92

I haven't read your long post in detail, so I hope the above suits.

73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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