[Thumbgps-devel] Fwd: Long term SiRF data

[Thumbgps-devel] Fwd: Long term SiRF data

[Dave Taht]

I can't remember if I had shared this already.


---------- Forwarded message ----------
From: Hal Murray <hmurray@megapathdsl.net>
Date: Tue, Oct 25, 2011 at 2:58 AM
Subject: Long term SiRF data
To: Eric Raymond <esr@thyrsus.com>
Cc: Hal Murray <hmurray@megapathdsl.net>, Dave Taht
<dave.taht@gmail.com>, Jim Getty <jg@freedesktop.org>, Gary Miller
<gem@rellim.com>



I've been collecting data from 2 SiRF units.  I'm up to about 12 days now.

Quick summary: both suck.

Both are located inside my house, poor conditions.


The first is a Holux GR-213.  It's setup to only send GPRMC sentences.
That's what I would use with ntpd.

Here is the startup:
 http://www.megapathdsl.net/~hmurray/bb/gps/Holux-1.png

The green marks are "good" sentences.  The Y offset is the difference between
the actual arrival time and the time stamp in the sentence.  The blue marks
are the fraction part of the time stamp in the sentence.  The red marks are
invalid sentences.

At about -2.94 (hours) the reported time jumped by 1 second.  My guess is
that it learned about the latest leap second or something like that.

At about -2.82 hours, the fractional part of the report switched to 0.  I
have no idea what caused that.  It doesn't really matter much.  It wasn't
useful anyway.

Here is the big picture:
 http://www.megapathdsl.net/~hmurray/bb/gps/Holux-2.png
There is a mode shift every 1-3 days.  What's the right term?

For reference, here is an old graph with the mode shift every 8-12 hours.
 http://www.megapathdsl.net/~hmurray/bb/gps/SiRF-GPRMC-4800.png

This is the previous 2 pictures glued together:
 http://www.megapathdsl.net/~hmurray/bb/gps/Holux-3.png

Here is one day:
 http://www.megapathdsl.net/~hmurray/bb/gps/Holux-4.png

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

The second unit is a Global Sat BU-353.  It ignored my attempts to change the
configuration, so I let it run in the default setup.  Normally it sends
GPGGA, GPGSA, and GPRMC.  Every 5 seconds it includes 3 GPGSV sentences
before the GPRMC.  I think that fits in 1 second at 4800 baud, but the GPRMC
gets pushed over to the next second.

Here is the graph for the GPGGA sentences:
 http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga.png
The long term cycle time is 8-10 days.

Here is the graph for the GPRMC sentences:
 http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gprmc.png
The top band of green is the data that gets pushed over to the next second.
The blue and purple are the number of satellites.  (They are scaled up by
100.)  I don't see any pattern.

This unit doesn't always return 000 for the fraction part of the time stamp.
Sometimes it's 998 or 999 with the previous second.
 http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga-off.png



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





-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Ron Frazier (NTP)]

Hi all,

(I'd like to cross post this message, including the original message 
below to the NTP questions list since we've been discussing this nmea 
wandering effect.  Let me know if there are any objections.)
(Please forward this to the original sender of the first message if needed.)

I've been seeing similar wandering of the NMEA output on my BU-353. 
  This graph shows what looks like the internet servers (colored lines) 
wandering off while my pc is locked to gps time (dark jaggy baseline). 
  I suppose it's actually the GPS wandering off.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Can someone please tell me, if known, why this happens?  I've been 
discussing this a good bit on the NTP questions list.  On my particular 
home network / internet connection, my offsets to internet servers with 
NTP running run about + / - 50 ms.  I've decided to use the BU-353 GPS 
anyway, since in the short term, my offsets are + / - 6 ms or so, even 
if over days, my time varies + / - 70 ms from UTC.  At least the 
variations are not every 15 minutes like they would be if I was polling 
the internet.  I hope to shortly have a Sure Electronics GPS board and 
will be testing that.  David Taylor, on the NTP questions list says the 
same NMEA wandering has been observed on the Garmin 18 ??.  I'm not sure 
which model that was.

Here's how to reprogram th BU-353.  Lots of the support stuff is here:

http://www.usglobalsat.com/s-122-bu-353-support.aspx

However, the program we need is not.  To program the unit, you need 
SirfDemo.

First check out the FAQ here:

http://www.usglobalsat.com/store/gpsfacts/bu353_gps_facts.html

And you can find a link to SirfDemo here:

http://www.usglobalsat.com/downloads/setupSiRFDemoV387.zip

Unzip and install SirfDemo.  Do the following to reprogram the BU-353. 
  I assume other SirfIII units are similar.  SirfDemo gives you access 
to a HUGE number of internal GPS functions, probably enough to really 
screw up the device if you're not careful.  You can also do factory 
restarts, etc., from the menus.

