Hello,
   I am interested in getting a GPS clock to synchronize our internal
test network.  I am curious to hear about relativley cheap and Linux
friendly GPS clock. (Less than $100 would be great)

Thanks in advance

>   I am interested in getting a GPS clock to synchronize our internal
>test network.  I am curious to hear about relativley cheap and Linux
>friendly GPS clock. (Less than $100 would be great)

The Garmin GPS 18 LVC is popular.  "Some assembly required."
(aka soldering)  No big deal if somebody has a soldering iron
handy.  There are a couple of links from here:
  http://support.ntp.org/bin/view/Support/InexpensiveOemGps

Bewares:
  You don't want the GPS 18 USB version.

  There are a lot of low cost USB GPS gizmos that use the
SiRF Star III.  They suck for timekeeping.

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

Hal Murray wrote:
>>   I am interested in getting a GPS clock to synchronize our internal
>> test network.  I am curious to hear about relativley cheap and Linux
>> friendly GPS clock. (Less than $100 would be great)
> 
> The Garmin GPS 18 LVC is popular.  "Some assembly required."
> (aka soldering)  No big deal if somebody has a soldering iron
> handy.  There are a couple of links from here:
>   http://support.ntp.org/bin/view/Support/InexpensiveOemGps

You will need a 5VDC power supply and a DB-9 or DB-25 connector that 
will connect to a serial or parallel port.  The serial port DCD line is 
frequently used.  Also some hookup wire, solder, and perhaps other goodies.

On Sep 11, 4:54 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >   I am interested in getting a GPS clock to synchronize our internal
> >test network.  I am curious to hear about relativley cheap and Linux
> >friendly GPS clock. (Less than $100 would be great)
>
> The Garmin GPS 18 LVC is popular.  "Some assembly required."
> (aka soldering)  No big deal if somebody has a soldering iron
> handy.  There are a couple of links from here:
>  http://support.ntp.org/bin/view/Support/InexpensiveOemGps
>
> Bewares:
>   You don't want the GPS 18 USB version.
>
>   There are a lot of low cost USB GPS gizmos that use the
> SiRF Star III.  They suck for timekeeping.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.
Thanks.  Although, I would prefer something to be just ready to go, as
we have a paper deadline coming up.

On 2008-09-12, rochertov@gmail.com <rochertov@gmail.com> wrote:

> On Sep 11, 4:54 pm, (Hal Murray) wrote:
>
>> >   I am interested in getting a GPS clock to synchronize our
>> >internal test network. I am curious to hear about relativley cheap
>> >and Linux friendly GPS clock. (Less than $100 would be great)

http://www.google.com/search?q=gps+clock
http://www.google.com/search?q=gps+clock+linux
http://www.google.com/search?q=gps+timing+receiver

Any timing GPS which ouputs NMEA sentences and a PPS signal is supported
by the Generic NMEA driver in ntpd. You do need to have LinuxPPS support
in your kernel or use a helper such as gpsd.

If you want a drop-in solution you'll need something like

http://www.ntp-systems.com/products.asp
or
http://www.endruntechnologies.com/time-servers.htm

>> The Garmin GPS 18 LVC is popular. "Some assembly required."
>> (aka soldering) No big deal if somebody has a soldering
>> iron handy. There are a couple of links from here:
>> http://support.ntp.org/bin/view/Support/InexpensiveOemGps
>
> Thanks. Although, I would prefer something to be just ready to go, as
> we have a paper deadline coming up.

The GPS 18 LVC costs less than $70. Add to that the time for someone to
work out the wiring and solder up the connector (well under an hour for
a competant tech).

Any other solution is likely to cost more.

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

Steve Kostecke wrote:

> The GPS 18 LVC costs less than $70. Add to that the time for someone to
> work out the wiring and solder up the connector (well under an hour for
> a competant tech).

If you ask Garmin Europe for a quote : ~190Euro + VAT Grrrrrrr.

uwe

Uwe Klein wrote:
> Steve Kostecke wrote:
> 
>> The GPS 18 LVC costs less than $70. Add to that the time for someone to
>> work out the wiring and solder up the connector (well under an hour for
>> a competant tech).
> 
> If you ask Garmin Europe for a quote : ~190Euro + VAT Grrrrrrr.

Huh???

I bought (i.e. ordered) one from a local dealer here in Oslo, I paid 
about $120 at the time, a few years ago.

