Hello all, I've been trying to set up a local NTP server on my windows workstation with a GPS as source, following David Taylor's guide here:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html

I'm using a Novatel Flexpak6 GPS and the operating system is Windows 7 x64 Professional. I've set up the GPS to transmit only GPRMC messages on com port 9 (USB3, as it appears on the terminal messages), screenshot here:

https://s10.postimg.org/6tqazjg95/terminal_msgs.png

I've tried to configure the GPS to send the messages at 4800 bauds per second, but I'm really not sure that it changed anything, as I can connect to the GPS using Realterm on port 9 with any baud rate setting and still read the GPRMC messages.

I've added the following line to the ntp.conf file:

 server 127.127.20.9 minpoll 4 prefer # NMEA Serial port

The problem I'm facing is the following - the communication that the GPS sends on COM port 9 doesn't seem to reach the NTP server, as the NTP status shows no data from the GPS:

https://s16.postimg.org/twa16orp1/gps_no_data.png

I'd appreciate any advice on how to get this setup to work.

Have a great day,
Tomer

On 14/09/2016 09:38, thetomerpeer@gmail.com wrote:
> Hello all, I've been trying to set up a local NTP server on my windows workstation with a GPS as source, following David Taylor's guide here:
> http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html
>
> I'm using a Novatel Flexpak6 GPS and the operating system is Windows 7 x64 Professional. I've set up the GPS to transmit only GPRMC messages on com port 9 (USB3, as it appears on the terminal messages), screenshot here:
>
> https://s10.postimg.org/6tqazjg95/terminal_msgs.png
>
> I've tried to configure the GPS to send the messages at 4800 bauds per second, but I'm really not sure that it changed anything, as I can connect to the GPS using Realterm on port 9 with any baud rate setting and still read the GPRMC messages.
>
> I've added the following line to the ntp.conf file:
>
>  server 127.127.20.9 minpoll 4 prefer # NMEA Serial port
>
> The problem I'm facing is the following - the communication that the GPS sends on COM port 9 doesn't seem to reach the NTP server, as the NTP status shows no data from the GPS:
>
> https://s16.postimg.org/twa16orp1/gps_no_data.png
>
> I'd appreciate any advice on how to get this setup to work.
>
> Have a great day,
> Tomer

Tomer,

Perhaps you need to configure the device to 4800 baud in the Device Manager?

If that doesn't work, perhaps try:

    server 127.127.20.9 minpoll 4 mode 1 prefer

I guess you mean $GPMRC sentences?  Or is the documentation wrong here:

   http://doc.ntp.org/4.2.6/drivers/driver20.html

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

On Wednesday, September 14, 2016 at 12:35:48 PM UTC+3, David Taylor wrote:
> On 14/09/2016 09:38, thetomerpeer@gmail.com wrote:
> > Hello all, I've been trying to set up a local NTP server on my windows workstation with a GPS as source, following David Taylor's guide here:
> > http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html
> >
> > I'm using a Novatel Flexpak6 GPS and the operating system is Windows 7 x64 Professional. I've set up the GPS to transmit only GPRMC messages on com port 9 (USB3, as it appears on the terminal messages), screenshot here:
> >
> > https://s10.postimg.org/6tqazjg95/terminal_msgs.png
> >
> > I've tried to configure the GPS to send the messages at 4800 bauds per second, but I'm really not sure that it changed anything, as I can connect to the GPS using Realterm on port 9 with any baud rate setting and still read the GPRMC messages.
> >
> > I've added the following line to the ntp.conf file:
> >
> >  server 127.127.20.9 minpoll 4 prefer # NMEA Serial port
> >
> > The problem I'm facing is the following - the communication that the GPS sends on COM port 9 doesn't seem to reach the NTP server, as the NTP status shows no data from the GPS:
> >
> > https://s16.postimg.org/twa16orp1/gps_no_data.png
> >
> > I'd appreciate any advice on how to get this setup to work.
> >
> > Have a great day,
> > Tomer
> 
> Tomer,
> 
> Perhaps you need to configure the device to 4800 baud in the Device Manager?
> 
> If that doesn't work, perhaps try:
> 
>     server 127.127.20.9 minpoll 4 mode 1 prefer
> 
> I guess you mean $GPMRC sentences?  Or is the documentation wrong here:
> 
>    http://doc.ntp.org/4.2.6/drivers/driver20.html
> 
> Cheers,
> David
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu


Thanks David, but both methods didn't change the status. Is there a way to debug NTPD to show why it doesn't communicate with the GPS?

Regarding $GPRMC, that's how it appears in that documentation:

$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf>
 
And it's called the same in the Novatel documentation as well.

Here's a ss of the ntpd run, maybe I've missed something here?:
https://s4.postimg.org/76na9robx/ntpd.png

On Wednesday, September 14, 2016 at 12:35:48 PM UTC+3, David Taylor wrote:
> On 14/09/2016 09:38, thetomerpeer@gmail.com wrote:
> > Hello all, I've been trying to set up a local NTP server on my windows workstation with a GPS as source, following David Taylor's guide here:
> > http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html
> >
> > I'm using a Novatel Flexpak6 GPS and the operating system is Windows 7 x64 Professional. I've set up the GPS to transmit only GPRMC messages on com port 9 (USB3, as it appears on the terminal messages), screenshot here:
> >
> > https://s10.postimg.org/6tqazjg95/terminal_msgs.png
> >
> > I've tried to configure the GPS to send the messages at 4800 bauds per second, but I'm really not sure that it changed anything, as I can connect to the GPS using Realterm on port 9 with any baud rate setting and still read the GPRMC messages.
> >
> > I've added the following line to the ntp.conf file:
> >
> >  server 127.127.20.9 minpoll 4 prefer # NMEA Serial port
> >
> > The problem I'm facing is the following - the communication that the GPS sends on COM port 9 doesn't seem to reach the NTP server, as the NTP status shows no data from the GPS:
> >
> > https://s16.postimg.org/twa16orp1/gps_no_data.png
> >
> > I'd appreciate any advice on how to get this setup to work.
> >
> > Have a great day,
> > Tomer
> 
> Tomer,
> 
> Perhaps you need to configure the device to 4800 baud in the Device Manager?
> 
> If that doesn't work, perhaps try:
> 
>     server 127.127.20.9 minpoll 4 mode 1 prefer
> 
> I guess you mean $GPMRC sentences?  Or is the documentation wrong here:
> 
>    http://doc.ntp.org/4.2.6/drivers/driver20.html
> 
> Cheers,
> David
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu


Thanks David, but both methods didn't change the status. Is there a way to debug NTPD to show why it doesn't communicate with the GPS? 

Regarding $GPRMC, that's how it appears in that documentation: 

$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf> 
  
And it's called the same in the Novatel documentation as well. 

Here's a ss of the ntpd run, maybe I've missed something here?: 
https://s4.postimg.org/76na9robx/ntpd.png 

