On 07/30/19 03:48, Jakob Bohm wrote:
On 29/07/2019 09:21, Maze wrote:
On Friday, November 27, 2009 at 7:39:06 PM UTC+3:30, jack wrote:
Hi all,
After reading Dave Hart's message, I realized that I didn't configure
the GPS device to only emit $GPRMC messages. After doing this, the NTP
software starts to function. So that's big progress for me.
Right now, I am using:
server 127.127.20.1 minpoll 4 prefer
server 127.127.22.1 minpoll 4
NTPStatus shows that it's syncing to PPS(1) although the offset and
jitter are still quite big (-3ms and 0.2ms respectively).
I tried the following combination but the offset actually increased.
server 127.127.20.1 minpoll 4 prefer
fudge 127.127.20.1 flag1 1
Right now I am trying to figure out how to switch to kernel mode. I
have
1) serialpps.sys
2) the correspond DLL
3) the environment variable that points to the DLL
I am unclear as to what should be done to switch to kernel mode.
Thanks to all for the help.
Jack
On Nov 27, 9:12 am, jack <j.jack.w...@gmail.com> wrote:
David,
You assumed right. I did start with a USB emulated port. The GPS I
bought is from U-Blox and it has both USB and serial output. The
serial output has the 1PPS signal (with an LED indicator). I thought I
would start with the USB output since it's rather hard to find a
computer with a serial port. Also I would like to see the accuracy by
using the USB port only. I later switched to a machine with a serial
port and started using the serial output of the U-Blox GPS device and
1PPS. My objective is to use two of these devices to sync two separate
computers to within ms so they can share time-sensitive data (time
stamped).
I left the device running overnight and I noticed it computed an
offset at one time. It's currently not updating (everything is zero
now). I will read carefully what Dave Hart said and follow his advice.
Thanks to everyone for your help.
Jack
On Nov 27, 1:51 am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-part.co.uk.invalid> wrote:
"jack" <> wrote in message
news:9db25657-9837-4ebe-ab32-ce15ae968...@j35g2000vbl.googlegroups.com...
David,
I only have the following in the configure file:
server 127.127.20.1 minpoll 4 prefer
I found the following entry in the log file:
Using user-mode PPS timestamp
Does it mean NTP reads the GPS strings and sees the 1PPS signal?
All the values are still 0 including reach. At one point for about 10
minutes, I saw some values after rebooting the machine but they
disappeared quickly.
Thanks.
jack
ps: I am using the latest NTP from Dave Hart's website. I also
installed serialpps.sys.
Jack,
As Dave Hart has answered you are talking to the expert in this area!
I had assumed in my first response that you had a GPS receiver with a
serial output connected to a serial-USB convertor, but I see now
that this
may not be the case. How well the PPS output is emulated in the
USB-serial port software you will need to check. You need somehow to
"connect" the PPS output from the GPS to the virtual DCD line of the
emulated COM1 port. Not quite sure how you do that. What GPS and
software are you using
Cheers,
David
Dear Jack.
I am doing the same as you do with ubloc evaluation kit(neo-m8t). but
i still have problem. I see in u-center that there are lots of ubx
messages which I'm not sure whether make any problem in ntp or not. i
configured ublox chip to just send $GPRMC among NMEA messages but i
couldn't disable sending ubx messages.
i am in a hurry .could you please help me make this working??
Thanks.
Maze
USB-to-RS-232 converters generally completely loose the precision timing
abilities of traditional serial port circuits (a 16550 or equivalent
chip connected to the main CPU bus like in the serial adapters for the
original 1981 IBM PC).
This is because the standard for USB-to-RS-232 is all about transferring
the data over an essentially "polled" USB 1.1/2.0 bus that polls once
per ms, with the conversion chip buffering stuff until the next
available 1ms USB frame. This is sufficient for talking to stuff like
modems and machine control serial ports.
Wiring GPS PPS signals to the modem control line inputs on a serial port
was a trick to get access to the near-instantaneous CPU interrupt line
that was indirectly wired to those lines on the old IBM PC serial ports.
To transfer precision time over USB would be much better done by a
special specification where the USB device reports when the PPS instant
happened relative to the USB frame pulses from the computer, such as a
special NMEA message stating "Time was 2019-07-30 01:35:36.12345678 at
the USB frame marker right before the first char of this message was
sent on the USB BUS", combined with a USB driver extension reporting the
exact computer HPET time of the frame containing a "serial" character
bundle. An NTP driver for USB could then tell the ntp daemon that
"time was 2019-07-30 01:35:36.12345678 at local time 2019-07-30
01:25:36.12345876" . Each of these messages would of cause be encoded
in protocol-appropriate ways.
As a transitional solution for such a technique, one could use an
enhanced USB-to-RS-232 adapter including a timestamp in its reporting of
"modem-control" inputs, such as "CD line went high 2.3456ms before the
start of this USB frame" (because it happened 0.3456ms before a frame,
but 2 frames were busy). An appropriate USB protocol format would be a
20 bit count of 48MHz USB "full speed" typical USB interface clocks
between the reported event and the leading edge SOF of the frame
containing the report, internally an adapter can do this with a 16 bit
hardware timer and software adding 48000 for each frame of additional
delay. A host-side driver could combine this with the USB frame number
reported by the USB host controller to get time relative to the USB host
controllers clocking, and an extensions to the USB controller driver
could report the local clock time of every 1000th USB frame as a
queryable statistic.
Incorporating these things into a variation of the USB Communications
Class protocol and drivers is left as an exercise for the maker
community, for example some MicroChip inc microcontrollers have the
hardware to implement the proposed timestamping.
Enjoy
Jakob
I would not expect real time performance from any usb device, especially
with the wide range of usb to serial devices on the market, none of
which were designed for this class of precision work and none of which
are likely have specified delays.
Seems to me a better plan would be to find a gps module or receiver
with a serial interface and interface to that. New GPS modules are cheap
as chips on Ebay and elsewhere and so are s/h gps boxes, so why make
life difficult ?...
Chris
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
