Autostar II Firmware was updated from 4.2g to 4.2G v19 on 2013-11-22 in order to access two critical enhancements :

• 10x finer tracking rate  
  10x finer Custom Tracking Rate adjustment to 0.01% of sidereal allows adjusting custom tracking rates to greater precision
  

• Save tracking rate 
  Restore Custom Tracking Rate at Power Up. Default operation of the Autostar is to reset the Tracking Rate to Sidereal upon power-up.

This was performed as part of a Nov 2013 Imaging Improvement Plan.  The workflow used was as follows:

USB Ports on USB Hub (from Left to Right) :

Following upgrade for Autostar II to 4.2G v19,  reinstallation of drivers for Prolific Serial-USB  adapter, and a number of enhancements and changes to my Observatory Software (including a new Observatory Tool Bar and access to Aurora Cloud Sensor data), a full systems test was carried out.  This was to check this everything was working together ok and that software was generally robust. 

- Observatory Program was started in debug mode
- COM port for LX200 telescope communication was updated to point to COM7 
- Telescope, CCD Camera and Cloud Sensor were started and connected to Observatory Program
- TPoint mapping run of 48 points was performed until cloud developed ending the session

Despite the deteriorating weather conditions the session (S556a) was judged a success.   Debugging mode caught an error (which would have otherwise caused  the program to crash).  A "try, catch end try"  coding was added and the program continued.  Underlying error related to the monitoring of Temp and  Star Elongation.   A further issue was noted with the Scope Monitoring not able to log scope position when TheSky is performing an image link.

TPoint Mapping was conducted by using automated routine , but with progress monitoring by indoors computer.   
Mapping was curtailed when cloud began to develop and there was insufficient stars to link/map in the last 16 attempted frames and a remaining 12 points were cancelled

• The mapping comprised :
  
  - Initial set of 8 points within 2 arc deg distance of Altair
  - a main set of points spread across the sky  with limits of Dec < 68 deg and Alt > 20 deg.
  

• A breakdown of the mapping runs is shown in the table below. 
  
  Of the 74 target points attempted, 26 points failed (largely due to link or map link failure due to cloud), leaving 48 points that were successfully mapped.
  
  Session logs showed that 2 points whilst initial linking ok (using my enhanced link algorithm), proceeded to get a map link through TheSky.Automap routine which can be shown to be technically invalid due to the rotation angle of the linked image being invalid given the alignment of the camera's CCD. This was not recognized before using the points in the TPoint Modelling and analysis below.  (Note  The 2 points are not the same 2 points that were rejected during TPoint analysis).
  
  A further 4 points whilst initially linking ok, failed to map with Map Failure error "Attempt to Slew beyond Dec Limit of +66 00 00.00" This message is strange since the slew to point had already taken place by this point. and the declination was less then 60 deg. In at least one case  the declination was 53 deg).  It would seem that Map Link had probably failed, but the error message given is somehow misplaced.  Checking the code indicates that a previous error message was being given, and was not be updated with the actual error message.
  

  Map Set No.	1)	2)	3)	Total
  Set Description	Initial set of  points near Altair	1st Set of  all-sky points	2nd Set of  all sky points
  Programmed Points	8	47	47	102
  Rejected points / Slew Failure (point below local horizon)	0	2	0	2
  Rejected points / Beyond Hard-Code Dec Limit	0	7	7	14
  Cancelled points (due to cloud)	0	0	12	12
  Imaged Points	8	38	28	74
  Mapped Points (*)	8	27	11	48
  Failed Points	0	11	17	26
  Map Success Rate	8 /8 (100%)	27 /38  (71%)	11 / 28  (39%)	46 / 74  (62%)
  Reasons for map failure
  Link Failure due to cloud	0	3	16	19
  Map Link Failure	0	6	6	7
  Mapping that should have been rejected due to discrepancy in rotation angle (*)	0	(2)	0	2()

   

• Across the entire sky the RMS error without model was determined to be 8.6 arc min.  
  
  This compares fairly closely with an RMS slew error of 6.1 arc min for 60 targets during an observing session without TPoint three weeks before (2013-11-01 S552). Of these points around 50% had errors in the range 6 - 10 arc mins, and the targets were probably less spread-out, than the mapping targets.
  

