[ntp:questions] Refclock Oncore Driver Change

juergen perlinger juergen.perlinger at t-online.de
Thu May 9 04:32:36 UTC 2019

Hello all!
Please see on bottom...

On 5/6/19 7:58 AM, Terje Mathisen wrote:
> Thomas Laus wrote:
>> Group:
>> The Motorola Oncore receiver has recently become non-usable because of
>> the
>> recent GPS week rollover.  The receiver year field is limited by the
>> receiver
>> to the years from 1988 to 2018.  The current driver is not able to write
>> the year 2019 successfully.
>> I have looked overr the refclock_oncore.c driver program and have some
>> thoughts.
>> The is a section of the code that makes a conversion of Unix time to
>> GPS time.
>> There is a 70 year constant applied to the message sent to the
>> receiver and
>> received from the refclock.  I think that this constant could be
>> 'fudged' to
>> either add or subtract hex 0x24ea0000 (decimal 619315200) for the
>> number of
>> seconds in a 1024 GPS week.  I looked at the date in my Oncore and
>> converted
>> it to Unix time.  I subtracted this factor from my system date and the
>> numbers
>> matched.
>> I send an email to the person that last made a change to the
>> refclock_oncore
>> driver program and have not received a reply yet.  I ask this group if
>> my idea
>> has any hidden 'gotchas'.  The Oncore driver already has sections for the
>> different models.  I am proposing using the conversion factor for
>> the 6 and 8 channel receivers and leave the code alone for the M12
>> receiver.
>> Are there any model VT, VP, GT, UT receivers that handled the recent
>> rollover
>> correctly?  Are there any M12 receivers that need this fix?
>> The code is a little complicated in ntp_unixtime.h because of the size
>> of the
>> number is greater than a 32 bit INT and my 'C' skills are a little rusty.
>> I plan on working on this next week and see if my idea is valid.  It
>> would
>> be great to have my Oncore back in operation for another 19 years and not
>> requiring a replacement receiver.  I am going to concentrate on making
>> the chage to the ntp_unixtime.h file because other refclocks might
>> require
>> a similar fix.  Am I on the right path or is there a better way?  The
>> receiver
>> will still think that the year is in the correct range, but all date
>> in and
>> out of ntp will be correct.
> I really do think this should work, i.e. adding 1024 weeks to the
> returned date value, but I would at least make it configurable, i.e. use
> a mode value in the server statement or a fudge flag to indicate that
> this hack is to be added.
> Take a look at the NMEA refclocks to see how this works for them. Afaik
> the Oncore refclock is currently not using any such mode/flag values?

There is some code in the NMEA driver to not trust the GPS time stamps
to deliver a valid absolute date, and the driver effectively uses a
rolling GPS era of 1024 weeks to map the NMEA date (either in y/m/d or
in GPS week/time scale) into the indicated GPS era.

> You could also add this as extra item in the oncore-specific config
> file, something like
> LAT 39 45.3753          # Positive is North.
> LONG -75 04.27187       # Negative is West
> HTGPS 18.28 M           # Height in meters.
> SHMEM  /var/log/ntpstats/ONCORE.0
> TRAIM YES               # May need this if bad antenna pos
> ## Extra hack for week counter fix:
> EPOCH 2            # Can also be 3, 4 etc
> This would indicate that the time returned should be forced into the
> second (counting from zero) GPS WEEK epoch, i.e. between week 2048 and
> 3071 inclusive, but only if less than this.
> If the gps firmware is correct this would do nothing, not even after the
> next rollower nearly 20 years from now, but for all those that got left
> behind and thinks it is currently 1999 (or even 1980) you would add 1024
> to the week value until it was >= both the current (compiled-in) date
> and the EPOCH value given in the config file.
> Terje

We have opened Bug 3576/3577 for this topic, as it affects all GPS based
clocks. I'm waiting to have these integrated, but the fix for 3576 would
provide the necessary canned routines to give any driver the tools to
fix the issue without doing all the calendar math themselves.

It would also ensure all drivers use the same rolling epoch, derived
either from the build date by default or by explicitely using a 'tos
basedate' statement in the config.

The solution works with the NMEA driver, Zyfer driver and I dared to
touch the Jupiter driver. I did not touch the oncore driver, as I'm not
feeling confident enough to do that blind and I have no hardware to test.

But I'm happy to assist once we have the fixes for the infrastructure in
place. It should put a plug into the problem for once and ever. I hope,
at least.


More information about the questions mailing list