I'm still trying to hunt down the clock problem, as unlike an above poster I do think this is the reason the GPS won't go from yellow to green (though I don't yet have any firm information on this, other than configuration information: In the web UI, the STIM # 106 says the internal clock gets its time from Time).
In any case, I can confirm that basically something is resetting the clock
exactly every 60 second. This is not the hardware rtc (which for me, defaults to Jan 1 1970 epoch). You can actually look at some of this with /proc/interrupts:
0: 323496 ADS_ext_IRQ
26: 502791 timer
27: 0 rtc timer
30: 18 rtc 1Hz
31: 0 rtc Alrm
I can confirm that "rtc 1Hz" is the number of times I have accessed the RTC with
hwclock. You can easily confirm this.
I was interested to note that (I need to state this carefully): the time the clock resets back to every 60 seconds, is the timestampped value of /etc/adjclock. It didn't seem like changing the timestamp on this had any effect, so I just moved it to the side.
I thought this was the end of this route. However, 30 minutes later (again, exactly) the file was recreated with the timestamp 30 minutes later, but now with zeroed contents (0.000000 0 0.0000000 / 0 / LOCAL).
Note that all of this was carried out with all of the time-related processes and local GUI processes killed. So either this is a driver, something kernel level, or elgato (the server itself) doing this.
edit 1:More notes. It looks like
/dev/receiver is a pointer to a UART where the GPS dumps raw information. Maybe.
In any case, looking at /dev/ram0 shows:
ttyS0 at I/O 0xf0100000 (irq = 50) is a 16550A
ttyS1 at I/O 0xf0120000 (irq = 51) is a 16550A
ttyS2 at I/O 0xf0140000 (irq = 52) is a 16550A
ttyS3 at I/O 0xf0160000 (irq = 54) is a 16550A
So these are all UART-things.