leontp offset?
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same rung of
the same tower. Tower has clear horizon to horizon view. cable runs are
the same (obviously).
I did run with the included puck in my south facing office window (rather
than the GPS antenna on the tower) for a couple of days when I first got
the unit. The offset behaviour was the same.
Here is a BSD computer running ntpd, configured with hardware serial port attached GPS, PPS through FatPPS into the serial port seen as GPS_NMEA below, along with the two LeoNTP servers at 192.168.20.5 and 192.168.20.6, offset and jitter appear reasonable, as expected on a LAN, and I've seen no anomalies over the past month.
remote refid st t when poll reach delay offset jitter
---============
oGPS_NMEA(0) .GPS. 0 l 20 16 377 0.000 0.002 0.001 <- BSD+PPS
+192.168.20.5 .GPS. 1 u 24 64 377 0.162 -0.011 0.006 <- LeoNTP #1
+192.168.20.6 .GPS. 1 u 44 64 377 0.159 -0.009 0.004 <- LeoNTP #2
The three devices above have separate GPS antennas installed within a couple meters of each other, all three see between 10 and 12 satellites.
A couple weeks ago I also used an HP 5334B to compare each LeoNTP PPS to a TVB screened T-Bolt PPS, the T-Bolt was configured with LH extended location calibration and in over-determined time mode, T-bolt sees 7 or 8 satellites. Each LeoNTP 1PPS BNC output agreed with the T-Bolt 1PPS to within some tens of nanoseconds over a 30 hour run. The LeoNTP and T-Bolt shared a Microsemi gps splitter and the same antenna.
After reading your email, as a final sanity check we just set up a Linux ntpd configured with both LeoNTP servers along with four random us ntp pool servers. After an hour here is ntpq -p.
remote refid st t when poll reach delay offset jitter
---============
+192.168.20.5 .GPS. 1 u 46 64 377 0.604 -0.059 0.123
*192.168.20.6 .GPS. 1 u 40 64 377 0.602 -0.050 0.116
-x.ns.gin.ntt.ne 249.224.99.213 2 u 528 1024 377 12.232 2.023 10.209
xclockb.ntpjs.or 132.163.4.101 2 u 421 1024 373 61.785 2.924 0.244
+four10.gac.edu 216.218.254.202 2 u 1017 1024 377 63.364 -0.137 0.381
-c-73-37-183-90. 142.66.101.13 2 u 418 1024 377 64.903 1.928 2.507
In the above, 192.168.20.5 and 192.168.20.6 are each LeoNTP, they agree with the four pool servers as nicely as can be expected with a cable modem connection.
Summary: I do not see any issues with the LeoNTP servers, both devices worked as expected. LeoNTP is also by far the friendliest commercial NTP server I've ever configured, the human interface is well thought out.
As Hal suggested, perhaps there is some systematic configuration issue with your other pair of clocks? I keep a $40 Adafruit Ultimate GPS with PPS output and little puck antenna, for the sort of situation you see, it powers up indoors in 60 seconds and its PPS into ntpd would let you have a 3rd clock if using internet servers doesn't get you an answer.
I have no relationship with the vendor other than as a satisfied customer.
Bob
On Oct 14, 2016, at 5:31 PM, gmx tallahassee gmx.tallahassee@gmail.com wrote:
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same rung of
the same tower. Tower has clear horizon to horizon view. cable runs are
the same (obviously).
I did run with the included puck in my south facing office window (rather
than the GPS antenna on the tower) for a couple of days when I first got
the unit. The offset behaviour was the same.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I think the best assumption you can make is to take it at face value.
It looks like leontp is about 10ms "off" from your local time. One
of you is wrong and at this point there is no way to know who is wrong
But of course you appear to be getting time closer to arbiter
So either arbiter or leontp is wrong. You don't know which.
I would add five more pool servers to your set of reference clocks and
let it run over night. Pool servers are good because many people use
them so if there was a problem they would hear about it
In any case you don't have enough reference clocks. Get some more
diversity, certainly more than two sources
One more thing, just because an NTP server is shown as getting time
from GPS does not mean it is accurate. They may be using only NMEA
sentences and no PPS in which case a 10ms error would be quite good
On Fri, Oct 14, 2016 at 5:31 PM, gmx tallahassee
gmx.tallahassee@gmail.com wrote:
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same rung of
the same tower. Tower has clear horizon to horizon view. cable runs are
the same (obviously).
I did run with the included puck in my south facing office window (rather
than the GPS antenna on the tower) for a couple of days when I first got
the unit. The offset behaviour was the same.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Briefly,
Here is an Intel Atom Linux NTP server fed from a Garmin GPS 18 LVC compared
against some other devices, where 192.168.0.20 is a LeoNTP:
remote refid st t when poll reach delay offset
jitter
---============
o127.127.22.0 .kPPS. 0 l 5 16 377 0.000 0.000
0.003
*127.127.28.0 .GPSD. 0 l 6 16 377 0.000 -3.598
0.662
192.168.0.83 .kPPS. 1 u 2 32 377 0.251 0.006
0.017
192.168.0.20 .GPS. 1 u 16 32 377 0.087 0.028
0.002
+192.168.0.1 .kPPS. 1 u 4 32 377 0.161 -0.119
0.022
+192.168.0.7 .kPPS. 1 u 18 32 377 0.196 -0.043
0.027
+192.168.0.8 .kPPS. 1 u 2 32 377 0.160 -0.018
0.139
There's no 10 ms offset. Other devices are: .83 a Raspberry Pi, .1, .7 .8
Windows kernel-mode PPS synced server. I would suggest checking your
Arbiter servers.
Can you check with a 'scope to compare the PPS out out the LeoNTP? It's a
100 ms positive pulse, within about 50 ns of a couple of other GPS/PPS
devices, and about 200 ns earlier than a Jackson Labs device.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
Check the Arbiter for anomalous "Cable Delay" or "Clock Offset" settings.
Maybe they accidentally got set to 9999999ns instead of zero.
Page 38 in this manual:
http://www.arbiter.com/files/product-attachments/1084_manual.pdf
Tim N3QE
On Fri, Oct 14, 2016 at 8:31 PM, gmx tallahassee gmx.tallahassee@gmail.com
wrote:
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---===========================
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same rung of
the same tower. Tower has clear horizon to horizon view. cable runs are
the same (obviously).
I did run with the included puck in my south facing office window (rather
than the GPS antenna on the tower) for a couple of days when I first got
the unit. The offset behaviour was the same.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
I am wandering if it will be the same results without 'FatPPS'. In my
Lab I was able to use T-Bolt 1PPS through TADD-3 (not from RS2323).
Works stable.
I am using 'chrony' though
210 Number of sources = 5
.- Number of sample points in measurement
set.
/ .- Number of residual runs with same
sign.
| / .- Length of measurement set
(time).
| | / .- Est. clock freq error
(ppm).
| | | / .- Est. error in
freq.
| | | | / .- Est.
offset.
| | | | | | On
the -.
| | | | | |
samples.
| | | | | |
|
Name/IP Address NP NR Span Frequency Freq Skew Offset
Std Dev
---============
PPS0 19 10 291 -0.000 0.003 -1ns
293ns
ntp2.torix.ca 10 7 154m +0.848 0.256 +4251us
459us
time.sidereal.ca 9 5 137m +0.311 0.539 -3996us
837us
S0106c04a00f34a5d.vc.shaw 40 18 11h -0.036 0.050 -5995us
1009us
omega.goholdings.ca 58 29 16h -0.040 0.036 +5987us
1345us
On 2016-10-15 01:17, Bob wrote:
Here is a BSD computer running ntpd, configured with hardware serial
port attached GPS, PPS through FatPPS into the serial port seen as
GPS_NMEA below, along with the two LeoNTP servers at 192.168.20.5 and
192.168.20.6, offset and jitter appear reasonable, as expected on a
LAN, and I've seen no anomalies over the past month.
remote refid st t when poll reach delay offset
jitter
---============
oGPS_NMEA(0) .GPS. 0 l 20 16 377 0.000 0.002
0.001 <- BSD+PPS
+192.168.20.5 .GPS. 1 u 24 64 377 0.162 -0.011
0.006 <- LeoNTP #1
+192.168.20.6 .GPS. 1 u 44 64 377 0.159 -0.009
0.004 <- LeoNTP #2
The three devices above have separate GPS antennas installed within a
couple meters of each other, all three see between 10 and 12
satellites.
A couple weeks ago I also used an HP 5334B to compare each LeoNTP PPS
to a TVB screened T-Bolt PPS, the T-Bolt was configured with LH
extended location calibration and in over-determined time mode, T-bolt
sees 7 or 8 satellites. Each LeoNTP 1PPS BNC output agreed with the
T-Bolt 1PPS to within some tens of nanoseconds over a 30 hour run.
The LeoNTP and T-Bolt shared a Microsemi gps splitter and the same
antenna.
After reading your email, as a final sanity check we just set up a
Linux ntpd configured with both LeoNTP servers along with four random
us ntp pool servers. After an hour here is ntpq -p.
remote refid st t when poll reach delay offset
jitter
---============
+192.168.20.5 .GPS. 1 u 46 64 377 0.604 -0.059
0.123
*192.168.20.6 .GPS. 1 u 40 64 377 0.602 -0.050
0.116
-x.ns.gin.ntt.ne 249.224.99.213 2 u 528 1024 377 12.232 2.023
10.209
xclockb.ntpjs.or 132.163.4.101 2 u 421 1024 373 61.785 2.924
0.244
+four10.gac.edu 216.218.254.202 2 u 1017 1024 377 63.364 -0.137
0.381
-c-73-37-183-90. 142.66.101.13 2 u 418 1024 377 64.903 1.928
2.507
In the above, 192.168.20.5 and 192.168.20.6 are each LeoNTP, they
agree with the four pool servers as nicely as can be expected with a
cable modem connection.
Summary: I do not see any issues with the LeoNTP servers, both
devices worked as expected. LeoNTP is also by far the friendliest
commercial NTP server I've ever configured, the human interface is
well thought out.
As Hal suggested, perhaps there is some systematic configuration issue
with your other pair of clocks? I keep a $40 Adafruit Ultimate GPS
with PPS output and little puck antenna, for the sort of situation you
see, it powers up indoors in 60 seconds and its PPS into ntpd would
let you have a 3rd clock if using internet servers doesn't get you an
answer.
I have no relationship with the vendor other than as a satisfied
customer.
Bob
On Oct 14, 2016, at 5:31 PM, gmx tallahassee
gmx.tallahassee@gmail.com wrote:
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a
week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently
been
in the 9.5 -10.5 range. since I'm measuring all three sources from
the
same (EL7) computer, I would expect that the offset of the leontp unit
to
converge to be in the close neighborhood of the offsets of the
arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into
the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same
rung of
the same tower. Tower has clear horizon to horizon view. cable runs
are
the same (obviously).
I did run with the included puck in my south facing office window
(rather
than the GPS antenna on the tower) for a couple of days when I first
got
the unit. The offset behaviour was the same.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
Hi
The 10 ms offset is suspiciously close to what you would get with a 10 ms pulse stretcher
and a setup that is triggering on the wrong edge.
Bob
On Oct 15, 2016, at 9:40 AM, Vlad time@patoka.org wrote:
I am wandering if it will be the same results without 'FatPPS'. In my Lab I was able to use T-Bolt 1PPS through TADD-3 (not from RS2323). Works stable.
I am using 'chrony' though
210 Number of sources = 5
.- Number of sample points in measurement set.
/ .- Number of residual runs with same sign.
| / .- Length of measurement set (time).
| | / .- Est. clock freq error (ppm).
| | | / .- Est. error in freq.
| | | | / .- Est. offset.
| | | | | | On the -.
| | | | | | samples.
| | | | | | |
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
---============
PPS0 19 10 291 -0.000 0.003 -1ns 293ns
ntp2.torix.ca 10 7 154m +0.848 0.256 +4251us 459us
time.sidereal.ca 9 5 137m +0.311 0.539 -3996us 837us
S0106c04a00f34a5d.vc.shaw 40 18 11h -0.036 0.050 -5995us 1009us
omega.goholdings.ca 58 29 16h -0.040 0.036 +5987us 1345us
On 2016-10-15 01:17, Bob wrote:
Here is a BSD computer running ntpd, configured with hardware serial
port attached GPS, PPS through FatPPS into the serial port seen as
GPS_NMEA below, along with the two LeoNTP servers at 192.168.20.5 and
192.168.20.6, offset and jitter appear reasonable, as expected on a
LAN, and I've seen no anomalies over the past month.
remote refid st t when poll reach delay offset jitter
---============
oGPS_NMEA(0) .GPS. 0 l 20 16 377 0.000 0.002
0.001 <- BSD+PPS
+192.168.20.5 .GPS. 1 u 24 64 377 0.162 -0.011
0.006 <- LeoNTP #1
+192.168.20.6 .GPS. 1 u 44 64 377 0.159 -0.009
0.004 <- LeoNTP #2
The three devices above have separate GPS antennas installed within a
couple meters of each other, all three see between 10 and 12
satellites.
A couple weeks ago I also used an HP 5334B to compare each LeoNTP PPS
to a TVB screened T-Bolt PPS, the T-Bolt was configured with LH
extended location calibration and in over-determined time mode, T-bolt
sees 7 or 8 satellites. Each LeoNTP 1PPS BNC output agreed with the
T-Bolt 1PPS to within some tens of nanoseconds over a 30 hour run.
The LeoNTP and T-Bolt shared a Microsemi gps splitter and the same
antenna.
After reading your email, as a final sanity check we just set up a
Linux ntpd configured with both LeoNTP servers along with four random
us ntp pool servers. After an hour here is ntpq -p.
remote refid st t when poll reach delay offset jitter
---============
+192.168.20.5 .GPS. 1 u 46 64 377 0.604 -0.059 0.123
*192.168.20.6 .GPS. 1 u 40 64 377 0.602 -0.050 0.116
-x.ns.gin.ntt.ne 249.224.99.213 2 u 528 1024 377 12.232 2.023 10.209
xclockb.ntpjs.or 132.163.4.101 2 u 421 1024 373 61.785 2.924 0.244
+four10.gac.edu 216.218.254.202 2 u 1017 1024 377 63.364 -0.137 0.381
-c-73-37-183-90. 142.66.101.13 2 u 418 1024 377 64.903 1.928 2.507
In the above, 192.168.20.5 and 192.168.20.6 are each LeoNTP, they
agree with the four pool servers as nicely as can be expected with a
cable modem connection.
Summary: I do not see any issues with the LeoNTP servers, both
devices worked as expected. LeoNTP is also by far the friendliest
commercial NTP server I've ever configured, the human interface is
well thought out.
As Hal suggested, perhaps there is some systematic configuration issue
with your other pair of clocks? I keep a $40 Adafruit Ultimate GPS
with PPS output and little puck antenna, for the sort of situation you
see, it powers up indoors in 60 seconds and its PPS into ntpd would
let you have a 3rd clock if using internet servers doesn't get you an
answer.
I have no relationship with the vendor other than as a satisfied customer.
Bob
On Oct 14, 2016, at 5:31 PM, gmx tallahassee gmx.tallahassee@gmail.com wrote:
Hi all,
I'm checking out the leontp ntp time server (leontp.com). After a week of
use I am getting the following ntp -q output:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
---============
*172.17.21.11 .GPS. 1 u 13 16 377 0.137 0.077
0.054 <- Arbiter 1084C GPS Clock
+172.17.21.12 .GPS. 1 u 11 16 377 0.101 0.085
0.174 <- Arbiter 1084C GPS Clock
x172.17.21.233 .GPS. 1 u 11 16 377 0.071 9.760
0.061 <- LeoNTP
the offset of the leontp device from the other clocks has consistently been
in the 9.5 -10.5 range. since I'm measuring all three sources from the
same (EL7) computer, I would expect that the offset of the leontp unit to
converge to be in the close neighborhood of the offsets of the arbiters.
It has not converged, instead maintaining the ~10ms offset.
Thoughts?
Thanks.
Details:
172.17.21.11 is approx 400M away through two Cisco 3750G switches no
routing.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
same 3750G switch
Antenna location for the .12 arbiter and the leontp is on the same rung of
the same tower. Tower has clear horizon to horizon view. cable runs are
the same (obviously).
I did run with the included puck in my south facing office window (rather
than the GPS antenna on the tower) for a couple of days when I first got
the unit. The offset behaviour was the same.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
When I read "fatPPS" I thought of the same thing. The best use of a pulse
stretcher is to verify you are interrupting on the correct edge because a
wrong edge error will be obvious if the pulse is wide.
On Sat, Oct 15, 2016 at 7:36 AM, Bob Camp kb8tq@n1k.org wrote:
Hi
The 10 ms offset is suspiciously close to what you would get with a 10
ms pulse stretcher
and a setup that is triggering on the wrong edge.
--
Chris Albertson
Redondo Beach, California