HELP ! - predictable sub error

[alan4908]

After an investigation into my sub frame quality, I've noticed an error in my sub frames that only appears to occur when my scope starts from the target position with guiding activated. I've illustrated the error with two close crops of a 1800s Ha exposure. The same effect can be seen in a much shorter exposure (eg 600s). As far as I can determine, the sequence of the automated events are: 

1. Go to target X and centers image - everything OK.

2. Start guider and wait until the guide error is less than 0.3 pixels guider pixels - OK

3. Start exposure - error in sub will occur

4. Start next exposure - error in sub will not occur - OK

5. Start next exposure - error in sub will not occur - OK

6. Everything is OK for 2 hours (my periodic autofocus interval) - OK 

7. Scope slews to autofocus position and runs autofocus routine - OK

8. Scope slews back to target X and centers image - everything OK.

9. Start guider and wait until the guide error is less than 0.3 pixels guider pixels - OK

10. Start exposure - error in sub will occur.

11 Start next exposure - error in sub in not occur.

12. ETC

My suspicion is that this is DEC backlash in my NEQ6, however, I'm perplexed about how to eliminate it.  As a bit of background my scope is controlled by ACP which uses MaximDL to automatically "press" the various buttons. My camera image scale is 1.49 arc seconds/pixel and my guide camera image scale is 4.41 arc seconds/pixel.  I have a theory that the parameter 0.3 is too high since I'm basically saying to the scope wait until the guiding is below 0.3 x 4.41 = 1.3 arc seconds/pixel before starting the exposure, which is 1.3/1.49 =  87% of a main camera pixel.  However, if I try to reduce the value down to say 0.2 pixels, it appears to significantly reduce my number of successful exposures since ACP doesn't allow the exposure to start because the value of 0.2 pixel guide error is often never reached in the time interval that ACP allows for the guider to settle.   

Sub error - 1800s Ha

 

 

Normal - 1800s Ha

Alan 

 

[Uranium235]

Sounds like backlash to me. The best way to overcome this is before you start your first exposure, nudge the mount (using the handset) in the direction you are guiding - either north or south... it depends on which way your mount likes to drift.

Or.... being as its summer, dont refocus at all but keep the telescope is a place that is cooler than the likely ambient temperature - ie: I keep mine in the basement, so more often than not it needs to actually "warm up" during summer nights.

[alan4908]

2 hours ago, Uranium235 said:

Sounds like backlash to me. The best way to overcome this is before you start your first exposure, nudge the mount (using the handset) in the direction you are guiding - either north or south... it depends on which way your mount likes to drift.

Or.... being as its summer, dont refocus at all but keep the telescope is a place that is cooler than the likely ambient temperature - ie: I keep mine in the basement, so more often than not it needs to actually "warm up" during summer nights.

Rob

Thanks for your thoughts.  Since I'm into automated operation and my NEQ6 handset is stored (somewhere) in my attic , I need to do the equivalent of your "nudge" but via software. Having had a look a the MaximDL user manual, it would appear than there is are backlash parameters that I can adjust (RA and DEC), so I think I'll try experimenting with these - I'll also make the assumption that I'm dealing with DEC backlash.

Alan

[Uranium235]

If its any consolation, I get exactly the same with my NEQ6 - but as I stated, a quick nudge sorts it out

Its not worth the faff of using backlash compensation, that can sometimes do more harm than good.

 

[alan4908]

9 hours ago, Uranium235 said:

 

If its any consolation, I get exactly the same with my NEQ6 - but as I stated, a quick nudge sorts it out

Its not worth the faff of using backlash compensation, that can sometimes do more harm than good.

 

Hmm that interesting.

I haven't touched the backlash compensation button for exactly the reason that you mention, so I will need to tread very carefully if I go down this route.  Alternatively, maybe I could (somehow) program a single short eg 30s exposure before every target with the intention of throwing the image away.  I shall have another think.

Alan

[Uranium235]

30s wont be enough, as it can sometimes take 10-15min for the backlash to kick in. The nudge is all you need to overcome it.

[alan4908]

Rob

Thanks for the input, I hadn't appreciated it could take 10-15mins for the backlash to kick in.

