Tracking Issue

[malc-c]

OK I'm at a total loss of what to try next, or what might be the issue.

We've got a clear, warm night so I thought I would do some testing.  I started from scratch and re-polar-aligned using the EQmod polar align tool.  Then selected Vega as the 1st target and after some pressing of NSEW buttons the star was centred.  A sync pointed added and confirmed it was saved.  I then went on to sync Deneb, Altar, Caph and a host of other targets (10 in total).  I then parke dthe scope to the home position, and then unparked and selected Vega as the target.... it was nowhere in the FOV.  I would of expected Vega to of been more or less centred as it was on the 1st sync.

The clutches are locked hard, so it's not that.  The mount is belt drive so there should be better precision for goto than gears.  The mount uses a custom 4:1 ratio, and this has been set in the EQMod options.  To give you some idea of the error here's the data.

First Slew to Vega, with Vega centred in the image EQMOD readout was RA 18h 40m 03s  with a DEC of +38d 30m 8s  (CdC reported the position as 18h 37m 29s and +38d 48m 19s).  The second time Vega was chosen the initial goto took me to 18h 37m 32s and +38d 48m 05s, and after repositioning to get Vega centred EQMOD displayed 18h 35m 59s with +38d 21m 58s

Again, I'm no expert with the workings of EQmod, but as CdC give the position for Vega as 18h 37m 29s and +38d 48m 19s, which was close to the second goto position of 18h 37m 32s  for RA and  +38d 48m 05s displaid on the EQmod application, then either somthing is not sennding the correct pulses to the mount, or the mount has a fault.  Or something screwy happens with a pier flip as the second slew occured later and resulted in a meridian flip.  If the flip is the cause does this suggest the polar alignment is off ?

[chrisshillito]

Can you advise me where the EPOCH settings are in EQMod so I can try and make sure that both CdC and EQMod are singing from the same hymn sheet. 

Should be on the driver setup screen somewhere. But it really isn't a case of having CDC an EQMOD singing from the same hymn sheet - the setting doesn't change anything in EQMOD itself and is only there as a means to ensure consistency between  those apps using EMQOD (but only if they are smart enough to read the EPOCH from EQMOD and then act upon it). If CDC is the only client you're using for alignment and gotos etc then EPOCH setting really doesn't matter.

Chris.

[Lonestar70]

EQMOD calculates the current RA/DEC coordinates by looking at the motor encoder positions, the current time and your site location. In addition if there is any pointing model active (alignment points or an active sync offset) then this will also be taken into account.

When EQMOD is commanded to slew it does the same but in reverse - i.e. works out what motor positions are required to move to the specified RA/DEC coords taking into account the  location, time and pointing model. Of course moving the motors to the calculated position will take time - and in that time RA will have shifted so once the motors reach their target another goto is issued to the same coordinates (and again adjusted by the model) and this iterative process continues for up to 5 iterations and until the calculated stepper position and actual position are within a set number of microsteps at which point "near enough" is considered "good enough"

Chris.

Hi Guy's,

Chris... Just a few thoughts... the above could surely only be achieved if the mount motors were fitted with true positional encoders... which the HEQ5, or HEQ6 do not have... they are open loop.

In reality, on these mounts, the motor control board has no idea where the scope is actually pointing.

The only positional info the motor control board, and any other control software would have available is the number of steps the motors have been issued with, and in which direction from a known start position.

These current pulse counts could be out by a fair bit in reality as far as the actual position of the scope is concerned, since it cannot take into account any missed steps..i.e just becouse a number of steps has been issued does not mean the motors have actually made them, which is much more likely when microstepping is used (much lower step torque available) so even a small bit of extra drag could cause the motor to miss a step or more and the controller board or EQMOD would have no means of detecting this.

The same would apply to any stored sync offset values since these may (for the same reason) also contain a false step count.

Any calculations for a new slew position would therefore be starting from a possibly flawed values and the resulting slew target values would be out by the same amounts... furthermore, the resultant slew could quite easily add to the count errors for the same reason.

