Unruh wrote:
> All I was saying was that just because the time routines are capable of
> recording time with nsec precision does not mean that that accuracy of
> the clock is anywhere near that, and I have great difficulty believing
> that the accuracy is any better than usec.
You are somewhat cor
"hven...@astound.net" writes:
>On May 13, 10:25=A0am, Unruh wrote:
>> What the structure returns need have nothing to do with the accuracy.
>> Linux system calls can return a structure with nsec but the accuracy of
>> the linux clock is no better than usec.
>This has not been true since 2.6.26.
On May 13, 10:25 am, Unruh wrote:
> What the structure returns need have nothing to do with the accuracy.
> Linux system calls can return a structure with nsec but the accuracy of
> the linux clock is no better than usec.
This has not been true since 2.6.26. Linux since that time has had a
nanos
John Hasler wrote:
> David wries:
>> .. but if something only needs millisecond timing, designing for
>> nanosecond accuracy is gross over-engineering, and likely rather
>> costly.
>
> There's no real cost: just a few bytes in a data structure. Better
> to have it and never need it then to leave
David wries:
> .. but if something only needs millisecond timing, designing for
> nanosecond accuracy is gross over-engineering, and likely rather costly.
There's no real cost: just a few bytes in a data structure. Better to have
it and never need it then to leave it out and later find it necessa
Unruh wrote:
[]
> Well, I call "good" to include the design. If a car is designed so
> that
> the wheels fall off every 100 miles, no matter how closely the car
> meets
> the design, it is a bad car.
.. but if something only needs millisecond timing, designing for
nanosecond accuracy is gross ove
"David J Taylor"
writes:
>Unruh wrote:
>[]
>> Since the same machine can run Linux or BSD whose resolution is usec
>> or
>> nsec, yes, the hardware can do better. The question is how good is the
>> software in the kernel. If I do a timestamp on an event, how accurate
>> is
>> that timestamp?
>>
Unruh wrote:
[]
> Since the same machine can run Linux or BSD whose resolution is usec
> or
> nsec, yes, the hardware can do better. The question is how good is the
> software in the kernel. If I do a timestamp on an event, how accurate
> is
> that timestamp?
> Is it msec? Is it 15msec?
The precis
"David J Taylor"
writes:
>David Woolley wrote:
>> David J Taylor wrote:
>>
>>>
>>> - with operating system calls, the main clock can be read with a
>>> precision of 1 millisecond (although the ticks may be only 15
>>> milliseconds). There are higher resolution counters which can also
>>> be rea
David Woolley wrote:
> David J Taylor wrote:
>
>>
>> - with operating system calls, the main clock can be read with a
>> precision of 1 millisecond (although the ticks may be only 15
>> milliseconds). There are higher resolution counters which can also
>> be read.
>
>
> The architectural resolutio
David J Taylor wrote:
>
> - with operating system calls, the main clock can be read with a
> precision of 1 millisecond (although the ticks may be only 15
> milliseconds). There are higher resolution counters which can also be
> read.
The architectural resolution is much higher than this.
Unruh wrote:
[]
> OK, I keep forgetting. What accuracy can the clock be read on windows?
> is there an interpolation routine in the kernel so the clock can be
> read
> to usec accuracy?
> I would thin k you could set up and interrupt routine to read and
> record
> the clock time when the interrupt
"David J Taylor"
writes:
>Unruh wrote:
>> "David J Taylor"
>[]
>>> On my system, I can detect no difference between the GPS 18 and the
>>> GSP 18x. I am looking at jitters in the order of 2.2 microseconds,
>>> and offsets in the range +170/-100 microseconds.
>>
>> How are you reading the PPS in
Unruh wrote:
> "David J Taylor"
[]
>> On my system, I can detect no difference between the GPS 18 and the
>> GSP 18x. I am looking at jitters in the order of 2.2 microseconds,
>> and offsets in the range +170/-100 microseconds.
>
> How are you reading the PPS interrupts>. That offset is terrible.
"David J Taylor"
writes:
>Hal Murray wrote:
>[]
>> If anybody has figured out how to get good timing out of the
>> SiRF units, please clue me in.
>On my system, I can detect no difference between the GPS 18 and the GSP
>18x. I am looking at jitters in the order of 2.2 microseconds, and
>offs
Hal Murray wrote:
[]
> If anybody has figured out how to get good timing out of the
> SiRF units, please clue me in.
On my system, I can detect no difference between the GPS 18 and the GSP
18x. I am looking at jitters in the order of 2.2 microseconds, and
offsets in the range +170/-100 microsec
Unruh wrote:
> Yes. Do not use NMEA strings to time your system, unless you only wnat
> ms accuracy.
You use the NMEA strings to get the absolute time (to the nearest second)
and the PPS to get accurate time to the second.
The NMEA data is so variable that it can even be tricky to get to the
nea
Hal Murray wrote:
> It uses the SiRF chip set. There is no PPS. The timing
> on the NMEA strings is bad to horrible.
>
> If anybody has figured out how to get good timing out of the
> SiRF units, please clue me in.
The NMEA protcol is unsuitable for accurate timing. There often is
not even a s
hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
>In article <3uftl.5045$lc7.2...@text.news.virginmedia.com>,
> "David J Taylor"
> writes:
>>I don't know if anyone has written a driver which will suit your USB-based
>>BU353.
>The BU-353 uses one of the common serial-USB chips a
In article ,
"Richard B. Gilbert" writes:
>ISTR that there have been previous references in this newsgroup.
>Specifically, EIDE disk drivers can mask or disable interrupts for a
>period long enough to cause a "lost tick". I believe the group is
>archived somewhere. . . .
Old old old versi
In article <8001da0b-3037-491a-a4a4-7a441cff9...@13g2000yql.googlegroups.com>,
jack writes:
>Thanks again for your suggestion. It seems Garmin 18X USB can be
>tailored to only output certain messages as you said. Hopefully this
>will improve the performance. I am going to give it a try.
The USB
In article <3uftl.5045$lc7.2...@text.news.virginmedia.com>,
"David J Taylor"
writes:
>I don't know if anyone has written a driver which will suit your USB-based
>BU353.
The BU-353 uses one of the common serial-USB chips and
speaks the NMEA protocol. I expect it will work if you
just plug it
>
> My plan is to read GPS messages in my own application and use them to
> discipline a simulated software clock with Windows high performance
> counter. This way I can avoid Windows scheduling issues.
Seems to me that you want to implement your application in-process with
ntpd or equivalent.
>
Uwe Klein wrote:
> Kevin Oberman wrote:
>> To get an idea of the fanaticism involved, several years ago, Kirk
>> McKusick and my former boss here in Berkeley counted the machine cycles
>> in the FreeBSD kernel for the PPS response(all done in the interrupt
>> service routine) and used that to corre
Kevin Oberman wrote:
> To get an idea of the fanaticism involved, several years ago, Kirk
> McKusick and my former boss here in Berkeley counted the machine cycles
> in the FreeBSD kernel for the PPS response(all done in the interrupt
> service routine) and used that to correct the time. Of course,
Richard B. Gilbert wrote:
> David J Taylor wrote:
>> Richard B. Gilbert wrote:
>>> David J Taylor wrote:
David Woolley wrote:
[]
> You won't get millisecond accuracy on Windows. Although the
> software clock can be disciplined to better than a millisecond,
> applications can
> From: Dave Hart
> Date: Tue, 10 Mar 2009 08:56:14 -0700 (PDT)
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
> On Mar 10, 3:44 pm, "Richard B. Gilbert"
> wrote:
> > You might want to take a look at the work of Poul-Henning Kamp (PHK).
> > He used Soekris 4501 single board computers
On Mar 11, 8:48 pm, Augustine wrote:
>
> Is the system timer always 1024Hz?
Windows timeBeginPeriod multimedia timer resolution manipulation
accepts millisecond units, so the fastest you can crank is 1000Hz.
That's what the ntpd -M workaround does. As an aside, one Vista
machine of mine has a
On Mar 11, 3:16 am, "David J Taylor" wrote:
>
> I ask because for the last several years I have been running my Windows
> system with 1KHz timers (.e. with the MM timers enabled) and I haven't
> been aware of any particular problems. Indeed, the timekeeping with NTP
> in a "client-only" configura
David Woolley wrote:
> David J Taylor wrote:
>> David Woolley wrote:
>> []
>
>>
>> David, do you have a reference for your "risks lost ticks" statement as
>> applied to Windows?
>
> Windows has been mentioned on this newsgroup as losing ticks on many
> occasions. The fastest multi-media timers
David J Taylor wrote:
> Richard B. Gilbert wrote:
>> David J Taylor wrote:
>>> David Woolley wrote:
>>> []
You won't get millisecond accuracy on Windows. Although the
software clock can be disciplined to better than a millisecond,
applications can only read to one tick, which is 10m
Richard B. Gilbert wrote:
> David J Taylor wrote:
>> David Woolley wrote:
>> []
>>> You won't get millisecond accuracy on Windows. Although the
>>> software clock can be disciplined to better than a millisecond,
>>> applications can only read to one tick, which is 10ms by default
>>> and 1ms with
David J Taylor wrote:
> David Woolley wrote:
> []
>> You won't get millisecond accuracy on Windows. Although the software
>> clock can be disciplined to better than a millisecond, applications
>> can only read to one tick, which is 10ms by default and 1ms with the
>> fastest multi-media timers (wh
David,
My plan is to read GPS messages in my own application and use them to
discipline a simulated software clock with Windows high performance
counter. This way I can avoid Windows scheduling issues.
Now I am not sure how to get GPS messages as soon as they come in. Is
there a way to do it thro
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Martin Burnicki wrote:
>> Agreed, too. However, if we are discussing about Garmins with 50 ns
>> accuracy then 1000 ns delay is magnitudes worse.
>
> Garmins never give better than about 1000 ns, i.e. 1 us.
>>
>> Also, PPS pulses must not nece
Martin Burnicki wrote:
> Also, PPS pulses must not necessarily be used only as PPS signals for
> computers. We have also applications where just a piece of hardware is
> synchronized by a PPS signal, in which case 1 microsecond *is* relevant.
My original solution for "timely" data aquisition from
Martin Burnicki wrote:
> Agreed, too. However, if we are discussing about Garmins with 50 ns accuracy
> then 1000 ns delay is magnitudes worse.
Garmins never give better than about 1000 ns, i.e. 1 us.
>
> Also, PPS pulses must not necessarily be used only as PPS signals for
> computers. We have a
Unruh wrote:
> Martin Burnicki writes:
>
>>David Woolley wrote:
>>> Unruh wrote:
>>>
No. That is what GPS does for you. It determines your postion, then
uses that to determine the time delay from the sattelite to your
receiver.
>>>
>>> Actually, it is the other way round.
David Woolley wrote:
> David J Taylor wrote:
>> David Woolley wrote:
>> []
>
>>
>> David, do you have a reference for your "risks lost ticks" statement
>> as applied to Windows?
>
> Windows has been mentioned on this newsgroup as losing ticks on many
> occasions. The fastest multi-media timers cor
David J Taylor wrote:
> David Woolley wrote:
> []
>
> David, do you have a reference for your "risks lost ticks" statement as
> applied to Windows?
Windows has been mentioned on this newsgroup as losing ticks on many
occasions. The fastest multi-media timers correspond to the timer
frequenci
David Woolley wrote:
[]
> You won't get millisecond accuracy on Windows. Although the software
> clock can be disciplined to better than a millisecond, applications
> can only read to one tick, which is 10ms by default and 1ms with the
> fastest multi-media timers (which risks lost ticks).
David,
jack wrote:
> I cannot switch to Linux because my main application runs only on
> Windows. It would take us a long time to port to Linux.
> If I can get to millisecond accuracy, I'd be happy.
You won't get millisecond accuracy on Windows. Although the software
clock can be disciplined to better
On 2009-03-10, jack wrote:
> It seems Garmin 18X USB can be tailored to only output certain
> messages as you said. Hopefully this will improve the performance. I
> am going to give it a try.
Just keep in mind that the GPS sends the NMEA sentence(s) when it is not
busy doing other things.
--
S
David,
Thanks again for your suggestion. It seems Garmin 18X USB can be
tailored to only output certain messages as you said. Hopefully this
will improve the performance. I am going to give it a try.
To all others:
I am only trying to find the best solution given my other constraints.
Will try in
Unruh wrote:
[]
>> The newer "x" version appears to be a lot more sensitive, at the
>> expense of somewhat higher current consumption. You can tell the
>> LVC version what sentences to send. Better check the technical spec
>> to see what the USB one can be told to do:
>> http://www.garmin.com/ma
jack writes:
>Hi everyone,
>First of all, I thank you for all your response.
>I understand the best solution would be using an IRIG board and that's
>what we had been using. We are now trying to make our product more
>compact by using a small single board PC with no RS 232 or PCI slot
>(no slot
On Tue, 10 Mar 2009 09:17:58 -0700 (PDT), jack wrote:
> I cannot switch to Linux because my main application runs only on
> Windows. It would take us a long time to port to Linux.
> If I can get to millisecond accuracy, I'd be happy.
>
> Jack
>
> On Mar 10, 11:56 am, Dave Hart wrote:
>> On Mar 10,
"David J Taylor"
writes:
>jack wrote:
>> Hi everyone,
>>
>> First of all, I thank you for all your response.
>>
>> I understand the best solution would be using an IRIG board and that's
>> what we had been using. We are now trying to make our product more
>> compact by using a small single board
Martin Burnicki writes:
>David Woolley wrote:
>> Unruh wrote:
>>
>>>
>>> No. That is what GPS does for you. It determines your postion, then uses
>>> that to determine the time delay from the sattelite to your receiver.
>>
>> Actually, it is the other way round. It uses the differences in the
jack wrote:
> I cannot switch to Linux because my main application runs only on
> Windows. It would take us a long time to port to Linux.
have you looked at running under wine
or compiling a native linux app against winelib?
http://www.winehq.org/about/
uwe
___
I cannot switch to Linux because my main application runs only on
Windows. It would take us a long time to port to Linux.
If I can get to millisecond accuracy, I'd be happy.
Jack
On Mar 10, 11:56 am, Dave Hart wrote:
> On Mar 10, 3:44 pm, "Richard B. Gilbert"
> wrote:
>
> > You might want to ta
On Mar 10, 3:44 pm, "Richard B. Gilbert"
wrote:
> You might want to take a look at the work of Poul-Henning Kamp (PHK).
> He used Soekris 4501 single board computers together with a GPS receiver
> to make a highly accurate clock. This was long enough ago that most of
> the hardware he used is no
jack wrote:
> Hi everyone,
>
> First of all, I thank you for all your response.
>
> I understand the best solution would be using an IRIG board and that's
> what we had been using. We are now trying to make our product more
> compact by using a small single board PC with no RS 232 or PCI slot
> (no
jack wrote:
> Hi everyone,
>
> First of all, I thank you for all your response.
>
> I understand the best solution would be using an IRIG board and that's
> what we had been using. We are now trying to make our product more
> compact by using a small single board PC with no RS 232 or PCI slot
> (
Hi everyone,
First of all, I thank you for all your response.
I understand the best solution would be using an IRIG board and that's
what we had been using. We are now trying to make our product more
compact by using a small single board PC with no RS 232 or PCI slot
(no slot at all). Currently I
David Woolley wrote:
> Unruh wrote:
>
>>
>> No. That is what GPS does for you. It determines your postion, then uses
>> that to determine the time delay from the sattelite to your receiver.
>
> Actually, it is the other way round. It uses the differences in the
> time delays to solve for the po
Jack,
jack wrote:
> Hi all,
>
> I am trying to sync my Windows box to an external GPS source. I
> currently have BU353, whose output is not very periodic. I read up on
> ntpd implementation that uses PPS signal but I don't even have an RS
> 232 port on my computer.
>
> My questions:
> 1) what's
Unruh wrote:
[]
> How do you get the signal in now? Do you have a parallel port?
> USB is terrible. But then Windows is terrible as well, so the two
> probably are about equivalent. If you can use the PPS you can get a
> few microseconds accuracy on a Linux/BSD ssytem. I think on Windows
> you are
Unruh wrote:
>
> No. That is what GPS does for you. It determines your postion, then uses
> that to determine the time delay from the sattelite to your receiver.
Actually, it is the other way round. It uses the differences in the
time delays to solve for the position (and the actual time dela
"Richard B. Gilbert" writes:
>jack wrote:
>> Hi all,
>>
>> I am trying to sync my Windows box to an external GPS source. I
>> currently have BU353, whose output is not very periodic. I read up on
>> ntpd implementation that uses PPS signal but I don't even have an RS
>> 232 port on my computer.
Augustine writes:
>On Mar 9, 4:23=A0pm, "Richard B. Gilbert"
>wrote:
>>
>> Just about any GPS timing receiver is accurate to within about 50
>> nanoseconds using the PPS signal. =A0
>Just wondering, does one need to consider the delay that the signal
>takes to reach the receiver from the satell
On Mar 9, 8:02 pm, jack wrote:
>
> I am trying to sync my Windows box to an external GPS source. I
> currently have BU353, whose output is not very periodic. I read up on
> ntpd implementation that uses PPS signal but I don't even have an RS
> 232 port on my computer.
Google tells me that's a USB
Augustine wrote:
> On Mar 9, 4:23 pm, "Richard B. Gilbert"
> wrote:
>> Just about any GPS timing receiver is accurate to within about 50
>> nanoseconds using the PPS signal.
>
> Just wondering, does one need to consider the delay that the signal
> takes to reach the receiver from the satellite?
jack writes:
>Hi all,
>I am trying to sync my Windows box to an external GPS source. I
>currently have BU353, whose output is not very periodic. I read up on
>ntpd implementation that uses PPS signal but I don't even have an RS
>232 port on my computer.
How do you get the signal in now? Do you
jack wrote:
> Hi all,
>
> I am trying to sync my Windows box to an external GPS source. I
> currently have BU353, whose output is not very periodic. I read up on
> ntpd implementation that uses PPS signal but I don't even have an RS
> 232 port on my computer.
>
> My questions:
> 1) what's the best
On Mar 9, 4:23 pm, "Richard B. Gilbert"
wrote:
>
> Just about any GPS timing receiver is accurate to within about 50
> nanoseconds using the PPS signal.
Just wondering, does one need to consider the delay that the signal
takes to reach the receiver from the satellite?
TIA
jack wrote:
> Hi all,
>
> I am trying to sync my Windows box to an external GPS source. I
> currently have BU353, whose output is not very periodic. I read up on
> ntpd implementation that uses PPS signal but I don't even have an RS
> 232 port on my computer.
>
> My questions:
> 1) what's the bes
Hi all,
I am trying to sync my Windows box to an external GPS source. I
currently have BU353, whose output is not very periodic. I read up on
ntpd implementation that uses PPS signal but I don't even have an RS
232 port on my computer.
My questions:
1) what's the best GPS antenna (and protocol) i
68 matches
Mail list logo
