[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] NMEA time calculation question
From: |
Ed W |
Subject: |
Re: [gpsd-dev] NMEA time calculation question |
Date: |
Mon, 07 May 2012 17:58:48 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 |
Hi
My Skytraq Venus 634 and 638 at 1Hz update (with UTC sync enabled) can
work this way with a fixed latency to the start bit of the first
sentence (I think 2mS - it is perfectly consistent on my scope on the
TTL line). I don't know about other chipsets, but most don't even
have a way to do this.
Yes, I have a Venus 6 and I believe it's the same. Rumour is that the
first bit is of similar jitter to the PPS? Do you observe that on a scope?
USB 1.1 has a 1mS jitter minimum since that is the polling interval.
USB2.0 can go down to 125uS.
See my previous email - it appears that only USB2 *high* speed goes to 125uS
I don't know what the goal is, but you would need a hardware pin and
some kernel patches if you want a linux or bsd system to sync to sub
mS accuracy.
Well, I obviously didn't get my point across.
1) My jitter is slightly higher than expected. Q: is this related to
the way GPSD estimates the arrival time of the first $, ie can I make a
change to the gpsd algorithm which would give me 0.5ms precision on my
NMEA time (from venus 6 over usb)
2) *IF* not just the initial bit, but in fact if every bit of the Venus
6 output were of low jitter, then because we collect multiple
observations of the serial output via USB, then it should be possible to
improve our estimate of the arrival timestamp below the 0.5ms mark. ie
we can observe the number of characters read on each USB timestamp,
compare with our predicted number of characters we should be able to get
sub ms estimates of the arrival time of a particular character - use
that to work back and get the arrival time of the first bit. Note that
if feasible, this technique would give better accuracy than PPS over USB !
That said, an Arduino Mega with an Ethernet shield (available at radio
shack and globally, just under $100 US, cheaper if you shop) is pure
embedded so the PPS can go into an input capture and be tagged with
67nS precision (and measure and compensate for crystal accuracy), so
you can create a very accurate clock down to a few microsecnds and
there should be enough space to implement SNTP, and at 100Mbps,
Ethernet will have far less latency and jitter than USB.
Agreed. I think the goal here is to see how far one can push USB for
accuracy? For the vast majority of uses I think 0.5ms is very decent.
If we could get that into the few hundred microsec range then we almost
certainly surpass the average stratum 1.
PPS into a GPIO is the way to go for best accuracy, but don't you find
it interesting that we might be able to get into the few hundred
microsecs using only usb?
Cheers
Ed W
- [gpsd-dev] NMEA time calculation question, Ed W, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, tz, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, Jim Thompson, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question,
Ed W <=
- Re: [gpsd-dev] NMEA time calculation question, tz, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, Ed W, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, tz, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, Ed W, 2012/05/07
- Re: [gpsd-dev] NMEA time calculation question, tz, 2012/05/07
Re: [gpsd-dev] NMEA time calculation question, Gary E. Miller, 2012/05/07