Re: [chrony-users] Application requires frequency accuracy but not time accuracy

[Joe Smith <joe.smith@xxxxxxxxxxxxxxxxxxx>]

Not sure if you've already looked into this or if somebody has already mentioned but perhaps a battery backed real-time clock (RTC) would help also. It should keep fairly accurate time while the Pi is off so your clock will be closer to correct time when your system starts up and should allow chrony to home in on GPS time quicker.

https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi 

Hope this helps. 

On Tue, Oct 1, 2019 at 9:22 AM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

On Mon, Sep 30, 2019 at 04:13:51PM -0400, Brian Morgan wrote:
> I just finished testing but first let me apologize for my idiotic
> expectation that Chrony should have a good estimate of the current time at
> boot-up. Not possible because the Pi is completely isolated.

It might have a good estimate of the frequency error, depending on the
clocksource and whether the calibration is stable across reboots.

> I performed this test outdoors at around 3pm with overcast skies and ambient
> temperature noticeably growing cooler. This is quite amazing. Frequency sync
> to within 10PPM after only 20 minutes following GPS fix, and then it just
> gets better.

Did you log freq or skew? Skew might be more interesting here.

> This has got me thinking. I have an under-utilized Arduino high-precision
> temperature logger. All that's to be done is to log "Freq" and then
> afterwards I can join it with the temperature data. Then I'll be able to see
> how quickly Chronyc responds to changes in ambient temperature.

If you could provide chronyd with the temperature in real time, it
could compesate for it with the tempcomp directive.

> On 9/30/2019 9:44 AM, Brian Morgan wrote:
> > degree at the celestial equator. There are 86400 seconds per solar day
> > and therefore 240 seconds per degree. This reduces to 152.97
> > milliseconds per pixel. For a target above or below the celestial
> > equator you need to multiply 152.97 by the cosine of the object's
> > declination. For the Andromeda Galaxy the declination is 41 degrees
> > north. All said and done, that is 115.45 milliseconds per pixel. So to

Shouldn't objects above the equator move slower in the view? I.e.
use division instead of multiplication?

In any case, synchronizing the clock to a hundred milliseconds
shouldn't be too difficult, even with the NMEA source alone. I'd not
care about frequency too much unless the GPS is expected to lose the
fix during exposure.

--
Miroslav Lichvar

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.