• 12  alternate TPoint models were created with generally progressively lower RMS and PSD (see table below).  
  
  Using 12 terms including Tube Flexure, MA, ME  and four harmonic terms (Model 8) reduces the RMS error to 0.9 arc min.   
  Adding further additional harmonic terms (Models 9 & 10) doesn't produce any improvement in fit (in fact the the match deteriorates)
  
  Since the LX-200’s control system does refraction calculations automatically, Pressure and Height were set to zero in the Observing Parameters dialog in order to forces TPoint to ignore its refraction calculations.
  
  

 

 

The TPoint mapping run described above was used to analyze the Polar Alignment of the LX200 Mount

• The Polar Alignment indicated by alternate TPoint models is fairly consistent in Azimuth (MA -68 to -73)  but there is more uncertainty in Altitude ( ME between +42 and +198).
  
  It is noted that excluding tube flexure and including more harmonic terms it is possible to get a similar low overall RMS value, but with a negative ME value of -289.  This is significantly different :  models that include tube flexure suggest raising the polar axis whilst the the model that excludes Tube Flexure suggests lowering the polar axis.
  However in creating the alternate models it was very obvious that Tube Flexure term single handedly improved model fit to data more than any other single term.
  
  [The TPoint Users Guide states that additional harmonic terms must be added to the TPoint model for the polar alignment information to be accurate. When you can achieve 30- to 40-arc seconds RMS value by using the Suggest Terms (Add Harmonics dialog box) you will have accurate polar alignment information from TPoint.]
  
  Test suggest the optimum data fit comes with 4 additional harmonic terms (Model 8)
  ME/MA values indicate that Polar Axis should be rotated clockwise by 2.1 arc mins and raised by 2.7 arc mins.
  
  Several models suggest raise the Polar Axis by only 1.9 to 2.2 arc mins, ount
  

