After first trying the Haicom HI-204III claiming to have PPS in the
manual without really having it, I bought a Garmin 18x LVC and
connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
mainboard. The Haicom is residing on a USB serial adapter (COM6) to
check how stable the offset is.

Running ntp4.2.5p175-win-x86-bin configured with a couple of
timesources it seems like my ISP's NTP-server gets "disqualified".
Before setting up my own ref.clock I used to have ntp.online.no as my
"favorite NTP-server" thinking it would be the best / most local
server, but now I might offer them to use me as a clock-source? ;)

Anyone wishing to see on their own, might check with ntpq
solbakken.dyndns.org   What kind of accuracy is expectable with a NMEA
GPS with PPS connected to the DCD-line of the serial port? It's not
that I have any special need for extreme accuracy, but I suppose it's
allright having the most accurate clock in the neighborhood. :)



Cheers,
Geir F

pisteoff@start.no wrote:
> After first trying the Haicom HI-204III claiming to have PPS in the
> manual without really having it, I bought a Garmin 18x LVC and
> connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
> mainboard. The Haicom is residing on a USB serial adapter (COM6) to
> check how stable the offset is.
>
> Running ntp4.2.5p175-win-x86-bin configured with a couple of
> timesources it seems like my ISP's NTP-server gets "disqualified".
> Before setting up my own ref.clock I used to have ntp.online.no as my
> "favorite NTP-server" thinking it would be the best / most local
> server, but now I might offer them to use me as a clock-source? ;)
>
> Anyone wishing to see on their own, might check with ntpq
> solbakken.dyndns.org   What kind of accuracy is expectable with a NMEA
> GPS with PPS connected to the DCD-line of the serial port? It's not
> that I have any special need for extreme accuracy, but I suppose it's
> allright having the most accurate clock in the neighborhood. :)
>
>
>
> Cheers,
> Geir F

Geir,

I typically see an offset within 0.2 milliseconds using a direct 
connection:

  http://www.satsignal.eu/mrtg/feenix_ntp_2.html

With USB I would see within about 0.5 milliseconds.

Both are much better than an Internet-based time source.

Your Haicom has an offset of nearly 0.5s, suggesting that you might be 
using the wrong edge of the PPS signal.

Cheers,
David 

On 27 Mai, 21:21, "David J Taylor" <david-tay...@blueyonder.not-this-
part.nor-this.co.uk.invalid> wrote:
> piste...@start.no wrote:
> > After first trying the Haicom HI-204III claiming to have PPS in the
> > manual without really having it, I bought a Garmin 18x LVC and
> > connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
> > mainboard. The Haicom is residing on a USB serial adapter (COM6) to
> > check how stable the offset is.
>
> > Running ntp4.2.5p175-win-x86-bin configured with a couple of
> > timesources it seems like my ISP's NTP-server gets "disqualified".
> > Before setting up my own ref.clock I used to have ntp.online.no as my
> > "favorite NTP-server" thinking it would be the best / most local
> > server, but now I might offer them to use me as a clock-source? ;)
>
> > Anyone wishing to see on their own, might check with ntpq
> > solbakken.dyndns.org =A0 What kind of accuracy is expectable with a NME=
A
> > GPS with PPS connected to the DCD-line of the serial port? It's not
> > that I have any special need for extreme accuracy, but I suppose it's
> > allright having the most accurate clock in the neighborhood. :)
>
> > Cheers,
> > Geir F
>
> Geir,
>
> I typically see an offset within 0.2 milliseconds using a direct
> connection:
>
> =A0http://www.satsignal.eu/mrtg/feenix_ntp_2.html
>
> With USB I would see within about 0.5 milliseconds.
>
> Both are much better than an Internet-based time source.
>
> Your Haicom has an offset of nearly 0.5s, suggesting that you might be
> using the wrong edge of the PPS signal.
>
> Cheers,
> David=96 Skjul sitert tekst =96
>
> =96 Vis sitert tekst =96

The 0,5s offset has a quite logical explanation - the claimed PPS
doesn=92t exist. There simply aren't enough wires in the cable and I
have also checked with oscilloscope on the spare connectors inside the
unit, and as good as every soldering point inside, but no PPS... Quite
disappointing since the manual claims it has PPS, and I also see clear
indications where inside the GPS the PPS-signal is "supposed to be". I
suppose all that's needed is a firmware to activate the PPS output,
but my mail to Haicom has never been answered. If anyone has good
contacts at Haicom, please let me know! :)

Now I'm just curious how stable the offset is compared to my PPS GPS.
At least the stable part of the offset is possible to configure away,
but guess it's still far away from PPS when it comes to jitter...The
0,5s offset has a quite logical explanation - the claimed PPS doesn=92t
exist. I have checked with oscilloscope on the spare connectors inside
the unit, and as good as every soldering point inside, but no PPS...
Quite disappointing since the manual claims it has PPS, and I also see
clear indications where inside the GPS the PPS-signal is "supposed to
be". I suppose all that's needed is a firmware to activate the PPS
output, but my mail to Haicom has never been answered.

pisteoff@start.no wrote:
> After first trying the Haicom HI-204III claiming to have PPS in the
> manual without really having it, I bought a Garmin 18x LVC and
> connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO

Very good!

(Using USB power I assume?)

> mainboard. The Haicom is residing on a USB serial adapter (COM6) to
> check how stable the offset is.
> 
> Running ntp4.2.5p175-win-x86-bin configured with a couple of

Windows...

> timesources it seems like my ISP's NTP-server gets "disqualified".
> Before setting up my own ref.clock I used to have ntp.online.no as my
> "favorite NTP-server" thinking it would be the best / most local
> server, but now I might offer them to use me as a clock-source? ;)
> 
> Anyone wishing to see on their own, might check with ntpq
> solbakken.dyndns.org   What kind of accuracy is expectable with a NMEA
> GPS with PPS connected to the DCD-line of the serial port? It's not
> that I have any special need for extreme accuracy, but I suppose it's
> allright having the most accurate clock in the neighborhood. :)

Hei, hei!

If your neighborhood is Oslo, I probably have you beat, with 6-8 
GPS-quality PPS sources, including 5 Oncore timing receivers, all 
connected to FreeBSD servers with PPS support. :-)

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> piste...@start.no wrote:
> > After first trying the Haicom HI-204III claiming to have PPS in the
> > manual without really having it, I bought a Garmin 18x LVC and
> > connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
>
> Very good!
>
> (Using USB power I assume?)

I was thinking about USB-power, but ended up with keyboard-power since
a PS2 connector was easiest to find when soldering the cable. :)

Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
like it's quite a lot cheaper abroad, but with tax and postage I don't
think it's any cheaper to order one unit from US or somewhere...

> > mainboard. The Haicom is residing on a USB serial adapter (COM6) to
> > check how stable the offset is.
>
> > Running ntp4.2.5p175-win-x86-bin configured with a couple of
>
> Windows...

Windows XP SP3 running on an AMD Athlon Dual Core 4850e (2,5G0Hz) with
4GB PC8500 RAM. Quite overkill for a pure NTP-server I suppose, but I
have lot's of other things I like to test on this computer!

> > timesources it seems like my ISP's NTP-server gets "disqualified".
> > Before setting up my own ref.clock I used to have ntp.online.no as my
> > "favorite NTP-server" thinking it would be the best / most local
> > server, but now I might offer them to use me as a clock-source? ;)
>
> > Anyone wishing to see on their own, might check with ntpq
> > solbakken.dyndns.org =A0 What kind of accuracy is expectable with a NME=
A
> > GPS with PPS connected to the DCD-line of the serial port? It's not
> > that I have any special need for extreme accuracy, but I suppose it's
> > allright having the most accurate clock in the neighborhood. :)
>
> Hei, hei!
>
> If your neighborhood is Oslo, I probably have you beat, with 6-8
> GPS-quality PPS sources, including 5 Oncore timing receivers, all
> connected to FreeBSD servers with PPS support. :-)

I'm on Gj=F8vik, so until the opposite is proved I still think I have
got the most accurate clock in the neighborhood :)

pisteoff@start.no writes:

>After first trying the Haicom HI-204III claiming to have PPS in the
>manual without really having it, I bought a Garmin 18x LVC and
>connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
>mainboard. The Haicom is residing on a USB serial adapter (COM6) to
>check how stable the offset is.

>Running ntp4.2.5p175-win-x86-bin configured with a couple of
>timesources it seems like my ISP's NTP-server gets "disqualified".
>Before setting up my own ref.clock I used to have ntp.online.no as my
>"favorite NTP-server" thinking it would be the best / most local
>server, but now I might offer them to use me as a clock-source? ;)

>Anyone wishing to see on their own, might check with ntpq
>solbakken.dyndns.org   What kind of accuracy is expectable with a NMEA
>GPS with PPS connected to the DCD-line of the serial port? It's not
>that I have any special need for extreme accuracy, but I suppose it's
>allright having the most accurate clock in the neighborhood. :)

Probably better than 10 microseconds from the PPS if you had a decent
operating system (eg BSD or Linux) On windows, maybe 1 msec accuracy.\. 

Note that my checking with something in germany is not going to give me
very good timing. the earth is a large place. 





>Cheers,
>Geir F

pisteoff@start.no writes:

>On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> piste...@start.no wrote:
>> > After first trying the Haicom HI-204III claiming to have PPS in the
>> > manual without really having it, I bought a Garmin 18x LVC and
>> > connected it to the onboard COM-port (COM1) on my Asus M3N78 PRO
>>
>> Very good!
>>
>> (Using USB power I assume?)

>I was thinking about USB-power, but ended up with keyboard-power since
>a PS2 connector was easiest to find when soldering the cable. :)

>Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
>like it's quite a lot cheaper abroad, but with tax and postage I don't
>think it's any cheaper to order one unit from US or somewhere...

How much is "quite expensive" It should be about US$100.


>> > mainboard. The Haicom is residing on a USB serial adapter (COM6) to
>> > check how stable the offset is.
>>
>> > Running ntp4.2.5p175-win-x86-bin configured with a couple of
>>
>> Windows...

>Windows XP SP3 running on an AMD Athlon Dual Core 4850e (2,5G0Hz) with
>4GB PC8500 RAM. Quite overkill for a pure NTP-server I suppose, but I
>have lot's of other things I like to test on this computer!