Tracking could also be effected by this problem as well.

The use of custom gearing could also influence this sort of error, but in which direction is open to conjecture since it will change the loading on the motors.

I am thinking a lot of the goto accuracy issues are related to this lack of knowledge by the software of the actual true position of the scope.

Of course, using different epochs in each software package would make matters worse.

How do you feel this source of error could best be handled, other than installing true positional encoders.

I can't think of any way EQMOD, ASCOM or any other software package could get round this particular problem.

Keep happy.

Sandy.

[chrisshillito]

Despite it being open loop I personally don't think there is a fundamental problem with the use of software counters - all the skywatcher mounts use them and most folks seem to get by just fine. Even the newer ones with "hardware encoders" are reliant on software counters to achieve accurate gotos.  Whilst microstepping will produce varying torques, and the microsteps themselves will not be perfectly evenly spaced across a step, the fact is that whenever the microstepping reaches a complete step (or maybe half step) you achieve maximum torque and the motor/axis will snap to the correct position irrespective of any previous step errors.  So it really doesn't matter how far you slew the max positioning error at the end will be the same.

Chris.

[malc-c]

Sandy & Chris, thanks for your comments.

Chris, I have three applications, CdC, Skytech and C2A that have been tried and I get the same positioning error.  The other night it was clear so I could do some reall testing with the mount rather than using the simulator.  I started from screatch, polar aligned using the tool within EQmod.  Set the mount so that DEC was 0 degrees and checked it with a spirit level.  Parked the scope to the standard home position and then un-parked and reset the "encoders".  Slewed to Vega... which has an RA of 18h 37m 29s and +38d 48m 19s... EQmod put the scope at 18h 40m 03s with +38d 30m 08s.  No poblem  Just re-position and sync.  I did this for around 10 targets at various points in the sky, confirming that each point was saved.  I then slewed back to Vega, expecting it to be centre in the image, well I've already told it where it is and a correction point made... it was out by some margin.  18h 35m 59s and +38d 21m 58s.  Now if the DEC had remained the same, and RA was wrong I would say that I might have a slipping clutch, but to have both axis out of position suggest that the clutches ars sound and sothing else is pointing the scope off target.  I check the clutches and they are solid (so tight it hurt my finger trying to release them !)

I no longer have the SW handset to try that in comparison, and EQMOD is my only means of driving the scope.  Whilst I can live with this error whilst there is a bright star as a point of reference, it's useless if I'm targeting a faint object that has no bright star close enough to it.  For example, having centred Vega I selected the ring nebular as a target.  It was still in the FOV of the camera, but right at the bottom, so even in that fairly short movement of the mount there is a pointing error.

I would welcome suggestions on any steps to try to see where these errors are creeping in.

[Lonestar70]

Sandy & Chris, thanks for your comments.

Chris, I have three applications, CdC, Skytech and C2A that have been tried and I get the same positioning error.  The other night it was clear so I could do some reall testing with the mount rather than using the simulator.  I started from screatch, polar aligned using the tool within EQmod.  Set the mount so that DEC was 0 degrees and checked it with a spirit level.  Parked the scope to the standard home position and then un-parked and reset the "encoders".  Slewed to Vega... which has an RA of 18h 37m 29s and +38d 48m 19s... EQmod put the scope at 18h 40m 03s with +38d 30m 08s.  No poblem  Just re-position and sync.  I did this for around 10 targets at various points in the sky, confirming that each point was saved.  I then slewed back to Vega, expecting it to be centre in the image, well I've already told it where it is and a correction point made... it was out by some margin.  18h 35m 59s and +38d 21m 58s.  Now if the DEC had remained the same, and RA was wrong I would say that I might have a slipping clutch, but to have both axis out of position suggest that the clutches ars sound and sothing else is pointing the scope off target.  I check the clutches and they are solid (so tight it hurt my finger trying to release them !)

