time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

GPS USB dongle for time server

JS
jim s
Tue, Nov 9, 2010 1:14 AM

This is probably the thousandth time this was asked, but I googled and
didn't get a direct answer.

I want to do a crude (as in to the second or so) time server inhouse to
add into a group of high accuracy servers.  This is so that I can go off
grid and still get updates.

I see that there is a way to get a feed called PPS or with PPS via
RS232.  The discussions of using USB instead are concerned with having
too much jitter.

since USB by its nature won't have an accurate exact dedicated line to
let the GPS toggle to do a time hack to the software, I can see why
RS232 is preferable with the hardware signal lines they have.

If I just go with the NEMA stream as it gets to me via an USB HID Com
port, I assume that there will be some jitter baring a way to send in
the physical time hack.

Any pointers to reading or comment on this would be appreciated.  I am
probably asking the query before I should, as far as research, and
appreciate any replies.

Jim

This is probably the thousandth time this was asked, but I googled and didn't get a direct answer. I want to do a crude (as in to the second or so) time server inhouse to add into a group of high accuracy servers. This is so that I can go off grid and still get updates. I see that there is a way to get a feed called PPS or with PPS via RS232. The discussions of using USB instead are concerned with having too much jitter. since USB by its nature won't have an accurate exact dedicated line to let the GPS toggle to do a time hack to the software, I can see why RS232 is preferable with the hardware signal lines they have. If I just go with the NEMA stream as it gets to me via an USB HID Com port, I assume that there will be some jitter baring a way to send in the physical time hack. Any pointers to reading or comment on this would be appreciated. I am probably asking the query before I should, as far as research, and appreciate any replies. Jim
BC
Bob Camp
Tue, Nov 9, 2010 1:39 AM

Hi

The gotcha is that the NEMA string has a poorly defined transit due to the USB stack. The jitter is still there. On a loaded system it can be fairly large.

The next layer to the onion is that the location of the PPS within the NEMA string is also poorly defined on a lot of the cheap(er) hardware out there. There are some devices where it's off by a large fraction of a second.

Better to figure out a way to get a "real" pps into the box.

Bob

On Nov 8, 2010, at 8:14 PM, jim s wrote:

This is probably the thousandth time this was asked, but I googled and didn't get a direct answer.

I want to do a crude (as in to the second or so) time server inhouse to add into a group of high accuracy servers.  This is so that I can go off grid and still get updates.

I see that there is a way to get a feed called PPS or with PPS via RS232.  The discussions of using USB instead are concerned with having too much jitter.

since USB by its nature won't have an accurate exact dedicated line to let the GPS toggle to do a time hack to the software, I can see why RS232 is preferable with the hardware signal lines they have.

If I just go with the NEMA stream as it gets to me via an USB HID Com port, I assume that there will be some jitter baring a way to send in the physical time hack.

Any pointers to reading or comment on this would be appreciated.  I am probably asking the query before I should, as far as research, and appreciate any replies.

Jim


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

Hi The gotcha is that the NEMA string has a poorly defined transit due to the USB stack. The jitter is still there. On a loaded system it can be fairly large. The next layer to the onion is that the location of the PPS within the NEMA string is also poorly defined on a lot of the cheap(er) hardware out there. There are some devices where it's off by a large fraction of a second. Better to figure out a way to get a "real" pps into the box. Bob On Nov 8, 2010, at 8:14 PM, jim s wrote: > This is probably the thousandth time this was asked, but I googled and didn't get a direct answer. > > I want to do a crude (as in to the second or so) time server inhouse to add into a group of high accuracy servers. This is so that I can go off grid and still get updates. > > I see that there is a way to get a feed called PPS or with PPS via RS232. The discussions of using USB instead are concerned with having too much jitter. > > since USB by its nature won't have an accurate exact dedicated line to let the GPS toggle to do a time hack to the software, I can see why RS232 is preferable with the hardware signal lines they have. > > If I just go with the NEMA stream as it gets to me via an USB HID Com port, I assume that there will be some jitter baring a way to send in the physical time hack. > > Any pointers to reading or comment on this would be appreciated. I am probably asking the query before I should, as far as research, and appreciate any replies. > > Jim > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
J
jimlux
Tue, Nov 9, 2010 3:58 AM