Anyway it is so small and cheap that I'd simply order one from the US: 
Even if you have to pay freight and customs, you're still far below that 
Euro price!

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Richard B. Gilbert wrote:
> Hal Murray wrote:
>> The Garmin GPS 18 LVC is popular.  "Some assembly required."
>> (aka soldering)  No big deal if somebody has a soldering iron
>> handy.  There are a couple of links from here:
>>   http://support.ntp.org/bin/view/Support/InexpensiveOemGps
> 
> You will need a 5VDC power supply and a DB-9 or DB-25 connector that 
> will connect to a serial or parallel port.  The serial port DCD line is 
> frequently used.  Also some hookup wire, solder, and perhaps other goodies.

Using a USB port for the +5V line is the canonical solution: Very cheap, 
dependable, and no extra wall warts.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote:
> Uwe Klein wrote:
> 
>> Steve Kostecke wrote:
>>
>>> The GPS 18 LVC costs less than $70. Add to that the time for someone to
>>> work out the wiring and solder up the connector (well under an hour for
>>> a competant tech).
>>
>>
>> If you ask Garmin Europe for a quote : ~190Euro + VAT Grrrrrrr.
> 
> 
> Huh???
> 
> I bought (i.e. ordered) one from a local dealer here in Oslo, I paid 
> about $120 at the time, a few years ago.
> 
> Anyway it is so small and cheap that I'd simply order one from the US: 
> Even if you have to pay freight and customs, you're still far below that 
> Euro price!

YES
friend of mine is a reseller for garmin. I had him ask for the price
at Garmin DE about a year ago. I was quite astonished.

uwe

Terje Mathisen wrote:
> Richard B. Gilbert wrote:
>> Hal Murray wrote:
>>> The Garmin GPS 18 LVC is popular.  "Some assembly required."
>>> (aka soldering)  No big deal if somebody has a soldering iron
>>> handy.  There are a couple of links from here:
>>>   http://support.ntp.org/bin/view/Support/InexpensiveOemGps
>>
>> You will need a 5VDC power supply and a DB-9 or DB-25 connector that 
>> will connect to a serial or parallel port.  The serial port DCD line 
>> is frequently used.  Also some hookup wire, solder, and perhaps other 
>> goodies.
> 
> Using a USB port for the +5V line is the canonical solution: Very cheap, 
> dependable, and no extra wall warts.
> 
> Terje
> 

I have read claims here that the high and unpredictable latencies in USB 
render it useless for time keeping!

hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


>>   I am interested in getting a GPS clock to synchronize our internal
>>test network.  I am curious to hear about relativley cheap and Linux
>>friendly GPS clock. (Less than $100 would be great)

>The Garmin GPS 18 LVC is popular.  "Some assembly required."
>(aka soldering)  No big deal if somebody has a soldering iron
>handy.  There are a couple of links from here:
>  http://support.ntp.org/bin/view/Support/InexpensiveOemGps

>Bewares:
>  You don't want the GPS 18 USB version.

You also do not want the GPS 18 PC serial port version either. Neither has
a PPS ( pulse per second) output.



>  There are a lot of low cost USB GPS gizmos that use the
>SiRF Star III.  They suck for timekeeping.

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

Uwe Klein <uwe_klein_habertwedt@t-online.de> writes:

>Steve Kostecke wrote:

>> The GPS 18 LVC costs less than $70. Add to that the time for someone to
>> work out the wiring and solder up the connector (well under an hour for
>> a competant tech).

>If you ask Garmin Europe for a quote : ~190Euro + VAT Grrrrrrr.

Wow! Order from the US. The shipping will not be 150 euros ( the price
difference between 190 E and the cost in the US)


>uwe

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

>Terje Mathisen wrote:
>> Richard B. Gilbert wrote:
>>> Hal Murray wrote:
>>>> The Garmin GPS 18 LVC is popular.  "Some assembly required."
>>>> (aka soldering)  No big deal if somebody has a soldering iron
>>>> handy.  There are a couple of links from here:
>>>>   http://support.ntp.org/bin/view/Support/InexpensiveOemGps
>>>
>>> You will need a 5VDC power supply and a DB-9 or DB-25 connector that 
>>> will connect to a serial or parallel port.  The serial port DCD line 
>>> is frequently used.  Also some hookup wire, solder, and perhaps other 
>>> goodies.
>> 
>> Using a USB port for the +5V line is the canonical solution: Very cheap, 
>> dependable, and no extra wall warts.
>> 
>> Terje
>> 

>I have read claims here that the high and unpredictable latencies in USB 
>render it useless for time keeping!

Yes. That is why you ONLY use it for the 5V. The usb output is +5V, Signal
+, Signal -, Power ground. Ignore the signal lines and just use the +5V and
ground to power your Garmin GPS.

Hal Murray wrote:

>   There are a lot of low cost USB GPS gizmos that use the
> SiRF Star III.  They suck for timekeeping.
> 
Is there a reason known for this?

uwe

Richard B. Gilbert wrote:
> Terje Mathisen wrote:
>> Using a USB port for the +5V line is the canonical solution: Very 
>> cheap, dependable, and no extra wall warts.
>>
>> Terje
>>
> 
> I have read claims here that the high and unpredictable latencies in USB 
> render it useless for time keeping!

Sure, but +5V DC is _perfect_ for powering said GSP. :-)

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Uwe Klein wrote:
> Hal Murray wrote:
> 
>>   There are a lot of low cost USB GPS gizmos that use the
>> SiRF Star III.  They suck for timekeeping.
>>
> Is there a reason known for this?

No PPS signal.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

In article <ko8qp5-po8.ln1@klein-habertwedt.de>,
 Uwe Klein <uwe_klein_habertwedt@t-online.de> writes:
>Hal Murray wrote:
>
>>   There are a lot of low cost USB GPS gizmos that use the
>> SiRF Star III.  They suck for timekeeping.
>> 
>Is there a reason known for this?

I assume it's a software bug/feature.  The problem is drift/wander
in the offset.  The offset changes too slowly for normal
jitter filters to work on it.
  http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif

I forgot to mention another problem with those chipsets.
They have a leap second bug.
  http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif


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

On Thu, 11 Sep 2008 18:54:25 -0500, Hal Murray wrote:

>>   I am interested in getting a GPS clock to synchronize our internal
>>test network.  I am curious to hear about relativley cheap and Linux
>>friendly GPS clock. (Less than $100 would be great)
> 
> The Garmin GPS 18 LVC is popular.  

The above has been superseded by Garmin model: GPS 18x LVC
Physically identical, but having a more "sensitive" receiver.
Note the "x" in the model number when shopping for one.

> "Some assembly required." (aka
> soldering)  No big deal if somebody has a soldering iron handy.  There
> are a couple of links from here:
>   http://support.ntp.org/bin/view/Support/InexpensiveOemGps
> 
> Bewares:
>   You don't want the GPS 18 USB version.
> 
>   There are a lot of low cost USB GPS gizmos that use the
> SiRF Star III.  They suck for timekeeping.

Hal Murray wrote:
> In article <ko8qp5-po8.ln1@klein-habertwedt.de>,
>  Uwe Klein <uwe_klein_habertwedt@t-online.de> writes:
> 
>>Hal Murray wrote:
>>
>>
>>>  There are a lot of low cost USB GPS gizmos that use the
>>>SiRF Star III.  They suck for timekeeping.
>>>
>>
>>Is there a reason known for this?
> 
> 
> I assume it's a software bug/feature.  The problem is drift/wander
> in the offset.  The offset changes too slowly for normal
> jitter filters to work on it.
>   http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
connected via serial/nmea or pps?

that looks like some beat frequency effect.
But it is much too slow/time too big
  to be sender and/or receiver uart clocking.

> 
> I forgot to mention another problem with those chipsets.
> They have a leap second bug.
>   http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif
Hmpf
> 
uwe

> 

>> I assume it's a software bug/feature.  The problem is drift/wander
>> in the offset.  The offset changes too slowly for normal
>> jitter filters to work on it.
>>   http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif

>connected via serial/nmea or pps?

Direct USB.

I have another one (using the SiRF chips)  that is serial
via a serial-USB adapter.  Same thing.


>that looks like some beat frequency effect.
>But it is much too slow/time too big
>  to be sender and/or receiver uart clocking.

Yes.  But I don't think it's a USB problem.  I get much better
results with a Garmin GPS 18 USB.  (Of course, what I don't know
about USB could fill ...)

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

Hal Murray wrote:
>>>I assume it's a software bug/feature.  The problem is drift/wander
>>>in the offset.  The offset changes too slowly for normal
>>>jitter filters to work on it.
>>>  http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
> 
> 
>>connected via serial/nmea or pps?
> 
> 
> Direct USB.
> 
> I have another one (using the SiRF chips)  that is serial
> via a serial-USB adapter.  Same thing.
There is a good chance that the direct USB thingy
has the serial2USB converter just integrated
( replacing the rs232 levelshifter ).
> 
> 
> 
>>that looks like some beat frequency effect.
>>But it is much too slow/time too big
>> to be sender and/or receiver uart clocking.
> 
> 
> Yes.  But I don't think it's a USB problem.  I get much better
> results with a Garmin GPS 18 USB.  (Of course, what I don't know
> about USB could fill ...)
I had my fingers in USB recently, but ..