I no longer have the SW handset to try that in comparison, and EQMOD is my only means of driving the scope.  Whilst I can live with this error whilst there is a bright star as a point of reference, it's useless if I'm targeting a faint object that has no bright star close enough to it.  For example, having centred Vega I selected the ring nebular as a target.  It was still in the FOV of the camera, but right at the bottom, so even in that fairly short movement of the mount there is a pointing error.

I would welcome suggestions on any steps to try to see where these errors are creeping in.

Hi Malcolm,

It would appear from the above that the positional error in RA is reasonably constant at around 2' 30" but your DEC error is between 18' 11" and 27' 39"... this would suggest 2 possible causes.

It is possible that your Belt modification is either slipping somehow (belt or pulley) or maybe the belts are too tight, especially in the DEC motor... which could easily result in the motor missing pulses or lack of mount movement.

Much as I admire Chris' faith in open loop systems, my 20+ years in designing stepper driven precision positioning systems for industry, where such errors could easily cost the customer several thousands of pounds, would contradict this... I have, on several occasions, witnessed steppers snapping backwards to the last stable detent position on receiving a full torque phase... meanwhile the counter has registered a full 16 microsteps... it does not take many such instances, and yes they can and do occur, to render the data held in the counters useless for further positioning... the only way to eliminate such problems was to utilise encoders.

I accept that a hobby telescope mount is a different application and that any such error is more of an inconvenience (albeit very frustrating) rather than a potentially large financial loss, the fact still remains that such errors could account for at least some of the positioning errors we experience with our mounts. The later SW mounts, which do have proper encoders should be much less prone to this, since the encoders should at least ensure the counters contained the correct information.

So I would first check your belt mod and make sure it is all aligned correctly, the belts are correctly tensioned and not over tightened and also the pulleys are firmly fixed to the motor spindles.

The other thing to check for is CONE ERROR... it is quite possible that your scope and mount are pointing to different locations in the sky... a 2' 30" error is not a lot when referenced directly at the scope /mount attachment... this could effect both RA and DEC relative to the scopes polar axis.

This sure is a strange one though and I suspect there is more than just one issue...all combining to produce the apparent problem/s.

It is going to be a case of 1 thing changed at a time in order to correct things.

I hope you can locate the error/s soon.

Best regards.

Sandy.

[malc-c]

Sandy, thank you for such a positive post.

I'll take a look at the belts and pulleys as suggested.  I don't hear any indication of slipping, but that's to say its not happening.  The strange thing is that it doesn't explain why I was having the same issue when I used the simulator on a different PC as outlined a few posts above, which suggests to me that it's more to do with communications between applications.  I still have the gearing so could revert the mount back to stock and see if I get the same errors, but it would be a last resort.

Cone error could be a factor, especially as a flip was involved. I'll take the OTA off the mount, check the screws on the dovetail are free and then re-attach the OTA and investigate how much cone error there is.  As you say, one step at a time.

[chrisshillito]

My "faith" in skywatcher's use of open loop 'software encoders' comes only from my own 8 year experience of a skywatcher mount where I've had no problems (touch wood) - perhaps I'm just lucky. I'm happy to accept that under some conditions steppers are prone to slippage but I can only imagine that extremely light loading, relatively slow speeds and careful management of acceleration and deceleration rates as applied in the skywatcher mounts make this a rare event. If it weren't, and discrepancies like Malcolm is experiencing were common place, then I suspect the forums would be talking of nothing else. It may be that skywatcher introduced their low res encoders in an effort to improve control however I seem to recall that skywatcher recommend disabling them for high precision gotos ??  I suspect the main motivation for introducing encoders was for rough manual positioning of the mount with the clutches released.

Anyhow, If Malcolm is concerned about stepper slips, belt slips etc then it may be worth moving between two park positions. If possible use a terrestrial target as an alignment marker for the parks and that way you can see if the mount is returning to position correctly. Alternatively you might be able to use the EQMOD encoder axis dials to set two park positions an integer number of  worm rotation apart (if you right click on the hour angle / declination values you get to see the encoder values - in hex) and use something to index the rotation of the worm itself. If there is a stepper / belt issue then this should show it up without the added complication of the conversion to celestial coordinates and the application of pointing models etc.