jim s wrote:

This is probably the thousandth time this was asked, but I googled and
didn't get a direct answer.

I want to do a crude (as in to the second or so) time server inhouse to
add into a group of high accuracy servers.  This is so that I can go off
grid and still get updates.

I see that there is a way to get a feed called PPS or with PPS via
RS232.  The discussions of using USB instead are concerned with having
too much jitter.

since USB by its nature won't have an accurate exact dedicated line to
let the GPS toggle to do a time hack to the software, I can see why
RS232 is preferable with the hardware signal lines they have.

If I just go with the NEMA stream as it gets to me via an USB HID Com
port, I assume that there will be some jitter baring a way to send in
the physical time hack.

I would think that USB is not inherently worse than a hardware RS232.
Both have some interrupt latency, but it's small in both cases.  USB has
to handle audio reliably at no worse than 8kHz sampling rate.

jim s wrote: > This is probably the thousandth time this was asked, but I googled and > didn't get a direct answer. > > I want to do a crude (as in to the second or so) time server inhouse to > add into a group of high accuracy servers. This is so that I can go off > grid and still get updates. > > I see that there is a way to get a feed called PPS or with PPS via > RS232. The discussions of using USB instead are concerned with having > too much jitter. > > since USB by its nature won't have an accurate exact dedicated line to > let the GPS toggle to do a time hack to the software, I can see why > RS232 is preferable with the hardware signal lines they have. > > If I just go with the NEMA stream as it gets to me via an USB HID Com > port, I assume that there will be some jitter baring a way to send in > the physical time hack. > > I would think that USB is not inherently worse than a hardware RS232. Both have some interrupt latency, but it's small in both cases. USB has to handle audio reliably at no worse than 8kHz sampling rate.
RS
Randy Scott
Tue, Nov 9, 2010 4:08 AM

I would think that USB is not inherently worse than a
hardware RS232. Both have some interrupt latency, but it's
small in both cases.  USB has to handle audio reliably
at no worse than 8kHz sampling rate.

Using isochronous USB enpoints, yes.  USB-to-serial converters and probably whatever they put into USB GPS receivers no doubt use bulk endpoints with slightly more non-deterministic buffering on both ends of the wire.

Randy.

> I would think that USB is not inherently worse than a > hardware RS232. Both have some interrupt latency, but it's > small in both cases.  USB has to handle audio reliably > at no worse than 8kHz sampling rate. Using isochronous USB enpoints, yes. USB-to-serial converters and probably whatever they put into USB GPS receivers no doubt use bulk endpoints with slightly more non-deterministic buffering on both ends of the wire. Randy.
MC
Michael Conlen
Tue, Nov 9, 2010 4:26 AM

On Nov 8, 2010, at 10:58 PM, jimlux wrote:

jim s wrote:

This is probably the thousandth time this was asked, but I googled and didn't get a direct answer.
I want to do a crude (as in to the second or so) time server inhouse to add into a group of high accuracy servers.  This is so that I can go off grid and still get updates.
I see that there is a way to get a feed called PPS or with PPS via RS232.  The discussions of using USB instead are concerned with having too much jitter.
since USB by its nature won't have an accurate exact dedicated line to let the GPS toggle to do a time hack to the software, I can see why RS232 is preferable with the hardware signal lines they have.
If I just go with the NEMA stream as it gets to me via an USB HID Com port, I assume that there will be some jitter baring a way to send in the physical time hack.

I would think that USB is not inherently worse than a hardware RS232. Both have some interrupt latency, but it's small in both cases.  USB has to handle audio reliably at no worse than 8kHz sampling rate.