No, serioius underkill. windows is NOT what you want to use to keep
time. The time keeping functions of windows are not up to the job of
keeping accurate time. Operating system limitations, not hardware. 



>> > timesources it seems like my ISP's NTP-server gets "disqualified".
>> > Before setting up my own ref.clock I used to have ntp.online.no as my
>> > "favorite NTP-server" thinking it would be the best / most local
>> > server, but now I might offer them to use me as a clock-source? ;)
>>
>> > Anyone wishing to see on their own, might check with ntpq
>> > solbakken.dyndns.org =A0 What kind of accuracy is expectable with a NME=
>A
>> > GPS with PPS connected to the DCD-line of the serial port? It's not
>> > that I have any special need for extreme accuracy, but I suppose it's
>> > allright having the most accurate clock in the neighborhood. :)
>>
>> Hei, hei!
>>
>> If your neighborhood is Oslo, I probably have you beat, with 6-8
>> GPS-quality PPS sources, including 5 Oncore timing receivers, all
>> connected to FreeBSD servers with PPS support. :-)

>I'm on Gj=F8vik, so until the opposite is proved I still think I have
>got the most accurate clock in the neighborhood :)

Unruh wrote:
 > Note that my checking with something in germany is not going
 >  to give me very good timing. the earth is a large place.

Isn't the round trip delay calc
     (Client Destination TS - Client Origin TS)
   - (Server Transmit TS - Server Receive TS)
  diff supposed to help compensate for that?

-- 
E-Mail Sent to this address <BlackList@Griffin-Technologies.net>
  will be added to the BlackLists.

Unruh wrote:
 >> Actually the Garmin 18x LVC is quite expensive here in Norway?
 >> Seems like it's quite a lot cheaper abroad, but with tax and
 >>  postage I don't think it's any cheaper to order one unit from
 >>  US or somewhere...
 >
 > How much is "quite expensive" It should be about US$100.

$70usd-$80usd, + tax, +shipping, ... ?

-- 
E-Mail Sent to this address <BlackList@Griffin-Technologies.net>
  will be added to the BlackLists.

Unruh wrote:
[]
> Probably better than 10 microseconds from the PPS if you had a decent
> operating system (eg BSD or Linux) On windows, maybe 1 msec
> accuracy.\.

More like better than 200 microseconds on a good Windows 2000 or XP 
system, even in a non-temperature-controlled environment, when running on 
a non-interactive system.

  http://www.satsignal.eu/mrtg/feenix_ntp_2.html

David 

Unruh wrote:
> pisteoff@start.no writes:
[]
>> Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
>> like it's quite a lot cheaper abroad, but with tax and postage I
>> don't think it's any cheaper to order one unit from US or
>> somewhere...
>
> How much is "quite expensive" It should be about US$100.

In the UK the base price, without tax, is GBP 56.98 (~ US $91)

With tax and delivery it was GBP 71.02 (~US $113)

I also feel this is quite expensive, as some base prices are down to US 
$63

  http://shopping.aol.com/garmin-gps-18x-lvc-receiver-12-channels-/75700944

David 

On 28 Mai, 08:12, "David J Taylor" <david-tay...@blueyonder.not-this-
part.nor-this.co.uk.invalid> wrote:
> Unruh wrote:
> > piste...@start.no writes:
> []
> >> Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
> >> like it's quite a lot cheaper abroad, but with tax and postage I
> >> don't think it's any cheaper to order one unit from US or
> >> somewhere...
>
> > How much is "quite expensive" It should be about US$100.
>
> In the UK the base price, without tax, is GBP 56.98 (~ US $91)
>
> With tax and delivery it was GBP 71.02 (~US $113)
>
> I also feel this is quite expensive, as some base prices are down to US
> $63
>
> =A0http://shopping.aol.com/garmin-gps-18x-lvc-receiver-12-channels-/7570.=
...
>
> David

The recommended customer price from the Norwegian Garmin importer
seems to be 975NOK (+shipping), which was what I had to pay for it. It
also seems difficult to find stores having this LVC-model in their
assortment, so I actually asked a web shop that sell other Garmin
products if they could get me this model too.

When calculating NOK to USD, I end up with $152,24. That's actually
more than double the $63 price you have seen in US!! If I found a US
place selling it for $63 I suppose it should get quite a lot cheaper
even when adding shipping and tax.



Geir

pisteoff@start.no wrote:
> On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
> like it's quite a lot cheaper abroad, but with tax and postage I don't
> think it's any cheaper to order one unit from US or somewhere...

I got mine from Malfix in Oslo, paid about 800 NOKs.

>> If your neighborhood is Oslo, I probably have you beat, with 6-8
>> GPS-quality PPS sources, including 5 Oncore timing receivers, all
>> connected to FreeBSD servers with PPS support. :-)
> 
> I'm on Gj�vik, so until the opposite is proved I still think I have
> got the most accurate clock in the neighborhood :)

OK, you're about an hour or two away then. OTOH my servers are located 
in Oslo, Porsgrunn and Bergen, with fast private (mostly fiber) between 
them. :-)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 28 Mai, 09:14, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> piste...@start.no wrote:
> > On 27 Mai, 21:43, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> > Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
> > like it's quite a lot cheaper abroad, but with tax and postage I don't
> > think it's any cheaper to order one unit from US or somewhere...
>
> I got mine from Malfix in Oslo, paid about 800 NOKs.
>
> >> If your neighborhood is Oslo, I probably have you beat, with 6-8
> >> GPS-quality PPS sources, including 5 Oncore timing receivers, all
> >> connected to FreeBSD servers with PPS support. :-)
>
> > I'm on Gj=F8vik, so until the opposite is proved I still think I have
> > got the most accurate clock in the neighborhood :)
>
> OK, you're about an hour or two away then. OTOH my servers are located
> in Oslo, Porsgrunn and Bergen, with fast private (mostly fiber) between
> them. :-)

That seems like a little over the hobby level NTP-server I'
running :)  Do these NTP-servers have a special purpose which demands
high accuracy? Or is it =93only=94 for time syncing workstations in a
network or something?


Geir

pisteoff@start.no wrote:
[]
> When calculating NOK to USD, I end up with $152,24. That's actually
> more than double the $63 price you have seen in US!! If I found a US
> place selling it for $63 I suppose it should get quite a lot cheaper
> even when adding shipping and tax.
>
> Geir

... except that many American suppliers will not ship outside the US. 
Probably still worth getting, though, at NOK ~800.

David 

pisteoff@start.no wrote:
> On 28 Mai, 08:12, "David J Taylor" <david-tay...@blueyonder.not-this-
> part.nor-this.co.uk.invalid> wrote:
>> Unruh wrote:
>>> piste...@start.no writes:
>> []
>>>> Actually the Garmin 18x LVC is quite expensive here in Norway? Seems
>>>> like it's quite a lot cheaper abroad, but with tax and postage I
>>>> don't think it's any cheaper to order one unit from US or
>>>> somewhere...
>>> How much is "quite expensive" It should be about US$100.
>> In the UK the base price, without tax, is GBP 56.98 (~ US $91)
>>
>> With tax and delivery it was GBP 71.02 (~US $113)
>>
>> I also feel this is quite expensive, as some base prices are down to US
>> $63
>>
>>  http://shopping.aol.com/garmin-gps-18x-lvc-receiver-12-channels-/7570...
>>
>> David
> 
> The recommended customer price from the Norwegian Garmin importer
> seems to be 975NOK (+shipping), which was what I had to pay for it. It
> also seems difficult to find stores having this LVC-model in their
> assortment, so I actually asked a web shop that sell other Garmin
> products if they could get me this model too.
> 
> When calculating NOK to USD, I end up with $152,24. That's actually
> more than double the $63 price you have seen in US!! If I found a US
> place selling it for $63 I suppose it should get quite a lot cheaper
> even when adding shipping and tax.
> 

I had a list of around five cheapest, I think four in US one Canada.
Only one of those could manage a normal Visa payment and export to UK
with delivery charge of extra 70 USD. There would also have been UK
import duty then VAT on total including shipping.

I eventually ordered from gpsw.co.uk, UKP 71.02 inclusive. I'd
searched their site prior to trying the US ones and not been able to
locate the GPS 18x-LVC and only went back after it being confirmed
here they stocked the product.

I've not yet connected the GPS 18x as still thinking about where to
mount it. I previously tried with a BR304 without pps and had 80%
of time +/- 25ms, much worse than for time from internet whilst a
Conrad DCF module used over a few days gave 80% at +/- 2ms, better
than expected, but both BR304 and DCF have reception difficulties.

David

> 
> 
> Geir

David Lord wrote:
[]
> I eventually ordered from gpsw.co.uk, UKP 71.02 inclusive. I'd
> searched their site prior to trying the US ones and not been able to
> locate the GPS 18x-LVC and only went back after it being confirmed
> here they stocked the product.

I also ordered from  GPS warehouse and it arrived very quickly.
  http://www.gpsw.co.uk/details/prod2402.html

> I've not yet connected the GPS 18x as still thinking about where to
> mount it. I previously tried with a BR304 without pps and had 80%
> of time +/- 25ms, much worse than for time from internet whilst a
> Conrad DCF module used over a few days gave 80% at +/- 2ms, better
> than expected, but both BR304 and DCF have reception difficulties.
>
> David

Mine is now sitting indoors, near the roof of an upstairs room.  It's a 
lot more sensitive than the plain "18" model, so I'm trying it indoors 
rather than on the roof  (where my 18 lives).  It's a backup, and working 
into a rather poor Windows box, but keeping generally within 0.5ms.

  http://www.satsignal.eu/mrtg/stamsund_ntp_2.html

I couldn't see any change between the outdoors 18 and the indoors 18x on 
that PC.  The changeover was on Friday, May 22, week 21 - spot any 
difference?

Cheers,
David 

E-Mail Sent to this address will be added to the BlackLists wrote:
> Unruh wrote:
>  > Note that my checking with something in germany is not going
>  >  to give me very good timing. the earth is a large place.
> 
> Isn't the round trip delay calc
>     (Client Destination TS - Client Origin TS)
>   - (Server Transmit TS - Server Receive TS)
>  diff supposed to help compensate for that?
> 

