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

[ Thread Index | Date Index | More Archives ]


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.


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

Mail converted by MHonArc 2.6.19+