With respect to RA/DEC slews and EQMOD's alignment model it might be worth a try in switching the alignment behaviour to nearest point transformation and applying a "local quadrant" point filter. With 3-point alignment you have to be aware that even if returning to a previous alignment star,  that star would have moved and so two other points will exert some influence on the final position.

Chris.

[malc-c]

Chris,

Thanks for the suggestions regarding the parking test.  I have the scope set to park in a horizontal parking position, so I've just done a stimple test of moving between this parking position and the normal default home position.  To check for any actual movement, I riged up a length of wood with a cable tie pointing to the middle of the weight bar, and marked the bar with a marking pen.  The results displayed by EQMOD from slewing back and fourth are as follows.

Initial park position

RA 05h 37m 57s

DEC +35d 17m 39s

Slew to default home

RA 17h 32m 26s

DEC +89d 44m 20s

Slew back to initial park position

RA 05h 40m 06s

DEC +35d 17m 39s

Slew back to default home

RA 17h 34m 50s

DEC +89d 44m 20s

Slew back to initial position

RA 05h 42m 41s

DEC +35d 17m 39s

Each time the scope was slewed back to the initial position the alignment of the dot on the weight bar was perfect withj the tip of the cable tie.  Can you explain what the RA reported by EQMod is constantly different and increasing on each slew, even though the DEC co-ordinates remain constant after each slew

[chrisshillito]

Could it be you've placed you mount on a rotating Earth! A park position is fixed with respect to the earth, but the earth isn't fixed with respect to the sky, so the RA of the park position inevitably increases with time.

