I recently bought a Symmetricom SyncServer S350 off of eBay, but have had a couple of problems:
- The GPS will not go into lock. It reports that the antenna is good, and it’s seen as many as 10 satellites concurrently, pretty quickly going from position survey to position hold—but it still reports unlocked. This is seemingly due to a GPS week number rollover issue.
- Clicking on the “Timing” tab in the web UI will lock the app up. I haven’t figured this one out yet.
I came across a few interesting forum posts.
- Looking for SyncServer S350 SAASM cf card image is interesting not for the CF card image someone eventually shares, but for a number of images of the internals that are shared. It also links to…
- …this post in another thread, which details a cleverly-simple way to enable root ssh access needed for various hackery. There’s also a good discussion of the GPS cards used and the week number rollover issue.
- This post and the one after it about the Furuno GT-8031F GPS unit, which is what is in my S350.
Gallery
Week Number Rollover
GPS.gov has a page about the rollover, but in short, GPS transmits a 10-bit week number as part of the date, which means it rolls over back to 0 every 1,024 weeks. This first happened in 1999, and happened again on April 6, 2019. Almost like the Y2K bug where apps using a 2-digit year reverted to thinking it was 1900, the week number rollover caused poorly-designed GPS units to jump back 1024 weeks in time.
Based on this Furuno doc (an embedded PDF), the GT-8031 receiver in my unit was offset from this, and instead rolled over on September 18, 2022, thrusting its output date back to February 2, 2003.
So what I suspect is happening is that the GPS is correctly computing position (this I have witnessed) and outputting accurate 1PPS (I suspect), but that the reported NMEA date is in 2003 due to this error, and the SyncServer is therefore refusing to go into lock because it’s wildly wrong.
The Furuno doc above suggests that the year can be updated “by entering the date with ZDA comand,” but doesn’t give further explanation. ZDA is an NMEA command, and esr has documented NMEA here1Yes, I find some of esr’s views on other matters problematic and offensive, but these NMEA docs are not misogynistic, racist, or homophobic.. It’s noted in the Furuno docs that their equipment only suffers from rollover issues if the receiver is started up past the rollover and doesn’t have a post-rollover date in memory. It’s unclear to me at the moment what memory facilities are available—i.e., if I figure out how to set the time on this thing, will it survive a reboot?
This post (I am loving EEVBlog today!) contains PDFs of the GT-8031 hardware specs and the I/O protocol specs. It notes that the default time is January 1, 2002, but accepts values through December 31, 2079. The hardware spec sheet, dated 2005, also reports a typical 2σ time accuracy of 30ns.
As an aside, the protocol documentation also refers to enabling RTCM SC-104 DGPS data (version 2.1), though I’m not sure the SyncServer provides any support for this. (Nor do I really understand whether trying to apply differential GPS corrections to a timing receiver is useful.)
Mirrors of some of the above PDFs:
- Furuno’s Week Number Rollover Doc
- GT-8031 Hardware Specs
- GT-8031 Protocol Spec (Rev 1)
- Pentar SA101 Datasheet
- Symmetricom Field Service Bulletin about the issue
(Note to self: These are in a Rackspace Cloud Files bucket in DFW.)
Web interface restart
I haven’t yet figured out why clicking on the “Timing” tab in the web app times out (and whether it’s related to the above issue or not). After getting root on the thing it’d be interesting to debug.
In the meantime, I’ve found that logging in over ssh (username ‘admin’, default password ‘symmetricom’) and running http off, and then when that completes, http on, will restart the web app.