Le 12 juin 2012 à 16:37, Ross T61AA a écrit :

A little detail of your issue might help. If you are using usb, I assume you are using the NMEA driver.  I don't have Lion, but 10.6. I did try out a mg1613s usb board with my MacBook and got it working with the following IIRC ( I disconnected it as I was just testing the device but that was back in 2010):

Generic NMEA driver - default is timing at last message in stream

Serial Port: /dev/gpsu; 4800 baud, 8-bits, no parity

127.127.20.x mode y  where

x is the com port number

y is the mode which is a concatenation of message selection in bits 0-3

0 = use all messsages

1  = $GPRMC  etc  see the doc.

bits 456 are the speed. value 0 = 4800, 16 = 9600,  etc

ex. mode 18 is just $GPGGA messages at 9600 bps

server 127.127.20.1 mode 18

fudge 127.127.20.1  time1 0.0 time2 0.0 stratum 8

IIRC there was a time offset due to the message end being used as timing, which can be allowed for using the time2 fudge.

On Tue, Jun 12, 2012 at 8:13 AM, mike cook michael.cook@sfr.fr wrote:

I'd expect it not to run as well on a Mac simply because these are no
serial ports on any current Mac.

But getting it running should be easy because the Mac ships with NTP
already set up and running.  All you should have to do edit the config
file.

If you already have a Linux system running at a server with a direct
connect GPS there is little need to put a GPS on the Mac because
without a good PPS signal on a serial oct you may as well use a
networked GPS server for time

Chris Albertson
Redondo Beach, California

I've used a number of different time signal
receiver devices as accurate clock sources for
NTP running on Mac systems over the last few
years.  I have been doing this sort of thing from
Mac OS X 10.3 onwards, though I have not tried
using a clock receiver on the Mac OS 10.7
machines yet.

I've used a few different WWVB receivers, as well
as a few GPS receivers.  I've been using both
Spectracom and TrueTime receivers.

The NTP software works exactly as one would
expect.  Use a recent version of the main line
NTP code and it should compile and work very
smoothly on the Mac.  I have submitted a few bugs
to the NTP team when there have been compile
issues, and these have been addressed very
quickly.

The big difficulty in using a Mac as a primary
NTP source, as has already been mentioned, is
that all the recent (e.g. in the last decade) Mac
systems do not have native serial ports.

The most common approach most people use to get
Seial on the Mac is to use USB serial ports.

These work, but due to the architecture of USB as
a polled buss, tend to have some fairly
noticeable issues with latency and jitter for any
medium to high accuracy application.  USB is not
great for time sensitive applications in general.
It can be OK, but is not great.

In personal experience Ethernet, despite some
somewhat non-deterministic latency issues,
actually seems to work much better for precision
time sensitive applications in my experience.

This experience, which has been shared with
another time nut on the list, suggests that
Ethernet to serial interfaces actually usually
work at least as well as, and usually much better
than, USB to serial interfaces.

If you don't mind 100 MS related limits to
precision, then you can probably be quite happy
with a USB to serial interface or a USB GPS
device.  I personally have used USB serial
interfaces on a Mac as a backup NTP source for
many years quite happily.  I also have a small
herd of higher accuracy (and higher precision)
dedicated NTP servers that are actually the first
line of time sources in my network.  These are
sufficiently better that I can see the USB
limitations pretty clearly.

If USB is OK for your applications, then you
should be able to get things working on a Mac
without too much trouble.

The next trick to remember is that US devices are
dynamically allocated, and NTP normally expects
to find a clock source under a specific file name
which is usually made available by making a
symbolic link.

Since the Mac tries to manage USB device node
creation dynamically this means that one usually
needs to create or update that link every time
the machine is rebooted (or has it's device tree
updated for any other reason).

Russell

At 6:04 PM -0700 2012/06/12, Chris Albertson wrote: