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

[Brian Morgan <oopfan@xxxxxxxxxxxxx>]

Professor Unruh,

The FOV of figures A&B is 5 arcmin high and 3 arcmin wide.

I think you are right about the atmosphere. NCP is up in the images 
therefore RA is left/right. Smearing occurred left/right which suggests 
RA tracking. I am at latitude 42N and at the time of capture left/right 
in the image was very close to up/down relative to the horizon.

Thank you for pointing that out.

Brian

On 10/5/2019 3:48 PM, Bill Unruh wrote:
> I estimate that the clock would have to be out by about a second to 
> give that
> smearing of the star trails (10-15 arc seconds). That is really 
> unlikely over
> 8 min for chrony.
>
>
>
>
> William G. Unruh __|_ Canadian Institute for|____ Tel: +1(604)822-3273
> Physics&Astronomy _|____ Advanced Research _|____ Fax: +1(604)822-5324
> UBC, Vancouver,BC _|__ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> Canada V6T 1Z1 ____|_____ and Gravity ______|_ www.theory.physics.ubc.ca/
>
> On Sat, 5 Oct 2019, Brian Morgan wrote:
>
> > 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.

--
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.