Re: [time-nuts] Msg to N.Z. time nuts

[M. Warner Losh]

In message: 
"Lux, James P"  writes:
: 
: 
: 
: On 5/19/09 1:15 PM, "Russell Rezaian"  wrote:
: 
: > At 12:58 PM -0700 2009/05/19, Hal Murray wrote:
: >> USB has a bad reputation, but I think it's way way overblown.  Yes, it's
: >> polled, but that polling is done in hardware and the time scale is 1 ms.  
If
: >> you are satisfied with an accuracy of a few 10s of ms, USB works fine.  The
: >> problem is the GPS unit.
: > 
: > And I can confirm that for my very un-scientific experiments I do get
: > a pretty consistent time sync around 1 MS plus or minus mark from a
: > USB serial port adapter in best case conditions.  That's with no
: > special work on a pretty stock consumer grade computer with an off
: > the shelf USB to serial port.
: > 
: 
: I would expect that the basic "frame" timing on USB (without actually
: digging out my USB documents, because I'm lazy) is on the order of 125
: microseconds (e.g. 8kHz, to support a 8ksps audio stream, just like IEEE1394
: does), but that might just be a latency jitter bound.

Well, Yes and No.

Yes, you can get frames that fast in isochronous mode, but most host
adapters have buffering and queue things up to be dealt with on ~1ms
boundaries.  And serial port modem control pin status change messages
aren't isochronous transfers.

Warner

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

Re: [time-nuts] Msg to N.Z. time nuts

[Lux, James P]

On 5/19/09 1:15 PM, "Russell Rezaian"  wrote:

> At 12:58 PM -0700 2009/05/19, Hal Murray wrote:
>> USB has a bad reputation, but I think it's way way overblown.  Yes, it's
>> polled, but that polling is done in hardware and the time scale is 1 ms.  If
>> you are satisfied with an accuracy of a few 10s of ms, USB works fine.  The
>> problem is the GPS unit.
> 
> And I can confirm that for my very un-scientific experiments I do get
> a pretty consistent time sync around 1 MS plus or minus mark from a
> USB serial port adapter in best case conditions.  That's with no
> special work on a pretty stock consumer grade computer with an off
> the shelf USB to serial port.
> 

I would expect that the basic "frame" timing on USB (without actually
digging out my USB documents, because I'm lazy) is on the order of 125
microseconds (e.g. 8kHz, to support a 8ksps audio stream, just like IEEE1394
does), but that might just be a latency jitter bound.



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

Re: [time-nuts] Msg to N.Z. time nuts

[Russell Rezaian]

At 12:58 PM -0700 2009/05/19, Hal Murray wrote:

USB has a bad reputation, but I think it's way way overblown.  Yes, it's
polled, but that polling is done in hardware and the time scale is 1 ms.  If
you are satisfied with an accuracy of a few 10s of ms, USB works fine.  The
problem is the GPS unit.


And I can confirm that for my very un-scientific experiments I do get 
a pretty consistent time sync around 1 MS plus or minus mark from a 
USB serial port adapter in best case conditions.  That's with no 
special work on a pretty stock consumer grade computer with an off 
the shelf USB to serial port.


Even my worst case machine where I expect horrible USB performance 
(busy USB 1.x port with other devices, and a CPU that runs at 100% 
busy for extended periods of time) I find I things never seem to go 
worse than +-50 ms.  Not great, but much better than I was expecting 
based on some of the things I had read.


All my tests done with a time oriented GPS receiver.
--
Russell

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

Re: [time-nuts] Msg to N.Z. time nuts

[Hal Murray]

li...@philpem.me.uk said:
> All of which are running the SiRF 3.2 firmware, so if there is a
> firmware bug  in play, they're all going to be doing much the same
> thing... 

I'm pretty sure that all the SiRF units I was watching had essentially the 
same behavior, and that included one using RS-232 without USB.


> They all use the Prolific PL2303 serial-to-USB chip.
> That might be what's causing the timing jitter, especially if there
> are other  devices on the USB bus. USB-to-serial chips aren't known
> for accurate timing  -- a few of them buffer incoming data and then
> send it over the USB bus in one  burst. 

USB has a bad reputation, but I think it's way way overblown.  Yes, it's 
polled, but that polling is done in hardware and the time scale is 1 ms.  If 
you are satisfied with an accuracy of a few 10s of ms, USB works fine.  The 
problem is the GPS unit.

I did the experiment of running one GPS unit through a splitter into a serial 
port and also into a serial-USB converter and into a USB port.  Mostly, what 
it showed was that the low-latency serial port option on that system was 
broken.  USB was much better than the serial port.  :)

Here is a graph of the offset ntpd sees from a Garmin GPS-18-USB.
  http://www.megapathdsl.net/~hmurray/ntp/GPS18USB-off.gif
peak-peak is under 20 ms so it's possible to get that sort of timing using 
USB.


The real problem with the SiRF chips (and Garmin 18x) is that there is a 
large low frequency component in the noise/jitter.  I'd call it wander rathre 
than jitter to emphasize the low frequency nature.  It's hard to filter that 
out when the clock you are trying to correct has temperature changes which 
happen much faster than that.  Typical numbers are 100 ms wander over a 
period of 12-24 hours.
  http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif

It might be fun to see if you can get good results on a box with a stable 
clock using one of these chips.  I'm thinking of a very long time constant on 
the PLL filter.  But how long?  See the old discussions about hanging 
bridges.  So maybe the goal should be to build a hanging-bridge detector.  :)



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




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