a) Shut down NTP, GPSD, or any other thing attached to the GPS virtual 
com port.
b) Start SirfDemo.
c) A Data Source window will pop up.  Select the com port and data rate 
that the GPS is currently set to.  If the baud rate is unknown, try 4800 
then try to connect, then 9600, etc.  If the com port is unknown, look 
in the Windows control panel, system, device manager under ports com and 
lpt to determine which com port is active.
d) Under the view menu, turn on the Signal, Radar, Map, Messages 
Response, Messages Error, and Messages Debug windows if not on already.
e) Click the 5th toolbar button, which is connect to data source.
f) If the unit is outputting NMEA data, that should appear in the debug 
window.  If it is outputting satellite data, you'll get that in the 
signal and radar windows.
g) Under the Action menu, select switch to SIRF protocol.  The NMEA data 
will stop and the response window will start outputting data.
h) Under the Action menu, select switch to NMEA protocol.
i) A parameter selection window will pop up.  This allows the sentence 
output to be customized.  Using the drop down boxes, put a 1 in every 
sentence you want to occur once per second.  Put a 2 for once every 2 
seconds, etc.  Put a 0 if you don't want the sentence to appear at all. 
  You can click in the first number field, type a number, and tab to the 
rest if you like.  I leave checksums turned on.  Select your baud rate, 
then click send.
j) The response view windows should stop updating and the debug view 
should start up again with NMEA sentences.
k) Click the 5th toolbar button again which will disconnect you from the 
GPS.
l) Close SirfDemo.
m) You are now ready to resume using the GPS with NTP as normal.

There are many many other options you can choose from the menu options 
of SirfDemo, including a factory reset, should you need it.

Hope this helps.

Sincerely,

Ron


> I can't remember if I had shared this already.
>
>
> ---------- Forwarded message ----------
> From: Hal Murray<hmurray@megapathdsl.net>
> Date: Tue, Oct 25, 2011 at 2:58 AM
> Subject: Long term SiRF data
> To: Eric Raymond<esr@thyrsus.com>
> Cc: Hal Murray<hmurray@megapathdsl.net>, Dave Taht
> <dave.taht@gmail.com>, Jim Getty<jg@freedesktop.org>, Gary Miller
> <gem@rellim.com>
>
>
>
> I've been collecting data from 2 SiRF units.  I'm up to about 12 days now.
>
> Quick summary: both suck.
>
> Both are located inside my house, poor conditions.
>
>
> The first is a Holux GR-213.  It's setup to only send GPRMC sentences.
> That's what I would use with ntpd.
>
> Here is the startup:
>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-1.png
>
> The green marks are "good" sentences.  The Y offset is the difference between
> the actual arrival time and the time stamp in the sentence.  The blue marks
> are the fraction part of the time stamp in the sentence.  The red marks are
> invalid sentences.
>
> At about -2.94 (hours) the reported time jumped by 1 second.  My guess is
> that it learned about the latest leap second or something like that.
>
> At about -2.82 hours, the fractional part of the report switched to 0.  I
> have no idea what caused that.  It doesn't really matter much.  It wasn't
> useful anyway.
>
> Here is the big picture:
>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-2.png
> There is a mode shift every 1-3 days.  What's the right term?
>
> For reference, here is an old graph with the mode shift every 8-12 hours.
>   http://www.megapathdsl.net/~hmurray/bb/gps/SiRF-GPRMC-4800.png
>
> This is the previous 2 pictures glued together:
>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-3.png
>
> Here is one day:
>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-4.png
>
> -------------
>
> The second unit is a Global Sat BU-353.  It ignored my attempts to change the
> configuration, so I let it run in the default setup.  Normally it sends
> GPGGA, GPGSA, and GPRMC.  Every 5 seconds it includes 3 GPGSV sentences
> before the GPRMC.  I think that fits in 1 second at 4800 baud, but the GPRMC
> gets pushed over to the next second.
>
> Here is the graph for the GPGGA sentences:
>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga.png
> The long term cycle time is 8-10 days.
>
> Here is the graph for the GPRMC sentences:
>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gprmc.png
> The top band of green is the data that gets pushed over to the next second.
> The blue and purple are the number of satellites.  (They are scaled up by
> 100.)  I don't see any pattern.
>
> This unit doesn't always return 000 for the fraction part of the time stamp.
> Sometimes it's 998 or 999 with the previous second.
>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga-off.png
>
>
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.
>
>
>
>
>
>    

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Ron Frazier (NTP)]

PS to my prior message.  The following should reset the GPS's NMEA 
offset from UTC to it's initial point.  I don't know how varying 
satellite view affects this.  Shut down NTP, unplug the GPS for 30 
seconds, replug the GPS, wait 30 seconds, restart NTP.

Sincerely,

Ron