On 14/09/2016 11:18, thetomerpeer@gmail.com wrote:
[]
> Thanks David, but both methods didn't change the status. Is there a way to debug NTPD to show why it doesn't communicate with the GPS?
>
> Regarding $GPRMC, that's how it appears in that documentation:
>
> $GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf>
>
> And it's called the same in the Novatel documentation as well.
>
> Here's a ss of the ntpd run, maybe I've missed something here?:
> https://s4.postimg.org/76na9robx/ntpd.png

Tomer,

I've very rarely needed to debug ntpd at that level, but I think you 
need to tell it where the configuration lives, something like:

   ntpd -n -c "C:\Tools\NTP\etc\ntp.conf"

I think the NTP documentation may be wrong on the GPS sentence name, 
that's what I was suggesting.

In normal server mode, you can use the Windows Event Viewer to see the 
messages from NTP.  Get just the messages you want by filtering for the 
source to be "NTP".

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

On Wednesday, September 14, 2016 at 7:50:49 PM UTC+3, David Taylor wrote:
> On 14/09/2016 11:18, thetomerpeer@gmail.com wrote:
> []
> > Thanks David, but both methods didn't change the status. Is there a way to debug NTPD to show why it doesn't communicate with the GPS?
> >
> > Regarding $GPRMC, that's how it appears in that documentation:
> >
> > $GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf>
> >
> > And it's called the same in the Novatel documentation as well.
> >
> > Here's a ss of the ntpd run, maybe I've missed something here?:
> > https://s4.postimg.org/76na9robx/ntpd.png
> 
> Tomer,
> 
> I've very rarely needed to debug ntpd at that level, but I think you 
> need to tell it where the configuration lives, something like:
> 
>    ntpd -n -c "C:\Tools\NTP\etc\ntp.conf"
> 
> I think the NTP documentation may be wrong on the GPS sentence name, 
> that's what I was suggesting.
> 
> In normal server mode, you can use the Windows Event Viewer to see the 
> messages from NTP.  Get just the messages you want by filtering for the 
> source to be "NTP".
> 
> Cheers,
> David
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu


The GPS responds to a command to log GPMRC with an error, so the NTP documentation must have a typo there.

I've managed to receive a new error message, after setting the GPS to output 1PPS with a negative polarity (which is supposed to be the default setting of the GPS):

15 Sep 12:24:02 ntpd[2868]: 1 ctr samples exceed +/- 976 PPM range gate

On 15/09/2016 08:28, thetomerpeer@gmail.com wrote:
> The GPS responds to a command to log GPMRC with an error, so the NTP documentation must have a typo there.
>
> I've managed to receive a new error message, after setting the GPS to output 1PPS with a negative polarity (which is supposed to be the default setting of the GPS):
>
> 15 Sep 12:24:02 ntpd[2868]: 1 ctr samples exceed +/- 976 PPM range gate

You can ignore odd individual errors like that, they are part of the old 
interpolation scheme used with Windows prior to Win-8.

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

Alright, but I still do not have a lead as to why the NTP doesn't manage to see the GPS's messages. Could this be related to the serialpps driver?

On 18/09/2016 09:40, Tomer P wrote:
> Alright, but I still do not have a lead as to why the NTP doesn't manage to see the GPS's messages. Could this be related to the serialpps driver?

Tomer,

Try without the serialpps driver first to test that theory.

Is NTP seeing the serial NMEA data from the GPS?  Is the baud rate 
correct?  Are there any messages in the Event Log from source NTP 
relating the the type 20 driver?

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

On Sunday, September 18, 2016 at 12:51:04 PM UTC+3, David Taylor wrote:
> On 18/09/2016 09:40, Tomer P wrote:
> > Alright, but I still do not have a lead as to why the NTP doesn't manage to see the GPS's messages. Could this be related to the serialpps driver?
> 
> Tomer,
> 
> Try without the serialpps driver first to test that theory.
> 
> Is NTP seeing the serial NMEA data from the GPS?  Is the baud rate 
> correct?  Are there any messages in the Event Log from source NTP 
> relating the the type 20 driver?
> 
> Cheers,
> David
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu

I think it doesn't see the NMEA data, but how can I tell for sure, besides seeing that all the fields in the ntpd status are zeros?

On 18/09/2016 14:30, Tomer P wrote:
[]
> I think it doesn't see the NMEA data, but how can I tell for sure, besides seeing that all the fields in the ntpd status are zeros?

As I already asked:

   Is the baud rate correct?

   Are there any messages in the Event Log from source NTP relating the 
the type 20 driver?

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

Tomer P schrieb:
> On Sunday, September 18, 2016 at 12:51:04 PM UTC+3, David Taylor wrote:
>> On 18/09/2016 09:40, Tomer P wrote:
>>> Alright, but I still do not have a lead as to why the NTP doesn't manage to see the GPS's messages. Could this be related to the serialpps driver?
>>
>> Tomer,
>>
>> Try without the serialpps driver first to test that theory.
>>
>> Is NTP seeing the serial NMEA data from the GPS?  Is the baud rate 
>> correct?  Are there any messages in the Event Log from source NTP 
>> relating the the type 20 driver?
>>
>> Cheers,
>> David
>> -- 
>> Cheers,
>> David
>> Web: http://www.satsignal.eu
> 
> I think it doesn't see the NMEA data, but how can I tell for sure, besides seeing that all the fields in the ntpd status are zeros?

You can try ntpq's "clockvars" (cv) command.

If the output of "ntpq -p" lists the NMEA clock in the first line of the
table you can run

ntpq -c "cv &1"

to see the clockvars for the first association. The type and amount of
output depends on the clock type, though, and I don't know what should
be expected for the NMEA diver.

Maybe you should just report the output of that command here, and maybe
also the *full* contents of your ntp.conf file.

Do you have any "restrict" lines in ntp.conf which prevent ntpd from
working?

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Sunday, September 18, 2016 at 7:20:44 PM UTC+3, David Taylor wrote:
> On 18/09/2016 14:30, Tomer P wrote:
> []
> > I think it doesn't see the NMEA data, but how can I tell for sure, besi=
des seeing that all the fields in the ntpd status are zeros?
>=20
> As I already asked:
>=20
>    Is the baud rate correct?

Honestly, I'm not sure. When I'm telling the GPS to work at a baud rate of =
4800, it replies with an [OK] message, but when I use Realterm to connect t=
o it using other baud rates (higher or lower than 4800), it connects alrigh=
t, which puzzles me. Maybe it's because it's connected through USB to the P=
C?

>    Are there any messages in the Event Log from source NTP relating the=
=20
> the type 20 driver?

When looking at the event viewer and screening it by events from the NTP as=
 source, nothing related to the type 20 driver pops up.

On Monday, September 19, 2016 at 10:25:03 AM UTC+3, Martin Burnicki wrote:
> Tomer P schrieb:
> > On Sunday, September 18, 2016 at 12:51:04 PM UTC+3, David Taylor wrote:
> >> On 18/09/2016 09:40, Tomer P wrote:
> >>> Alright, but I still do not have a lead as to why the NTP doesn't manage to see the GPS's messages. Could this be related to the serialpps driver?
> >>
> >> Tomer,
> >>
> >> Try without the serialpps driver first to test that theory.
> >>
> >> Is NTP seeing the serial NMEA data from the GPS?  Is the baud rate 
> >> correct?  Are there any messages in the Event Log from source NTP 
> >> relating the the type 20 driver?
> >>
> >> Cheers,
> >> David
> >> -- 
> >> Cheers,
> >> David
> >> Web: http://www.satsignal.eu
> > 
> > I think it doesn't see the NMEA data, but how can I tell for sure, besides seeing that all the fields in the ntpd status are zeros?
> 
> You can try ntpq's "clockvars" (cv) command.
> 
> If the output of "ntpq -p" lists the NMEA clock in the first line of the
> table you can run
> 
> ntpq -c "cv &1"
> 
> to see the clockvars for the first association. The type and amount of
> output depends on the clock type, though, and I don't know what should
> be expected for the NMEA diver.
> 
> Maybe you should just report the output of that command here, and maybe
> also the *full* contents of your ntp.conf file.
> 
> Do you have any "restrict" lines in ntp.conf which prevent ntpd from
> working?
> 
> Martin
> -- 
> Martin Burnicki
> 
> Meinberg Funkuhren
> Bad Pyrmont
> Germany

Hi Martin, I've just read your email and replied, but for the sake of online documentation, I'll answer here as well. 

When using the ntpq -c "cv &1" command, I receive this output:

associd=17175 status=00f1 15 events, clk_no_reply,
device="NMEA GPS Clock", timecode=, poll=0, noreply=20, badformat=0,
baddata=0, stratum=0, refid=GPS, flags=0

Is there a way to check what driver the ntpd program is using so I could check if the serialpps driver update didn't work?

Tomer,

Tomer P wrote:
> On Monday, September 19, 2016 at 10:25:03 AM UTC+3, Martin Burnicki wrote:
>> You can try ntpq's "clockvars" (cv) command.
>>
>> If the output of "ntpq -p" lists the NMEA clock in the first line of the
>> table you can run
>>
>> ntpq -c "cv &1"
>>
>> to see the clockvars for the first association. The type and amount of
>> output depends on the clock type, though, and I don't know what should
>> be expected for the NMEA diver.
>>
>> Maybe you should just report the output of that command here, and maybe
>> also the *full* contents of your ntp.conf file.
>>
>> Do you have any "restrict" lines in ntp.conf which prevent ntpd from
>> working?
[...]

> Hi Martin, I've just read your email and replied, but for the sake of online documentation, I'll answer here as well. 
> 
> When using the ntpq -c "cv &1" command, I receive this output:
> 
> associd=17175 status=00f1 15 events, clk_no_reply,
> device="NMEA GPS Clock", timecode=, poll=0, noreply=20, badformat=0,
> baddata=0, stratum=0, refid=GPS, flags=0

So this means the NMEA refclock driver doesn't receive an NMEA string.

> Is there a way to check what driver the ntpd program is using so I could check if the serialpps driver update didn't work?

HM, AFAIK the serialpps driver works in the same way as the original
serial driver, but I've never tried it personally.

However, I've run some tests here on a Windows 7 machine. Fed an NMEA
GPRMC sentence to COM4, with 4800/8N1. While ntpd is not running, the
terminal program "putty" shows these incoming NMEA strings:

----------------------------------------------------------------------
$GPRMC,100156.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*62
$GPRMC,100157.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*63
$GPRMC,100158.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*6C
$GPRMC,100159.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*6D
$GPRMC,100200.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*62
$GPRMC,100201.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*63
$GPRMC,100202.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*60
$GPRMC,100203.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*61
$GPRMC,100204.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*66
$GPRMC,100205.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*67
----------------------------------------------------------------------


Installed ntp-4.2.8p8 with the default options, and entered
"127.127.20.4" as server address during installation. The last part of
the IP address is "4" here since the NMEA string is actually fed into
port COM4. If a different COM port is used then the number has to be
changed accordingly.

After the ntp.conf file has been created I accepted the option to revies
/ edit the file, and appended " minpoll 4" to the "server 127.127.20.4"
line.

The resulting ntp.conf file is:

----------------------------------------------------------------------
# NTP Network Time Protocol
# **** ATTENTION ****: *You have to restart the NTP service when you
change this file to activate the changes*
# PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED
# Configuration File created by Windows Binary Distribution Installer
Rev.: 1.27  mbg
# please check http://www.ntp.org for additional documentation and
background information
# restrict access to avoid abuse of NTP for traffic amplification attacks
# see http://news.meinberg.de/244 for details
restrict default noquery nopeer nomodify notrap
restrict -6 default noquery nopeer nomodify notrap

# allow status queries and everything else from localhost
restrict 127.0.0.1
restrict -6 ::1

# if you need to allow access from a remote host, you can add lines like
this:
# restrict <IP OF REMOTE HOST>

# Use drift file
driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"

# your local system clock, could be used as a backup
# (this is only useful if you need to distribute time no matter how good
or bad it is)
#server 127.127.1.0
# but it should operate at a high stratum level to let the clients know
and force them to
# use any other timesource they may have.
#fudge 127.127.1.0 stratum 12

# Use specific NTP servers
server 127.127.20.4 minpoll 4

# End of generated ntp.conf --- Please edit this to suite your needs
----------------------------------------------------------------------


After ntpd had been started, ran the command ntpq -p -c "cv &1"
repeatedly. Immediately after ntpd was started "reach" is still 0, but
the "clockvars" already report the incoming NMEA string:

----------------------------------------------------------------------
C:\Windows\system32>ntpq -p -c "cv &1"
     remote       refid    st t when poll reach   delay   offset  jitter
========================================================================
 GPS_NMEA(4)     .GPS.      0 l    5   16    0    0.000    0.000   0.977
associd=65233 status=0011 1 event, clk_no_reply,
device="NMEA GPS Clock",
timecode="$GPRMC,100255.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*62",
poll=1, noreply=1, badformat=0, baddata=0, stratum=0, refid=GPS, flags=0
----------------------------------------------------------------------


After a few polling intervals (16 seconds each) "reach" is at "377", and
the GPS_NMEA(4) clock is flagged as system peer:

----------------------------------------------------------------------
C:\Windows\system32>ntpq -p -c "cv &1"
     remote       refid    st t when poll reach   delay   offset  jitter
========================================================================
*GPS_NMEA(4)     .GPS.      0 l    2   16  377    0.000  -150.85  56.083
associd=65233 status=0011 1 event, clk_no_reply,
device="NMEA GPS Clock",
timecode="$GPRMC,100459.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*68",
poll=9, noreply=1, badformat=0, baddata=0, stratum=0, refid=GPS, flags=0


So everything basically works well.


If it doesn't work for you then we need to find out why.

Are there any error messages from ntpd in the Windows application event
log (event viewer) after ntpd has been (re-)started?

One of your screenshots shows that a terminal program can receive the
NMEA string, so the serial driver basically seems to work. I see no
reason why ntpd should not be able to use it. A quick test showed that
the GPS_NMEA() refclock is not listed if ntpd fails to open the serial
port e.g because it's in use.

