[ntp:questions] Refclock Oncore Driver Change

Terje Mathisen terje.mathisen at tmsw.no
Mon May 6 05:58:26 UTC 2019


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?

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

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list