Andrew replied to the topic 'Calculate and Apply Custom Tracking Rates from Ephemeris Data' in the forum. yesterday

Thank you Jasem and Wouter!
It might be possible to calculate the dRA and dDec from the Orbital elements information provided by VSOP87, but as far as I know these are black boxes to me. I attempted to research how they are calculated but came up empty.


Andrew replied to the topic 'Calculate and Apply Custom Tracking Rates from Ephemeris Data' in the forum. yesterday

I found that the JPL Solar System Dynamics - Horizons System will provide difference in RA and Dec rates for minor bodies in units of Arcsec/hour. Converting them to Arcsec/s by a factor of 3600 and adding that to the Sidereal Rate (RA:15.041 & Dec:0) as a custom tracking rate would make it possible to easily follow moving targets such as comets and asteroids. I would not be surprised if this information is already available with the service KStars is using to get Comet and Asteroid positions.

The JPL SSD - Horizons system can be accessed via a web interface, Telnet service, and Email service. My wish is for KStars to fetch the current differential tracking rate via telnet and apply it as a custom rate automatically when tracking monor bodies. Lunar tracking could also be made more accurate by accounting for DEC rates that vary slightly at different latitudes due to parallax.

From the example below:

Date__(UT)__HR:MN     dRA*cosD d(DEC)/dt
 2019-May-23 00:00 *   29.25040  -38.5810
dRA*cosD=29.25040 arc"/hour = 0.0081251 arcs/s
Custom RA Rate: 15.041+0.0081 = 15.049
Custom Dec Rade: 0 + -0.0107

