I recently picked up a Symmetricom SyncServer S350 with a Rubidium oscillator and PTP option, thinking I’d gotten a steal. It turns out that the GPS is affected by a week number rollover bug, and will take some hacking to get it to sync.
I have noticed that, set up to just run as a stratum 2 NTP server for now, the Rubidium oscillator went into lock. It’s not immediately clear to me if it’s free-running, or if it’s actually being driven by NTP. If the latter, it got me curious how well this would work. Would I benefit from the short- (and even medium-term) stability of Rubidium, while NTP keeps it long-term accurate? Or is the ~1ms ballpark accuracy of NTP going to forever limit absolute accuracy? I’m wondering if there could be any value in putting this into a colo facility where it wouldn’t have a view of the sky, to forever run at stratum 2, or if it’d be no better than a regular PC.
I have a Symmetricom S200 that suffers from the same week rollover problem and cannot lock onto sattelites and therefore cannot obtain its time from them.
With a replacement GPS module (Furuno GT-8736) i can get a satellite lock. However, the hardware clock never seems to synchronize with GPS for some reason.
Please check experiences of other people on upgrading/updating symmetricom units on this forum.
To answer your question, stability will be better than regular PC. However, the timing source of the S350 is a source with an error larger than the GPS module has. Surely it makes sense to find a replacement GPS module that doesnt suffer from the week rollover problem.
It’s designed for your use case - you have a PPS that has a decent frequency but no connection to the proper offset. I have a blog post about it: NTP server frequency stability
I had come across this PDF from Furuno which mentions that the GT-8031 can keep working if the date is manually set, but it’s light on details. Only last night did I realize that the GPS board is actually a Pentar SA101, with a chip on the underside. It look like the Pentar sits in front of the GT-8031 and makes it look like a Motorola GPS. So I’m guessing that’s why there’s not an easy fix to extend the life of these GPS units.
It’s also unclear to me if the Rubidium oscillator is actually being steered by NTP or is just free-running. This doesn’t inspire a lot of confidence:
ntpdc> loopinfo
offset: 0.000703 s
frequency: -105.277 ppm
poll adjust: 18
watchdog timer: 398 s
It would be interesting to get the GPS set up again while it’s doing NTP and see if things stabilize.
Where did you get the GT-8736? I’m having a hard time finding anywhere selling them. I’d also love a multi-constellation receiver, but I’m not sure anyone is making them with what I’m inferring is Motorola Oncore compatibility.
I believe the Meinberg LANTIME systems has a mode where they do an NTP query every second (always) to get more accurate time and then use that to steer the local oscillator.
It seems plausible that you can get “better than 1ms” with enough NTP queries and math…
I ultimately took Kets_One up on his offer and have a replacement GPS coming my way. I like the idea of PPS from GPS + NTP for time of day, but if I can get the thing doing native GPS, that’s even better.
In the current “NTP appliance with an onboard rubidium oscillator claiming it’s locked, but getting time from the Internet” state, I’m unclear what it’s using for system time, but it’s not looking great:
My understanding is that a free-running rubidium oscillator should have way, way less than 70ppm of frequency error.
I had wondered what would happen if I put this in a data center, where GPS would be unavailable (or at least unaffordable). What I hoped would happen is that rubidium would give me excellent short-term stability, and NTP would guard against long-term drift. In actuality, it doesn’t look any better than a commodity PC.