[time-nuts] ntpd not talking to gpsd

Chris Kuethe chris.kuethe at gmail.com
Wed Apr 2 22:01:09 UTC 2008


On undefined, Matthew Smith <matt at smiffytech.com> wrote:
>  OK, I think it's time for me to back-track and try to go to a 'known
>  good' setup.
>
>  Firstly, I'll dump off some NMEA data and examine it per Hal's
>  suggestion to make sure that it's not all being flagged as bad.

You can also use "cgps" to get a nice little curses console showing
your fix and satellite tracking.

>  Then, on an i386 machine (to eliminate any possible issues with the
>  SPARC system), I will try to duplicate what Chris is running.

SPARC machines do work, provided you wire them correctly - I messed up
the first couple of cables I built. I built a pair of time servers
around SunFire v120's with the GPS connected to serial port B. Here's
how I wired mine.

DB9  	RJ45  	Signal  	Direction
1 		8 		1PPS 	Data to computer
2 		3 		TXD 	Control to GPS
3 		6 		RXD 	Data to computer
5 		4 		GND 	Ground

For more about the insanity that is sun serial ports:
http://www.pccables.com/tech/sun_serial_null.html#netrat1105.link
http://www.sunhelp.org/unix-serial-port-resources/serial-pinouts/

>  Can we
>  confirm that this is just nmeaattach and the shipped ntpd with OpenBSD
>  (is that OpenNTPd) and that ntpd.conf just needs to contain:
>  listen on *
>  sensor *

Correct. nmeaattach and ntpd in base are all you need to set up a time
server. GPSD is just there for eye candy or if you need a copy of the
data coming in. You can watch the time sensor status with systat:
"systat 1 sensors".

>  I assume that any initialisation of the GPS module would need to be done
>  by an external application run before nmeaattach is called.  The VP
>  seems to come up in NMEA mode, so I'll try that first after checking the
>  data quality.

Yes, initialization functions are not the domain of nmeaattach. That's
something gpsd can do for some receivers. GPSD has a function similar
to nmeaattach, so it will also create/activate the time sensor...
(which can be monitored by systat)

>  If I am still stuck doing this with the Oncores, I'll just leave it
>  until I've got the required connectors and hook it into one of the
>  Trimbles which just 'do' NMEA on the second port without any of this
>  messing around.

That would work too. My Oncore UT+ was happy this morning, so I can
now put some love into the proper gpsd (and possibly kernel) driver.

>  Just had a thought - what NMEA sentences need to be turned on for
>  nmeaattach and gpsd to behave properly?  By default, the Oncores don't
>  put out anything much apart from satellite data.

just GPRMC. The kernel snoops the tty com port watching for GPRMC,
extracts timing data, and passes the stream on to userland. That's got
enough time and fix quality information in it to decide whether this
fix should be believed.

CK

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?




More information about the Time-nuts_lists.febo.com mailing list