The NMEA sentence I've been using looks a little bit different than
yours. Maybe that's the problem?

Have there been any error messages when you installed the NTP software
package? Eventually you can completely uninstall and then re-install it.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On 20/09/2016 12:45, Martin Burnicki wrote:
> ...

One obvious question of more general interest:

Is the serialpps driver supposed to work with USB attached serial ports
(since those don't generate microsecond precision hardware interrupts
anyway, as far as I understand).


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

On 20/09/2016 19:14, Jakob Bohm wrote:
[]
> One obvious question of more general interest:
>
> Is the serialpps driver supposed to work with USB attached serial ports
> (since those don't generate microsecond precision hardware interrupts
> anyway, as far as I understand).
>
>
> Enjoy
>
> Jakob
================================

No, it works with "real" COM ports, ones which use the Microsoft driver. 
  It won't work with add-in COM ports which need a third-party driver.

In the source distribution there is another serial PPSAPI provider named 
"loopback" which I understand works with a wider range of serial 
drivers.  However, I'm unsure where the documentation is for this abd 
I've not used it myself.

In earlier tests, I found that even PPS over USB resulted in a lower 
jitter than Internet sources alone, but those tests were with XP and 
didn't take advantage of the finer time resolution provided by Windows-8 
and later.  You are correct that USB data is less accurate than a pure 
COM port DCD line - USB may only be sampled at an 8 kHz (125 
microsecond) rate (don't know about USB 3, though).

-- 
Cheers,
David
Web: http://www.satsignal.eu

David Taylor schrieb:
> On 20/09/2016 19:14, Jakob Bohm wrote:
> []
>> One obvious question of more general interest:
>>
>> Is the serialpps driver supposed to work with USB attached serial ports
>> (since those don't generate microsecond precision hardware interrupts
>> anyway, as far as I understand).

As David already said, I don't think serialpps works with USB-to-serial
converters.

However, in the last setup we discussed the PPS signal wasn't even used,
and the strange thing is that a terminal program receives the NMEA
string, but ntpd doesn't.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Tuesday, September 20, 2016 at 1:50:04 PM UTC+3, Martin Burnicki wrote:

> However, I've run some tests here on a Windows 7 machine. Fed an NMEA
> GPRMC sentence to COM4, with 4800/8N1. While ntpd is not running, the
> terminal program "putty" shows these incoming NMEA strings:
> 
> ----------------------------------------------------------------------
> $GPRMC,100156.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*62
> $GPRMC,100157.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*63

> The NMEA sentence I've been using looks a little bit different than
> yours. Maybe that's the problem?

A quick search on google shows that the output I'm receiving is as should be from a $GPRMC message, but the one you're getting is missing the "Magnetic variation" field.

http://aprs.gids.nl/nmea/#rmc

> After the ntp.conf file has been created I accepted the option to revies
> / edit the file, and appended " minpoll 4" to the "server 127.127.20.4"
> line.
> 
> The resulting ntp.conf file is:
> 
> ----------------------------------------------------------------------
> # NTP Network Time Protocol
> # **** ATTENTION ****: *You have to restart the NTP service when you
> change this file to activate the changes*
> # PLEASE CHECK THIS FILE CAREFULLY AND MODIFY IT IF REQUIRED
> # Configuration File created by Windows Binary Distribution Installer
> Rev.: 1.27  mbg
> # please check http://www.ntp.org for additional documentation and
> background information
> # restrict access to avoid abuse of NTP for traffic amplification attacks
> # see http://news.meinberg.de/244 for details
> restrict default noquery nopeer nomodify notrap
> restrict -6 default noquery nopeer nomodify notrap
> 
> # allow status queries and everything else from localhost
> restrict 127.0.0.1
> restrict -6 ::1
> 
> # if you need to allow access from a remote host, you can add lines like
> this:
> # restrict <IP OF REMOTE HOST>
> 
> # Use drift file
> driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
> 
> # your local system clock, could be used as a backup
> # (this is only useful if you need to distribute time no matter how good
> or bad it is)
> #server 127.127.1.0
> # but it should operate at a high stratum level to let the clients know
> and force them to
> # use any other timesource they may have.
> #fudge 127.127.1.0 stratum 12
> 
> # Use specific NTP servers
> server 127.127.20.4 minpoll 4
> 
> # End of generated ntp.conf --- Please edit this to suite your needs
> ----------------------------------------------------------------------

Our ntp.conf files are about the same I think.


> After ntpd had been started, ran the command ntpq -p -c "cv &1"
> repeatedly. Immediately after ntpd was started "reach" is still 0, but
> the "clockvars" already report the incoming NMEA string:
> 
> ----------------------------------------------------------------------
> C:\Windows\system32>ntpq -p -c "cv &1"
>      remote       refid    st t when poll reach   delay   offset  jitter
> ========================================================================
>  GPS_NMEA(4)     .GPS.      0 l    5   16    0    0.000    0.000   0.977
> associd=65233 status=0011 1 event, clk_no_reply,
> device="NMEA GPS Clock",
> timecode="$GPRMC,100255.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*62",
> poll=1, noreply=1, badformat=0, baddata=0, stratum=0, refid=GPS, flags=0
> ----------------------------------------------------------------------
> 
> 
> After a few polling intervals (16 seconds each) "reach" is at "377", and
> the GPS_NMEA(4) clock is flagged as system peer:
> 
> ----------------------------------------------------------------------
> C:\Windows\system32>ntpq -p -c "cv &1"
>      remote       refid    st t when poll reach   delay   offset  jitter
> ========================================================================
> *GPS_NMEA(4)     .GPS.      0 l    2   16  377    0.000  -150.85  56.083
> associd=65233 status=0011 1 event, clk_no_reply,
> device="NMEA GPS Clock",
> timecode="$GPRMC,100459.000,A,5158.9422,N,00913.5548,E,0.0,0.0,200916,,,A*68",
> poll=9, noreply=1, badformat=0, baddata=0, stratum=0, refid=GPS, flags=0
> 
> 
> So everything basically works well.
> 

Mine still doesn't seem to be able to recognize any data, as the timecode field is empty.

C:\Users\1>ntpq -p -c "cv &1"
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPS_NMEA(1)     .GPS.            0 l    -   16    0    0.000    0.000   0.000
associd=61839 status=00f1 15 events, clk_no_reply,
device="NMEA GPS Clock", timecode=, poll=0, noreply=87, badformat=0,
baddata=0, stratum=0, refid=GPS, flags=0


> If it doesn't work for you then we need to find out why.
> 
> Are there any error messages from ntpd in the Windows application event
> log (event viewer) after ntpd has been (re-)started?

No error messages from ntpd show up in th event viewer.

> Have there been any error messages when you installed the NTP software
> package? Eventually you can completely uninstall and then re-install it.
> 

I didn't have any error messages when installing it, but I may re-install or install it on another machine to see if it could get it to work.

I've also contacted Novatel support (the GPS manufacturers), but I still can't get it to work after the steps they listed in their email, so no change there.

Alright, I may have a lead on the cause of this issue:

When I checked which drivers are being used by the COM ports of the GPS, I saw that on my Windows 7 x64 system, it uses these two drivers:

C:\windows\system32\drivers\hddserial64.sys
C:\windows\system32\drivers\ngpsser.sys

I then tried installing the server on another machine that has a Windows 10 x64 on it. I reached the exact same problem, only on the windows 10 machine I saw that it only used the ngpsser.sys driver.

How do I force windows to use the serialpps driver for the com ports instead of these drivers?

On 21/09/2016 11:11, Tomer P wrote:
> Alright, I may have a lead on the cause of this issue:
>
> When I checked which drivers are being used by the COM ports of the GPS, I saw that on my Windows 7 x64 system, it uses these two drivers:
>
> C:\windows\system32\drivers\hddserial64.sys
> C:\windows\system32\drivers\ngpsser.sys
>
> I then tried installing the server on another machine that has a Windows 10 x64 on it. I reached the exact same problem, only on the windows 10 machine I saw that it only used the ngpsser.sys driver.
>
> How do I force windows to use the serialpps driver for the com ports instead of these drivers?

Tomer,

As those are non-standard drivers, it's very unlikely that serialpps.sys 
will work with that hardware.

But first, concentrate on getting the serial NMEA data seen by NTP.  I 
am also puzzled by the ability of a terminal emulator to see the data 
but not NTP.  Did you check the baud rate in the Device Manager, driver 
settings as I suggested?

If you insist on trying serialpps.sys, first see whether the hardware 
works with the standard Microsoft driver (serial.sys).

-- 
Cheers,
David
Web: http://www.satsignal.eu

On Wednesday, September 21, 2016 at 2:57:05 PM UTC+3, David Taylor wrote:
> On 21/09/2016 11:11, Tomer P wrote:
> > Alright, I may have a lead on the cause of this issue:
> >
> > When I checked which drivers are being used by the COM ports of the GPS, I saw that on my Windows 7 x64 system, it uses these two drivers:
> >
> > C:\windows\system32\drivers\hddserial64.sys
> > C:\windows\system32\drivers\ngpsser.sys
> >
> > I then tried installing the server on another machine that has a Windows 10 x64 on it. I reached the exact same problem, only on the windows 10 machine I saw that it only used the ngpsser.sys driver.
> >
> > How do I force windows to use the serialpps driver for the com ports instead of these drivers?
> 
> Tomer,
> 
> As those are non-standard drivers, it's very unlikely that serialpps.sys 
> will work with that hardware.
> 
> But first, concentrate on getting the serial NMEA data seen by NTP.  I 
> am also puzzled by the ability of a terminal emulator to see the data 
> but not NTP.  Did you check the baud rate in the Device Manager, driver 
> settings as I suggested?

Yes, I set it to 4800 through the port settings, but for some reason I can connect to it with any setting I input, for example, 115200.


> If you insist on trying serialpps.sys, first see whether the hardware 
> works with the standard Microsoft driver (serial.sys).

I've decided to get an RS232 to PCI-E adapter and to connect the GPS through RS232 instead of USB...

On 21/09/2016 14:25, Tomer P wrote:
> On Wednesday, September 21, 2016 at 2:57:05 PM UTC+3, David Taylor wrote:
[]
>> As those are non-standard drivers, it's very unlikely that serialpps.sys
>> will work with that hardware.
>>
>> But first, concentrate on getting the serial NMEA data seen by NTP.  I
>> am also puzzled by the ability of a terminal emulator to see the data
>> but not NTP.  Did you check the baud rate in the Device Manager, driver
>> settings as I suggested?
>
> Yes, I set it to 4800 through the port settings, but for some reason I can connect to it with any setting I input, for example, 115200.
>
>
>> If you insist on trying serialpps.sys, first see whether the hardware
>> works with the standard Microsoft driver (serial.sys).
>
> I've decided to get an RS232 to PCI-E adapter and to connect the GPS through RS232 instead of USB...

Strange you cannot connect.

I also bought a PCIe RS232 card, found it required special drivers, and 
was of no use with serialpps.sys.  If your motherboard has a COM port 
header that's likely to be a "standard" COM port and to work with 
serialpps.sys.

-- 
Cheers,
David
Web: http://www.satsignal.eu

Tomer P wrote:
> On Wednesday, September 21, 2016 at 2:57:05 PM UTC+3, David Taylor wrote:
[...]
>> But first, concentrate on getting the serial NMEA data seen by NTP.  I 
>> am also puzzled by the ability of a terminal emulator to see the data 
>> but not NTP.  Did you check the baud rate in the Device Manager, driver 
>> settings as I suggested?
> 
> Yes, I set it to 4800 through the port settings, but for some reason I can connect to it with any setting I input, for example, 115200.

If you run a terminal program with 4800 and it shows a correct NMEA
string then the device should be transmitting at that speed anyway.

I've made a debug build of ntpd available here:
https://www.meinberg.de/download/ntp/windows/ntp-4.2.8p8-ntpd-debug.zip

Please

- stop the NTP service
- go to the NTP/bin directory
- rename ntpd.exe to something different
- copy the ntpd.exe extracted from the ZIP archive here

Then "run as administrator" a cmd console and type:

ntpd -n -D 3 -c "C:\Program Files\NTP\etc\ntp.conf"

-n    means "don't start as service, stay in foreground
-D 3  specifies the debug level, a higher number gives more output
-c <path> specifies the path to your ntp.conf file

Be be sure to specify the *correct* path to your ntp.conf file.
Otherwise ntpd will not even try to read the NMEA string.

Eventually the debug output shows if a string is received, and why it
might be discarded. A higher debug level (e.g. 9) makes the output more
verbose.

>> If you insist on trying serialpps.sys, first see whether the hardware 
>> works with the standard Microsoft driver (serial.sys).
> 
> I've decided to get an RS232 to PCI-E adapter and to connect the GPS through RS232 instead of USB...

It would be interesting for us here to know if that works ...


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Wednesday, September 21, 2016 at 6:05:02 PM UTC+3, Martin Burnicki wrote:
> Tomer P wrote:
> > On Wednesday, September 21, 2016 at 2:57:05 PM UTC+3, David Taylor wrote:
> [...]
> >> But first, concentrate on getting the serial NMEA data seen by NTP.  I 
> >> am also puzzled by the ability of a terminal emulator to see the data 
> >> but not NTP.  Did you check the baud rate in the Device Manager, driver 
> >> settings as I suggested?
> > 
> > Yes, I set it to 4800 through the port settings, but for some reason I can connect to it with any setting I input, for example, 115200.
> 
> If you run a terminal program with 4800 and it shows a correct NMEA
> string then the device should be transmitting at that speed anyway.
> 
> I've made a debug build of ntpd available here:
> https://www.meinberg.de/download/ntp/windows/ntp-4.2.8p8-ntpd-debug.zip
> 
> Please
> 
> - stop the NTP service
> - go to the NTP/bin directory
> - rename ntpd.exe to something different
> - copy the ntpd.exe extracted from the ZIP archive here
> 
> Then "run as administrator" a cmd console and type:
> 
> ntpd -n -D 3 -c "C:\Program Files\NTP\etc\ntp.conf"
> 
> -n    means "don't start as service, stay in foreground
> -D 3  specifies the debug level, a higher number gives more output
> -c <path> specifies the path to your ntp.conf file
> 
> Be be sure to specify the *correct* path to your ntp.conf file.
> Otherwise ntpd will not even try to read the NMEA string.
> 
> Eventually the debug output shows if a string is received, and why it
> might be discarded. A higher debug level (e.g. 9) makes the output more
> verbose.
> 
> >> If you insist on trying serialpps.sys, first see whether the hardware 
> >> works with the standard Microsoft driver (serial.sys).
> > 
> > I've decided to get an RS232 to PCI-E adapter and to connect the GPS through RS232 instead of USB...
> 
> It would be interesting for us here to know if that works ...
> 
> 
> Martin
> -- 
> Martin Burnicki
> 
> Meinberg Funkuhren
> Bad Pyrmont
> Germany

