Re: [time-nuts] eBay Ublox
Yep. You are right. May help only in the serial data... And irrelevant.
Doc
On 11/21/2012 06:24 AM, David J Taylor wrote:
I only use gpsd on the Linux system, and then only because it was the
first thing I discovered when searching with Google. As the precise
timing is from the PPS signal fed to the GPIO pin, with a GPIO interrupt
handler, I am forced to use that. I don't think the interrupt handler
talks to the gpsd at all, but I might be wrong. There is no DCD line on
the Raspberry Pi for gpsd to receive the PPS signal.
What you have is probably better than the typical RS-232 DCD line.
Ultimately it's doing the same thing with mostly the same code --
triggering an interrupt when the line changes, and timestamping that in
the kernel to keep the slippage between the pulse being input and NTP
getting to process it as low as possible. There is also a PPS driver for
serial ports, which is the best way to do it when you are using a serial
port.
As a lot of this is new to me, my understanding is not as complete as I
would like. VMS device drivers I used to understand. I think I have a
moderate knowledge of Windows and how .SYS drivers fit in, and how DLLs
might support them. What Linux "modules" are I don't yet know, so why I
need both a revised kernel /and/ modules on Linux to support PPS is
currently unknown - although my guess is that the modules are the
equivalent of Windows device drivers.
They are the same, although Linux modules almost always need to be
compiled against the specific kernel version while Windows drivers are
typically only bound to which release you're running. That is the reason
you have to compile the kernel, rather than just plop down a driver
downloaded from the internet. That said, the reason your PPS driver is a
module is that it makes it easier to tweak options. Almost all modules
that are part of the main kernel source (which PPS is, for a year or so)
can be compiled in rather than as a separate module, but you can pass
options to a module as you load it while you cannot do that with a
builtin. It also makes it possible to tweak the source, recompile just
that module, and test it on the fly rather than recompiling the entire
kernel and rebooting.
With respect to interrupt latency, the PPS driver is the best you're
going to get without a custom add-in card that provides input capture
(timestamping). I considered going that route but making PCI or PCI-e
cards essentially means using FPGAs which are expensive and fussy, and
sort of overkill. A I2C or SPI based card for use with Raspberry Pi or
other single-board computers is also a possibility. But instead I'm
looking at a microcontroller based solution with no conventional OS that
will act as a pure NTP server (no client) with built-in GPSDO. IMHO it's
more elegant to eliminate the software PLL. That project is next on the
plate after I finish a current non-time-nuts project also using
Ethernet, to familiarize myself with the Ethernet hardware.
-- m. tharp
-----Original Message-----
From: Michael Tharp
[]
What you have is probably better than the typical RS-232 DCD line.
Ultimately it's doing the same thing with mostly the same code --
triggering an interrupt when the line changes, and timestamping that in
the kernel to keep the slippage between the pulse being input and NTP
getting to process it as low as possible. There is also a PPS driver for
serial ports, which is the best way to do it when you are using a serial
port.
---==========
Yes, there's no filtering like you might get on a real-world protected I/O
line!
As a lot of this is new to me, my understanding is not as complete as I
would like. VMS device drivers I used to understand. I think I have a
moderate knowledge of Windows and how .SYS drivers fit in, and how DLLs
might support them. What Linux "modules" are I don't yet know, so why I
need both a revised kernel /and/ modules on Linux to support PPS is
currently unknown - although my guess is that the modules are the
equivalent of Windows device drivers.
They are the same, although Linux modules almost always need to be
compiled against the specific kernel version while Windows drivers are
typically only bound to which release you're running. That is the reason
you have to compile the kernel, rather than just plop down a driver
downloaded from the internet. That said, the reason your PPS driver is a
module is that it makes it easier to tweak options. Almost all modules
that are part of the main kernel source (which PPS is, for a year or so)
can be compiled in rather than as a separate module, but you can pass
options to a module as you load it while you cannot do that with a
builtin. It also makes it possible to tweak the source, recompile just
that module, and test it on the fly rather than recompiling the entire
kernel and rebooting.
---==========
Thanks for that - I've added it as a note to my Web page as I'm sure that
other will appreciate knowing just what happens. Likely you can pass
parameters to Windows drivers as well, either through the registry or via
the Control Panel, and they can also be dynamically loaded. Apart from
re-compiling the kernel, the Linux implementation sound nice. Whether I
would have the patience for a kernel recompile on the Raspberry Pi is
another matter! I guess it will come to that one day.
---==========
With respect to interrupt latency, the PPS driver is the best you're
going to get without a custom add-in card that provides input capture
(timestamping). I considered going that route but making PCI or PCI-e
cards essentially means using FPGAs which are expensive and fussy, and
sort of overkill. A I2C or SPI based card for use with Raspberry Pi or
other single-board computers is also a possibility. But instead I'm
looking at a microcontroller based solution with no conventional OS that
will act as a pure NTP server (no client) with built-in GPSDO. IMHO it's
more elegant to eliminate the software PLL. That project is next on the
plate after I finish a current non-time-nuts project also using
Ethernet, to familiarize myself with the Ethernet hardware.
-- m. tharp
---==========
If I'm brutally honest, I only /need/ millisecond accuracy on my systems.
So even a GPS/PPS is overkill for my needs, but at $20 it's the most cost
effective solution. I've had fun with the card-sized PCs, and learnt
something along the way. But if you are aiming for better, there will be
plenty of folk here encouraging you!
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
On 21 Nov, 2012, at 10:34 , Michael Tharp gxti@partiallystapled.com wrote:
With respect to interrupt latency, the PPS driver is the best you're going to get without a custom add-in card that provides input capture (timestamping). I considered going that route but making PCI or PCI-e cards essentially means using FPGAs which are expensive and fussy, and sort of overkill. A I2C or SPI based card for use with Raspberry Pi or other single-board computers is also a possibility.
I did a prototype PCI-X card like that some years ago. It
was expensive but worked pretty well; the high-speed part
of the FPGA ran at 320 MHz, so timestamps were taken with a
resolution of just over 3 ns. Having a card plugged into
your computer which knows what time it is to within 3 ns,
but which is on the far side of a bus across which a single
PIO read takes 80 ns to complete, is of limited direct use
to the computer itself, however, so the hardest part of the
design involved minimizing the uncertainty of the time
transfer from the card's clock to the computer's system clock.
I'm not quite sure that it always requires custom hardware
to get a few 10's of nanoseconds precision for PPS sampling,
though. Some off-the-shelf hardware may also work for this.
In particular the on-chip clock peripherals included in the
TI CPU used for the BeagleBone board have hardware
timestamp-capture inputs (the TIMER4-7 i/o pins on one of the
cape connectors) which seem to do the right thing. That,
plus the fact that the TI chip also has an onboard Ethernet
mac core (as opposed to the USB Ethernet device the Raspberry
PI uses) is making me think that that the BeagleBone might
be a bit better base on which to build a good NTP server
than the RPI is.
Dennis Ferguson