From: Hal Murray
To:devel@ntpsec.org
Subject: Testing
Does anybody test our code on Apple? Solaris?
In order to test 32 bit and 64 bit big and little endian hosts with the
Trimble driver, I have been using:
LE32: Raspberry Pi 3B with Raspbian
LE64: Xeon with Gentoo
BE32: Power Mac G4 with Fre
On Thu, 13 Feb 2020 03:24:21 -0800, you wrote:
I didn't get time this weekend to put anything on the issue tracker,
but I'll test over the next week with --disable-fuzz without changing
anything.
I have not made any changes to the Trimble driver since the generic
GPS rollover workaround suffixes
>Message: 3
>Date: Tue, 11 Feb 2020 00:33:07 -0800
>From: Hal Murray
>To: devel@ntpsec.org
>Subject: Anybody taking care of refclock_trimble?
>Message-ID:
> <20200211083307.a89ce406...@ip-64-139-1-69.sjc.megapath.net>
>Content-Type: text/plain; charset=us-ascii
>
>
>/* get timestamp
>Hal Murray hmurray at megapathdsl.net wrote:
>Fri Dec 6 11:47:41 UTC 2019
>
>I just pushed it.
>
>Default is no change. If you add --disable-fuzz to your configure line,
>almost all that code goes away.
>
>The "almost" is because ifdef-s don't work in bison input. So "tinker tick
>" still gets
On Fri, 29 Nov 2019 21:18:50 -0500, you wrote:
>On Wed, 27 Nov 2019 22:08:48 -0500, Trevor N.
>wrote:
>...
>>I have already begun collecting F9T data with gpsd-3.19 (kernel PPS
>>enabled) through shm on the latest ntpsec. I'll post 1-day output as
>>soon as it's available.
>>
>The results at
>Gary E. Miller gem at rellim.com wrote
Thank you for the comments, I have replies for each point:
>Yo Udo!
>
>On Sun, 24 Nov 2019 09:23:19 +0100
>Udo van den Heuvel via devel wrote:
>
>> I cam across this ublox ntpsec refclock:
>> https://gitlab.com/trv-n/ntpsec-ublox
>> Would it be usable for
Eric S. Raymond esr at thyrsus.com :
>Gary E. Miller via devel :
>> > So there is nothing you recommend be merged at this time?
>>
>> I sorta wish NTPsec had a staging area like the Linux kernel does.
>>
>> There is value to a small and clean u-blox driver fully integrated
>> into NTPsec. But wi
>> Is there any point to it without the matching kernel driver?
>
>Has anybody tried asking for the "echo" from user space?
>
>That is:
> grab time
> raise modem signal
> grab time
> read timestamp over serial port
>
>If you precede that with
> grab time
> lower modem signal
>I think that wil
I modified the pps_parport Linux Kernel Module to produce pulses in
addition to receiving them. It's different from the existing
pps_gen_parport in a few ways:
*works with multiple parallel ports
*timestamps assert or clear edge instead of just asserting at the top
of the second without timestampi
>Yo Achim!
>
>On Tue, 28 Aug 2018 19:28:32 +0200
>Achim Gratz via devel wrote:
>
>> Gary E. Miller via devel writes:
>> > We probably need to work with linuxpps, but we may have an easier
>> > time working with the folks that maintain the Raspberry Pi fork.
>> > The last time I asked for a dtb cha
>Hal Murray hmurray at megapathdsl.net
>Sun Jan 28 07:37:05 UTC 2018
>
>There is another approach that might be interesting. Use a loopback on some
>modem control signals or gpio pins. Then a test program can grab the time,
>flap the pin, and grab the time, then read the PPS time.
>
>Things may
It's not necessary to use refclock_process() if the driver creates
its own l_fp timecode timestamp and uses refclock_process_offset(). I
was considering removing refclock_process() when I added the rollover
workaround to the trimble driver, but then I read this:
https://bugs.ntp.org/show_bu
The CI builds worked, and I usually start with a ./waf distclean so I
didn't notice that moving the function into libntp breaks builds that
have not been cleaned.
While attempting to fix classic bug 2659 I noticed another problem
with my commit d74cf1e3: Since the UTC offset is now required to
obta
Please revert commit d74cf1e3 if possible. It seems that the MR page
is only available when not logged in, so I can't comment there.
On Sat, 27 May 2017 12:00:00 +, you wrote:
>Date: Fri, 26 May 2017 14:57:37 -0700
>From: "Gary E. Miller"
>To:
>Subject: ?MR 422
>Message-ID: <20170526145737.7
I just finished testing the refclocks supported by the Trimble
driver on a sparc64 machine. The configure was able to set
WORDS_BIGENDIAN 1
without any problem. I didn't notice any runtime problems besides
what's likely due to serial port delays, but there were some warnings
during the bui
I have a device that will rollover after week 1998 (in 2018) that I
just tested with a GPS simulator set to 2 years in the future,
attached to ntpd classic with a +2 year offset in get_ostime (and
"disable ntp" in conf) and ntpcal_get_build_date() of 2016. The
512-week-around-receive-timestamp cod
I created a loop like that for the Trimble driver. The algorithm is
pretty simple so I'm probably missing something; please check out the
merge request I made a few days ago. I still need to test the changes
with my simulator and with ntpd started with date offsets.
>Hal Murray hmurray at megapa
17 matches
Mail list logo