While I'm still trying to get the serial ports expansion card to work, here's the output that the debug version of NTPD generated:

C:\Windows\system32>ntpd -n -D 3 -c "C:\tools\ntp\etc\ntp.conf"
22 Sep 16:17:07 ntpd[3896]: ntpd 4.2.8p8@1.3265-o Jun 03 11:43:40 (UTC+02:00) 20
16  (1): Starting
22 Sep 16:17:07 ntpd[3896]: Command line: ntpd -n -D 3 -c C:\tools\ntp\etc\ntp.c
onf
22 Sep 16:17:07 ntpd[3896]: Raised to realtime priority class
22 Sep 16:17:07 ntpd[3896]: Clock interrupt period 15.600 msec
22 Sep 16:17:07 ntpd[3896]: Performance counter frequency 3.328 MHz
22 Sep 16:17:07 ntpd[3896]: Windows clock precision 10.000 msec, min. slew 6.410
 ppm/s
22 Sep 16:17:07 ntpd[3896]: HZ 64.102 using 43 msec timer 23.256 Hz 64 deep
22 Sep 16:17:10 ntpd[3896]: set_process_priority: Leave priority alone: priority
_done is <2>
22 Sep 16:17:10 ntpd[3896]: proto: precision = 0.300 usec (-22)
Finished Parsing!!
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000001d0
restrict: op 1 addr :: mask :: mflags 00000000 flags 000001d0
getnetnum given ::, got ::
getnetnum given ::, got ::
restrict: op 1 addr :: mask :: mflags 00000000 flags 000001d0
getnetnum given 127.0.0.1, got 127.0.0.1
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 0000000
0
getnetnum given ::1, got ::1
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 0000
0000 flags 00000000
loop_config: item 12 freq 0.000000
create_sockets(123)
22 Sep 16:17:10 ntpd[3896]: Listen and drop on 0 v6wildcard [::]:123
created interface #0: fd=320, bfd=-1, name=v6wildcard, flags=0x81, ifindex=0, si
n=::, Disabled:
22 Sep 16:17:10 ntpd[3896]: Listen and drop on 1 v4wildcard 0.0.0.0:123
created interface #1: fd=324, bfd=-1, name=v4wildcard, flags=0x89, ifindex=0, si
n=0.0.0.0, bcast=0.0.0.0, mask=255.255.255.255, Disabled:
update_interfaces(123)
create_interface(fe80::9caf:8618:f7aa:72f%14#123)
22 Sep 16:17:10 ntpd[3896]: Listen normally on 2 Wireless Network Connection [fe
80::9caf:8618:f7aa:72f%14]:123
restrict: op 1 addr fe80::9caf:8618:f7aa:72f%14 mask ffff:ffff:ffff:ffff:ffff:ff
ff:ffff:ffff mflags 00003000 flags 00000001
created interface #2: fd=344, bfd=-1, name=Wireless Network Connection, flags=0x
11, ifindex=14, sin=fe80::9caf:8618:f7aa:72f%14, Enabled:
updating interface #2: fd=344, bfd=-1, name=Wireless Network Connection, flags=0
x11, ifindex=14, sin=fe80::9caf:8618:f7aa:72f%14, Enabled: new - created
create_interface(10.0.0.38#123)
22 Sep 16:17:10 ntpd[3896]: Listen normally on 3 Wireless Network Connection 10.
0.0.38:123
restrict: op 1 addr 10.0.0.38 mask 255.255.255.255 mflags 00003000 flags 0000000
1
created interface #3: fd=352, bfd=-1, name=Wireless Network Connection, flags=0x
19, ifindex=0, sin=10.0.0.38, bcast=10.0.0.255, mask=255.255.255.0, Enabled:
updating interface #3: fd=352, bfd=-1, name=Wireless Network Connection, flags=0
x19, ifindex=0, sin=10.0.0.38, bcast=10.0.0.255, mask=255.255.255.0, Enabled: ne
w - created
create_interface(::1#123)
22 Sep 16:17:10 ntpd[3896]: Listen normally on 4 Loopback Pseudo-Interface 1 [::
1]:123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 0000
3000 flags 00000001
created interface #4: fd=356, bfd=-1, name=Loopback Pseudo-Interface 1, flags=0x
15, ifindex=1, sin=::1, Enabled:
updating interface #4: fd=356, bfd=-1, name=Loopback Pseudo-Interface 1, flags=0
x15, ifindex=1, sin=::1, Enabled: new - created
create_interface(127.0.0.1#123)
22 Sep 16:17:10 ntpd[3896]: Listen normally on 5 Loopback Pseudo-Interface 1 127
..0.0.1:123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 0000000
1
created interface #5: fd=360, bfd=-1, name=Loopback Pseudo-Interface 1, flags=0x
15, ifindex=0, sin=127.0.0.1, mask=255.0.0.0, Enabled:
updating interface #5: fd=360, bfd=-1, name=Loopback Pseudo-Interface 1, flags=0
x15, ifindex=0, sin=127.0.0.1, mask=255.0.0.0, Enabled: new - created
create_sockets: Total interfaces = 6
io_open_sockets: maxactivefd 0
findexistingpeer_addr(127.127.20.1:123, NULL, 3, 0x1)
newpeer(127.127.20.1): using fd 360 and our addr 127.0.0.1
key_expire: at 0 associd 43557
peer_clear: at 0 next 1 associd 43557 refid INIT
common_serial_open given /dev/gps1
common_serial_open skipped to ending digits leaving 1
windows device \\.\COM1
event at 0 GPS_NMEA(1) 8011 81 mobilize assoc 43557
newpeer: 127.0.0.1->127.127.20.1 mode 3 vers 4 poll 4 4 flags 0x29 0x1 ttl 1 key
 00000000
loop_config: item 1 freq 0.000000
event at 0 0.0.0.0 c012 02 freq_set ntpd 0.000 PPM
rstclock: mu 0 state 2 poll 3 count 0
event at 0 0.0.0.0 c016 06 restart
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
refclock_transmit: at 1 127.127.20.1
event at 1 GPS_NMEA(1) 802b 8b clock_event clk_no_reply
poll_update: at 1 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16
auth_agekeys: at 1 keys 0 expired 0
timer: interface update
update_interfaces(123)
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
Received 12 bytes fd 356 in buffer 026C16A8 from ::1
receive: at 5 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 0000000
000.00000000
in process_control()
opcode 1, found command handler
read_status: ID 0
sendpkt(356, dst=::1, src=::1, ttl=-6, len=16)
Received 12 bytes fd 356 in buffer 026C0DA0 from ::1
receive: at 5 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 0000000
000.00000000
in process_control()
opcode 2, found command handler
sendpkt(356, dst=::1, src=::1, ttl=-6, len=480)
sendpkt(356, dst=::1, src=::1, ttl=-6, len=100)
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
Received 12 bytes fd 356 in buffer 026C0498 from ::1
receive: at 14 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 000000
0000.00000000
in process_control()
opcode 1, found command handler
read_status: ID 0
sendpkt(356, dst=::1, src=::1, ttl=-6, len=16)
Received 12 bytes fd 356 in buffer 026BFB90 from ::1
receive: at 14 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 000000
0000.00000000
in process_control()
opcode 2, found command handler
sendpkt(356, dst=::1, src=::1, ttl=-6, len=480)
sendpkt(356, dst=::1, src=::1, ttl=-6, len=100)
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
refclock_transmit: at 17 127.127.20.1
poll_update: at 17 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
Received 12 bytes fd 356 in buffer 026C31C0 from ::1
receive: at 23 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 000000
0000.00000000
in process_control()
opcode 1, found command handler
read_status: ID 0
sendpkt(356, dst=::1, src=::1, ttl=-6, len=16)
Received 12 bytes fd 356 in buffer 026C16A8 from ::1
receive: at 23 ::1<-::1 flags 15 restrict 000 org 0000000000.00000000 xmt 000000
0000.00000000
in process_control()
opcode 2, found command handler
sendpkt(356, dst=::1, src=::1, ttl=-6, len=480)
sendpkt(356, dst=::1, src=::1, ttl=-6, len=100)
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000
adj_systime: 0.000000000 -> 0.000000000 residual 0.000000000

On Wednesday, September 21, 2016 at 5:38:51 PM UTC+3, David Taylor wrote:
> On 21/09/2016 14:25, Tomer P wrote:
> > On Wednesday, September 21, 2016 at 2:57:05 PM UTC+3, David Taylor wrote:
> []
> >> As those are non-standard drivers, it's very unlikely that serialpps.sys
> >> will work with that hardware.
> >>
> >> But first, concentrate on getting the serial NMEA data seen by NTP.  I
> >> am also puzzled by the ability of a terminal emulator to see the data
> >> but not NTP.  Did you check the baud rate in the Device Manager, driver
> >> settings as I suggested?
> >
> > Yes, I set it to 4800 through the port settings, but for some reason I can connect to it with any setting I input, for example, 115200.
> >
> >
> >> If you insist on trying serialpps.sys, first see whether the hardware
> >> works with the standard Microsoft driver (serial.sys).
> >
> > I've decided to get an RS232 to PCI-E adapter and to connect the GPS through RS232 instead of USB...
> 
> Strange you cannot connect.
> 
> I also bought a PCIe RS232 card, found it required special drivers, and 
> was of no use with serialpps.sys.  If your motherboard has a COM port 
> header that's likely to be a "standard" COM port and to work with 
> serialpps.sys.
> 
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu

David, which GPS model are you using?

On 22/09/2016 11:22, Tomer P wrote:
[]
> findexistingpeer_addr(127.127.20.1:123, NULL, 3, 0x1)
> newpeer(127.127.20.1): using fd 360 and our addr 127.0.0.1
> key_expire: at 0 associd 43557
> peer_clear: at 0 next 1 associd 43557 refid INIT
> common_serial_open given /dev/gps1
> common_serial_open skipped to ending digits leaving 1
> windows device \\.\COM1
[]

I thought you were testing COM4?

Cheers,
David
-- 
Cheers,
David
Web: http://www.satsignal.eu

On 22/09/2016 11:23, Tomer P wrote:
[]
> David, which GPS model are you using?

I have two PCs connected to Sure GPS evaluation boards, and a couple 
connected to Garmin - one shared GPS 18 LVC and one GPS 18x LVC.  The 
second shared output on the GPS 18 LVC goes to the COM port of a Linux 
box.  I've also used a Chinese NEO 6M module with an older Compaq 
Windows system.  In almost all cases it's been a 3-wire connection 
between GPS and PC (TX to PC, PPS to PC, ground), just needed the TX 
when updating the 18x firmware.

-- 
Cheers,
David
Web: http://www.satsignal.eu

Tomer P wrote:
> While I'm still trying to get the serial ports expansion card to work, here's the output that the debug version of NTPD generated:
> 
[...]
> findexistingpeer_addr(127.127.20.1:123, NULL, 3, 0x1)
> newpeer(127.127.20.1): using fd 360 and our addr 127.0.0.1
> key_expire: at 0 associd 43557
> peer_clear: at 0 next 1 associd 43557 refid INIT
> common_serial_open given /dev/gps1
> common_serial_open skipped to ending digits leaving 1
> windows device \\.\COM1
> event at 0 GPS_NMEA(1) 8011 81 mobilize assoc 43557
> newpeer: 127.0.0.1->127.127.20.1 mode 3 vers 4 poll 4 4 flags 0x29 0x1 ttl 1 key
>  00000000

The output above looks like you are now using COM1. Is that correct?

[...]
> refclock_transmit: at 1 127.127.20.1
> event at 1 GPS_NMEA(1) 802b 8b clock_event clk_no_reply
> poll_update: at 1 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16

[...]
> refclock_transmit: at 17 127.127.20.1
> poll_update: at 17 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16

Normally I'd expect at least some debug messages from the NMEA refclock
driver here, but there aren't any. So it really looks like nothing is
received from the serial port. :-(

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Thursday, September 22, 2016 at 5:30:05 PM UTC+3, Martin Burnicki wrote:
> Tomer P wrote:
> > While I'm still trying to get the serial ports expansion card to work, here's the output that the debug version of NTPD generated:
> > 
> [...]
> > findexistingpeer_addr(127.127.20.1:123, NULL, 3, 0x1)
> > newpeer(127.127.20.1): using fd 360 and our addr 127.0.0.1
> > key_expire: at 0 associd 43557
> > peer_clear: at 0 next 1 associd 43557 refid INIT
> > common_serial_open given /dev/gps1
> > common_serial_open skipped to ending digits leaving 1
> > windows device \\.\COM1
> > event at 0 GPS_NMEA(1) 8011 81 mobilize assoc 43557
> > newpeer: 127.0.0.1->127.127.20.1 mode 3 vers 4 poll 4 4 flags 0x29 0x1 ttl 1 key
> >  00000000
> 
> The output above looks like you are now using COM1. Is that correct?
> 
> [...]
> > refclock_transmit: at 1 127.127.20.1
> > event at 1 GPS_NMEA(1) 802b 8b clock_event clk_no_reply
> > poll_update: at 1 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16
> 
> [...]
> > refclock_transmit: at 17 127.127.20.1
> > poll_update: at 17 127.127.20.1 poll 4 burst 0 retry 0 head 0 early 2 next 16
> 
> Normally I'd expect at least some debug messages from the NMEA refclock
> driver here, but there aren't any. So it really looks like nothing is
> received from the serial port. :-(
> 
> Martin
> -- 
> Martin Burnicki
> 
> Meinberg Funkuhren
> Bad Pyrmont
> Germany


On Thursday, September 22, 2016 at 4:55:06 PM UTC+3, David Taylor wrote:
> On 22/09/2016 11:22, Tomer P wrote:
> []
> > findexistingpeer_addr(127.127.20.1:123, NULL, 3, 0x1)
> > newpeer(127.127.20.1): using fd 360 and our addr 127.0.0.1
> > key_expire: at 0 associd 43557
> > peer_clear: at 0 next 1 associd 43557 refid INIT
> > common_serial_open given /dev/gps1
> > common_serial_open skipped to ending digits leaving 1
> > windows device \\.\COM1
> []
> 
> I thought you were testing COM4?
> 
> Cheers,
> David
> -- 
> Cheers,
> David
> Web: http://www.satsignal.eu


I've tried COM4 but then switched to COM1, didn't really change much :)

I am using a Navisys GR-8013W USB GPS on Windows 10.  It is made with a
u-blox 8 GPS and a PL-2303 Serial to USB converter wired in such a way that
PPS is provided through USB.  Unless the manufacturer goes out of their way
to do this, then I would not expect PPS to make it through a serial to USB
converter.

Since the PL-2303 Windows driver is ser2pl64.sys rather than serial.sys,
there is no hope for serialpps.sys to be used.

However, a link provided by Martin in a post from a while back made
reference to a "loopback" driver which is part of the standard NTP
distribution upon which Meinberg creates a Windows build.  I am successfully
using this driver.
PPSAPI_DLLS=loopback-ppsapi-provider.dll

Since the driver is USB 1.1, you cannot do better than +/- 1 ms.

I used a u-blox demonstration utility to see the GPS output.  I have not
experienced GPS output that does not make it to NTPD.  I get no output until
a fix, of course, which can be seen when the red light dims once per second.


The GR-8013W does not make it through a reboot unless the GPS mouse USB is
unplugged and plugged back in.  It shows up as COM3.  Since the settings are
not retained when unplugged, I use the factory default 9600 baud and NMEA
sentence GPRMC which is output first.

C:\Users\Daniel>ntpq -p
     remote           refid      st t when poll reach   delay   offset 
     jitter
==============================================================================
 north-america.p .POOL.          16 p    -   64    0    0.000    0.000  
 0.000
oGPS_NMEA(3)     .GPS.            0 l   44   64  377    0.000    0.143  
0.247
+167.88.117.204  108.76.168.145   2 u  131  128  377   48.424   -1.747  
5.039
*helium.constant 128.59.0.245     2 u   53   64  377   31.167   -0.898  
5.825
+149.56.35.206   24.150.203.150   2 u   31   64  377   41.678   -1.753  
2.104
+159.203.31.244  24.150.203.150   2 u  243  128  376   46.281   -2.971  
4.463
+a1.pcloud.com   18.26.4.105      2 u  121  128  377   68.232   -2.685  
3.716
+orchid.sidereal 200.98.196.212   2 u   47   64  377   31.179   -0.380  
3.708
+sanction.trebor 192.5.41.209     2 u    9   64  377   57.413   -6.486  
1.502
+ec2-52-6-160-3. 209.51.161.238   2 u   18   64  377   27.803    2.535  
1.640

Early error messages show up in the Windows Application event log before
NTPD switches to the logfile in ntp.conf.

Below is the ntp.conf:
#
driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
leapfile "C:\Program Files (x86)\NTP\etc\leap-seconds.list" #
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
logfile "C:\Program Files (x86)\NTP\etc\ntp.log"
#
restrict default limited kod nomodify notrap nopeer noquery # restrictive
default IPv4
restrict -6 default limited kod nomodify notrap nopeer noquery # restrictive
default IPv6
restrict source nomodify notrap # required for pool directive to work if
using restrictive default permissions
restrict 127.0.0.1 # permissive localhost IPv4
restrict -6 ::1 # permissive localhost IPv6
#
pool north-america.pool.ntp.org iburst
server 127.127.20.3 iburst mode 17 # NMEA GPRMC  9600 Baud  NaviSys GR-8013W
fudge 127.127.20.3 time1 0.000 time2 0.111 flag1 1 flag2 1 # No PPS offset,
0.111 NMEA offset, enable PPS, pulse on falling edge
#
enable stats
statsdir "C:\Program Files (x86)\NTP\etc\"
statistics loopstats
filegen loopstats  file loopstats  type week enable
#

Something I noticed when debugging configuration changes was that ntpd would
be locked out of the GPS data if I was looking at it with the u--blox
utility.  And vice versa was true as well.  The u-blox utility was locked
out of the GPS data if ntpd was running.

On Friday, September 23, 2016 at 8:35:00 PM UTC+3, Dan Gearty wrote:
> Something I noticed when debugging configuration changes was that ntpd would
> be locked out of the GPS data if I was looking at it with the u--blox
> utility.  And vice versa was true as well.  The u-blox utility was locked
> out of the GPS data if ntpd was running.

Yeah, that happens with Realterm as well, ports get locked.

On 23/09/2016 18:34, Dan Gearty wrote:
> Something I noticed when debugging configuration changes was that ntpd would
> be locked out of the GPS data if I was looking at it with the u--blox
> utility.  And vice versa was true as well.  The u-blox utility was locked
> out of the GPS data if ntpd was running.

Only one program at a time can access the serial port.

There's a COM0COM project:

   http://com0com.sourceforge.net/

which allows programs to talk to each over over an emulated virtual 
null-modem, perhaps a program in the suite can also be used to 
distribute a single COM port to multiple programs (on a read-only basis 
for most).

There is also:

   http://gpsgate.com/products/gpsgate_client
   http://www.franson.com/gpsgate/franson-gpsgate-whitepaper.htm

which allows a GPS to talk to several programs at once.  I have a free 
version (2.6.0.402) and I think that's still available - ah, now called: 
"GpsGate Splitter Express" which allows one GPS to talk to two devices. 
My install file appears to be 2,594,735 bytes, and I don't see the two 
device limitation.  Don't know whether it accepts serial in, though, 
mines working from a Garmin USB source (in Windows-10).

-- 
Cheers,
David
Web: http://www.satsignal.eu

Alright, so after a short pause, I've finally got it working.

I purchased a Gold Touch PCI-E To RS232 Serial 2-Ports Controller Card and installed it into the PC. Now, When connected with a null modem cable to the Novatel GPS, I finally see data incoming from the GPS and the NTP status is updating.

Next step would be to get the 1PPS enabled.