Re: [time-nuts] Msg to N.Z. time nuts

[Philip Pemberton]

Hal Murray wrote:
I started collecting low cost GPS receivers a year or two ago.  I thought I 
had some with the SiRF-II chips.  Either I can't find them or I didn't 
actually get any.


I've been "collecting" the OEM modules for about the same amount of time. That 
said, I haven't got that many -- a pair of Trimble SVeeSixes with 4.12 
firmware and an Axiom Sandpiper (SiRF2 based). I've just got a pair of Fastrax 
"iTrax" IT321 receivers, which are surface-mount (i.e. solder-down to a PCB) 
receiver modules based on the SiRF3 chipset.



  GSW3.2.4_3.1.00.12-SDK003P1.00a  GlobalSat BU-353
  GSW3.2.2_3.1.00.12-SDK003P1.01a  AmbiCom GPS-USB Rev 2.1
  GSW3.2.2_3.1.00.12-SDK003P1.01a  Navibe GM-720
  GSW3.2.4Pat2_3.1.00.12-SDK001P1.00  Navisys GR-300


All of which are running the SiRF 3.2 firmware, so if there is a firmware bug 
in play, they're all going to be doing much the same thing...



They all use the Prolific PL2303 serial-to-USB chip.


That might be what's causing the timing jitter, especially if there are other 
devices on the USB bus. USB-to-serial chips aren't known for accurate timing 
-- a few of them buffer incoming data and then send it over the USB bus in one 
burst.


That's not to say the SiRF chipset isn't the cause of the error, but it might 
not be the only variable. I'd be tempted to tie a TTL=>RS232 level translator 
to the RXD_IN pin on the PL2303, then connect the output of the translator to 
a spare 'proper' RS232 port on a PC. The timing should be far more accurate 
(though probably not fantastic).


--
Phil.
li...@philpem.me.uk
http://www.philpem.me.uk/

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

Re: [time-nuts] Msg to N.Z. time nuts

[Hal Murray]

li...@philpem.me.uk said:
>>> Interesting that the three receivers with issues were all SiRF III
>>> based. Do  you know what firmware these were running? 
 
>> Nope.  If you know the recipe to find out, I'll ask them.  :)
 
> Failing that, the "sirfmon" app that comes with gpsd might get the
> receiver  into binary mode and should let you talk to it, but I
> haven't used it. 

Thanks.  That works for me.

