Re: Testing

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

Re: Anybody taking care of refclock_trimble?

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

Re: Anybody taking care of refclock_trimble?

>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

RE: --disable-fuzz

>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

Re: ublox refclock

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

ublox refclock

>> 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

LKM Timemark Driver for PC parallel ports with refclock_trimble now available for testing

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

RE: [ntp:hackers] u-blox reference clock driver

>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

Additional pps-gpio

>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

Verified - ntpd ignores the year part of refclock timestamps

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:

Fw: ntpsec | build failed today on server - but without issues in the past (#320)

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

Re: devel Digest, Vol 19, Issue 20

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:

Re: NTPsec on MIPSbe

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

Re: Does anybody have a sample of a NMEA device with the 1024 week bug?

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

Re: I think we can drop the Jupiter driver.

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