• Looking at advice from Tom Bisque on Software Bisque Tom's Corner
  
  Do not add the tube flexure term until after you have added additional terms. As is the case with the polar alignment information reported BEFORE adding any additional terms the data cannot be fully trusted. Try fixing the system with several additional terms using the terms wizard first then add the Tube Flexure term LAST. You may even find it does little to nothing!
  
  
  Models 11 and 12 (either not adding Tube Flexure or adding it last) as suggested by Tom Bisque's advice, would suggest raising Polar Axis by only 0.7 to 1.8 arc mins.  With this in mind it is 

  it is proposed to make the following changes to the mount, on the next suitable night
  
  

  Action

  Rotate polar axis eastwards by 2.3 arc mins (i.e. clockwise)

  Raise polar axis by 1.5 arc mins

   
   The planned procedure is as follows 

  Code	Actions	Notes
  1	Slew to suitable starfield in southern sky  (close to Dec 0),	Should contain a reasonably bright star for quick 1sec frames during mount/wedge adjustment and sufficient stars in a 5-10s image for  getting a good image link
  2	Take 5-10s Baseline image and perform image link	From this we can determine the scope's precise position before adjustment (this provides some safety in the event that star position is lost during adjustments to the mount/wedge.
  3	Determine altitude of the bright star in image
  3	Jog Scope to move the bright star to a position that is precisely cosine (altitude) * 2.3 arc min west of CCD image centre (see note) and 1.2 arc min south of the image centre (For a south-up raw imaging star will be to position to upper left of image centre).	We position star to west of image center so that star will be re-centered when mount is rotated clockwise We position star to south of image center so that star will be recentered when polar axis is raised, (which causes our southerly directed scope to move south
  4	take 5-10s image, perform image link	Compare to baseline image and confirm that star is in correct starting position
  5	without jog scope or using handset,  adjust wedge and mount so that star becomes precisely re-centred in the image.
  6	take final 5-10s image, perform image link	Compare final image with base line image and confirm that required adjustment has been made

   

  From my latitude a star positioned on meridian at Dec 0  will have an altitude of 32.68 (90-57.32).   Cosine (32.68) is 0.8417 .
  This means that the scope needs to be pointing 1.94 arc min east of star (from 2.3 x 0.8418) before polar adjustment begins.
  
  

A star at Dec 0 in the southern sky was monitored  for 16 mins, during which time the star drifted westwards at an overall rate of around 0.7 arc secs/min.
This means that scope is tracking too slowly.  The star was then monitored  for a 3 further 16 min periods during which the star continued to drift westwards at overall rates of 1.3 arc sec/min, 0.5 arc sec/min, and 1.0 arc sec/min

The mean rate of drift over the 4 intervals is westwards at  0.9 arc sec/min (ie - 0.9 arc sec/min)

During these intervals the precise star position was analyzed at 13 sec intervals. This provided 161 measurements of the tracking drift over approximately 8 minute period intervals (see graph below). Mean drift was 0.97 arc sec/min (range 0.0 to 2.3, SD 0.47). 

Scatter is graph data assumed to be due to a mixture of residual periodic error and imperfections in the RA gear.  An overall tracking drift of -0.9 arc sec/min is generally supportable.  In order to speed up the scope a positive tracking rate adjustment is required.  This would normally be +0.9 (in practice +1), but since the x10 finer tracking rate patch has been included in the Autostar II firmware upgrade to 4.2G, the required tracking rate adjustment is +9.

Tracking Rate in Autostar II was duly updated to a custom value of +9.   
The setting will be checked at start of next session to confirm that the tracking rate has been preserved between power cycles.

Notes collected from Internet : The *unpatched* tracking rate adjustment is very close to being units of "arcseconds of drift per clock minute" So if a star drifts eastward (i.e. scope too fast) two arcminutes in 15 wall-clock minutes, you'd want to use a Custom value of 2*60 (to give arcseconds) divided by 15 (clock minutes): 2*60/15=8 Since the scope is "too fast", you want a negative Custom value to slow it down. So "-8" is the desired setting. If you have the patch installed, that becomes -80.

The (unpatched) Tracking Rate Custom is in units of tenths of a percent compared to (what the Autostar calls) normal sidereal.  Part of the 10x Finer patch is a change of the prompts from: 'Enter Rate Adj.' to '.01%'s sidereal'

If the polar axis is off by (say) 0.5 deg, the tracking rate could be out by a factor of cos(0.5) = 0.99996.

In the previous session (S556b) it was estimated that Tracking rate was running too slow by 0.09% of sidereal and a Custom RA Tracking Rate adjustment of +9 was entered into Autostar II before parking the scope and powering down.  Normally (with 4.2g firmware) the tracking adjustment would be lost when scope was powered down, but with the upgrade to 4.2G it was expected that the settings would be retained to the next session.

Session S557 began by examining the RA tracking setting in Autostar II - it showed Custom Tracking with a value of +9.  This indicated that the setting had apparently been preserved as expected.   However there remains some uncertainty whether the saved Custom Tracking Rate is actually being correctly applied from start-up.

Initial tracking rate measurements (8 min moving average) showed that a star at Dec 0 in the southern sky was drifting west at 3.5 arc secs/min. Whilst some variation in measurements was expected (S.D. of 0.5 over 8 min period determined in the last session), the difference from expectation (which was no or little drift) was unreasonably large.  The initial thought was that I must have the sign wrong, and made a second run with tracking rate adjustment set to -9.  In this run the star drifted west at -1.8 arc secs/min.    Further runs were then made with tracking rate adjustment set to +29, +20, +14, +13.

Results of these runs and the previous runs from last session are shown in the graph below.   A best fit line shows that correct sidereal tracking tracking requires a tracking rate adjustment of +11.  This compares reasonably well with the estimate of +9 from the previous session.

Although the scope had been powered down at end of last session with a Tracking Rate adjustment of +9 it behaved on power up as if it had a tracking rate adjustment of around -20 (despite showing a value of +9 on the Autostar II screen).     

The scope was powered down at end of session S557 with a Tracking Rate adjustment of +13.   Tracking rate will again be examined at start of next session to test whether the problem was just a first use issue or whether the problem is more persistent.   After this the tracking rate will be set to +11 and the Tracking Rate measured again.  Residual Periodic Error (after PEC corrections) will mean that tracking will never be perfect, however the aim is to use a RA tracking rate adjustment that cancels the mean RA drift.

Polar alignment adjustment was made in both azimuth and altitude based on the misalignment estimates made in previous session

Star in southern sky at approximately Dec 0 was centered in the FOV.  The scope was then jogged by required amounts in RA and Dec. Finally azimuth and altitude adjustments to wedge were made to recenter the star.  Process is illustrated by the following pictures (South Up).