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

[Brian Morgan <oopfan@xxxxxxxxxxxxx>]

All,

Thankfully I had clear skies last night for testing.

(Please let me know if sending attachments is forbidden or bad etiquette.)

In the attachment "chrony-tracking-poll-7" I zoomed in on a star field. 
Figures A and B were taken about 1 hour apart. Figure A contains the 
roundest stars. As I learned later this was due to stable ambient 
temperature. Figure B is an unusual case where the temperature gradient 
was 2C per hour.

A note about my equipment: Unlike 99% of astrophotographers I do not 
actively guide, meaning that I do not have a secondary telescope with 
its own camera dedicated to guiding. With active guiding, software like 
PHD2 analyses the position of stars and sends commands to the mount to 
correct for deviations. I, on the other hand, rely completely on my own 
software to drive the stepper motor to compensate for what is called 
Periodic Error (PE). It does not accept commands from PHD2 to make 
corrections -- it is on its own, running blind if you will. In an ideal 
world the mount's gears are perfectly machined. In the real world, 
depending on how much you are willing to pay, the amount of error is 
quite high, high enough to produce severely elongated stars in long 
exposures. That means that I drive the motor at a constantly changing 
rate, this is called Periodic Error Correction (PEC). PEC is not perfect 
but it is what I rely on. Chrony is now an integral part of my PEC solution.

Figures A and B are both 8 minute exposures. The period of my mount's 
worm gear is 8.5 minutes so you are seeing the full extent of my 
periodic error.

The last attachment "PacMan_Ha_7x8m_bin2_no-drizzle" is a stack of seven 
8-minute exposures of NGC 281 taken in Hydrogen-alpha (6nm bandwidth).

Thank you for all your help. I am going to change chrony config from 
poll 7 to poll 6.

Brian


On 10/1/2019 9:22 AM, Miroslav Lichvar 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.

Attachment: chrony-tracking-poll-7.jpg
Description: JPEG image

Attachment: PacMan_Ha_7x8m_bin2_no-drizzle.jpg
Description: JPEG image