It doesn't "compensate"!  It simply tells you the maximum uncertainty 
introduced in transmitting the request and reply.  You know that it 
can't be worse than one half of the round trip time.  All other things 
being equal, the lowest round trip time gives you the best time.

pisteoff@start.no wrote:
> On 28 Mai, 09:14, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> OK, you're about an hour or two away then. OTOH my servers are located
>> in Oslo, Porsgrunn and Bergen, with fast private (mostly fiber) between
>> them. :-)
> 
> That seems like a little over the hobby level NTP-server I'
> running :)  Do these NTP-servers have a special purpose which demands
> high accuracy? Or is it �only� for time syncing workstations in a
> network or something?

This is the ntp network for our own servers plus all our corporate 
customers (Hydro, Yara, Statoil...)

I.e. about 1/3 of the total Oslo stock exchange value. Not just a hobby. :-)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Griffin-Technologies.invalid> writes:

>Unruh wrote:
> > Note that my checking with something in germany is not going
> >  to give me very good timing. the earth is a large place.

>Isn't the round trip delay calc
>     (Client Destination TS - Client Origin TS)
>   - (Server Transmit TS - Server Receive TS)
>  diff supposed to help compensate for that?

jThe opperative words are "supposed to help". Yes, it helps. It does not
eliminate. It will eliminate ONLY if the one way times are identical.
They are not. They travel different paths across the surface of the
earth, they suffer different delays, etc. And the longer the path the
more of these differential delays there are. 

E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Griffin-Technologies.invalid> writes:

>Unruh wrote:
> >> Actually the Garmin 18x LVC is quite expensive here in Norway?
> >> Seems like it's quite a lot cheaper abroad, but with tax and
> >>  postage I don't think it's any cheaper to order one unit from
> >>  US or somewhere...
> >
> > How much is "quite expensive" It should be about US$100.

>$70usd-$80usd, + tax, +shipping, ... ?

I was asking how much it cost in Norway.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>E-Mail Sent to this address will be added to the BlackLists wrote:
>> Unruh wrote:
>>  > Note that my checking with something in germany is not going
>>  >  to give me very good timing. the earth is a large place.
>> 
>> Isn't the round trip delay calc
>>     (Client Destination TS - Client Origin TS)
>>   - (Server Transmit TS - Server Receive TS)
>>  diff supposed to help compensate for that?
>> 

>It doesn't "compensate"!  It simply tells you the maximum uncertainty 

It does "compensate". It says that the best estimate of the time offset
is the difference between the average of the two local times minus the
average of the two remote times. Ie, it assumes that the propagation
delays are symmetric. What you are talking about is the worst case
expected error in that which is half the roundtrip time. 

>introduced in transmitting the request and reply.  You know that it 
>can't be worse than one half of the round trip time.  All other things 
>being equal, the lowest round trip time gives you the best time.

But all other things are not equal. Thus I have to secondary sources,
one here at UBC and one in Regina. (my primary is a gps receiver) the a
average offset from Regina is about 300usec, with a round trip time of
45ms, while the average ofset from UBC ( less than 1/2Km away) is 4ms
with a round trip time of 6ms. 

Unruh wrote:
>>> How much is "quite expensive" It should be about US$100.
> 
>> $70usd-$80usd, + tax, +shipping, ... ?
> 
> I was asking how much it cost in Norway.

And I wrote a few days ago that I paid NOK 800 (i.e. ~$120) over the 
counter here in Oslo.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Richard B. Gilbert wrote:

> 
> It doesn't "compensate"!  It simply tells you the maximum uncertainty 
> introduced in transmitting the request and reply.  You know that it 
> can't be worse than one half of the round trip time.  All other things 
> being equal, the lowest round trip time gives you the best time.
> 

It does compensate.  However the degree of compensation may be wrong by 
anywhere between + and - half the round trip time.

The compensation is added to the time estimates, but is also added to 
the error bound calculation.

David J Taylor wrote:
> David Lord wrote:
> []
>> I eventually ordered from gpsw.co.uk, UKP 71.02 inclusive. I'd
>> searched their site prior to trying the US ones and not been able to
>> locate the GPS 18x-LVC and only went back after it being confirmed
>> here they stocked the product.
> 
> I also ordered from  GPS warehouse and it arrived very quickly.
>  http://www.gpsw.co.uk/details/prod2402.html
> 
>> I've not yet connected the GPS 18x as still thinking about where to
>> mount it. I previously tried with a BR304 without pps and had 80%
>> of time +/- 25ms, much worse than for time from internet whilst a
>> Conrad DCF module used over a few days gave 80% at +/- 2ms, better
>> than expected, but both BR304 and DCF have reception difficulties.
>>
>> David
> 
> Mine is now sitting indoors, near the roof of an upstairs room.  It's a 
> lot more sensitive than the plain "18" model, so I'm trying it indoors 
> rather than on the roof  (where my 18 lives).  It's a backup, and 
> working into a rather poor Windows box, but keeping generally within 0.5ms.
> 
>  http://www.satsignal.eu/mrtg/stamsund_ntp_2.html
> 
> I couldn't see any change between the outdoors 18 and the indoors 18x on 
> that PC.  The changeover was on Friday, May 22, week 21 - spot any 
> difference?

Late last night I got round to connecting the Garmin GPS18x-LVC and
just after midnight it stepped from around 60s to 0.5ms and 8 hours
later is between -74us and +62us. The module is in south facing
upstairs window in same location I failed to get anything useful
from the Globalsat BR304. Now I need to make a 30m extender cable to
get the signals downstairs to back of house to connect to servers.

David

David Lord wrote:
[]
> Late last night I got round to connecting the Garmin GPS18x-LVC and
> just after midnight it stepped from around 60s to 0.5ms and 8 hours
> later is between -74us and +62us. The module is in south facing
> upstairs window in same location I failed to get anything useful
> from the Globalsat BR304. Now I need to make a 30m extender cable to
> get the signals downstairs to back of house to connect to servers.
>
> David

Good news, David.  Sensitive little pill-box, isn't it?

One suggestion might be wireless - could you get a very atom-based small 
PC or even a wireless router to accept the GPS signal and serve NTP over 
the WLAN?  Cable would be nicer and my preference.  With Dave Hart's new 
PPS support it /should/ be possible to send just the PPS signal around 
(two wires), and use that to refine an Internet-derived time.  I might be 
inclined to go for a screened cable if you need a 30m run, but thin 3-core 
mains cable /might/ suffice.  The RS-232 I used to use was very tolerant 
of cabling, but it probably had higher signal levels and robustness than 
the GPS 18x LVC.

Cheers,
David 

David J Taylor wrote:
[]
> I might be inclined to go for a screened
> cable if you need a 30m run, but thin 3-core mains cable /might/
> suffice.

I'm not sure whether the NMEA driver attempts to send anything /to/ the 
GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
otherwise four lines are required.  If you want to take USB power from the 
server (as I now do), it's five lines minimum.

Cheers,
David 

David J Taylor wrote:
> David J Taylor wrote:
> []
>> I might be inclined to go for a screened
>> cable if you need a 30m run, but thin 3-core mains cable /might/
>> suffice.

I'm intending buffering the pps to give 75r output to coax with
another converter back to ttl at the server. The NMEA should manage
the distance over twisted pair at 4800 baud.

> 
> I'm not sure whether the NMEA driver attempts to send anything /to/ the 
> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
> otherwise four lines are required.  If you want to take USB power from 
> the server (as I now do), it's five lines minimum.

I'd rather have the option for two way in case the Garmin needs to be
set to a different mode. I have a reel of utp I think should do.

I'll have some sort of fan-out box to get a pps signal to each of
servers that are powered up continuously.

I've now seen an error in ntp log and suspect pps isn't enabled in
kernel by default (NetBSD-5). I'll check tomorrow.

Cheers

David

David Lord wrote:
> I'm intending buffering the pps to give 75r output to coax with
> another converter back to ttl at the server. The NMEA should manage
> the distance over twisted pair at 4800 baud.
[]
> I'd rather have the option for two way in case the Garmin needs to be
> set to a different mode. I have a reel of utp I think should do.
>
> I'll have some sort of fan-out box to get a pps signal to each of
> servers that are powered up continuously.
>
> I've now seen an error in ntp log and suspect pps isn't enabled in
> kernel by default (NetBSD-5). I'll check tomorrow.
>
> Cheers
>
> David

David, if you have UTP cable, I think that's four twisted pairs, so I 
would just use one pair per signal (TX, RX, PPS)  and the remaining pair 
as an earth/+5V.  Unless you have a noisy electrical environment, I think 
that will be fine over 30m.  Screened would be better, if you have it. 
Fan-out would be nice - I've used two RS-232 input in parallel fed from 
one GPS 18 without problems.

I thought the offset figures you were quoting were for Windows - 
"between -74us and +62us".  For a PPS signal on a FreeBSD system I would 
expect much better.  I recall needing both the NMEA and the ATOM driver 
configured.  Oh, yes, I vaguely recall having to compile the kernel as 
well.  It was a few years ago....
  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

Cheers,
David 

David J Taylor wrote:

> 
> David, if you have UTP cable, I think that's four twisted pairs, so I 
> would just use one pair per signal (TX, RX, PPS)  and the remaining pair 
> as an earth/+5V.  Unless you have a noisy electrical environment, I 

When used with proper balanced drivers and receivers, twisted pair is 
often better than coax.

For any type of cable, group delay characteristics may be more important 
than characteristic impedance match.

David Woolley wrote:
[]
> When used with proper balanced drivers and receivers, twisted pair is
> often better than coax.
>
> For any type of cable, group delay characteristics may be more
> important than characteristic impedance match.

Whilst I agree with both points, for carrying what are TTL-level signals 
with rise-times probably greater than 100ns where you are using an RS-232 
receiver to detect pulses 0.2s wide, and over a distance or 30m (i.e. a 
time of around 100-150ns), almost any cable will do.  The only exception I 
might make is where the environment is electrically noisy - i.e. an 
industrial setting or running behind a photocopier, air conditioner, heavy 
motor or similar, where I would want at least shielded cables.

I say this from years - too many years! - experience with RS-232.

Cheers,
David 