I started collecting low cost GPS receivers a year or two ago.  I thought I 
had some with the SiRF-II chips.  Either I can't find them or I didn't 
actually get any.

  GSW3.2.4_3.1.00.12-SDK003P1.00a  GlobalSat BU-353

  GSW3.2.2_3.1.00.12-SDK003P1.01a  AmbiCom GPS-USB Rev 2.1
  GSW3.2.2_3.1.00.12-SDK003P1.01a  Navibe GM-720

  GSW3.2.4Pat2_3.1.00.12-SDK001P1.00  Navisys GR-300

The first 3 are "GPS mice", small with long USB tails.  The last one is a 
Thumb/Dongle, only a bit bigger than the typical USB Flash drive.

They all use the Prolific PL2303 serial-to-USB chip.


In case nobody hasn't noticed, the price for simple GPS "mice" has been 
dropping.  It's easy to find them advertised for under $40.  Unfortunately, I 
haven't been able to get good time out of the USB versions.  The old Garmin 
GPS-18-USB was actually pretty good.  The new 18x isn't very good.


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




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

Re: [time-nuts] Msg to N.Z. time nuts

[Philip Pemberton]

Hal Murray wrote:

Interesting that the three receivers with issues were all SiRF III
based. Do  you know what firmware these were running? 


Nope.  If you know the recipe to find out, I'll ask them.  :)

I just scanned their NMEA documentation and didn't see any way to get it.


If memory serves, there's a $PSRF command to kick them into SiRF Binary mode, 
then you send a SiRF binary command -- "Request Version" or something like 
that. Then you get a binary response with the software type (i.e. if the 
manufacturer of the GPS board paid extra for the "enhanced navigation" 
software) and the version of that software.


To be truthful, the stuff is in the manuals (you want $PSRF100 from the SiRF 
NMEA manual, which is on www.fastraxgps.com under Products, IT321, in the 
datasheet section on the bottom right) but if you've got a Windows box around 
somewhere, it's probably easier to grab a copy of SiRF's "SiRF Demo" app and 
use that. To get the software version, plug the GPS in, select the serial port 
and connect to the module, then select Poll >> SW Version. The version number 
should appear in the "Response View".


Failing that, the "sirfmon" app that comes with gpsd might get the receiver 
into binary mode and should let you talk to it, but I haven't used it.


For reference when dealing with SiRF manuals: GSW2 = SiRFStar II, GSW3 = 
SiRFStar III.


The data gets collected on a system without PPS, but it's sitting next to a 
machine that does have PPS from a Z3801A.  So their is some noise on the 
reference time, but not much on the scale of a 100 ms that the SiRF chips 
wander over.


There is something of a subtle note in the SiRF NMEA manual 
() 
on page 1-7 (PDF p.15) under "ZDA -- Time and Date". Basically, the chip sends 
the 1PPS first, then queues a ZDA message to be sent.


I suspect there's probably some form of co-operative multitasking or RTOS 
engine running on the SiRF chip's CPU (I've been told it's an ARM 
something-or-other), which loops over a list of 'tasks' in a round-robin 
fashion. If the PPS flag gets sent (by the 1PPS loop, probably an interrupt 
driven from the correlator array, I haven't read the GPS specs but understand 
the basics) just after the flag is checked by the ZDA handler, you won't see 
another ZDA message until the loop gets back to the ZDA handler again.


So accuracy of the NMEA messages may well be pretty terrible, though as you 
said the 1PPS should be pretty good.


I expect the PPS output is still OK.  It's just that the software is off by 
one in some strange pattern when a leap second is pending.


I remember reading something about this a few days ago, but it seems to have 
dropped out of my Firefox browsing history. IIRC there were issues with the 
various navigation modes in V3.1.1, but all my Google searches are coming up 
with are some GPS user's forums and a note in the gpsd changelog from 2005.


Hmm.

--
Phil.
li...@philpem.me.uk
http://www.philpem.me.uk/

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

Re: [time-nuts] Msg to N.Z. time nuts

[Hal Murray]

