[ntp:questions] Problems with NMEA refclocks, Ublox6 GPS, on WinXP with 4.2.7p21
Darren.Long at uk.thalesgroup.com
Thu Sep 29 09:32:46 UTC 2011
> -----Original Message-----
> From: questions-bounces+darren.long=uk.thalesgroup.com at lists.ntp.org
> [mailto:questions-bounces+darren.long=uk.thalesgroup.com at lists.ntp.org]On
Behalf Of David J Taylor
> OK, Darren, but I would still like to know whether Visual GPS
> works, just
> for interest.
Yep, I've just tried Visual GPS and it works fine with the Ublox6 on WinXP
and is baudrate agnostic too.
> > I understand this to be the case, but we're operating in an
> island of
> > connectivity and have no real alternative to adopting this
> > other
> > than to not hook up the GPS to ntpd and simply set the
> system clock to
> > GPS
> > time in the background, and use the local clock as the only
> > Its
> > my arguably uneducated (I've just bought the Mills book, so
> this may
> > change)
> > guess that the alternative approach would be worse.
> Yes, if you can get GPS to work, that would be better. Any
> chance you
> could try a GPS device which is known to work such as the GPS
> 18(x) LVC or
> Sure electronics evaluation board?
That's not likely to happen in the near future, I'm afraid. However I did
lay my hands on an el-cheapo Evermore GPS puck that uses a conventional
RS-232 connection and was more than surprised that it actually worked
(kinda) with ntpd. Of course I don't mean that I didn't expect ntpd to work
in this fashion at all, but I'd got so used to failure that I nearly fell
off my chair when it worked. It was a little quirky, with ntpd apparently
seeing message splices that suggested an issue with detection of line
terminations. The output from the Evermore looked OK in my bespoke nav sw
and in putty, and in a hex editor.
So, inspired by this I resorted to adapting my bespoke nav sw (which is
required to interface to the GPS) to use a 2nd (virtual) COM port (using
com0com) to forward NMEA messages to ntpd, and that also works, seemingly
without issue. That seems to be the solution I need to resolve my problems
at work, so I'm pretty happy.
Having now shared my problems with the community, I feel that I should at
least try to properly summarise them and help reach closure, but I'll have
to do that in my spare time. I'm thinking that I should probably raise a
bug regarding the Ublox6 interface issues. I don't know how to explain the
lack of invocation of nmea_receive() with the different sources I've tried
previously or whether there is a real issue or just finger trouble on my
part (but clearly everything worked on Linux). I got as far as determining
that the call to WaitForMultipleObjects() in GetReceivedBuffers() never went
through the Io Event case before discovering my useable workaround.
> > David, your consideration of my problems is appreciated.
> Which version
> > of
> > the NTP RI are you using?
> I don't understand RI.
> I use the NTP downloads from:
> and the actual versions in use are listed at the bottom of this page:
Ah yes. I think your site is where I started on this adventure and tried
Dave Hart's build first of all, and had all the same issues so I switched to
building source from upstream to investigate.
> BTW: I'm not seeing Dave Hart's messages on the NNTP server.
I don't know about that, I'm just working with the mailing list. BTW, sorry
for the direct email yesterday. Being a noob to the list/group I wasn't
aware of the convention in this regard.
> Typically, I install the Meinberg version, and then overwrite
> the binaries
> with Dave Hart's version. I have once compiled my own with VS 2010
> Express, but I am not comfortable working in C/C++. Delphi is my
> preferred language, and one I find highly productive.
As it goes, I'm more than comfortable working with C++, but find myself
doing a fair bit of head scratching when immersed in hardcore C (especially
in the world of MS APIs).
More information about the questions