David J Taylor wrote:
> David Lord wrote:
>> I'm intending buffering the pps to give 75r output to coax with
>> another converter back to ttl at the server. The NMEA should manage
>> the distance over twisted pair at 4800 baud.
> []
>> I'd rather have the option for two way in case the Garmin needs to be
>> set to a different mode. I have a reel of utp I think should do.
>>
>> I'll have some sort of fan-out box to get a pps signal to each of
>> servers that are powered up continuously.
>>
>> I've now seen an error in ntp log and suspect pps isn't enabled in
>> kernel by default (NetBSD-5). I'll check tomorrow.
>>
>> Cheers
>>
>> David
> 
> David, if you have UTP cable, I think that's four twisted pairs, so I 
> would just use one pair per signal (TX, RX, PPS)  and the remaining pair 
> as an earth/+5V.  Unless you have a noisy electrical environment, I 
> think that will be fine over 30m.  Screened would be better, if you have 
> it. Fan-out would be nice - I've used two RS-232 input in parallel fed 
> from one GPS 18 without problems.

I'll scope pps down utp but doubt the pps will keep its rising
edge. I'm having a box with indicator led and 5V regulator at end
of the stock Garmin cable and coax + utp from that box downstairs.
One pair will have +9V/0V to the regulator. It's a long while
since I ran an rs232 cable downstairs but remember I had problems
with higher data rates and 38400 bps being unreliable but 9600 bps
just ok. That was also full rs232 levels rather than ttl.

> 
> I thought the offset figures you were quoting were for Windows - 
> "between -74us and +62us".  For a PPS signal on a FreeBSD system I would 
> expect much better.  I recall needing both the NMEA and the ATOM driver 
> configured.  Oh, yes, I vaguely recall having to compile the kernel as 
> well.  It was a few years ago....
>  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

NetBSD-5 sources are from March 1, so pre NetBSD-5.0. I'll update
to 5.0 off peak tonight and compile a new kernel. The last kernel
compiled in March for a different pc includes "options PPS_SYNC"
whereas that option doesn't appear in "GENERIC" or "std.i386" so
as GPS with pps option enabled drifting further and ntpd throwing
out more errors I think I can take it pps isn't working.
Meanwhile I've removed the pps flag and restarted ntp.

Anyway getting better than 100us on Garmin vs better than 700ms
with BR304 is a big enough step up already. Really all I need is
that all pcs keep same time and several ms from utc is ok.
Problem with ntp via broadband is sometimes a large download or
build gives >100ms difference between servers and I expect
feeding pps to each server will solve that problem.

cheers

David

David Lord wrote:
[]
> I'll scope pps down utp but doubt the pps will keep its rising
> edge. I'm having a box with indicator led and 5V regulator at end
> of the stock Garmin cable and coax + utp from that box downstairs.
> One pair will have +9V/0V to the regulator. It's a long while
> since I ran an rs232 cable downstairs but remember I had problems
> with higher data rates and 38400 bps being unreliable but 9600 bps
> just ok. That was also full rs232 levels rather than ttl.

Capacitive loading may slow down the edge a little, but I would expect 
that risetimes which are similar to RS-232 risetimes would be quite fine 
for PPS use, so a smooth one microsecond edge would be just fine. 
However, 38400 bps would be 26 us wide pulses, so if you had problems with 
that, perhaps it's not good enough for PPS.  I have a 5V regulator on one 
GPS 18, but decided to use the USB 5V approach for the other and it's been 
fine.

[]
> Anyway getting better than 100us on Garmin vs better than 700ms
> with BR304 is a big enough step up already. Really all I need is
> that all pcs keep same time and several ms from utc is ok.
> Problem with ntp via broadband is sometimes a large download or
> build gives >100ms difference between servers and I expect
> feeding pps to each server will solve that problem.
>
> cheers
>
> David

With my broadband, I recall that PCs kept well within +/- 100ms, but I 
perhaps have a different usage pattern to you.  I like the idea of a 
buffered PPS feed to each server, and would be most interested to hear how 
it works out.  To be within a few ms though, having one stratum-1 server 
and the rest over the LAN would probably be adequate.  BTW: I'm using 
different minpoll and maxpoll values to have the benefit of both LAN 
stratum-1 and Internet fallback servers, without hammering the Internet 
servers too hard.

____________________________________
server 192.168.0.2  iburst maxpoll 6  prefer # startum-1
server 192.168.0.7  maxpoll 6  # second stratum-1

server 0.uk.pool.ntp.org minpoll 10
server 1.uk.pool.ntp.org minpoll 10
____________________________________


Cheers,
David 

David J Taylor wrote:
> David Lord wrote:
> []
> 
> With my broadband, I recall that PCs kept well within +/- 100ms, but I 
> perhaps have a different usage pattern to you.  I like the idea of a 
> buffered PPS feed to each server, and would be most interested to hear 
> how it works out.  To be within a few ms though, having one stratum-1 
> server and the rest over the LAN would probably be adequate.  BTW: I'm 
> using different minpoll and maxpoll values to have the benefit of both 
> LAN stratum-1 and Internet fallback servers, without hammering the 
> Internet servers too hard.
> 
> ____________________________________
> server 192.168.0.2  iburst maxpoll 6  prefer # startum-1
> server 192.168.0.7  maxpoll 6  # second stratum-1
> 
> server 0.uk.pool.ntp.org minpoll 10
> server 1.uk.pool.ntp.org minpoll 10
> ____________________________________
> 

Similar here for remotes, minpoll 9, maxpoll 11 and all currently
sat at 2048 sec. I have five servers in each list though.


I only have a pair of servers as peer and that is maxpoll 8 and
both sat at 256 sec. Offsets are 203us and 593us.

I have problems with the larger maxpoll value as temperature
changes are sometimes at a higher rate than ntpd can compensate
for but this affects the pcs differently and having peers with
lower maxpoll might help. Otherwise the higher maxpoll does
seem to tend to give lower offset variation and jitter. So far
this year I've not had temperature in back room shoot from 15C
to near 30C as happened on a couple of days last year.

David

David Lord wrote:
[]
> I only have a pair of servers as peer and that is maxpoll 8 and
> both sat at 256 sec. Offsets are 203us and 593us.

I see more like 1-3ms for the Internet servers (compared to the GPS), with 
delays in the order of 30ms.  This is with Windows, though, not a UNIX 
system.

> I have problems with the larger maxpoll value as temperature
> changes are sometimes at a higher rate than ntpd can compensate
> for but this affects the pcs differently and having peers with
> lower maxpoll might help. Otherwise the higher maxpoll does
> seem to tend to give lower offset variation and jitter. So far
> this year I've not had temperature in back room shoot from 15C
> to near 30C as happened on a couple of days last year.
>
> David

Yes, it's the classic trade-off - high precision requires a long 
time-constant, but that means a poorer response to temperature changes. 
You have to decide when you have it "good enough", otherwise you will be 
tinkering for life!

Cheers,
David 

David J Taylor <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
> One suggestion might be wireless 

Isn't that just asking for jitter?

rick jones
-- 
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones wrote:
> David J Taylor
> <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
>> One suggestion might be wireless
>
> Isn't that just asking for jitter?
>
> rick jones

Have you tried it?  How much extra jitter do you see?  It would be 
interesting to see some real data.

If the choice were between plugging in a wireless system and having a 
little extra jitter, and having to pay some money for work to allow cables 
to be run.....

Cheers,
David 

David J Taylor <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
> Rick Jones wrote:
> > David J Taylor
> > <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
> >> One suggestion might be wireless
> >
> > Isn't that just asking for jitter?

> Have you tried it? 

No, I'm just channeling dimm memories of what half-duplex wired
Ethernet used to be like under load :)

rick jones
-- 
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision.  - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

"David J Taylor" <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> writes:

>David Lord wrote:
>[]
>> Late last night I got round to connecting the Garmin GPS18x-LVC and
>> just after midnight it stepped from around 60s to 0.5ms and 8 hours
>> later is between -74us and +62us. The module is in south facing
>> upstairs window in same location I failed to get anything useful
>> from the Globalsat BR304. Now I need to make a 30m extender cable to
>> get the signals downstairs to back of house to connect to servers.
>>
>> David

>Good news, David.  Sensitive little pill-box, isn't it?

>One suggestion might be wireless - could you get a very atom-based small 
>PC or even a wireless router to accept the GPS signal and serve NTP over 
>the WLAN?  Cable would be nicer and my preference.  With Dave Hart's new 
>PPS support it /should/ be possible to send just the PPS signal around 
>(two wires), and use that to refine an Internet-derived time.  I might be 
>inclined to go for a screened cable if you need a 30m run, but thin 3-core 
>mains cable /might/ suffice.  The RS-232 I used to use was very tolerant 
>of cabling, but it probably had higher signal levels and robustness than 
>the GPS 18x LVC.

I use cat 5e cable since it is cheap, available and is supposed to be
good for better than about 100MMHz
(10nsec) signals. I would not use usb cable or any old wire, because of
the problems of spread of the pulse from the gps. Also I would terminate
it properly as well so that signal  reflections could be problematic. on
long runs.
If the run is less than 10m it should be ok even with improper
termination.


>Cheers,
>David 

David Lord <snews@lordynet.org> writes:

>David J Taylor wrote:
>> David J Taylor wrote:
>> []
>>> I might be inclined to go for a screened
>>> cable if you need a 30m run, but thin 3-core mains cable /might/
>>> suffice.

>I'm intending buffering the pps to give 75r output to coax with
>another converter back to ttl at the server. The NMEA should manage
>the distance over twisted pair at 4800 baud.

The nmea is virtually useless for accurate timing. The main thing that
the unit gives you is the PPS. You have to makes sure you do not degrade
it. 



>> 
>> I'm not sure whether the NMEA driver attempts to send anything /to/ the 

Which NMEA driver? 
>> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
>> otherwise four lines are required.  If you want to take USB power from 
>> the server (as I now do), it's five lines minimum.

>I'd rather have the option for two way in case the Garmin needs to be
>set to a different mode. I have a reel of utp I think should do.

>I'll have some sort of fan-out box to get a pps signal to each of
>servers that are powered up continuously.

>I've now seen an error in ntp log and suspect pps isn't enabled in
>kernel by default (NetBSD-5). I'll check tomorrow.

