On Thu, Nov 16, 2017 at 01:40:12PM -0800, Bill Unruh wrote:
> On Thu, 16 Nov 2017, Rob Janssen wrote:
> > For really accurate PPS handling one would want a dedicated PCI-E card
> > with a clock oscillator and a counter,
> > latched in a register on PPS edge, and issuing the interrupt. The
> > driv
I thought i might add my own $0.02 as this is something i've been
working on for some time (i.e. trying to figure out which gps module is
best for my OSH project).
The MTK3339 is ok, but my current round of hardware design has been
putting the neo6m, Quectel L80 and MTK3339 up against each oth
Bill Unruh wrote:
All of those systems have an "onboard UART". Setserial determines them as:
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
However there is of course no 16550A anywhere on those boards, it is a cell in
some system support chip.
It is true that parallel is better than serial, if
On Thu, 16 Nov 2017, Rob Janssen wrote:
Bill Unruh wrote:
I am using chrony with serial PPS on a number of different machines, and I
see the 6-7 us figure
on HP Proliant systems while on Dell PowerEdge sytems it is more like 1us.
No idea where the difference comes from.
How do you measure
On Thu, 16 Nov 2017, Denny Page wrote:
On Nov 16, 2017, at 10:32, Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the
Bill Unruh wrote:
I am using chrony with serial PPS on a number of different machines, and I see
the 6-7 us figure
on HP Proliant systems while on Dell PowerEdge sytems it is more like 1us.
No idea where the difference comes from.
How do you measure that latency? It does seem that the parall
> On Nov 16, 2017, at 10:32, Bill Unruh wrote:
>
> On Thu, 16 Nov 2017, Denny Page wrote:
>
>> Interrupt latency for character devices in Linux is 6-7 us, even with no
>> other activity. You
>
> It has been a while but I ran tests on a system in which I changed the state
> of a parallel port
On Thu, 16 Nov 2017, Rob Janssen wrote:
Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no
other activity. You
It has been a while but I ran tests on a system in which I changed the
state
of a parallel port
Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the state
of a parallel port pin and fed that into an interrupt grabbing
It has now been suggested to you at least by two different people-- hook your
system up to the network, and do a timing using a nearby ntp server.
That will give you of the order of 10-20us accuracy, and you can see if that
time is the same as your pps time.
I have no idea how accurate gpsd is.
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the state
of a parallel port pin and fed that into an interrupt grabbing the system time
ju
I'm not too concerned about the accuracy of the PPS. This particular GPS
receiver is pretty high quality.
https://learn.adafruit.com/adafruit-ultimate-gps/overview It delivers the
NMEA data and the PPS. A number of online resources describing similar
projects and the GPSD Time Service HOWTO page a
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You can get better than this using a gpio and spinning on it, but I
haven’t seen anyone do this with with serial pps.
Denny
> On Nov 16, 2017, at 09:57, Bill Unruh wrote:
>
> The PPS accuracy is largely
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Thu, 16 N
I'm trying to determine the best way to get an idea of my clock accuracy
now that I'm getting the PPS signals. Is that "chronyc tracking"? When I do
"chronyc sources" or "chronyc sourcestats" those seem to indicate NMEA
offsets that are on the order of 40-60ms.
debian@beaglebone:~$ chronyc sources
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Wed, 15 N
Thank you so much!! With the lock NMEA it is no longer ignoring the pulses.
I should be able to make adjustments to the offset and whatnot to get the
clock accuracy down to where I need it.
On Wed, Nov 15, 2017 at 2:02 AM, Miroslav Lichvar
wrote:
> On Tue, Nov 14, 2017 at 03:45:41PM -0500, Joe
On Tue, Nov 14, 2017 at 03:45:41PM -0500, Joe Smith wrote:
> I rebuilt chrony with --enable-debug and ran with -d -d Below is some
> output although I'm not 100% sure what it means. Tried looking at the
> source code to see if I could ascertain the cause but I was unable. I let
> it run for a bit
I have also not looked at the code recently but am suspicious. The time is
for example 1510691647.698064095 That is almost exactly half way between the
two seconds, and I think that the time needs to be within 1/4 sec of the top
of the second for chrony to think that there is a lock, and to start
I rebuilt chrony with --enable-debug and ran with -d -d Below is some
output although I'm not 100% sure what it means. Tried looking at the
source code to see if I could ascertain the cause but I was unable. I let
it run for a bit and here's some sample output. The pattern just seems to
repeat ove
On Tue, Nov 14, 2017 at 07:40:33AM -0500, Joe Smith wrote:
> Thank you for the quick response Bill... The PPS is coming in on /dev/pps1
> which is what I have in the refclock entry in my chrony.conf file. When run
> the cat command corresponding to that device I get:
>
> debian@beaglebone:~/ntp-gp
Thank you for the quick response Bill... The PPS is coming in on /dev/pps1
which is what I have in the refclock entry in my chrony.conf file. When run
the cat command corresponding to that device I get:
debian@beaglebone:~/ntp-gps-server/pps-overlay$ cat
/sys/devices/virtual/pps/pps1/assert
151066
On Mon, 13 Nov 2017, Joe Smith wrote:
A little background... I am building a small NTP server utilizing a BeagleBone
Black Rev C
and an AdaFruit Ultimate GPS breakout board (with external antenna)
(https://learn.adafruit.com/adafruit-ultimate-gps/overview). I have the
hardware connected,
have
A little background... I am building a small NTP server utilizing a
BeagleBone Black Rev C and an AdaFruit Ultimate GPS breakout board (with
external antenna) (https://learn.adafruit.com/adafruit-ultimate-gps/overview).
I have the hardware connected, have GPS data coming in, and the PPS signal
bein
24 matches
Mail list logo