And as an audio nut as well as a time nut I can say that USB and Firewire both do this poorly (under certain conditions).

I often have to restart encodings of multi-track audio if I don't shut absolutely everything down on what should be a well powered system because USB and Firewire both are unable to keep up.

--
Mike

On Nov 8, 2010, at 10:58 PM, jimlux wrote: > jim s wrote: >> This is probably the thousandth time this was asked, but I googled and didn't get a direct answer. >> I want to do a crude (as in to the second or so) time server inhouse to add into a group of high accuracy servers. This is so that I can go off grid and still get updates. >> I see that there is a way to get a feed called PPS or with PPS via RS232. The discussions of using USB instead are concerned with having too much jitter. >> since USB by its nature won't have an accurate exact dedicated line to let the GPS toggle to do a time hack to the software, I can see why RS232 is preferable with the hardware signal lines they have. >> If I just go with the NEMA stream as it gets to me via an USB HID Com port, I assume that there will be some jitter baring a way to send in the physical time hack. > > I would think that USB is not inherently worse than a hardware RS232. Both have some interrupt latency, but it's small in both cases. USB has to handle audio reliably at no worse than 8kHz sampling rate. And as an audio nut as well as a time nut I can say that USB and Firewire both do this poorly (under certain conditions). I often have to restart encodings of multi-track audio if I don't shut absolutely everything down on what should be a well powered system because USB and Firewire both are unable to keep up. -- Mike
HS
Harlan Stenn
Tue, Nov 9, 2010 4:30 AM

Using USB serial introduces amusing amounts of jitter.  This is usually
not a problem for the NMEA sentences, but I wouldn't want to be
detecting the PPS signal via USB1 or USB2 serial devices.

I've heard that USB3 should be much better.  I haven't touched any of
these yet.

--
Harlan Stenn stenn@ntp.org
http://ntpforum.isc.org  - be a member!

Using USB serial introduces amusing amounts of jitter. This is usually not a problem for the NMEA sentences, but I wouldn't want to be detecting the PPS signal via USB1 or USB2 serial devices. I've heard that USB3 should be much better. I haven't touched any of these yet. -- Harlan Stenn <stenn@ntp.org> http://ntpforum.isc.org - be a member!
JS
jim s
Tue, Nov 9, 2010 5:50 AM

On 11/8/2010 5:14 PM, jim s wrote:

This is probably the thousandth time this was asked, but I googled and
didn't get a direct answer.

Here is the reference to the PPS that made me make statements about RS232

http://forums.freebsd.org/showthread.php?t=16507

Here is an actual implementation using a Garmin 18LVC, which was
referenced by another poster.

http://time.qnan.org/

The difference between the RS-232 and the USB is that there is a wire
(DCD or CTS) so you can do a precise hack if you can overcome the issues
of system load, etc.  Perhaps a driver patch to grab the exact system
clock time in a driver when either changes would be one method, immune
to system load.

No way to do so as pointer out on USB.  It has not only some difference
depending on the number of USB hubs, but also total number of devices.
Assuming you hack the USB driver to get a time hack exactly when a
certain string comes from the USB, you would need to figure out how to
estimate the latency from the device to the interrupt service routine to
eliminate that, as it would jitter.

The other thing I didn't state was that I got the USB receiver out of a
discard frenzy at the place I'm working, and got it to work with a
freebe program on windows XP.  It's a Holux GM-210.

They do make an RS232 version, but I got the USB one.  It says it uses
the Sirf Star II in the document.  I suspect if one pried open the box
it would have pinouts for RS232 in the pod I have.

I suspect it was given to them as a starter kit for a project way before
I arrived.

Jim

On 11/8/2010 5:14 PM, jim s wrote: > This is probably the thousandth time this was asked, but I googled and > didn't get a direct answer. > Here is the reference to the PPS that made me make statements about RS232 http://forums.freebsd.org/showthread.php?t=16507 Here is an actual implementation using a Garmin 18LVC, which was referenced by another poster. http://time.qnan.org/ The difference between the RS-232 and the USB is that there is a wire (DCD or CTS) so you can do a precise hack if you can overcome the issues of system load, etc. Perhaps a driver patch to grab the exact system clock time in a driver when either changes would be one method, immune to system load. No way to do so as pointer out on USB. It has not only some difference depending on the number of USB hubs, but also total number of devices. Assuming you hack the USB driver to get a time hack exactly when a certain string comes from the USB, you would need to figure out how to estimate the latency from the device to the interrupt service routine to eliminate that, as it would jitter. The other thing I didn't state was that I got the USB receiver out of a discard frenzy at the place I'm working, and got it to work with a freebe program on windows XP. It's a Holux GM-210. They do make an RS232 version, but I got the USB one. It says it uses the Sirf Star II in the document. I suspect if one pried open the box it would have pinouts for RS232 in the pod I have. I suspect it was given to them as a starter kit for a project way before I arrived. Jim
MC
mike cook
Tue, Nov 9, 2010 7:57 AM

Le 09/11/2010 06:50, jim s a écrit :

The other thing I didn't state was that I got the USB receiver out of
a discard frenzy at the place I'm working, and got it to work with a
freebe program on windows XP.  It's a Holux GM-210.

They do make an RS232 version, but I got the USB one.  It says it uses
the Sirf Star II in the document.  I suspect if one pried open the box
it would have pinouts for RS232 in the pod I have.

As your original post indicated that your were not needingt a really
accurate reference, you could download the Meinberg NTP implementation
for windows XP and let that keep your clock sync'd via the NMEA stream.
Even with a USB hocky puck like yours which is really designed for PDA
navigation, you should be able to get the desired accuracy. Better
receivers can do <10ms on USB, though I cannot find the specs for your
device in the user manual.

BEWARE: you will be in the situation of a man with one watch.

Jim


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

Le 09/11/2010 06:50, jim s a écrit : > > The other thing I didn't state was that I got the USB receiver out of > a discard frenzy at the place I'm working, and got it to work with a > freebe program on windows XP. It's a Holux GM-210. > > They do make an RS232 version, but I got the USB one. It says it uses > the Sirf Star II in the document. I suspect if one pried open the box > it would have pinouts for RS232 in the pod I have. > As your original post indicated that your were not needingt a really accurate reference, you could download the Meinberg NTP implementation for windows XP and let that keep your clock sync'd via the NMEA stream. Even with a USB hocky puck like yours which is really designed for PDA navigation, you should be able to get the desired accuracy. Better receivers can do <10ms on USB, though I cannot find the specs for your device in the user manual. BEWARE: you will be in the situation of a man with one watch. > Jim > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > >
PK
Poul-Henning Kamp
Tue, Nov 9, 2010 8:18 AM

In message 201011090430.oA94UP7Y046011@stenn.ntp.org, Harlan Stenn writes:

Using USB serial introduces amusing amounts of jitter.  This is usually
not a problem for the NMEA sentences, but I wouldn't want to be
detecting the PPS signal via USB1 or USB2 serial devices.

I've heard that USB3 should be much better.  I haven't touched any of
these yet.

There is no difference, the basic poll-rate is still the same.

--
Harlan Stenn stenn@ntp.org
http://ntpforum.isc.org  - be a member!


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

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <201011090430.oA94UP7Y046011@stenn.ntp.org>, Harlan Stenn writes: >Using USB serial introduces amusing amounts of jitter. This is usually >not a problem for the NMEA sentences, but I wouldn't want to be >detecting the PPS signal via USB1 or USB2 serial devices. > >I've heard that USB3 should be much better. I haven't touched any of >these yet. There is no difference, the basic poll-rate is still the same. > >-- >Harlan Stenn <stenn@ntp.org> >http://ntpforum.isc.org - be a member! > >_______________________________________________ >time-nuts mailing list -- time-nuts@febo.com >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >and follow the instructions there. > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.