Run the PPS to say gpsd or shmpps and then use ntp to use it to
discipline the clock. PUtting the PPS into the kenrel has no advantages
as far as I can see. 





>Cheers

>David

"David J Taylor" <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> writes:

>David Lord wrote:
>[]
>> I only have a pair of servers as peer and that is maxpoll 8 and
>> both sat at 256 sec. Offsets are 203us and 593us.

>I see more like 1-3ms for the Internet servers (compared to the GPS), with 
>delays in the order of 30ms.  This is with Windows, though, not a UNIX 
>system.

>> I have problems with the larger maxpoll value as temperature
>> changes are sometimes at a higher rate than ntpd can compensate
>> for but this affects the pcs differently and having peers with
>> lower maxpoll might help. Otherwise the higher maxpoll does
>> seem to tend to give lower offset variation and jitter. So far
>> this year I've not had temperature in back room shoot from 15C
>> to near 30C as happened on a couple of days last year.
>>
>> David

>Yes, it's the classic trade-off - high precision requires a long 
>time-constant, but that means a poorer response to temperature changes. 
>You have to decide when you have it "good enough", otherwise you will be 
>tinkering for life!

I disagree, A long time constant is good for getting an accurate rate
for the clocks, but that is useless if the rate changes. A long time
scale is not of any particular help in getting an accurate offset in
ntp. NTP basically uses a fixed number of data points to estimate the
offset, no matter what the poll is. Ie the exponential time constant is
a multiple of the poll interval. This means that the statistical noise
is reduced by the square root of that number, which, being a constant
independent of poll interval, the offset variance is the same. no matter
what the poll interval. The rate variance is dominated by temperature
fluctuations in computers, and it does no good to have the poll
interval anywhere near the time scale of the temperature variation,
because of ntp's terrible response to rate changes.  

Now you could get far better response by using the temperature of the
computer to also correct for rate responses. 

>Cheers,
>David 

Unruh wrote:
[]
> Now you could get far better response by using the temperature of the
> computer to also correct for rate responses.

I do agree that if temperature could be included NTP could work even 
better.

David 

Unruh wrote:
[]
> The nmea is virtually useless for accurate timing. The main thing that
> the unit gives you is the PPS. You have to makes sure you do not
> degrade it.

The GPS 18x LVC only claims an accuracy of one microsecond for PPS in the 
first place.  The RS-232 receivers may well have some filtering limiting 
the risetime to a couple of microseconds (i.e. good enough for the maximum 
baud rate, typically 115,200 baud), so even if the final risetime after 
the cable is a microsoecond or so, that's not going to degrade the 
accuracy signifcantly for normal use.  Not an issue.

>>> I'm not sure whether the NMEA driver attempts to send anything /to/
>>> the
>
> Which NMEA driver?


The one in NTP, which would work with the GPS 18x LVC.

David 

Unruh wrote:
[]
> I use cat 5e cable since it is cheap, available and is supposed to be
> good for better than about 100MMHz
> (10nsec) signals. I would not use usb cable or any old wire, because
> of
> the problems of spread of the pulse from the gps. Also I would
> terminate
> it properly as well so that signal  reflections could be problematic.
> on
> long runs.
> If the run is less than 10m it should be ok even with improper
> termination.

Cat 5e cable sounds like a good compromise.  On very long runs, you would 
not only need to terminate the cable correctly, you would need to drive it 
correctly as well, requiring powered line drivers and receivers at either 
end.

In the OP's case, the run is only 30m (i.e. about 100-150ns) so the effect 
of reflections on a system (RS-232) which is bandwidth-limited to a 
microsecond or two should be very little, and I would likely use the cable 
in an unbalanced configuration.

Cheers,
David 

Unruh wrote:
> David Lord <snews@lordynet.org> writes:
> 
>> David J Taylor wrote:
>>> David J Taylor wrote:
>>> []
>>>> I might be inclined to go for a screened
>>>> cable if you need a 30m run, but thin 3-core mains cable /might/
>>>> suffice.
> 
>> I'm intending buffering the pps to give 75r output to coax with
>> another converter back to ttl at the server. The NMEA should manage
>> the distance over twisted pair at 4800 baud.
> 
> The nmea is virtually useless for accurate timing. The main thing that
> the unit gives you is the PPS. You have to makes sure you do not degrade
> it. 

Accepted, the uncertainty from rs232 at 4800 baud limits timing
to around +/- 100us which is what I'm seeing.

I need the NMEA for the time information though, don't I?

I don't have any network connection to this pc.


> 
>>> I'm not sure whether the NMEA driver attempts to send anything /to/ the 
> 
> Which NMEA driver? 

Type 20, and from driver20.html it does appear the driver outputs
a request if there is no sentence input from the gps.

>>> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
>>> otherwise four lines are required.  If you want to take USB power from 
>>> the server (as I now do), it's five lines minimum.
> 
>> I'd rather have the option for two way in case the Garmin needs to be
>> set to a different mode. I have a reel of utp I think should do.
> 
>> I'll have some sort of fan-out box to get a pps signal to each of
>> servers that are powered up continuously.
> 
>> I've now seen an error in ntp log and suspect pps isn't enabled in
>> kernel by default (NetBSD-5). I'll check tomorrow.
> 
> Run the PPS to say gpsd or shmpps and then use ntp to use it to
> discipline the clock. PUtting the PPS into the kenrel has no advantages
> as far as I can see. 

I'll be trying shm driver for MSF and DCF but have no experience
of its use whereas the ppsapi is already there if that kernel
option is selected.

I've now rebooted with new kernel compiled with pps and had a
string of messages in ntp.log that seem to indicate pps status
changes, rather than the error messages I had before.

After 30 minutes offset has gone from > 20ms to 4us but doesn't
appear to be getting closer than that.


David

David J Taylor wrote:
> Unruh wrote:
> []
>> I use cat 5e cable since it is cheap, available and is supposed to be
>> good for better than about 100MMHz
>> (10nsec) signals. I would not use usb cable or any old wire, because
>> of
>> the problems of spread of the pulse from the gps. Also I would
>> terminate
>> it properly as well so that signal  reflections could be problematic.
>> on
>> long runs.
>> If the run is less than 10m it should be ok even with improper
>> termination.
> 
> Cat 5e cable sounds like a good compromise.  On very long runs, you 
> would not only need to terminate the cable correctly, you would need to 
> drive it correctly as well, requiring powered line drivers and receivers 
> at either end.
> 
> In the OP's case, the run is only 30m (i.e. about 100-150ns) so the 
> effect of reflections on a system (RS-232) which is bandwidth-limited to 
> a microsecond or two should be very little, and I would likely use the 
> cable in an unbalanced configuration.

First I don't think there's any problem getting the nmea down
twisted pair at 4800 baud.

To play safe with the ttl level pps I've setup to use a simple
emitter follower that can drive into 75r coax.

I didn't want to use line drivers as I don't have any handy that
work off single 5V supply.

I need a converter back to ttl before going to pc and don't have
any spare gates in the box with compulsory flashing led and
ticker, so will use another couple of transistors wired as
Schmitt trigger.


David

David Lord wrote:
[]
> First I don't think there's any problem getting the nmea down
> twisted pair at 4800 baud.

... agreed, but .....

> To play safe with the ttl level pps I've setup to use a simple
> emitter follower that can drive into 75r coax.
>
> I didn't want to use line drivers as I don't have any handy that
> work off single 5V supply.
>
> I need a converter back to ttl before going to pc and don't have
> any spare gates in the box with compulsory flashing led and
> ticker, so will use another couple of transistors wired as
> Schmitt trigger.
>
>
> David

I think you're needlessly overcomplicating the PPS signal.  I have the GPS 
18LVC feeding /two/ parallel RS-232 interfaces, /and/ a low-current LED, 
so for a 30m length I think you would get away with a simple wire 
connection.  However, have fun with the soldering iron!

If you're seeing 4us offset now, that may be as good as it gets.  You may 
need a more constant temperature to see better.

Cheers,
David 

David J Taylor wrote:
> David Lord wrote:
> []
>> First I don't think there's any problem getting the nmea down
>> twisted pair at 4800 baud.
> 
> .. agreed, but .....
> 
>> To play safe with the ttl level pps I've setup to use a simple
>> emitter follower that can drive into 75r coax.
>>
>> I didn't want to use line drivers as I don't have any handy that
>> work off single 5V supply.
>>
>> I need a converter back to ttl before going to pc and don't have
>> any spare gates in the box with compulsory flashing led and
>> ticker, so will use another couple of transistors wired as
>> Schmitt trigger.
>>
>>
>> David
> 
> I think you're needlessly overcomplicating the PPS signal.  I have the 
> GPS 18LVC feeding /two/ parallel RS-232 interfaces, /and/ a low-current 
> LED, so for a 30m length I think you would get away with a simple wire 
> connection.  However, have fun with the soldering iron!

Are you getting better than 10us offsets though? :-)

I've no idea how much signal degradation there would be using
utp for pps and will both put it on spice and keep the spare
pair in cable free to give it a try.

However I'm making up various pcbs so an extra couple of tiny
jobs won't add much to the fun and is playing safe in case I
end up mounting aerials on roof or in garden, although that
looks very much less likely to be needed now.


> If you're seeing 4us offset now, that may be as good as it gets.  You 
> may need a more constant temperature to see better.

That's another project, putting the servers in a cupboard
with temperature control. Alternative of locating the crystals
and fitting heater is also a possibility. Cupboard idea has
advantage of cutting down noise and will help keep the pcs
from overheating.

David

David Lord wrote:
[]
>> I think you're needlessly overcomplicating the PPS signal.  I have
>> the GPS 18LVC feeding /two/ parallel RS-232 interfaces, /and/ a
>> low-current LED, so for a 30m length I think you would get away with
>> a simple wire connection.  However, have fun with the soldering iron!
>
> Are you getting better than 10us offsets though? :-)

No, but I'm using Windows which is known to be not as good as FreeBSD.

> I've no idea how much signal degradation there would be using
> utp for pps and will both put it on spice and keep the spare
> pair in cable free to give it a try.

I'd be interested to know the results.

> However I'm making up various pcbs so an extra couple of tiny
> jobs won't add much to the fun and is playing safe in case I
> end up mounting aerials on roof or in garden, although that
> looks very much less likely to be needed now.

Yes, my GPS 18x LVC is indoors, under a sloping roof, in Edinburgh (at 56 
degrees north), and has a fairly poor sky view.  I managed to get my GPS 
18 LVC outside just on the roof.  Both appear to have adequate coverage.

>> If you're seeing 4us offset now, that may be as good as it gets.  You
>> may need a more constant temperature to see better.
>
> That's another project, putting the servers in a cupboard
> with temperature control. Alternative of locating the crystals
> and fitting heater is also a possibility. Cupboard idea has
> advantage of cutting down noise and will help keep the pcs
> from overheating.
>
> David

Cupboard keeps the PCs from overheating?  Doesn't it restrict air flow? 
If you add air conditioning to the cupboard, a little noisy and power 
hungry?  I would try and either go for a low-power PC (perhaps Intel atom 
based, perhaps flash-disk), or cut down the power consumed by the PC and 
try to keep the load constant.  Turn down the clock in the BIOS, remove or 
disconnect the power from unwanted devices (CD/DVD drives), use "green" 
HDs etc. etc.

All way over the top for time-keeping "better than your ISP", of course!
<G>

Cheers,
David 

David Lord <snews@lordynet.org> writes:

>Unruh wrote:
>> David Lord <snews@lordynet.org> writes:
>> 
>>> David J Taylor wrote:
>>>> David J Taylor wrote:
>>>> []
>>>>> I might be inclined to go for a screened
>>>>> cable if you need a 30m run, but thin 3-core mains cable /might/
>>>>> suffice.
>> 
>>> I'm intending buffering the pps to give 75r output to coax with
>>> another converter back to ttl at the server. The NMEA should manage
>>> the distance over twisted pair at 4800 baud.
>> 
>> The nmea is virtually useless for accurate timing. The main thing that
>> the unit gives you is the PPS. You have to makes sure you do not degrade
>> it. 

>Accepted, the uncertainty from rs232 at 4800 baud limits timing
>to around +/- 100us which is what I'm seeing.

Well, I suppose you could somehow set the thing up to grab the rise time
of the first bit sent along the serial line, but there is no evidence
that the maker of the GPS made even that first bit at all accurate. Ie,
the time when that first bit is sent could well vary by milliseconds.
NMEA was never intended for accurate timeing.


>I need the NMEA for the time information though, don't I?

Yes, you need it to determine the value of the seconds.


>I don't have any network connection to this pc.


>> 
>>>> I'm not sure whether the NMEA driver attempts to send anything /to/ the 
>> 
>> Which NMEA driver? 

>Type 20, and from driver20.html it does appear the driver outputs
>a request if there is no sentence input from the gps.

>>>> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
 >>>> otherwise four lines are required.  If you want to take USB power from 
>>>> the server (as I now do), it's five lines minimum.
>> 
>>> I'd rather have the option for two way in case the Garmin needs to be
>>> set to a different mode. I have a reel of utp I think should do.
>> 
>>> I'll have some sort of fan-out box to get a pps signal to each of
>>> servers that are powered up continuously.
>> 
>>> I've now seen an error in ntp log and suspect pps isn't enabled in
>>> kernel by default (NetBSD-5). I'll check tomorrow.
>> 
>> Run the PPS to say gpsd or shmpps and then use ntp to use it to
>> discipline the clock. PUtting the PPS into the kenrel has no advantages
>> as far as I can see. 

>I'll be trying shm driver for MSF and DCF but have no experience
>of its use whereas the ppsapi is already there if that kernel
>option is selected.

>I've now rebooted with new kernel compiled with pps and had a
>string of messages in ntp.log that seem to indicate pps status
>changes, rather than the error messages I had before.

>After 30 minutes offset has gone from > 20ms to 4us but doesn't
>appear to be getting closer than that.


>David

David Lord <snews@lordynet.org> writes:

>David J Taylor wrote:
>> David Lord wrote:
>> []
>>> First I don't think there's any problem getting the nmea down
>>> twisted pair at 4800 baud.
>> 
>> .. agreed, but .....
>> 
>>> To play safe with the ttl level pps I've setup to use a simple
>>> emitter follower that can drive into 75r coax.
>>>
>>> I didn't want to use line drivers as I don't have any handy that
>>> work off single 5V supply.
>>>
>>> I need a converter back to ttl before going to pc and don't have
>>> any spare gates in the box with compulsory flashing led and
>>> ticker, so will use another couple of transistors wired as
>>> Schmitt trigger.
>>>
>>>
>>> David
>> 
>> I think you're needlessly overcomplicating the PPS signal.  I have the 
>> GPS 18LVC feeding /two/ parallel RS-232 interfaces, /and/ a low-current 
>> LED, so for a 30m length I think you would get away with a simple wire 
>> connection.  However, have fun with the soldering iron!

>Are you getting better than 10us offsets though? :-)

I get an average of 2usec from pps driving the parallel interrupt ( with
"myown" interupt service daemon). I think much of that is a) ntp's
handling of rate fluctuations, and b)natural variation in the interrupt
handling due to computer issues. My gps 18 has about a 20m run to the
computer, and is simply a "bar wire ( well one of the Cat5e twisted pair
wires) connection.



>I've no idea how much signal degradation there would be using
>utp for pps and will both put it on spice and keep the spare
>pair in cable free to give it a try.

>However I'm making up various pcbs so an extra couple of tiny
>jobs won't add much to the fun and is playing safe in case I
>end up mounting aerials on roof or in garden, although that
>looks very much less likely to be needed now.


>> If you're seeing 4us offset now, that may be as good as it gets.  You 
>> may need a more constant temperature to see better.

>That's another project, putting the servers in a cupboard
>with temperature control. Alternative of locating the crystals
>and fitting heater is also a possibility. Cupboard idea has
>advantage of cutting down noise and will help keep the pcs
>from overheating.

Putting in a thermistor on top of the clock crystal and read the
temperature and use it to predict the rate variation. That will probably
give far better results than using a temperature controll. Also using
chrony ( which now has an shm refclock input at least in beta). will
give better results than ntp. 


>David

David J Taylor wrote:
> David Lord wrote:
> []
>>> I think you're needlessly overcomplicating the PPS signal.  I have
>>> the GPS 18LVC feeding /two/ parallel RS-232 interfaces, /and/ a
>>> low-current LED, so for a 30m length I think you would get away with
>>> a simple wire connection.  However, have fun with the soldering iron!
>>
>> Are you getting better than 10us offsets though? :-)
> 
> No, but I'm using Windows which is known to be not as good as FreeBSD.
> 
>> I've no idea how much signal degradation there would be using
>> utp for pps and will both put it on spice and keep the spare
>> pair in cable free to give it a try.
> 
> I'd be interested to know the results.

I'll put up some link but gps pc isn't lan connected until I
move it back and put in the extension. So far as I can see the
Garmin hasn't lost being valid source so I'm now tempted to try
out of back window with only short cable to servers.

......

>> That's another project, putting the servers in a cupboard
>> with temperature control. Alternative of locating the crystals
>> and fitting heater is also a possibility. Cupboard idea has
>> advantage of cutting down noise and will help keep the pcs
>> from overheating.

> Cupboard keeps the PCs from overheating?  Doesn't it restrict air flow? 
> If you add air conditioning to the cupboard, a little noisy and power 
> hungry?  I would try and either go for a low-power PC (perhaps Intel 
> atom based, perhaps flash-disk), or cut down the power consumed by the 
> PC and try to keep the load constant.  Turn down the clock in the BIOS, 
> remove or disconnect the power from unwanted devices (CD/DVD drives), 
> use "green" HDs etc. etc.

Cupboard will have a quiet fan pushing a good air flow over some
cooling fins from an ex dehumidifier. The eventual servers are
600MHz VIA C3 but they don't like 30C temperatures as happened
couple of days last year. All my servers seem to be around 40-50W
but that's probably due to non low power psus as a mate has his
target < 25W but it's cost him.

> All way over the top for time-keeping "better than your ISP", of course!
> <G>

ADSL is pretty bad for ntp from my experience and faster means
worse. So yes, OTT and as mentioned before it's more important to
have  servers in sync than be spot on UTC and if I could get MSF
or DCF reliably that would be ok. I already know ground floor has
embedded steel mesh and suspect this may be case for some walls.
GPS gives much more than I need for ntp but I was also after a
good frequency reference and the gps with 10kHz out seem to be
no longer available.

David

Unruh <unruh-spam@physics.ubc.ca> wrote:
> Well, I suppose you could somehow set the thing up to grab the rise time
> of the first bit sent along the serial line, but there is no evidence
> that the maker of the GPS made even that first bit at all accurate. Ie,
> the time when that first bit is sent could well vary by milliseconds.
> NMEA was never intended for accurate timeing.

The time field in the NMEA packet is the time of the fix that the data
in the packet is related to, presumably the most recent fix the unit
has calculated.
Interpreting it as "the current time" is quite risky.  The delay between
the calculation of the fix and the transmission of the packets depends
on implementation details, and on the amount of data being transmitted.
(an NMEA command can be issued to instruct the unit to transmit fewer
or more different types of data packets)

When you want more reliable time information, it often is better to
put the unit into the binary protocol mode.  However, this is different for
every manufacturer, so it complicates the writing of drivers.

gpsd tries to put the unit in binary mode.  it often provides more
detail as well.
however, the timing remains tricky.  to get reliable timing, you really
need PPS in addition to serial data.

David Lord wrote:
[]
> ADSL is pretty bad for ntp from my experience and faster means
> worse.

I've used cable, and that's not been too bad.

> So yes, OTT and as mentioned before it's more important to
> have  servers in sync than be spot on UTC and if I could get MSF
> or DCF reliably that would be ok. I already know ground floor has
> embedded steel mesh and suspect this may be case for some walls.
> GPS gives much more than I need for ntp but I was also after a
> good frequency reference and the gps with 10kHz out seem to be
> no longer available.
>
> David

I've seen some circuits around for syncing a 10MHz oscillator to a PPS 
signal, so yes, it would be good to have a frequency reference out of this 
as well!

Cheers,
David 

David J Taylor <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
>> So yes, OTT and as mentioned before it's more important to
>> have  servers in sync than be spot on UTC and if I could get MSF
>> or DCF reliably that would be ok. I already know ground floor has
>> embedded steel mesh and suspect this may be case for some walls.
>> GPS gives much more than I need for ntp but I was also after a
>> good frequency reference and the gps with 10kHz out seem to be
>> no longer available.
>>
>> David
>
> I've seen some circuits around for syncing a 10MHz oscillator to a PPS 
> signal, so yes, it would be good to have a frequency reference out of this 
> as well!

There used to be a "Jupiter" GPS receiver that output 10 kHz in addition
to 1 Hz.  That was much more convienient to lock a 10 MHz oscillator.
But as written above, they don't seem to make them anymore.

Unruh wrote:
> David Lord <snews@lordynet.org> writes:
> 
>> David J Taylor wrote:
>>> David Lord wrote:

.....

> 
> I get an average of 2usec from pps driving the parallel interrupt ( with
> "myown" interupt service daemon). I think much of that is a) ntp's
> handling of rate fluctuations, and b)natural variation in the interrupt
> handling due to computer issues. My gps 18 has about a 20m run to the
> computer, and is simply a "bar wire ( well one of the Cat5e twisted pair
> wires) connection.

Thanks for that Bill, to both you and David, I'll still make up
the pcbs but will first try connecting with straight through cable.

.....

> Putting in a thermistor on top of the clock crystal and read the
> temperature and use it to predict the rate variation. That will probably
> give far better results than using a temperature controll. Also using
> chrony ( which now has an shm refclock input at least in beta). will
> give better results than ntp. 

 From my searches I had opposite impression, that patches to ntp
for temperature compensation were good but not anywhere near as
good as keeping crystal at constant temperature.

Add to that a pps source probably takes system clocks largely
out of the equation.

I'm very happy to give chrony another try. I used it for a few
years without problems when on dialup. I'm thinking of
notebook rather than servers but I'd be happy to try on one of
servers (webserver uses ntpd but has chrony-1.20nb3 which I
guess is old).


David

David J Taylor wrote:
> Unruh wrote:
> []
>> The nmea is virtually useless for accurate timing. The main thing that
>> the unit gives you is the PPS. You have to makes sure you do not
>> degrade it.
> 
> The GPS 18x LVC only claims an accuracy of one microsecond for PPS in 
> the first place.  The RS-232 receivers may well have some filtering 
> limiting the risetime to a couple of microseconds (i.e. good enough for 

Note, if you actually do this you are deliberately grossly 
mis-terminating the line, not that that is necessarily a bad thing to do.

Incidentally, it is the transmitter's responsibility to control rise 
time, not the receiver's in RS232C.

> the maximum baud rate, typically 115,200 baud), so even if the final 

Baud rate should be irrelevant for modem control signals, but even for 
asynch data, the actual sampling resolution is 16 times better.

> risetime after the cable is a microsoecond or so, that's not going to 
> degrade the accuracy signifcantly for normal use.  Not an issue.
> 

David Lord wrote:

> 
> Accepted, the uncertainty from rs232 at 4800 baud limits timing
> to around +/- 100us which is what I'm seeing.

The uncertainty is about 14 microseconds.

David Woolley wrote:
> David J Taylor wrote:
[]
>> The GPS 18x LVC only claims an accuracy of one microsecond for PPS in
>> the first place.  The RS-232 receivers may well have some filtering
>> limiting the risetime to a couple of microseconds (i.e. good enough
>> for
>
> Note, if you actually do this you are deliberately grossly
> mis-terminating the line, not that that is necessarily a bad thing to
> do.
> Incidentally, it is the transmitter's responsibility to control rise
> time, not the receiver's in RS232C.
>
>> the maximum baud rate, typically 115,200 baud), so even if the final
>
> Baud rate should be irrelevant for modem control signals, but even for
> asynch data, the actual sampling resolution is 16 times better.

David,

In the RS-232 implementations I have seen, the line is /never/ correctly 
terminated, as I use the term.  Correct termination implies, if the cable 
impedance 50 ohms (such as the often used Belden 8777), that:

- the driver output impedance is 50-ohms
- the cable impedance is 50-ohms
- the receiver input impedance is 50-ohms

This would mean that there were no reflections either at the receiver 
input, or the transmitter output.  RS-232 typically has a much higher 
value of input impedance, in the region of 3-7K-ohms, according to:.
  http://www.arcelect.com/rs232.htm

so the line is not "correctly terminated".  That page also includes a 
maximum slew rate for the driver of 30V/us, so the driver controlling the 
risetime as you said.

Checking today's ICs I see that they suggest direct connection to the 
RS-232 socket, so the static protection must be better than it was some 
years back, and there is no need for external components.

Point taken about baud rate and the control signals.

Cheers,
David 

David Lord <snews@lordynet.org> writes:

>Unruh wrote:
>> David Lord <snews@lordynet.org> writes:
>> 
>>> David J Taylor wrote:
>>>> David Lord wrote:

>....

>> 
>> I get an average of 2usec from pps driving the parallel interrupt ( with
>> "myown" interupt service daemon). I think much of that is a) ntp's
>> handling of rate fluctuations, and b)natural variation in the interrupt
>> handling due to computer issues. My gps 18 has about a 20m run to the
>> computer, and is simply a "bar wire ( well one of the Cat5e twisted pair
>> wires) connection.

>Thanks for that Bill, to both you and David, I'll still make up
>the pcbs but will first try connecting with straight through cable.

>....

>> Putting in a thermistor on top of the clock crystal and read the
>> temperature and use it to predict the rate variation. That will probably
>> give far better results than using a temperature controll. Also using
>> chrony ( which now has an shm refclock input at least in beta). will
>> give better results than ntp. 

> From my searches I had opposite impression, that patches to ntp
>for temperature compensation were good but not anywhere near as
>good as keeping crystal at constant temperature.

>Add to that a pps source probably takes system clocks largely
>out of the equation.

>I'm very happy to give chrony another try. I used it for a few
>years without problems when on dialup. I'm thinking of
>notebook rather than servers but I'd be happy to try on one of
>servers (webserver uses ntpd but has chrony-1.20nb3 which I
>guess is old).

Yes, that is old. The latest is 1.23 but 
Miroslav Lichvar has since then put in a patch for giving chrony an shm
refclock driver 
I am not sure if I can post the location of the patch, but his email is mlichvar 
at redhat dot com
This is beta software, so report to him if you find bugs.
It needs a line in chrony.conf
refclock SHM 1 poll 4 offset 0.0 refid GPS1
 (poll, offset, refid are optional) The "1" refers to the shm port
number (gpsd uses 1) 

Note that he finds that chrony is about a factor 20 better than ntp at
poll level 4 (I think there is something wrong there) and about 2-3
times better at poll level 3. I suspect this depends crucially on the
thermal behaviour of the computer. 

David J Taylor wrote:

> 
> In the RS-232 implementations I have seen, the line is /never/ correctly 
> terminated, as I use the term.  Correct termination implies, if the

I'm not disputing that.  I was really pointing out that by using RS232 
you couldn't follow the earlier advice to use terminated lines.  RS232 
is designed to be used on bandwidth limited, electrically short lines, 
both driven and terminated above the characteristic impedance, so that 
the line behaviour approximates a discrete capacitor.

> cable impedance 50 ohms (such as the often used Belden 8777), that:

RS232 cables tend to have a high frequency impedance closer to 100 ohms, 
although at the frequencies involved, the impedance is variable and far 
from the high frequency limit.

> 
> - the driver output impedance is 50-ohms

Commonly not true, even for controlled impedance systems.  Radio 
transmitters rarely reverse terminate the line properly.

> - the cable impedance is 50-ohms
> - the receiver input impedance is 50-ohms

Whilst optimum for data transmission, for low noise radio receivers it 
can be the wrong thing.

> 

> Checking today's ICs I see that they suggest direct connection to the 
> RS-232 socket, so the static protection must be better than it was some 
> years back, and there is no need for external components.

I think that has been standard practice since the 1488 and 1489 were 
first introduced.

David Woolley wrote:
> David J Taylor wrote:
>
>>
>> In the RS-232 implementations I have seen, the line is /never/
>> correctly terminated, as I use the term.  Correct termination
>> implies, if the
>
> I'm not disputing that.  I was really pointing out that by using RS232
> you couldn't follow the earlier advice to use terminated lines.  RS232
> is designed to be used on bandwidth limited, electrically short lines,
> both driven and terminated above the characteristic impedance, so that
> the line behaviour approximates a discrete capacitor.

Thanks for clarifying that.  Agreed - that's why David Lord is proposing 
line drivers for his PPS signal over co-ax.  Had I the equipment and the 
time, I would like to see how well the GPS 18x LVC drives that amount of 
capacitive load.

>
>> cable impedance 50 ohms (such as the often used Belden 8777), that:
>
> RS232 cables tend to have a high frequency impedance closer to 100
> ohms, although at the frequencies involved, the impedance is variable
> and far from the high frequency limit.

Yes, that's what I thought until I looked again at the specs. for the 
cable we used to use!

>>
>> - the driver output impedance is 50-ohms
>
> Commonly not true, even for controlled impedance systems.  Radio
> transmitters rarely reverse terminate the line properly.

But there, the power loss inside the transmitter is important.  Take a 
look at fast data systems, sending video over cables etc. - they will be 
matched.

>> - the cable impedance is 50-ohms
>> - the receiver input impedance is 50-ohms
>
> Whilst optimum for data transmission, for low noise radio receivers it
> can be the wrong thing.

Agreed.

David 

David Lord wrote:
> David J Taylor wrote:
>> David Lord wrote:
>>> I'm intending buffering the pps to give 75r output to coax with
>>> another converter back to ttl at the server. The NMEA should manage
>>> the distance over twisted pair at 4800 baud.
>> []
>>> I'd rather have the option for two way in case the Garmin needs to be
>>> set to a different mode. I have a reel of utp I think should do.
>>>
>>> I'll have some sort of fan-out box to get a pps signal to each of
>>> servers that are powered up continuously.
>>>
>>> I've now seen an error in ntp log and suspect pps isn't enabled in
>>> kernel by default (NetBSD-5). I'll check tomorrow.
>>>
>>> Cheers
>>>
>>> David
>>
>> David, if you have UTP cable, I think that's four twisted pairs, so I 
>> would just use one pair per signal (TX, RX, PPS)  and the remaining 
>> pair as an earth/+5V.  Unless you have a noisy electrical environment, 
>> I think that will be fine over 30m.  Screened would be better, if you 
>> have it. Fan-out would be nice - I've used two RS-232 input in 
>> parallel fed from one GPS 18 without problems.
> 
> I'll scope pps down utp but doubt the pps will keep its rising
> edge. I'm having a box with indicator led and 5V regulator at end
> of the stock Garmin cable and coax + utp from that box downstairs.
> One pair will have +9V/0V to the regulator. It's a long while
> since I ran an rs232 cable downstairs but remember I had problems
> with higher data rates and 38400 bps being unreliable but 9600 bps
> just ok. That was also full rs232 levels rather than ttl.
> 
>>
>> I thought the offset figures you were quoting were for Windows - 
>> "between -74us and +62us".  For a PPS signal on a FreeBSD system I 
>> would expect much better.  I recall needing both the NMEA and the ATOM 
>> driver configured.  Oh, yes, I vaguely recall having to compile the 
>> kernel as well.  It was a few years ago....
>>  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
> 
> NetBSD-5 sources are from March 1, so pre NetBSD-5.0. I'll update
> to 5.0 off peak tonight and compile a new kernel. The last kernel
> compiled in March for a different pc includes "options PPS_SYNC"
> whereas that option doesn't appear in "GENERIC" or "std.i386" so
> as GPS with pps option enabled drifting further and ntpd throwing
> out more errors I think I can take it pps isn't working.
> Meanwhile I've removed the pps flag and restarted ntp.

I'm happy with very limited results so far so bringing the
PC back downstairs.


Garmin GPS18X-LVC
PC Mini-ITX ME6000 600MHz C3
NetBSD-5.0


NMEA string without PPS
GENERIC Kernel

# ntp.conf
server 127.127.1.0
fudge  127.127.1.0 stratum 12 time2 0
server 127.127.20.1
fudge  127.127.20.1 stratum 1

Over 6hrs (= 12 data points)
Offset:         Max     Avg     87%     50%
(us)            130      73     104      61


PPS enabled Kernel

# ntp.conf
server 127.127.1.0
fudge  127.127.1.0 stratum 12 time2 0
server 127.127.20.1 mode 1
fudge  127.127.20.1 stratum 1 flag3 1

Over 17hrs (= 34 data points)
Offset:         Max     Avg     87%     50%
(us)             12     4.2       7       3


######################
These are stats for past 24hrs of servers getting time from
internet. There's been no problems with load or temperature
otherwise Max would have hit its 12ms cutoff for graphing.

PC K6X400 NetBSD-3
                 Max             Average         Current
+offset:        3562 us         370 us          416 us
-offset:        2445 us         417 us          0 us


PC ME6000G NetBSD-4
                 Max             Average         Current
+offset:        2114 us         520 us          559 us
-offset:        4715 us         456 us          0 us


P4X2400C	NetBSD-4
                 Max             Average         Current
+offset:        1702 us         528 us          541 us
-offset:        2055 us         119 us          0 us

David Lord wrote:
[]
> I'm happy with very limited results so far so bringing the
> PC back downstairs.

Did you bring the puck downstairs as well, or use a cable?

[]
> Over 17hrs (= 34 data points)
> Offset:         Max     Avg     87%     50%
> (us)             12     4.2       7       3

Looks good!

> These are stats for past 24hrs of servers getting time from
> internet. There's been no problems with load or temperature
> otherwise Max would have hit its 12ms cutoff for graphing.

Next step?  Sync these PCs to your new stratum-1 clock as well as the 
Internet?

Cheers,
David 

David J Taylor wrote:
> David Lord wrote:
> []
>> I'm happy with very limited results so far so bringing the
>> PC back downstairs.
> 
> Did you bring the puck downstairs as well, or use a cable?

Neither, I'll be without gps for a while. Servers are right at
back of house. There used to be a phone upstairs (1/4" jack) and
if that line is still there I might be able to pull a cable
through otherwise it's a messy job. I'll try gps from back, high
up off a north facing wall, and might get away with that.

> 
> []
>> Over 17hrs (= 34 data points)
>> Offset:         Max     Avg     87%     50%
>> (us)             12     4.2       7       3
> 
> Looks good!
> 
>> These are stats for past 24hrs of servers getting time from
>> internet. There's been no problems with load or temperature
>> otherwise Max would have hit its 12ms cutoff for graphing.
> 
> Next step?  Sync these PCs to your new stratum-1 clock as well as the 
> Internet?

Yes that's the plan.

BTW and thanks, I used your mrtg page for setting up stats graphs.
Pity mrtg doesn't allow -ve values.


cheers

David

Unruh wrote:
> David Lord <snews@lordynet.org> writes:

.....

>> I'm very happy to give chrony another try. I used it for a few
>> years without problems when on dialup. I'm thinking of
>> notebook rather than servers but I'd be happy to try on one of
>> servers (webserver uses ntpd but has chrony-1.20nb3 which I
>> guess is old).
> 
> Yes, that is old. The latest is 1.23 but 
> Miroslav Lichvar has since then put in a patch for giving chrony an shm
> refclock driver 
> I am not sure if I can post the location of the patch, but his email is mlichvar 
> at redhat dot com
> This is beta software, so report to him if you find bugs.
> It needs a line in chrony.conf
> refclock SHM 1 poll 4 offset 0.0 refid GPS1
>  (poll, offset, refid are optional) The "1" refers to the shm port
> number (gpsd uses 1) 
> 
> Note that he finds that chrony is about a factor 20 better than ntp at
> poll level 4 (I think there is something wrong there) and about 2-3
> times better at poll level 3. I suspect this depends crucially on the
> thermal behaviour of the computer. 

I've installed chrony on an eee-pc running ubuntu but the mobile
broadband connection is worse than useless. Dns seems to go awol
or just doesn't happen. I can access sites by ip but even then
have rtt from 0.5s through 2s. I can also manage 3Mbit/s file
transfers over this high latency link, 50% faster than my 2Mbit/s
wired broadband? Bind now installed but not yet setup and it
doesn't address the latency problem.


I've also installed chrony on ubuntu desktop but guess for this
experiment it's better on one of the NetBSD servers. v1.23 is in
pkgsrc so I'll swap one of servers to that (I've run mixed chronyd
and ntpd before without problem and can always switch back).

cheers

David

David Lord wrote:
[]
> Neither, I'll be without gps for a while. Servers are right at
> back of house. There used to be a phone upstairs (1/4" jack) and
> if that line is still there I might be able to pull a cable
> through otherwise it's a messy job. I'll try gps from back, high
> up off a north facing wall, and might get away with that.

Ok, I misunderstood that you had the GPS downstairs as well.

>> Next step?  Sync these PCs to your new stratum-1 clock as well as the
>> Internet?
>
> Yes that's the plan.
>
> BTW and thanks, I used your mrtg page for setting up stats graphs.
> Pity mrtg doesn't allow -ve values.
>
>
> cheers
>
> David

Glad you found the MRTG stuff of use.  You could probably use RRDtool to 
better effect to handle the bipolar values.  There was a suggestion to 
plot the positive and negative values separately, which I think you have 
used, but personally I don't like the results for normal viewing:

  http://www.satsignal.eu/mrtg/daily_ntp-p.html

although they can be useful in that they auto-scale and allow you to see 
transients which would otherwise be off the normal graphs:

  http://www.satsignal.eu/mrtg/daily_ntp.html

Had some "interesting" rain and thunderstorms this afternoon, and rebooted 
one PC, which is why there are some unusual transients showing.

Cheers,
David 

On 2009-06-13, David Lord <snews@lordynet.org> wrote:

> BTW and thanks, I used your mrtg page for setting up stats graphs.
> Pity mrtg doesn't allow -ve values.

RRDtool does.

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

>I'm not sure whether the NMEA driver attempts to send anything /to/ the 
>GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
>otherwise four lines are required.  If you want to take USB power from the 
>server (as I now do), it's five lines minimum.

The driver expects the data to arrive without any help.  That
works with all the NMEA devices I've worked with.  You set them
up ahead of time by sending them a sequence of commands which
differ from device to device.

The driver does send "$PMOTG,RMC,0000*1D\r\n" every poll interval,
with a comment about some Motorola device needing it.  (That's one
per poll interval rather than one per second.  I don't expect it
to work very well.)

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

Hal Murray wrote:
>> I'm not sure whether the NMEA driver attempts to send anything /to/ the 
>> GPS device.  If not, three lines might to (ground, TX from GPS, PPS), 
>> otherwise four lines are required.  If you want to take USB power from the 
>> server (as I now do), it's five lines minimum.
> 
> The driver expects the data to arrive without any help.  That
> works with all the NMEA devices I've worked with.  You set them
> up ahead of time by sending them a sequence of commands which
> differ from device to device.
> 
> The driver does send "$PMOTG,RMC,0000*1D\r\n" every poll interval,
> with a comment about some Motorola device needing it.  (That's one
> per poll interval rather than one per second.  I don't expect it
> to work very well.)

I used input to disable non required NMEA sentences but I'm not
sure if any apparent improvement is due to that, temperature or
system load or other effects.

This system doesn't have network connection or mrtg. Ntp offsets
taken at 30 minute intervals with/without PPS and  with default
NMEA sentences vs RMC only. Garmin gps18x-lvc

nmea_std.dat
*      +/-offset     Num     Tot       %
*           (ms)
*           0.12       5      25      56
*           0.16       2      40      89
*           0.17       5      45     100

pps_std.dat
*      +/-offset     Num     Tot       %
*           (ms)
*          0.004      25      79      52
*          0.010       7     148      97
*          0.014       2     153     100

nmea_rmc.dat
*      +/-offset     Num     Tot       %
*           (ms)
*           0.07       5      27      51
*           0.16       3      49      92
*           0.20       1      53     100

pps_rmc.dat
*      +/-offset     Num     Tot       %
*           (ms)
*          0.002      49      76      54
*          0.005       7     140      99
*          0.006       1     141     100


David