> 
Hmm, you get one sentence per second?

I will have to read up if the usb2serial ics have some kind of fifo
included ( and enabled or not ). This could be an explanation.

uwe

Uwe Klein wrote:
> I will have to read up if the usb2serial ics have some kind of fifo
> included ( and enabled or not ). This could be an explanation.

The basic problem with serial to USB converters is that the serial lines
basically use transmission of characters whereas USB transmission is
block-oriented.

If a converter receives one character from the serial side it either can put
that single character into an USB block and send that block immediately,
which generates much overhead but low latency, or it could wait for a
certain interval whether additional characters arrive, which could be
packed together and sent in a single USB block. A new USB block is sent if
either enough serial characters have arrived, or no characters are arriving
anymore and a timeout occurs.

The latter is good for USB throughput but generates a latency up to the
timeout limit.

So the behaviour should depend on the implementation of an individual
converter type. BTW, similar problems arise with serial-to-LAN converters
which redirect a serial data stream using IP packets.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Richard B. Gilbert wrote:
> Terje Mathisen wrote:
>> Using a USB port for the +5V line is the canonical solution: Very 
>> cheap, dependable, and no extra wall warts.
>>
>> Terje
>>
> 
> I have read claims here that the high and unpredictable latencies in USB 
> render it useless for time keeping!

So, apparently not entirely useless. Using USB as a power source is 
getting to be highly popular. Witness the number of cup warmers, fan, 
etc. on the market. As long as you don't try to read the signal via 
USB, it should be okay.

One thought occurs to me. Would it work to have the PPS signal go to a 
serial port but the actual NMEA sentences be read via USB? It seems to 
me if the total jitter of the USB still kept the snetences timing 
within half a second it would work.

Brian Utterback

Martin Burnicki wrote:

> So the behaviour should depend on the implementation of an individual
> converter type. BTW, similar problems arise with serial-to-LAN converters
> which redirect a serial data stream using IP packets.

I have used the standard pl2303 type converters
and their bastard brethren ( to make an
existing RS485 based daisychained system "USB ready" )

communication to this system was a fast chitchat @38400 Baud:

every second {
	foreach slot_used {
		send <STX><BoxAddr><SlotAddr><payload message with linefeed>,
		wait for response including linefeed,
		send <ETX>  // to deselect the current slot
	}
}

~30 slots used.
I never had any latency problems.

Thus my guess is that these latency may lie in the firmware running
on the sirf chipset.

the gpsd people seem to have delved into this too:
	http://gpsd.berlios.de/performance.html

Q: does the sirf chipset talk on its own or do you have to request
sentences?
( the gpsd article gives the impression that its query .. response )


uwe

Once upon a time, Brian Utterback  <brian.utterback@sun.com> said:
>So, apparently not entirely useless. Using USB as a power source is 
>getting to be highly popular. Witness the number of cup warmers, fan, 
>etc. on the market. As long as you don't try to read the signal via 
>USB, it should be okay.

Another power source solution (especially for those like me that don't
have an open RS232 port anyway) is the SIIG series of PCI/PCI-E RS232
cards; they can optionally provide +5V or +12V on a pin.

>One thought occurs to me. Would it work to have the PPS signal go to a 
>serial port but the actual NMEA sentences be read via USB? It seems to 
>me if the total jitter of the USB still kept the snetences timing 
>within half a second it would work.

I am actually doing that right now (using the parallel port instead of
the serial port in my case); it works fine.

Has anyone tried isochronous mode USB to see if that helps with the
latency?  I have an FTDI USB-to-RS232 interface that supports
isochronous mode, but I haven't had a chance to try it.

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Uwe Klein wrote:
> Martin Burnicki wrote:
> 
>> So the behaviour should depend on the implementation of an individual
>> converter type. BTW, similar problems arise with serial-to-LAN converters
>> which redirect a serial data stream using IP packets.
> 
> I have used the standard pl2303 type converters
> and their bastard brethren ( to make an
> existing RS485 based daisychained system "USB ready" )
> 
> communication to this system was a fast chitchat @38400 Baud:
> 
> every second {
> foreach slot_used {
> send <STX><BoxAddr><SlotAddr><payload message with linefeed>,
> wait for response including linefeed,
> send <ETX>  // to deselect the current slot
> }
> }
> 
> ~30 slots used.
> I never had any latency problems.

Some times ago we had made some tests with some serial-to-USB converters
which are connected to the PC via USB and provide a serial port to which
serial devices can be connected. We have been using our GPS receivers which
send a serial time string once per second as soon as possible after a
second changeover. The jitter of the serial output is 1 bit time depending
on the baud rate, i.e. ~52 microseconds @ 19200.

