On 24/08/2014 19:22, Brian Inglis wrote:
[]
PPS pulse duration is not really any concern - at 115k2bps a bit is only
9us wide
and sampling at 16x bit rate a pulse is only .5us.
The slew rate limit of 30V/us is the issue for detecting transistions.
For a typical 3V TTL signal that should take
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob,
You have seen 'flag1' in the recent ntp-dev SHM driver documentation,
right?
I have installed ntp-dev and as part of that also ntp-dev-doc, but
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
The SHM driver has existed much longer than gpsd timekeeping.
In 2005 or 2006, I added timesyncing to gpsd. Before that, it
Rob writes:
Harlan wrote:
All the time variables are fixed-point decimals in seconds - you
should be able to say 0.001 to mean a millisecond (or -0.001 if you
need to go the other direction).
Should. But:
if (pp-sloppyclockflag CLK_FLAG1)
up-max_delta = 0;
Rob writes:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
I've got a couple of folks wondering about driver46. I'll let Juergen
discuss this.
He has reasons for
On Mon, Aug 25, 2014 at 4:44 AM, Harlan Stenn st...@ntp.org wrote:
Personally, I don't
understand why we should support these devices, but apparently it's
important to some folks and perhaps I just don't understand the issue.
You have to draw the line somewhere. Perhaps the ntp developers
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Brian Inglis brian.ing...@systematicsw.ab.ca wrote:
As the SHM driver 28 dev docs say, it is the ancient way to talk to gpsd
Then that better be corrected! It is hogwash.
I've got a couple of folks wondering about driver46. I'll let Juergen
Harlan Stenn st...@ntp.org wrote:
Now I'm trying to remember another discussion where the issue is 'we
have a refclock that will give us the time but not the date.' as I
recall that has bearing on the SHM driver. Personally, I don't
understand why we should support these devices, but
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Paul wrote:
To carp yet again: you should add timepps.h to the tar ball and stick
to that. Leave the package building to the distributions. If people
want/need more current features they should learn how to build the
current dev source and you
Harlan Stenn wrote:
Rob writes:
Harlan wrote:
All the time variables are fixed-point decimals in seconds - you
should be able to say 0.001 to mean a millisecond (or -0.001 if you
need to go the other direction).
Should. But:
if (pp-sloppyclockflag CLK_FLAG1)
On Mon, Aug 25, 2014 at 12:00 PM, Martin Burnicki
martin.burni...@meinberg.de wrote:
Since current Linux kernels *do* support PPS, and timepps.h is a valid
interface to use it, does anyone know *why* timepps.h isn't in the standard
set of header files for Linux, and is never going to be?
The
11 matches
Mail list logo