The only problem is that it the solution needs to be via software rather than a handset  To explain a little further, I often image multiple targets per night via my autonomous set up and my scope will start up whenever it thinks the sky is clear, the objects are above my local horizon etc so a manual solution is a non starter. There is no way that I'm loosing sleep and going back to manual imaging, I'd much rather loose the odd sub  

Alan

 

 

 

 

[Pompey Monkey]

3 hours ago, alan4908 said:

Rob

Thanks for the input, I hadn't appreciated it could take 10-15mins for the backlash to kick in.

The only problem is that it the solution needs to be via software rather than a handset  To explain a little further, I often image multiple targets per night via my autonomous set up and my scope will start up whenever it thinks the sky is clear, the objects are above my local horizon etc so a manual solution is a non starter. There is no way that I'm loosing sleep and going back to manual imaging, I'd much rather loose the odd sub  

Alan

 

 

 

 

It seems (as always) that I have a long way to travel in my path towards automation, but I guess that I get half of my fun from overcoming these kind of challenges

Back on topic, I have the AZ-EQ6 mount, which is probably very similar in terms of backlash, but I have never experienced this delayed backlash. However, I use PHD 2.something for my guiding and maybe the backlash compensation works very well.

Alternatively, before my newly acquired Polemaster, maybe my PA was so off so far that the DEC backlash was being driven out right at the start of the guiding sequence... Time will tell on that one 

[alan4908]

3 minutes ago, Pompey Monkey said:

It seems (as always) that I have a long way to travel in my path towards automation, but I guess that I get half of my fun from overcoming these kind of challenges

Back on topic, I have the AZ-EQ6 mount, which is probably very similar in terms of backlash, but I have never experienced this delayed backlash. However, I use PHD 2.something for my guiding and maybe the backlash compensation works very well.

Alternatively, before my newly acquired Polemaster, maybe my PA was so off so far that the DEC backlash was being driven out right at the start of the guiding sequence... Time will tell on that one 

Paul

If you're interested in automation then I would encourage you to go forth down the path....it will significantly increase your imaging efficiency, particularly given the poor UK weather. 

Back on track, I'm still thinking about how best to overcome this backlash issue via software, although to be quite honest it is more an irritation rather than a major issue with my current set up. 

Alan

[alan4908]

I've believe that I've found a software based solution to my DEC backlash problem - it is not ideal but is does appear to work.

By careful adjustment of the data rejection parameters in CCDstack, I've found that I can keep the poor quality sub frames containing the DEC backlash issue but without suffering a degradation in overall quality. I checked this by comparing the result with keeping only the good sub frames. 

For those that might be interested: CCDstack has various data rejection routines: if you have only a small number of subframes and want to nominate a particular sub-frame as a "gold standard" subframe - you can use the Poisson reject option.  

To take an extreme illustrative example: say you only have if you one good subframe and two bad subframes. You include the good subframe and only one bad subframe, you then perform Poisson reject, marking the good subframe as the "gold standard". Since CCDstack shows the rejected pixels in red you can see the effect of varying the data rejection strength. Once you are convinced that you've rejected all the offending pixels from the bad subframe#1 - you exclude if from the stack. You then include bad subframe#2 along with the good subframe and repeat the process.  

You now have three sub frames all with rejected pixels, so you now include all these in the stack and stack with mean option.

Alan

 

[adrock314]

If you are specifying a star to be used during autofocus, choose one located such that the mount will clear backlash on the return to target move.   It might take a bit more time but if your polar alignment isn't perfect you can at least see the declination drift direction from your guiding.  Stills seems like an odd problem though.  

[alan4908]

3 hours ago, adrock314 said:

If you are specifying a star to be used during autofocus, choose one located such that the mount will clear backlash on the return to target move.   It might take a bit more time but if your polar alignment isn't perfect you can at least see the declination drift direction from your guiding.  Stills seems like an odd problem though.  

Hi - unfortunately, I don't specify the focus star, ACP chooses this based a certain magnitude range. However, if I could (someone) work out how to force ACP to pick a particular one it might provide a better solution than my current work around. Thanks anyway.

Alan