Some of the tested devices introduced a very low latency whereas others
indroduced a much higher latency. So this depends in fact on the maybe the
chip set and in any case the driver/firmware used for the converter.
 
> Thus my guess is that these latency may lie in the firmware running
> on the sirf chipset.

Of course, if the firmware already inserts some latency then the
serial-to-USB converter is not to blame and can not eliminate it.
 
Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hi Martin,

Martin Burnicki wrote:

> Some times ago we had made some tests with some serial-to-USB converters
> which are connected to the PC via USB and provide a serial port to which
> serial devices can be connected. We have been using our GPS receivers which
> send a serial time string once per second as soon as possible after a
> second changeover. The jitter of the serial output is 1 bit time depending
> on the baud rate, i.e. ~52 microseconds @ 19200.
Yes, if one needs further improvements one would try to sync the baudrate
generator to the pps clock. with some tricks in the sending routine
one then could transmit in a coherent fashion.
Though you still retain the receiver uncertainty ( 1/16.. 1/64 of a baud cycle
depending on async receiver used )
> 
> Some of the tested devices introduced a very low latency whereas others
> indroduced a much higher latency. So this depends in fact on the maybe the
> chip set and in any case the driver/firmware used for the converter.
Have you got vendor/product Id pairs for those? on windows/linux/bsd/* ?
I'd be interested in related information.
>  
> 
>>Thus my guess is that these latency may lie in the firmware running
>>on the sirf chipset.
> 
> 
> Of course, if the firmware already inserts some latency then the
> serial-to-USB converter is not to blame and can not eliminate it.
>  
> Martin
uwe

Brian Utterback wrote:
> So, apparently not entirely useless. Using USB as a power source is 
> getting to be highly popular. Witness the number of cup warmers, fan, 
> etc. on the market. As long as you don't try to read the signal via USB, 
> it should be okay.
> 
> One thought occurs to me. Would it work to have the PPS signal go to a 
> serial port but the actual NMEA sentences be read via USB? It seems to 
> me if the total jitter of the USB still kept the snetences timing within 
> half a second it would work.

Sure, that should work, except that if you do have a serial port to 
receive the PPS signal on, using the same port for the rest of the 
signal simply makes sense.

The USB-based GPSes all seem to be missing a dedicated PPS signal.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

>Thus my guess is that these latency may lie in the firmware running
>on the sirf chipset.

That is my assumption.


>Q: does the sirf chipset talk on its own or do you have to request
>sentences?
>( the gpsd article gives the impression that its query .. response )

I'm running them in NMEA mode.  They send a sentence every second.

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

Uwe,

sorry for the delay.

Uwe Klein wrote:
> Hi Martin,
> 
> Martin Burnicki wrote:
> 
>> Some times ago we had made some tests with some serial-to-USB converters
>> which are connected to the PC via USB and provide a serial port to which
>> serial devices can be connected. We have been using our GPS receivers
>> which send a serial time string once per second as soon as possible after
>> a second changeover. The jitter of the serial output is 1 bit time
>> depending on the baud rate, i.e. ~52 microseconds @ 19200.
> Yes, if one needs further improvements one would try to sync the baudrate
> generator to the pps clock. with some tricks in the sending routine
> one then could transmit in a coherent fashion.
> Though you still retain the receiver uncertainty ( 1/16.. 1/64 of a baud
> cycle depending on async receiver used )
>> 
>> Some of the tested devices introduced a very low latency whereas others
>> indroduced a much higher latency. So this depends in fact on the maybe
>> the chip set and in any case the driver/firmware used for the converter.
> Have you got vendor/product Id pairs for those? on windows/linux/bsd/* ?
> I'd be interested in related information.

Unfortunately not. We have just made some quick tests under windows, using
some devices which you could buy at that time.

This has been some time ago, and I don't have those devices available
anymore. 

>>>Thus my guess is that these latency may lie in the firmware running
>>>on the sirf chipset.
>> 
>> 
>> Of course, if the firmware already inserts some latency then the
>> serial-to-USB converter is not to blame and can not eliminate it.

Yes, but what I meant is that the driver for the converter can insert some
latency which degrades accuracy even if the sending device behaves good.

We had tested some of our serial devices connected directly to a serial
port, and then connected to a serial-to-USB converter which implements an
additional COM port on the PC, which inserted several milliseconds of
jitter.

We have now some own USB devices which have USB support in the
microcontroller. They can be connected directly to an USB slot, so we have
more control on timing issues. However, there are still latencies in a
millisecond range due to the USB low level drivers which come with the
operating systems.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany