[time-nuts] eBay Ublox

David J Taylor david-taylor at blueyonder.co.uk
Wed Nov 21 16:24:35 UTC 2012


-----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 at blueyonder.co.uk 





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