WNRO fixup
Bob kb8tq said:
Simple answer: Run an external piece of software to correct the issue. It���s
by far the simplest solution. ( no, it���s not trivial ���.. )
The code to do the fixup can be simple. The trick is that you need the time
in seconds-since-tzero rather than year-month-day. POSIX uses seconds since
1970.
If you are on a POSIX system, you can use mktime and gmtime to convert back
and forth.
Here is the fixup code:
while (gps_time < magic_constant)
gps_time += 1024*seconds_per_week
The magic_constant is the time stamp for when the software was built.
You can get that from date +%s
The fixup code will work for 1024 weeks after the date corresponding to
magic_constant.
That's close to 20 years.
If you are working inside ntpd, NTP time starts at 1900 so the magic_constant
has to be offset by 1970-1900.
Tim Lister said:
Given that one of the time servers provides the IRIG-B signal for the 400 Hz
control loop for the drives for a ~20 ton 2-meter diameter telescope, I'm not
keen on a homebrew Raspberry Pi solution however much I like them for my own
time-nut home use...
Does that care about the date? Or can you modify that code?
If you can run ntpsec, I can teach it to fix the WNRO problem from selected
servers. That would let you use the old/broken Symmetricomm gear to provide
time to Linux or FreeBSD systems.
--
These are my opinions. I hate spam.
Thanks to all, but what I am trying is to update an old Magnavox Gps Engine receiver, part of a Trak Systems 8812.
I use the 8812 for TOD in uhf radio testing.
For testing purposes, even with WNRO issue it works but isn't aligned to real TOD !
I got the new firmware but the procedure belong to 8820 where the main board is different, so useless.
The other idea, is to replace the GPS Engine with an other Magnavox receiver and to connected the EMEA-0183 (magnavox) to the trak ! I did some reverse engineering around the gps engine so I know how to do it.
Because of this I got an MX 4200D (this was another nightmare because of wrong documentation on the web !!!) But the firmware on 4200D (D35) seems not the latest...
Ottenere Outlook per Androidhttps://aka.ms/AAb9ysg
From: Hal Murray via time-nuts time-nuts@lists.febo.com
Sent: Wednesday, October 5, 2022 4:19:09 AM
To: time-nuts@lists.febo.com time-nuts@lists.febo.com
Cc: Hal Murray halmurray@sonic.net
Subject: [time-nuts] WNRO fixup
Bob kb8tq said:
Simple answer: Run an external piece of software to correct the issue. It???s
by far the simplest solution. ( no, it???s not trivial ???.. )
The code to do the fixup can be simple. The trick is that you need the time
in seconds-since-tzero rather than year-month-day. POSIX uses seconds since
1970.
If you are on a POSIX system, you can use mktime and gmtime to convert back
and forth.
Here is the fixup code:
while (gps_time < magic_constant)
gps_time += 1024*seconds_per_week
The magic_constant is the time stamp for when the software was built.
You can get that from date +%s
The fixup code will work for 1024 weeks after the date corresponding to
magic_constant.
That's close to 20 years.
If you are working inside ntpd, NTP time starts at 1900 so the magic_constant
has to be offset by 1970-1900.
Tim Lister said:
Given that one of the time servers provides the IRIG-B signal for the 400 Hz
control loop for the drives for a ~20 ton 2-meter diameter telescope, I'm not
keen on a homebrew Raspberry Pi solution however much I like them for my own
time-nut home use...
Does that care about the date? Or can you modify that code?
If you can run ntpsec, I can teach it to fix the WNRO problem from selected
servers. That would let you use the old/broken Symmetricomm gear to provide
time to Linux or FreeBSD systems.
--
These are my opinions. I hate spam.