Example object information:
Ephemeris / WWW_USER Thu May 23 03:01:37 2019 Pasadena, USA      / Horizons    
Target body name: 123P/West-Hartley               {source: JPL#K192/3}
Center body name: Earth (399)                     {source: DE431}
Center-site name: (user defined site below)
Start time      : A.D. 2019-May-23 00:00:00.0000 UT      
Stop  time      : A.D. 2019-Jun-22 00:00:00.0000 UT      
Step-size       : 1440 minutes
Target pole/equ : No model available
Target radii    : (unavailable)                                                
Center geodetic : 284.330000,45.4200000,0.0000000 {E-lon(deg),Lat(deg),Alt(km)}
Center cylindric: 284.330000,4484.46453,4520.2328 {E-lon(deg),Dxy(km),Dz(km)}
Center pole/equ : High-precision EOP model        {East-longitude positive}
Center radii    : 6378.1 x 6378.1 x 6356.8 km     {Equator, meridian, pole}    
Target primary  : Sun
Vis. interferer : MOON (R_eq= 1737.400) km        {source: DE431}
Rel. light bend : Sun, EARTH                      {source: DE431}
Rel. lght bnd GM: 1.3271E+11, 3.9860E+05 km^3/s^2                              
Small-body perts: Yes                             {source: SB431-N16}
Atmos refraction: NO (AIRLESS)
RA format       : HMS
Time format     : CAL 
EOP file        : eop.190522.p190813                                           
EOP coverage    : DATA-BASED 1962-JAN-20 TO 2019-MAY-22. PREDICTS-> 2019-AUG-12
Units conversion: 1 au= 149597870.700 km, c= 299792.458 km/s, 1 day= 86400.0 s 
Table cut-offs 1: Elevation (-90.0deg=NO ),Airmass (>38.000=NO), Daylight (NO )
Table cut-offs 2: Solar elongation (  0.0,180.0=NO ),Local Hour Angle( 0.0=NO )
Table cut-offs 3: RA/DEC angular rate (     0.0=NO )                           
Initial IAU76/J2000 heliocentric ecliptic osculating elements (au, days, deg.):
  EPOCH=  2457126.5 ! 2015-Apr-14.0000000 (TDB)    RMSW= n.a.                  
   EC= .449300743971303    QR= 2.125967382318402   TP= 2455748.0628062398      
   OM= 46.53866425047554   W= 102.894694868525     IN= 15.35366879558836       
  Equivalent ICRF heliocentric equatorial cartesian coordinates (au, au/d):
   X= 4.657105285458996E+00  Y=-1.941203038292526E+00  Z=-2.417870194368305E+00
  VX= 2.829504245640315E-03 VY= 4.087231519282237E-03 VZ= 2.101437381881136E-03
Comet physical (GM= km^3/s^2; RAD= km):                                        
   GM= n.a.                RAD= n.a.                                           
   M1=  8.2      M2=  13.8     k1=  18.    k2=  5.      PHCOF=  .030           
Comet non-gravitational force model (AMRAT=m^2/kg;A1-A3=au/d^2;DT=days;R0=au): 
   AMRAT=  0.                                      DT=  0.                     
   A1= -2.738727331161E-9  A2= 7.358073592186E-9   A3= 0.                      
 Standard model:                                                               
   ALN=  .1112620426   NK=  4.6142   NM=  2.15     NN=  5.093    R0=  2.808    
 Date__(UT)__HR:MN     dRA*cosD d(DEC)/dt
 2019-May-23 00:00 *   29.25040  -38.5810
 2019-May-24 00:00 *   29.85669  -38.5969
 2019-May-25 00:00 *   30.45272  -38.6091
 2019-May-26 00:00 *   31.03869  -38.6178
 2019-May-27 00:00 *   31.61476  -38.6231
 2019-May-28 00:00 *   32.18106  -38.6252
 2019-May-29 00:00 *   32.73773  -38.6242
 2019-May-30 00:00 *   33.28488  -38.6202
 2019-May-31 00:00 *   33.82260  -38.6134
 2019-Jun-01 00:00 *   34.35094  -38.6037
 2019-Jun-02 00:00 *   34.86987  -38.5912
 2019-Jun-03 00:00 *   35.37933  -38.5760
 2019-Jun-04 00:00 *m  35.87914  -38.5580
 2019-Jun-05 00:00 *m  36.36908  -38.5373
 2019-Jun-06 00:00 *m  36.84890  -38.5137
 2019-Jun-07 00:00 *m  37.31837  -38.4874
 2019-Jun-08 00:00 *m  37.77730  -38.4582
 2019-Jun-09 00:00 *m  38.22559  -38.4262
 2019-Jun-10 00:00 *m  38.66329  -38.3915
 2019-Jun-11 00:00 *m  39.09052  -38.3541
 2019-Jun-12 00:00 *m  39.50754  -38.3143
 2019-Jun-13 00:00 *m  39.91468  -38.2721
 2019-Jun-14 00:00 *m  40.31235  -38.2277
 2019-Jun-15 00:00 *m  40.70099  -38.1814
 2019-Jun-16 00:00 *m  41.08109  -38.1333
 2019-Jun-17 00:00 *   41.45310  -38.0835
 2019-Jun-18 00:00 *   41.81747  -38.0322
 2019-Jun-19 00:00 *   42.17459  -37.9795
 2019-Jun-20 00:00 *   42.52481  -37.9256
 2019-Jun-21 00:00 *   42.86841  -37.8705
 2019-Jun-22 00:00 *   43.20564  -37.8143


Andrew replied to the topic 'ALS - Astro Live Stacker' in the forum. 4 days ago

Great work. I look forward to using this at public star parties I volunteer at.
Are the debayered images correcting for the RGGB green bias? If not it won't be as well received in public sessions.


Andrew replied to the topic 'Autoguider subframe automation' in the forum. 7 days ago

Guiding in EKOS already supports subframing. The check box for subframing in the guide module. Assuming your guide camera supports it, once a star is selected from the full field, it should crop down.


Andrew created a new topic ' Re: Old Sat Tracking script' in the forum. 7 days ago

There was a python script for attempting to track satellites written a few years back by user Farom.

The script no-longer appears to work properly with ongoing developments. Specifically there are problems importing PyIndi and a depreciated file causing an import error for

I would like to get it working again, but coding is not my field of expertise. But I have attempted to make changes to the Geographic Location portion to get Lat/Long by parsing NMEA sentences straight from the GPS. I think it's ok, but I could use a second opinion.
It would also be nice if the TLE information could be fetched automatically.

Here is the Python3 script. Thanks in advance

# --- Settings ---
# Change following parameters according to your need

# Geographic location
import serial
port = "/dev/tty0"
def parseGPS(data):
   if data[0:6] == "$GPRMS":
      sdata = data.split(",")
      latitude = decode(sdata[3])
      longitude = decode(sdata[5])

# Satellite TLE (can be retreived on
TLE_line_1 = '1 25544U 98067A   19136.87606988  .00001918  00000-0  37995-4 0  9998'
TLE_line_2 = '2 25544  51.6418 156.7644 0001513   1.2176  59.1588 15.52681763170397'

# INDI settings
host = 'localhost'
port = 7624
driver_name ="Telescope Simulator"

# Script settings
update_delay = 1 # delay in s between updates

# --- Code ---
import PyIndi
import time
import sys
import threading
import ephem
from math import pi

# default client
class IndiClient(PyIndi.BaseClient):
    def __init__(self):
        super(IndiClient, self).__init__()
    def newDevice(self, d):
    def newProperty(self, p):
    def removeProperty(self, p):
    def newBLOB(self, bp):
    def newSwitch(self, svp):
    def newNumber(self, nvp):
    def newText(self, tvp):
    def newLight(self, lvp):
    def newMessage(self, d, m):
    def serverConnected(self):
    def serverDisconnected(self, code):

# connect the server
print("Connection to " + host + ":" + str(port) + " ... ", end='')
if (not(indiclient.connectServer())):
    print("No indiserver running on "+indiclient.getHost()+":"+str(indiclient.getPort()))

# get the telescope device
print("Get driver '"+ driver_name + "' ... ", end='')
while not(device_telescope):

# wait CONNECTION property be defined for telescope
print("Wait CONNECTION property be defined ... ", end='')
while not(telescope_connect):

# if the telescope device is not connected, we do connect it
if not(device_telescope.isConnected()):
    print("Driver not connected, try to connect it ... ", end='')
    # Property vectors are mapped to iterable Python objects
    # Hence we can access each element of the vector using Python indexing
    # each element of the "CONNECTION" vector is a ISwitch
    telescope_connect[0].s=PyIndi.ISS_ON  # the "CONNECT" switch
    telescope_connect[1].s=PyIndi.ISS_OFF # the "DISCONNECT" switch
    indiclient.sendNewSwitch(telescope_connect) # send this new value to the device
    while not(device_telescope.isConnected()) and t>0:
    if not(device_telescope.isConnected()):
        print("Failed to connect the driver")

# We want to set the ON_COORD_SET switch to engage tracking after goto
# device.getSwitch is a helper to retrieve a property vector
print("Set tracking mode ... ", end='')
while not(telescope_on_coord_set):
# the order below is defined in the property vector, look at the standard Properties page
# or enumerate them in the Python shell when you're developing your program
telescope_on_coord_set[0].s=PyIndi.ISS_ON  # TRACK
telescope_on_coord_set[1].s=PyIndi.ISS_OFF # SLEW
telescope_on_coord_set[2].s=PyIndi.ISS_OFF # SYNC
while not(telescope_radec):

# Configure PyEphem
print("Configure PyEphem ... ", end='')
obs = ephem.Observer()
obs.lon = longitude = latitude
satellite = ephem.readtle('TARGET',TLE_line_1,TLE_line_2)

while 1:
    # compute satellite coordinates =
    print("    RA: ",satellite.ra)
    print("    DEC:",satellite.dec)
    print("    ALT:",satellite.alt)
    print("    AZ: ",

    # We set the desired coordinates


When I run the script, this is what I get back
Traceback (most recent call last):
  File "", line 26, in <module>
    import PyIndi
  File "/home/astropi/.local/lib/python3.5/site-packages/pyindi_client-0.1.0a1-py3.5-linux-armv7l.egg/", line 28, in <module>
    _PyIndi = swig_import_helper()
  File "/home/astropi/.local/lib/python3.5/site-packages/pyindi_client-0.1.0a1-py3.5-linux-armv7l.egg/", line 24, in swig_import_helper
    _mod = imp.load_module('_PyIndi', fp, pathname, description)
  File "/usr/lib/python3.5/", line 242, in load_module
    return load_dynamic(name, filename, file)
  File "/usr/lib/python3.5/", line 342, in load_dynamic
    return _load(spec)
ImportError: cannot open shared object file: No such file or directory


Andrew replied to the topic 'What is the right way to control meridian flips?' in the forum. 1 week ago

I also agree that the global control for meridian flip should only be located in the mount tab. Keep it simple.
Also, if it's not too off topic. Re:EQMod Target Pier side, when enabled areas of the sky become 'unreachable'. In that event it should ignore target pier side and slew normally.

Thanks all for all your hard work.


Andrew replied to the topic 'EKOS focus module' in the forum. 4 weeks ago

In-camera temperature readings do not reflect ambient temperature. They measure the sensor, which will warm up from use.


Andrew replied to the topic 'Encoder motor focuser' in the forum. 4 weeks ago

Interesting. I wonder what would be required to DIY a compatible motor controller.


Andrew created a new topic ' Encoder motor focuser' in the forum. 4 weeks ago

Q: Has anybody considered using a motor with a built in encoder as an alternative to a stepper motor for an absolute motorized focuser?

I can think of at least a couple advantages. Namely I expect they will run quieter and faster and provide accurate position feedback, while a stepper can skip steps and lose accuracy.

An example of a motor that got me thinking about them:


Andrew replied to the topic 'Powered USB Hubs' in the forum. 4 weeks ago
Alfred thanked Andrew in topic guide module (internal) 1 month ago

Andrew replied to the topic 'polar alignment moved????' in the forum. 1 month ago

Jasem. Based off of what I have seen, the polar error reported by PHD2 agrees almost exactly with the remaining error I have after the PAA routine. At least within ± 10 seconds