> Hi all,
>
> (I'd like to cross post this message, including the original message 
> below to the NTP questions list since we've been discussing this nmea 
> wandering effect.  Let me know if there are any objections.)
> (Please forward this to the original sender of the first message if 
> needed.)
>
> I've been seeing similar wandering of the NMEA output on my BU-353. 
>  This graph shows what looks like the internet servers (colored lines) 
> wandering off while my pc is locked to gps time (dark jaggy baseline). 
>  I suppose it's actually the GPS wandering off.
>
> http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg
>
> Can someone please tell me, if known, why this happens?  I've been 
> discussing this a good bit on the NTP questions list.  On my 
> particular home network / internet connection, my offsets to internet 
> servers with NTP running run about + / - 50 ms.  I've decided to use 
> the BU-353 GPS anyway, since in the short term, my offsets are + / - 6 
> ms or so, even if over days, my time varies + / - 70 ms from UTC.  At 
> least the variations are not every 15 minutes like they would be if I 
> was polling the internet.  I hope to shortly have a Sure Electronics 
> GPS board and will be testing that.  David Taylor, on the NTP 
> questions list says the same NMEA wandering has been observed on the 
> Garmin 18 ??.  I'm not sure which model that was.
>
> Here's how to reprogram th BU-353.  Lots of the support stuff is here:
>
> http://www.usglobalsat.com/s-122-bu-353-support.aspx
>
> However, the program we need is not.  To program the unit, you need 
> SirfDemo.
>
> First check out the FAQ here:
>
> http://www.usglobalsat.com/store/gpsfacts/bu353_gps_facts.html
>
> And you can find a link to SirfDemo here:
>
> http://www.usglobalsat.com/downloads/setupSiRFDemoV387.zip
>
> Unzip and install SirfDemo.  Do the following to reprogram the BU-353. 
>  I assume other SirfIII units are similar.  SirfDemo gives you access 
> to a HUGE number of internal GPS functions, probably enough to really 
> screw up the device if you're not careful.  You can also do factory 
> restarts, etc., from the menus.
>
> a) Shut down NTP, GPSD, or any other thing attached to the GPS virtual 
> com port.
> b) Start SirfDemo.
> c) A Data Source window will pop up.  Select the com port and data 
> rate that the GPS is currently set to.  If the baud rate is unknown, 
> try 4800 then try to connect, then 9600, etc.  If the com port is 
> unknown, look in the Windows control panel, system, device manager 
> under ports com and lpt to determine which com port is active.
> d) Under the view menu, turn on the Signal, Radar, Map, Messages 
> Response, Messages Error, and Messages Debug windows if not on already.
> e) Click the 5th toolbar button, which is connect to data source.
> f) If the unit is outputting NMEA data, that should appear in the 
> debug window.  If it is outputting satellite data, you'll get that in 
> the signal and radar windows.
> g) Under the Action menu, select switch to SIRF protocol.  The NMEA 
> data will stop and the response window will start outputting data.
> h) Under the Action menu, select switch to NMEA protocol.
> i) A parameter selection window will pop up.  This allows the sentence 
> output to be customized.  Using the drop down boxes, put a 1 in every 
> sentence you want to occur once per second.  Put a 2 for once every 2 
> seconds, etc.  Put a 0 if you don't want the sentence to appear at 
> all.  You can click in the first number field, type a number, and tab 
> to the rest if you like.  I leave checksums turned on.  Select your 
> baud rate, then click send.
> j) The response view windows should stop updating and the debug view 
> should start up again with NMEA sentences.
> k) Click the 5th toolbar button again which will disconnect you from 
> the GPS.
> l) Close SirfDemo.
> m) You are now ready to resume using the GPS with NTP as normal.
>
> There are many many other options you can choose from the menu options 
> of SirfDemo, including a factory reset, should you need it.
>
> Hope this helps.
>
> Sincerely,
>
> Ron
>
>
>> I can't remember if I had shared this already.
>>
>>
>> ---------- Forwarded message ----------
>> From: Hal Murray<hmurray@megapathdsl.net>
>> Date: Tue, Oct 25, 2011 at 2:58 AM
>> Subject: Long term SiRF data
>> To: Eric Raymond<esr@thyrsus.com>
>> Cc: Hal Murray<hmurray@megapathdsl.net>, Dave Taht
>> <dave.taht@gmail.com>, Jim Getty<jg@freedesktop.org>, Gary Miller
>> <gem@rellim.com>
>>
>>
>>
>> I've been collecting data from 2 SiRF units.  I'm up to about 12 days 
>> now.
>>
>> Quick summary: both suck.
>>
>> Both are located inside my house, poor conditions.
>>
>>
>> The first is a Holux GR-213.  It's setup to only send GPRMC sentences.
>> That's what I would use with ntpd.
>>
>> Here is the startup:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-1.png
>>
>> The green marks are "good" sentences.  The Y offset is the difference 
>> between
>> the actual arrival time and the time stamp in the sentence.  The blue 
>> marks
>> are the fraction part of the time stamp in the sentence.  The red 
>> marks are
>> invalid sentences.
>>
>> At about -2.94 (hours) the reported time jumped by 1 second.  My 
>> guess is
>> that it learned about the latest leap second or something like that.
>>
>> At about -2.82 hours, the fractional part of the report switched to 
>> 0.  I
>> have no idea what caused that.  It doesn't really matter much.  It 
>> wasn't
>> useful anyway.
>>
>> Here is the big picture:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-2.png
>> There is a mode shift every 1-3 days.  What's the right term?
>>
>> For reference, here is an old graph with the mode shift every 8-12 
>> hours.
>>   http://www.megapathdsl.net/~hmurray/bb/gps/SiRF-GPRMC-4800.png
>>
>> This is the previous 2 pictures glued together:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-3.png
>>
>> Here is one day:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/Holux-4.png
>>
>> -------------
>>
>> The second unit is a Global Sat BU-353.  It ignored my attempts to 
>> change the
>> configuration, so I let it run in the default setup.  Normally it sends
>> GPGGA, GPGSA, and GPRMC.  Every 5 seconds it includes 3 GPGSV sentences
>> before the GPRMC.  I think that fits in 1 second at 4800 baud, but 
>> the GPRMC
>> gets pushed over to the next second.
>>
>> Here is the graph for the GPGGA sentences:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga.png
>> The long term cycle time is 8-10 days.
>>
>> Here is the graph for the GPRMC sentences:
>>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gprmc.png
>> The top band of green is the data that gets pushed over to the next 
>> second.
>> The blue and purple are the number of satellites.  (They are scaled 
>> up by
>> 100.)  I don't see any pattern.
>>
>> This unit doesn't always return 000 for the fraction part of the time 
>> stamp.
>> Sometimes it's 998 or 999 with the previous second.
>>   http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga-off.png
>>
>>
>>
>> -- 
>> These are my opinions, not necessarily my employer's.  I hate spam.
>>
>>
>>
>>
>>
>

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Patrick Maupin]

On Sat, Mar 17, 2012 at 9:42 AM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> (I'd like to cross post this message, including the original message below
> to the NTP questions list since we've been discussing this nmea wandering
> effect.  Let me know if there are any objections.)

I don't know why there would be.  But perhaps you can forward any
interesting replies.

> I've been seeing similar wandering of the NMEA output on my BU-353.  This
> graph shows what looks like the internet servers (colored lines) wandering
> off while my pc is locked to gps time (dark jaggy baseline).  I suppose it's
> actually the GPS wandering off.

I've been making some progress on building a replicable device
suitable for fairly accurate short term timing.  I think the
capabilities required have been shrinking as things like reports of
300 us jitter come in, but I still think it would be extremely useful
to have a device (a) that we can have a few of and (b) that can be
used to validate timing variations from other devices and as a check
on the system clock and (c) that isn't a $100K piece of lab equipment.

So the simplest goal is to make a highly accurate oscillator that you
can hook to your PC that generates USB interrupts like the USB.  If it
"wanders" like the GPS, then, well, it's probably your PC, perhaps
losing time under heavy load or something.

The next goal is to be able to timestamp external events (e.g. from a
1pps pin) to even more accurately determine the intrinsic jitter.  As
part of this, the jitter from the USB chip can be measured fairly
automagically.

There are lots of OCXO and rubidium timing standards on places like
ebay.  Most are used, pulled from service for some reason, and reside
in China.  I found a cache of new OCXO oscillators in the US that
aren't the absolute best, but the specs seem pretty good for my
purposes:

OHM4048052GG010020-26.0M

http://pletronics.com/files/index.php/ohm4%205.0v.pdf

Accuracy is 100 ppb over entire temperature range and 100 ppb over any
power variations.  Short term accuracy (defined as: pick a pulse, and
then pick another pulse that should happen between 0.1s and 30 s
later, and measure the actual elapsed time vs. expected time, where
"expected time" is not the nominal frequency, but rather the long-term
measured frequency) is within 0.5 ppb.  If you can't figure out where
your jitter's coming from with that sort of accuracy, you're doing
something horribly wrong.

I found a discussion of these OCXOs in the timenuts mailing list
archives -- people seem happy with them, and he was selling them for
$2 last year.  They're a bit more now, but the guy apparently still
has lots of these and they're much cheaper than any other new OCXOs
around.

It's an oddball frequency, so my guess is somebody had a custom build
done and then didn't build as many units as they were anticipating,
and the price stays low because people building frequency standards
usually want 10 MHz, not 26 MHz.  Anyway, wanting to make sure that I
had a cheaply replicable device for a reasonable number of units, I
bought 10 of them for under $4 each.

Unlike people who want a stable, accurate 10 MHz signal in their lab,
we want stable, controllable USB interrupts.  Absolute accuracy is not
all that important, because if the signal is long-term stable, you can
easily figure out the real frequency.  The actual frequency of the
crystal is not important to us for the same reason.

The main downside of this OCXO from my perspective is that it is 5
volts, and I want to build a self-contained bus-powered USB unit for
it, and USB 5 volts is not very stable or accurate, so I will need to
build a boost converter followed by a linear LDO to get a more
accurate voltage source.  I've done some research on the components
for this and will probably try to lay out a board by next weekend.

