Topics

Four and a half months later ...

Khalid Baheyeldin
 
Edited

Finally, I am back to playing with OnStep under the stars ...
The last time I did that was 4.5 months ago (yes, since October 28th!), and as a result, I almost forgot the steps for my setup procedure, and had to re-learn it.
One goal was to resume experimenting with autoguiding.
There were also a few new variables: told OnStep to not do backlash compensation when guiding, a new USB hub, and the latest OnStep master branch (4.2c).

First things first: Howard, everything works well in the latest master as it used to, nothing unusual (I don't use the heater stuff though).

Autoguiding is kind of inconsistent, sometimes bad, sometimes OK. Not every image has round stars, so the experience is similar to before I guided (but with less rejects).

Even though autoguiding helps (I am not enabling PEC, imperfect polar alignment), it still has lots of variables (e.g. no idea if disabling backlash for guiding in OnStep helped or not, no idea how to analyze the logs and tune parameters [if any] based on what is in the logs, and so on ...).

Here is a screen capture of 'good guiding' (there is a spike in DEC in the middle, no idea why).
Here is a better example.
Both near the NCP. It was worse on M42 near the celestial equator. 

But got some good images, so sharing them ...

Here is a crop from M82, 300 seconds @ ISO 200 (with the above guiding).
A more extreme crop showing the dust lanes.

And a crop from M42, 120 seconds @ ISO 400, from earlier in the evening.

And a crop from M1, 120 seconds @ ISO 400.

And a Comet! C/2019 Y4 ATLAS, 120 seconds @ ISO 400. Found it by chance, when it showed up in KStars as I was checking what to capture next after M82. Nothing spectacular, but it does show a tiny tail, and I may get enough exposures to do a time sequence from them.

Mike Ahner
 

Looks really good, Khalid. I'm envious because it'll be another week or more before the rain/clouds clear out here in North Texas. I may have to relearn my setup procedures, too. And maybe I'll get a chance to try some of OnSteps features.

Good luck and good viewing!
-Mike

Aisling Lightworks
 

Looking good! 

jalonsodiaz07@...
 

I think it may be a mount related problem. I have STM32 kit and SXD mount and have had the same problem a few times with spike in DEC.

Other times this problem doesn't happen for many hours...

Howard Dutton
 

On Sun, Mar 15, 2020 at 09:13 PM, Khalid Baheyeldin wrote:

Here is a screen capture of 'good guiding' (there is a spike in DEC in the middle, no idea why).
Here is a better example.
I'm not an expert on PHD2... sadly I spend more time programming than imaging but when you see a series of declination guides indicated on the graph and no resulting action I assume we are in the BL.  Eventually the thing overcompensates and wham the Declination jumps too far the other way.  Then it sees that and compensates too far in the reverse direction.  Etc.

Read https://openphdguiding.org/man-dev/Advanced_settings.htm and tune.

jalonsodiaz07@...
 

Under Algorithms tab in PHD I have enabled "Backlash Compensation" and  "Amount"=1514 (it was automatically calculated by PHD) and I´m  not having problem  with DEC lately.

Khalid Baheyeldin
 

On Mon, Mar 16, 2020 at 08:26 AM, Howard Dutton wrote:
when you see a series of declination guides indicated on the graph and no resulting action I assume we are in the BL.  Eventually the thing overcompensates and wham the Declination jumps too far the other way.  Then it sees that and compensates too far in the reverse direction.  Etc.
That is a very likely scenario, since I enabled the following:
#define GUIDE_DISABLE_BACKLASH ON

And that is the only major difference between what I did last night and last October (I did not see the same problem then).

I thought that PHD2 would measure the backlash accurately, and compensate for it. That is part of the added complexity thing that I was (and still am) dreading ...

It does not happen in RA though, even the backlash there is worse (113" for RA vs. 77" for DEC).

If it is clear tonight or tomorrow, I will disable that setting and retry.

Khalid Baheyeldin
 

On Mon, Mar 16, 2020 at 08:57 AM, <jalonsodiaz07@...> wrote:
I think it may be a mount related problem. I have STM32 kit and SXD mount and have had the same problem a few times with spike in DEC. Other times this problem doesn't happen for many hours.
I have the same setup as you.
Did you use the MPJA NEMA11 18:1 motors too?

What is the backlash like in both axes?

Under Algorithms tab in PHD I have enabled "Backlash Compensation" and  "Amount"=1514 (it was automatically calculated by PHD) and I'm  not having problem with DEC lately.
Did PHD2 calculate it in the calibration phase?
For me, it is set to 20 (all three values are set to 20, which looks odd to me).
I tried checking the Enable option and unchecking it, but the results are the same.

jalonsodiaz07@...
 

Did you use the MPJA NEMA11 18:1 motors too?
No, I have a Chinese (HongYi Automation Co., Ltd)  Nema 11  5.18:1 motors 

What is the backlash like in both axes?
I´ve never really measured backlash accurately.  I´ve relied on getting decent guiding session.

Did PHD2 calculate it in the calibration phase?
Yes, PHD2 calculate amount of backlash compensation during calibration but I think PHD2 slightly change the "amount" when guiding too.
Be sure to put for example "min box" around 20 and "max box" for example 4500 so that PHD can calculate backlash compensation between 20 and 4500 (see my backlash.jpg)
 

Khalid Baheyeldin
 

On Mon, Mar 16, 2020 at 02:55 PM, <jalonsodiaz07@...> wrote:
No, I have a Chinese (HongYi Automation Co., Ltd)  Nema 11  5.18:1 motors 
Good to know there are other options for NEMA11 geared motors out there.

"What is the backlash like in both axes?"
I´ve never really measured backlash accurately.  I´ve relied on getting decent guiding session.
You don't need to measure it. You just need to tune it by trial and error.
I described how to tune OnStep backlash in another post. It is not hard.
Then after you are done, you know what the approximate backlash is, in arc seconds, from OnStep.

"Did PHD2 calculate it in the calibration phase?"
Yes, PHD2 calculate amount of backlash compensation during calibration but I think PHD2 slightly change the "amount" when guiding too.
Be sure to put for example "min box" around 20 and "max box" for example 4500 so that PHD can calculate backlash compensation between 20 and 4500.
Oh, I see now.
These values are in milliseconds (if I remember from last night).
That is part of the voodoo and complexity that I don't like in general ...

But I will give this a try.

Khalid Baheyeldin
 

On Mon, Mar 16, 2020 at 02:55 PM, <jalonsodiaz07@...> wrote:
I´ve never really measured backlash accurately.
Another question.
Do you use the parameter:
#define GUIDE_DISABLE_BACKLASH ON
Or you have it set to the default (OFF)?

jalonsodiaz07@...
 

Khalid Baheyeldin
 

On Mon, Mar 16, 2020 at 03:31 PM, <jalonsodiaz07@...> wrote:
I have #define GUIDE_DISABLE_BACKLASH        OFF
I turned that parameter to OFF and trying again tonight.
When I tried to turn on backlash compensation in PHD2, the value stayed at 20, despite setting the maximum to 4500.
No idea why.
I also balanced the DEC axis better. The guide scope is 80mm, and quite heavy, so it has some radial force.

Here is a guiding graph. It is much better than the previous night, although the RMS is not as good.

As I said, guiding is a mixed blessing: despite its benefits (no PEC, no proper polar alignment, longer exposures, less rejects) it adds to the overall complexity of an already complex system.

Khalid Baheyeldin
 

The previous message was when I was a bit south (M44).
Now that I pointed the rig near the NCP, to image C/2019 Y4 (which is potentially a Great Comet in late May), DEC is doing great, but RA is oscillating, per this graph.
Any ideas?

jalonsodiaz07@...
 

Do you have "Dec guide mode" as "auto" under "Algorithms" tab ?
See my "Algorithms" tab  (Advanced setup.jpg)

jalonsodiaz07@...
 

May be you should lower RA agressiveness and increase RA Hysteresis to avaoid over-coorection in RA

See my "Algorithms" tab  (Advanced setup.jpg)

hitosi sato
 

Hi Khalid
When I use PHD2, I don't use OnStep backlash assist.
If the value of the backlash can be set correctly, no operation error will occur,
but in some cases, the backlash compensation of PHD2 may become an abnormal value.
PHD2 has a guide assistance function. I think you should try it once.
I think it will be easier to understand the guiding condition.
It seems that the screenshot of #18528 have a over correction in RA.
It need to recheck the guide speed, aggressiveness and mechanical condition.

hitoshi

Aisling Lightworks
 

I also stay away from backlash assist. The best way I've found to deal with backlash is to balance the scope a bit heavy to one side and stay slightly out of polar alignment so it always pushes the same way for corrections.

Martin Bonfiore
 

Using gravitational bias to “lean” against the gear lash sounds  very good.  The subject of backlash comes up frequently in small hobby cnc machine discussions.  

The $$ approach for linear systems is ball screws or linear motors with high precision encoders.  I guess for scope drives the equivalent is big high precision worm drives.

Other interesting but not clearly practical approaches include negator springs or constant torque motors whose function is to resist rotation independent of orientation (which is a limitation of gravitational bias).  These torque controlled motors are used for roll stock tensioning in industrial applications.  Conceptually you can dialogue in the backlash resisting torque.

Anyone play with these for scope drive systems?  Usual caveat ...fun to thing about probably not worth the trouble....

 

On Sun, Mar 15, 2020 at 09:13 PM, Khalid Baheyeldin wrote:
And a Comet! C/2019 Y4 ATLAS, 120 seconds @ ISO 400. Found it by chance, when it showed up in KStars as I was checking what to capture next after M82.
What's the focal length/f-#, plate scale, etc.  I want to go looking myself, soon.