li...@philpem.me.uk said:
> Interesting that the three receivers with issues were all SiRF III
> based. Do  you know what firmware these were running? 

Nope.  If you know the recipe to find out, I'll ask them.  :)

I just scanned their NMEA documentation and didn't see any way to get it.


> How are you running the comparisons -- comparing against public NTP servers?

The data gets collected on a system without PPS, but it's sitting next to a 
machine that does have PPS from a Z3801A.  So their is some noise on the 
reference time, but not much on the scale of a 100 ms that the SiRF chips 
wander over.


> I'm just curious, there's a pair of Fastrax SiRF III modules that I
> was going  to wire up for testing (and maybe use for a GPSDO), but
> your test results have  planted the seeds of doubt! 

I expect the PPS output is still OK.  It's just that the software is off by 
one in some strange pattern when a leap second is pending.



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




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

Re: [time-nuts] Msg to N.Z. time nuts

[Philip Pemberton]

Hal Murray wrote:
One case was a gross software bug.  I think it was triggered by a pending 
leap second.

  http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif


Interesting that the three receivers with issues were all SiRF III based. Do 
you know what firmware these were running?


How are you running the comparisons -- comparing against public NTP servers?

I'm just curious, there's a pair of Fastrax SiRF III modules that I was going 
to wire up for testing (and maybe use for a GPSDO), but your test results have 
planted the seeds of doubt!


Thanks,
--
Phil.
li...@philpem.me.uk
http://www.philpem.me.uk/

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

[time-nuts] Msg to N.Z. time nuts re time pips

[Murray Greenman]

Geoff,
I'm not in a position to check at present, but have also noticed
discrepancies in the time pips in the past. I'd not use a GPS receiver
for this, as they can easily indicate a second or so out. I use a GPS
Disciplined Receiver (HP Z3801A or Trimble NTGS50AA) for the job.

I suggest you talk to Dr Tim Armstrong (t.armstr...@irl.cri.nz). He's
the guy who looks after the official NZ time service, which is the
source of those time pips. The equipment is at Gracefield in a room with
three Caesium standards. He should be able to explain how the time pips
are distributed, and you may find (if you encourage him a little!) that
he is also interested in measuring their delivered accuracy as well.

Regards,

Murray ZL1BPU


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

Re: [time-nuts] Msg to N.Z. time nuts

[Hal Murray]

> I am assuming my GPS clocks I have are correct (too early here to get
> WWVH reception).

> Hoping the one second delta is not me! 


I have seen consumer grade GPS receivers be off by a second while claiming to 
be OK.

One case was a gross software bug.  I think it was triggered by a pending 
leap second.
  http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif

One was off by a second for 13 seconds just before the leap second kicked in. 
 I assume they inserted it on GPS midnight rather than UTC midnight.

The interesting cases are just off-by-a-second quirks.  I think they happen 
when the receiver is recovering from a too-weak signal.
  http://www.megapathdsl.net/~hmurray/ntp/GPS18LVC-glitch1-off.gif
  http://www.megapathdsl.net/~hmurray/ntp/GPS18LVC-glitch2-off.gif


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




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

[time-nuts] Msg to N.Z. time nuts

[Kiwi Geoff]

Att NZ Time nuts:

Normally National Radio (AM and FM) is a reasonable source of time in
New Zealand, and the time pips are normally within about 200 ms of UTC
atomic time (due to coding delays in the digital transfer of the audio
program).

However today at 11am and Noon (local time 18 May 2009) I noticed the
time pips were 1 second SLOW compared with 2 GPS timing systems I
have.

I am assuming my GPS clocks I have are correct (too early here to get
WWVH reception). National Radio uses a land line feed from the NZ
standard (atomic) clocks, so it is a little strange to have such a
large error as one second!

So if there are any time nuts in NZ, you may like to listen to the
time pips on National radio this afternoon to see if you can detect
the one second difference.

Hoping the one second delta is not me!

Regards, Geoff (Christchurch, NZ).

___
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.