Sure. chrony disciplines both the time and the frequency and does so
(once it
has fallen into sync) quite smoothly. The biggest problem is that you are
running the gps in NMEA mode, rather than PPS mode, and NMEA tends to
have
much higher jitter-- a gps device issues the nmea sentence in "spare
time" and
the serial link is slow, so if the sentences are of different lengths,
the
time to transmit more or fewer characters add up to ms., rather than
microsec.
jitter. But it is not at all clear that makes a difference to your
application. The telescope stops moving for 40ms and then jumps
anyway, so if
that stop is 42ms rather then 38ms say, it won't make a difference, as
long as
the total jump in say a second is within a microarcsec. Note that it is
probably better if you have a longer rather than shorter poll time for
the
gps, since the frequency discipline tends to be better. However, I
suspect
this is also "straining at gnats" since at present your system is out
by about
30 PPM while with a properly disciplined clock it would be more like
1PPM of
less ver the short term, and much better than that over the longer.
(Over a
night, the difference should be less than a few milli-arc sec.)
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, 28 Sep 2019, Brian Morgan wrote:
Hello everyone,
Last night I successfully installed Chrony and GPSD on a Raspberry Pi
3B with the great
assistance of many discussions I found on the Internet. I discovered
a gentleman who appears
to have an application similar to mine. I've looked over his
chrony.conf and looked up the
commands and options in the Chrony docs:
driftfile /var/lib/chrony/drift
makestep 1 10
keyfile /etc/chrony/chrony.keys
commandkey 1
allow
refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2
I think it would be helpful to describe my application:
I use the RPi + Adafruit MotorHAT to control a stepper motor on my
telescope's Right Ascension
axis. This is the axis that compensates for the Earth's rotation. The
50-year old German
Equatorial Mount (GEM) has a polar axis that I precisely align with
the Earth's axis. The
motor advances one step when I tell it to. The step rate is 32.8 Hz
or one step every 30.49
milliseconds. My Python software is not at all interested in absolute
time. It is interested
in time spans. Here is a snippet of my code from the stepper thread:
while True:
self.stepper.oneStep()
target = self.tracking.next()
sec_sleep = target - time.time()
if sec_sleep < 0:
print "Fallen behind!"
else:
time.sleep(sec_sleep)
This solution has worked very well for two years until, like an
idiot, I blew up the Pi with a
screwdriver. The replacement Pi's system clock runs a bit slower. I
lose about 25 arc-seconds
every 30 minutes. Furthermore I have always had issues with star
tracking deviations as the
ambient temperature fluctuates. I would like to solve these issues.
I purchased a uBlox GPS dongle. From what I see it works perfectly
and like I mentioned I now
have Chrony set the time after a reboot or power up. The Chrony docs
are extensive. I came
across "corrtimeratio" and it got me thinking about what I am asking
Chrony to do for my
application.
I calculate that I can achieve excellent star tracking when the GPS
is sampled every one to
two minutes. But like I said I am not really interested in time
accuracy just frequency
accuracy? Is this possible with Chrony? If so can you suggest a
minimally complete chrony.conf
file?
Thank you very much for your time and assistance.
Brian Morgan