The primary other components are USB and an FPGA.  I'm initially
planning on making 3 of these boards, and ease of assembly is higher
on my priority list than low cost, so I am planning on using modules
for the USB and FPGA.

I will probably go with an FTDI high speed USB module -- the UM232H is
readily available.  For the FPGA, there's a company that has been
around awhile but has been uncompetitive for a long time, but that has
recently refreshed its product line, and now has a nice cheap open
source design:

http://xess.com/prods/prod048.php

They specialize in Windows, but all the microcontroller and driver
code is open source and someone did a Python script that uses PyUSB
for programming it.  I'm sure we could transfer timestamp info through
the PIC USB device it has on it, but I'm not interested in learning
that at this point, and it's only full-speed and I'm sure we can get
better resolution with a high speed device, so I will go ahead and
build a board that can accept the FTDI module.  I've ordered a couple
of these as well.

So far the design looks like this:

$20 FTDI UM232H module
$55 Xess FPGA module
$35 PCB (each for qty 3)
$ 3 OCXO
$ 7 estimated precision power supply for xtal
$ 5 estimated other components for xtal (tuning voltage, level shifter)
$20 estimated misc connectors, etc.
-------
$140

So if all goes well, in around three weeks, for under $500, I should
have three precision timing devices that we can ship around as needed,
and reprogram the FPGA on to give us whatever info we want.  They will
be usable both as a stable time base, and to be able to timestamp
external events, such as 1pps pulses, start of character data, end of
character data, etc.

Start of character data is useful because, for example, if a given
chipset outputs data at a known location in the second, and we can set
the latency timer to 0, then we will know by when the first character
comes out what time it is.  As esr points out, it may be difficult to
know whether this is accurate or not in the field, but as others point
out, this might be determinable via examining vendor-specific strings.

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Ron Frazier (NTP)]

On 3/17/2012 12:56 PM, Patrick Maupin wrote:
> On Sat, Mar 17, 2012 at 9:42 AM, Ron Frazier (NTP)
> <timekeepingntplist@c3energy.com>  wrote:
>    
>> (I'd like to cross post this message, including the original message below
>> to the NTP questions list since we've been discussing this nmea wandering
>> effect.  Let me know if there are any objections.)
>>      
> I don't know why there would be.  But perhaps you can forward any
> interesting replies.
>
>    
>> I've been seeing similar wandering of the NMEA output on my BU-353.  This
>> graph shows what looks like the internet servers (colored lines) wandering
>> off while my pc is locked to gps time (dark jaggy baseline).  I suppose it's
>> actually the GPS wandering off.
>>      
> I've been making some progress on building a replicable device
> suitable for fairly accurate short term timing.  I think the
> capabilities required have been shrinking as things like reports of
> 300 us jitter come in, but I still think it would be extremely useful
> to have a device (a) that we can have a few of and (b) that can be
> used to validate timing variations from other devices and as a check
> on the system clock and (c) that isn't a $100K piece of lab equipment.
>
> So the simplest goal is to make a highly accurate oscillator that you
> can hook to your PC that generates USB interrupts like the USB.  If it
> "wanders" like the GPS, then, well, it's probably your PC, perhaps
> losing time under heavy load or something.
>
>    

I don't know what all your design criteria are, but for just the little 
piece of the problem you mentioned above, you could try something like 
this.  Take the output of one of those OCXO's, which I think you said is 
26 Mhz.  If I'm doing my math right, run that through a 15 bit counter 
to divide it down.  The output should be a very accurate 793.457 Hz 
square wave.  You could, of course add more bits to divide further.  You 
could also add some glue logic to reset the counter at any point you 
wanted, to get less ugly output frequencies.  Take that 793 Hz square 
wave and feed it into one of the handshaking pins, like DCD, on any 
Prolific or FTDI based serial - usb converter that passes handshaking.  
I have a Trendnet TU-S9 unit which I hope to be testing soon.  This 
should give you very consistent USB messages coming from the converter 
with a period of about 1.2 ms.

Sincerely,

Ron