The thing to check is that the hour angle and DEC of the EQMOD dial displays (or encoder positions if you've right clicked on them) are consistent. If they are, and your mount is physically moving the correct distance as indicated by your cable tie then the software encoders, stepper and axis have all stayed in sync and stepper/belt slippage is not an issue.

Chris.

[malc-c]

Could it be you've placed you mount on a rotating Earth! A park position is fixed with respect to the earth, but the earth isn't fixed with respect to the sky, so the RA of the park position inevitably increases with time.

The thing to check is that the hour angle and DEC of the EQMOD dial displays (or encoder positions if you've right clicked on them) are consistent. If they are, and your mount is physically moving the correct distance as indicated by your cable tie then the software encoders, stepper and axis have all stayed in sync and stepper/belt slippage is not an issue.

Chris.

I'll do some more testing, but I've not changed anything in the EQMOD settings other than the 4:1 ratio option and the location for the observatory, and this was with a fresh install of the latest version of EQASCOM.  I had no planetarium software running in these test, just launched EQASCOM and went from park position to park position and back.  I have the default digit displayed rather than the dilas, but will do some further testing to see if the displays are different.

I can see what you are saying about the mount postion - I guess it's much like pointing to vega and then turning off RA and letting it drift. The scope will stay pointing in the same static postion in relation to it's surroundings, but the RA will be changing... so maybe the park / repark test is a bit of a red herring ?

[chrisshillito]

I can see what you are saying about the mount postion - I guess it's much like pointing to vega and then turning off RA and letting it drift. The scope will stay pointing in the same static postion in relation to it's surroundings, but the RA will be changing... so maybe the park / repark test is a bit of a red herring ?

The Park/repark test isn't a red herring - it is proving that your mount can repeatedly move a predetermined distance accurately and should reassure you that stepper/clutch/belt slip isn't at the root of this issue.

Chris.

[Lonestar70]

Hi Chris and Malcolm,

Well the above test results would appear to justify Chris' faith in open loop counters in this application, my apologies to you Chris for my doubts in this regards.

It is quite clear from the values that there is no error of any significance in DEC and the small incremental differences in RA can be accounted for by the motion of the earth.

This would suggest then that the large errors you are getting are not directly related to the stepper motors, but could they be due, somehow, to the 4:1 gear ratio handling in the software... especially since you appear to get different results with different versions of the same software.

I have my doubts on this score though, since there have been a lot of mounts modified in the same way and this particular problem has not been raised as a significant issue as far as I know... regardless of software version... and I am sure Chris would have jumped on any such potential problems in short order and got it resolved.

It would be interesting to see if the standard gearing produced the same errors on your mount Malcolm.

I must say I don't get any such large errors with my own HEQ5 using the same software combinations as yourself but my mount has not had any drive modifications applied to it as yet... but I am considering it... if only to quieten the mount down a bit when slewing (albeit I would be using the standard gearing version).

At the moment I am at a loss as to what to check next.

Perhaps Chris can suggest something more to try.

Best regards and I hope you find the problem.

Sandy.

[malc-c]

Thanks again for the input.  I don't reall believe the 4:1 ratio is the issue.  If it was then the DEC would also be out, and not corresponding to the information displayed, eg when parked at normal home position with a DEC of very close to 90 degree, the weight bar was actually in the correct downward position, and horizontal when at 0 degrees... If the 4:1 ratio was being incorrectly calculated the error would be more than the few minutes I got last night, and would be applied to both axis.

I'm going to run the same procedure again, but this time try and get the positioning data Chris has asked for.

[malc-c]

Ok,  selecting the mount position dials on the EQASCOm panel with the mount in it's observatory park position I have the following values:

RA:  00:14:36

DEC : 144:42:20

Unparked and slewed to the standard home position the values are:

RA:  00:08:15

DEC  89:44:20

Unparked and slewed back to the observatory park position and the values returned to:

RA: 00:14:36

DEC 144:42:20

This was also confirmed by the pointers I had set up around the mount.  So I presume then that this would suggest that there is no slip in the motors / belts / clutches, and that the mount can move to a given point with a degree of accuracy and then return to the origin with the same precision ? 

So I'm guessing that the issue is an alignment one, or cone error, or whatever works out the position for a target at a given time and location is getting the positioning wrong.  The thing I don't get is that having pointed at a target and entered a sync point, shouldn't EQAscom then calculate the error in the positioning so that it would apply that error when I told the mount to go back to Vega for the second time ?    Also, whilst I hear your comments regarding the Earths rotation in relation to the fixed point of reference, surley this is all taken into account (as would be the location co-ordinates) to calculate the number of pulses / duration etc the motor run for when instructing the mount to slew to target ?

Chris / Sandy ( ) I await you valuble feedback and comments

[Lonestar70]

Hi Malcolm,

I think that is conclusive proof that the problem is nothing to do with your stepper drives or the 4:1 gearing, so you can tick those off the list.

As for the return to a previous sync point... I am given to believe that the calculated error applied at a sync is not a constant, but rather it changes with elapsed time and can also be influenced by the type of pointing model you are applying... I believe this is what Chris was alluding too a few post above.

I am not familiar enough with celestial modelling to offer any meaningfull suggestions in this regard other than being aware that it becomes much more difficult to calculate when the meridian is crossed and a flip is initiated.

I will let Chris deal with this particular aspect.

At least you have made a couple of steps in the right direction by eliminating the steppers and gearing.

I guess the next thing to get to grips with is ensuring the scope and mount are both pointing at the same celestial point.

Whilst these sort of problems can be very frustrating when they occur, solving them can teach us a lot which might otherwise be missed.

I shall be keeping a watch on your progress and hopefully learn along with you.

Keep Happy.

Sandy.

[malc-c]

Oh yeah, don't get me wrong, this whole experience is a learning curve and I'm not in anyway suggesting that there is anything radically wrong with EQASCOM, it's served me well and is fantastic at what it does.  I just wished I knew more about how this all works and why, in my case I'm getting these strange goto's.  I'm hoping that what's documented in this thread will help anyone else in the future once I've (we've) sorted out the cause. 

If Chris, yourself or anyone else offer a suggestion to try before I remove the OTA from the mount and reset the rings and dovetail in order to try out cone error tests when we next get a decent night (possibly Friday evening looking at the weather forecast).