> The next goal is to be able to timestamp external events (e.g. from a
> 1pps pin) to even more accurately determine the intrinsic jitter.  As
> part of this, the jitter from the USB chip can be measured fairly
> automagically.
>
> There are lots of OCXO and rubidium timing standards on places like
> ebay.  Most are used, pulled from service for some reason, and reside
> in China.  I found a cache of new OCXO oscillators in the US that
> aren't the absolute best, but the specs seem pretty good for my
> purposes:
>
> OHM4048052GG010020-26.0M
>
> http://pletronics.com/files/index.php/ohm4%205.0v.pdf
>
> Accuracy is 100 ppb over entire temperature range and 100 ppb over any
> power variations.  Short term accuracy (defined as: pick a pulse, and
> then pick another pulse that should happen between 0.1s and 30 s
> later, and measure the actual elapsed time vs. expected time, where
> "expected time" is not the nominal frequency, but rather the long-term
> measured frequency) is within 0.5 ppb.  If you can't figure out where
> your jitter's coming from with that sort of accuracy, you're doing
> something horribly wrong.
>
> I found a discussion of these OCXOs in the timenuts mailing list
> archives -- people seem happy with them, and he was selling them for
> $2 last year.  They're a bit more now, but the guy apparently still
> has lots of these and they're much cheaper than any other new OCXOs
> around.
>
> It's an oddball frequency, so my guess is somebody had a custom build
> done and then didn't build as many units as they were anticipating,
> and the price stays low because people building frequency standards
> usually want 10 MHz, not 26 MHz.  Anyway, wanting to make sure that I
> had a cheaply replicable device for a reasonable number of units, I
> bought 10 of them for under $4 each.
>
> Unlike people who want a stable, accurate 10 MHz signal in their lab,
> we want stable, controllable USB interrupts.  Absolute accuracy is not
> all that important, because if the signal is long-term stable, you can
> easily figure out the real frequency.  The actual frequency of the
> crystal is not important to us for the same reason.
>
> The main downside of this OCXO from my perspective is that it is 5
> volts, and I want to build a self-contained bus-powered USB unit for
> it, and USB 5 volts is not very stable or accurate, so I will need to
> build a boost converter followed by a linear LDO to get a more
> accurate voltage source.  I've done some research on the components
> for this and will probably try to lay out a board by next weekend.
>
> The primary other components are USB and an FPGA.  I'm initially
> planning on making 3 of these boards, and ease of assembly is higher
> on my priority list than low cost, so I am planning on using modules
> for the USB and FPGA.
>
> I will probably go with an FTDI high speed USB module -- the UM232H is
> readily available.  For the FPGA, there's a company that has been
> around awhile but has been uncompetitive for a long time, but that has
> recently refreshed its product line, and now has a nice cheap open
> source design:
>
> http://xess.com/prods/prod048.php
>
> They specialize in Windows, but all the microcontroller and driver
> code is open source and someone did a Python script that uses PyUSB
> for programming it.  I'm sure we could transfer timestamp info through
> the PIC USB device it has on it, but I'm not interested in learning
> that at this point, and it's only full-speed and I'm sure we can get
> better resolution with a high speed device, so I will go ahead and
> build a board that can accept the FTDI module.  I've ordered a couple
> of these as well.
>
> So far the design looks like this:
>
> $20 FTDI UM232H module
> $55 Xess FPGA module
> $35 PCB (each for qty 3)
> $ 3 OCXO
> $ 7 estimated precision power supply for xtal
> $ 5 estimated other components for xtal (tuning voltage, level shifter)
> $20 estimated misc connectors, etc.
> -------
> $140
>
> So if all goes well, in around three weeks, for under $500, I should
> have three precision timing devices that we can ship around as needed,
> and reprogram the FPGA on to give us whatever info we want.  They will
> be usable both as a stable time base, and to be able to timestamp
> external events, such as 1pps pulses, start of character data, end of
> character data, etc.
>
> Start of character data is useful because, for example, if a given
> chipset outputs data at a known location in the second, and we can set
> the latency timer to 0, then we will know by when the first character
> comes out what time it is.  As esr points out, it may be difficult to
> know whether this is accurate or not in the field, but as others point
> out, this might be determinable via examining vendor-specific strings.
>
>    

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Patrick Maupin]

On Sat, Mar 17, 2012 at 1:04 PM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> I don't know what all your design criteria are, but for just the little
> piece of the problem you mentioned above, you could try something like this.
>  Take the output of one of those OCXO's, which I think you said is 26 Mhz.
>  If I'm doing my math right, run that through a 15 bit counter to divide it
> down.  The output should be a very accurate 793.457 Hz square wave.  You
> could, of course add more bits to divide further.  You could also add some
> glue logic to reset the counter at any point you wanted, to get less ugly
> output frequencies.  Take that 793 Hz square wave and feed it into one of
> the handshaking pins, like DCD, on any Prolific or FTDI based serial - usb
> converter that passes handshaking.  I have a Trendnet TU-S9 unit which I
> hope to be testing soon.  This should give you very consistent USB messages
> coming from the converter with a period of about 1.2 ms.

I'm not a huge fan of discrete logic, and I'm buying reasonable sized
FPGAs, so we don't need to do really fancy stuff to get count values
that we want.  It will be dead easy.  In fact, my thought was that the
system could tell it what frequency it wanted to be interrupted.
Sometimes you might want to monitor things closely, other times just
run minimal interrupts in the background.

Also, I can send characters to the host with fairly precise timing
(the parallel mode of the FTDI has a SIWU pin that you can assert to
empty the buffer to the host), so I thought I could send a counter to
the host, so you'd never get "lost".  I can also send timestamps for
external events, if we hook it up to other hardware.

BTW, the FPGA can internally multiply the clock up to around 200 MHz,
with only around 300 ps of jitter, so I can interrupt at pretty much
whatever really precise rate we want.

For work designs, I usually pick a clock rate around 130 MHz or so as
a nice balance -- 7.5 ns gives you close timing, and you can still get
plenty of gates between flops without violating timing.  At work I'm
usually using something like 8.192 MHz * 16 = 131.072 MHz, but with a
26 MHz crystal, I'll just use 26 * 5 = 130.000 MHz.

I've used the parallel mode of the FTDI chip a lot, and I can transfer
data between the FTDI and the FPGA at an equivalent baud rate > 30
MBaud, so we can have pretty tight tolerances there as well.

So the whole thing should be pretty flexible.

Regards,
Pat

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[tz]

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[Ron Frazier (NTP)]

This message showed up empty, or did I miss something?

Ron

On 3/17/2012 5:58 PM, tz wrote:
>
>    

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Fwd: Long term SiRF data

[tz]

I was composing in gmail but didn't want to send but hit tab then
return - which moved to the send and activated it.  Sorry

On Sat, Mar 17, 2012 at 7:02 PM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> This message showed up empty, or did I miss something?

Re: [Thumbgps-devel] [ntp:questions] Fwd: Long term SiRF data / NMEA Wandering

[Ron Frazier (NTP)]

Cross posting to the thumbgps-devel list.

Ron


On 3/17/2012 3:45 PM, Charles Elliott wrote:
> I program the BU-353 with regular C++.  I have a copy of the "SiRF NMEA
> Reference Manual" (P/N: 1050-0042, Rev 2.2, 11/08) that I received from
>
> SiRF Technology, Inc.
> 217 Devcon Drive
> San Jose, CA 95112
> PH: +1(408) 467-0410
> support@SiRF.com.
>
> It contains descriptions of all the NMEA messages SiRF supports (both input
> and output) and many of the SiRF proprietary messages.
>
> If SiRF is not forthcoming with another copy, I could try scanning it and
> posting it on Windows Live.  It is fairly long, so please let me know if you
> need it.
>
> Charles Elliott
>
>    
>> -----Original Message-----
>> From: questions-bounces+elliott.ch=verizon.net@lists.ntp.org
>> [mailto:questions-bounces+elliott.ch=verizon.net@lists.ntp.org] On
>> Behalf Of Ron Frazier (NTP)
>> Sent: Saturday, March 17, 2012 2:49 PM
>> To: questions@lists.ntp.org
>> Subject: [ntp:questions] Fwd: Long term SiRF data / NMEA Wandering
>>
>> Hi all,
>>
>> This is a cross post from the [Thumbgps-devel] list.  It relates to
>> some testing on some SIRF GPS's the original poster is doing (at the
>> bottom).
>>    The part on top is my reply to him.  I thought those here might like
>> to see it, considering recent GPS related discussions we've been
>> having.
>>
>> Sincerely,
>>
>> Ron
>>
>> -----------------
>>
>> Hi all,
>>
>> I've been seeing similar wandering of the NMEA output on my BU-353.
>> This graph shows what looks like the internet servers (colored lines)
>> wandering off while my pc is locked to gps time (dark jaggy baseline).
>> I suppose it's actually the GPS wandering off.
>>
>> http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg
>>
>> Can someone please tell me, if known, why this happens?  I've been
>> discussing this a good bit on the NTP questions list.  On my particular
>> home network / internet connection, my offsets to internet servers with
>> NTP running run about + / - 50 ms.  I've decided to use the BU-353 GPS
>> anyway, since in the short term, my offsets are + / - 6 ms or so, even
>> if over days, my time varies + / - 70 ms from UTC.  At least the
>> variations are not every 15 minutes like they would be if I was polling
>> the internet.  I hope to shortly have a Sure Electronics GPS board and
>> will be testing that.  David Taylor, on the NTP questions list says the
>> same NMEA wandering has been observed on the Garmin 18 ??.  I'm not
>> sure which model that was.
>>
>> Here's how to reprogram th BU-353.  Lots of the support stuff is here:
>>
>> http://www.usglobalsat.com/s-122-bu-353-support.aspx
>>
>> However, the program we need is not.  To program the unit, you need
>> SirfDemo.
>>
>> First check out the FAQ here:
>>
>> http://www.usglobalsat.com/store/gpsfacts/bu353_gps_facts.html
>>
>> And you can find a link to SirfDemo here:
>>
>> http://www.usglobalsat.com/downloads/setupSiRFDemoV387.zip
>>
>> Unzip and install SirfDemo.  Do the following to reprogram the BU-353.
>> I assume other SirfIII units are similar.  SirfDemo gives you access to
>> a HUGE number of internal GPS functions, probably enough to really
>> screw up the device if you're not careful.  You can also do factory
>> restarts, etc., from the menus.
>>
>> a) Shut down NTP, GPSD, or any other thing attached to the GPS virtual
>> com port.
>> b) Start SirfDemo.
>> c) A Data Source window will pop up.  Select the com port and data rate
>> that the GPS is currently set to.  If the baud rate is unknown, try
>> 4800 then try to connect, then 9600, etc.  If the com port is unknown,
>> look in the Windows control panel, system, device manager under ports
>> com and lpt to determine which com port is active.
>> d) Under the view menu, turn on the Signal, Radar, Map, Messages
>> Response, Messages Error, and Messages Debug windows if not on already.
>> e) Click the 5th toolbar button, which is connect to data source.
>> f) If the unit is outputting NMEA data, that should appear in the debug
>> window.  If it is outputting satellite data, you'll get that in the
>> signal and radar windows.
>> g) Under the Action menu, select switch to SIRF protocol.  The NMEA
>> data will stop and the response window will start outputting data.
>> h) Under the Action menu, select switch to NMEA protocol.
>> i) A parameter selection window will pop up.  This allows the sentence
>> output to be customized.  Using the drop down boxes, put a 1 in every
>> sentence you want to occur once per second.  Put a 2 for once every 2
>> seconds, etc.  Put a 0 if you don't want the sentence to appear at all.
>>    You can click in the first number field, type a number, and tab to
>> the rest if you like.  I leave checksums turned on.  Select your baud
>> rate, then click send.
>> j) The response view windows should stop updating and the debug view
>> should start up again with NMEA sentences.
>> k) Click the 5th toolbar button again which will disconnect you from
>> the GPS.
>> l) Close SirfDemo.
>> m) You are now ready to resume using the GPS with NTP as normal.
>>
>> There are many many other options you can choose from the menu options
>> of SirfDemo, including a factory reset, should you need it.
>>
>> Hope this helps.
>>
>> Sincerely,
>>
>> Ron
>>
>>
>>      
>>> I can't remember if I had shared this already.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Hal Murray<hmurray@megapathdsl.net>
>>> Date: Tue, Oct 25, 2011 at 2:58 AM
>>> Subject: Long term SiRF data
>>> To: Eric Raymond<esr@thyrsus.com>
>>> Cc: Hal Murray<hmurray@megapathdsl.net>, Dave Taht
>>> <dave.taht@gmail.com>, Jim Getty<jg@freedesktop.org>, Gary Miller
>>> <gem@rellim.com>
>>>
>>>
>>>
>>> I've been collecting data from 2 SiRF units.  I'm up to about 12 days
>>>        
>> now.
>>      
>>> Quick summary: both suck.
>>>
>>> Both are located inside my house, poor conditions.
>>>
>>>
>>> The first is a Holux GR-213.  It's setup to only send GPRMC
>>>        
>> sentences.
>>      
>>> That's what I would use with ntpd.
>>>
>>> Here is the startup:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/Holux-1.png
>>>
>>> The green marks are "good" sentences.  The Y offset is the difference
>>> between the actual arrival time and the time stamp in the sentence.
>>> The blue marks are the fraction part of the time stamp in the
>>> sentence.  The red marks are invalid sentences.
>>>
>>> At about -2.94 (hours) the reported time jumped by 1 second.  My
>>>        
>> guess
>>      
>>> is that it learned about the latest leap second or something like
>>>        
>> that.
>>      
>>> At about -2.82 hours, the fractional part of the report switched to
>>>        
>> 0.
>>      
>>> I have no idea what caused that.  It doesn't really matter much.  It
>>> wasn't useful anyway.
>>>
>>> Here is the big picture:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/Holux-2.png
>>> There is a mode shift every 1-3 days.  What's the right term?
>>>
>>> For reference, here is an old graph with the mode shift every 8-12
>>>        
>> hours.
>>      
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/SiRF-GPRMC-4800.png
>>>
>>> This is the previous 2 pictures glued together:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/Holux-3.png
>>>
>>> Here is one day:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/Holux-4.png
>>>
>>> -------------
>>>
>>> The second unit is a Global Sat BU-353.  It ignored my attempts to
>>> change the configuration, so I let it run in the default setup.
>>> Normally it sends GPGGA, GPGSA, and GPRMC.  Every 5 seconds it
>>> includes 3 GPGSV sentences before the GPRMC.  I think that fits in 1
>>> second at 4800 baud, but the GPRMC gets pushed over to the next
>>>        
>> second.
>>      
>>> Here is the graph for the GPGGA sentences:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga.png
>>> The long term cycle time is 8-10 days.
>>>
>>> Here is the graph for the GPRMC sentences:
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gprmc.png
>>> The top band of green is the data that gets pushed over to the next
>>>        
>> second.
>>      
>>> The blue and purple are the number of satellites.  (They are scaled
>>>        
>> up
>>      
>>> by
>>> 100.)  I don't see any pattern.
>>>
>>> This unit doesn't always return 000 for the fraction part of the time
>>>        
>> stamp.
>>      
>>> Sometimes it's 998 or 999 with the previous second.
>>>    http://www.megapathdsl.net/~hmurray/bb/gps/BU-353-gpgga-off.png
>>>
>>>
>>>
>>> --
>>> These are my opinions, not necessarily my employer's.  I hate spam.
>>>
>>>
>>> questions mailing list
>>> questions@lists.ntp.org
>>> http://lists.ntp.org/listinfo/questions
>>>        

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com