Things that customers do that drive me nuts on CN


Roland Christen
 

So here is an entry on Cloudy Nights that a customer posted under the following thread:
https://www.cloudynights.com/topic/622947-mach1-dec-oscillations-our-experience/page-9#entry8692618
Post #199:

"I'm not the OP but I can tell you that my PI measured eccentricity goes from < 0.4 on one side of meridian to > 0.6 on the other side, due to the DEC oscillations I'm seeing, and the stars are obviously not round."

However, this same person posted this in the PHD Google groups:

"12:40: Disabled Backlash compensation.  Had no obvious effect - continued to see oscillations
12:46: Reduced MinMo from 0.20 to 0.10.  The more aggressive MinMo resulted in more frequent oscillations
12:55:  Increased MinMo to 0.40.  At this point I also removed the motor cover on DEC so I could watch what was happening! (hence the large excursions in DEC and RA at this point :).  With MinMo set to 0.40 however, guiding stays within the seeing limits and DEC oscillations disappear.
01:01: Reduced MinMo back down to 0.20.  
01:02: Reduced MinMo back down to 0.10.  Immediately start to see oscillations again
01:04: Increased MinMo back up to 0.30.  Oscillations stop
01:06: MinMo back down to 0.10.  Oscillations start again
01:08: MinMo back up to 0.30.  Oscillations stop etc"

So, he already knows how to stop oscillations or what I call chasing the seeing. SET the MIN MOVE to a level that corresponds to the seeing. There is never a time when the seeing is 0.1 arc sec, most likely it will be 0.5 to over 1 arc sec., and this can be seen by simply taking a few minutes of Dec data with guiding turned off. You will see the star bounce around +- X arc seconds. Using that data, set your Min Move to between 50% and 80% of that value. There is no use trying to get a guide loop to hunt down atmospheric motions of less than that because the error measured comes well after the fact and by the time a correction is sent to the mount the star probably is elsewhere. A lot of times the error gets compounded instead of reduced, and it begins a back and forth oscillatory motion.

The other issue is the amount of correction by adjusting the aggressiveness to less than 100%. Near 100% you may exceed the 100% loop gain and instruct the mount to move more than the error size, and this will indeed set off oscillations. Close loop gain must always be less than 100% for any servo loop to be stable.

So would somebody that frequents CN please advise him of these simple facts? I am not on CN, but have covered this topic here extensively.

Thank you.

Rolando


W Hilmo
 

That thread is a mess. I (and a few others) posted more than once in that thread small min moves and excessive aggressiveness will cause oscillations. This signal to noise in that thread is worse than typical, even for Cloudy Nights.



Part of the problem on Cloudy Nights in general is that there are people there who will post their opinion in any thread, regardless of whether they have any experience with the situation or product being discussed. In many cases, it’s just well-meaning people who are repeating what they’ve heard – whether or not what they heard was either correct or in the proper context. People who know what they are talking about have a hard time getting through all the noise. I also think that there are a (very small) number of people there with an agenda, who are all too happy to stir the pot now and then.







From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Monday, July 9, 2018 4:55 PM
To: ap-gto@yahoogroups.com
Subject: [ap-gto] Things that customers do that drive me nuts on CN





So here is an entry on Cloudy Nights that a customer posted under the following thread:

https://www.cloudynights.com/topic/622947-mach1-dec-oscillations-our-experience/page-9#entry8692618

Post #199:



"I'm not the OP but I can tell you that my PI measured eccentricity goes from < 0.4 on one side of meridian to > 0.6 on the other side, due to the DEC oscillations I'm seeing, and the stars are obviously not round."



However, this same person posted this in the PHD Google groups:



"12:40: Disabled Backlash compensation. Had no obvious effect - continued to see oscillations

12:46: Reduced MinMo from 0.20 to 0.10. The more aggressive MinMo resulted in more frequent oscillations

12:55: Increased MinMo to 0.40. At this point I also removed the motor cover on DEC so I could watch what was happening! (hence the large excursions in DEC and RA at this point :). With MinMo set to 0.40 however, guiding stays within the seeing limits and DEC oscillations disappear.

01:01: Reduced MinMo back down to 0.20.

01:02: Reduced MinMo back down to 0.10. Immediately start to see oscillations again

01:04: Increased MinMo back up to 0.30. Oscillations stop

01:06: MinMo back down to 0.10. Oscillations start again

01:08: MinMo back up to 0.30. Oscillations stop etc"



So, he already knows how to stop oscillations or what I call chasing the seeing. SET the MIN MOVE to a level that corresponds to the seeing. There is never a time when the seeing is 0.1 arc sec, most likely it will be 0.5 to over 1 arc sec., and this can be seen by simply taking a few minutes of Dec data with guiding turned off. You will see the star bounce around +- X arc seconds. Using that data, set your Min Move to between 50% and 80% of that value. There is no use trying to get a guide loop to hunt down atmospheric motions of less than that because the error measured comes well after the fact and by the time a correction is sent to the mount the star probably is elsewhere. A lot of times the error gets compounded instead of reduced, and it begins a back and forth oscillatory motion.



The other issue is the amount of correction by adjusting the aggressiveness to less than 100%. Near 100% you may exceed the 100% loop gain and instruct the mount to move more than the error size, and this will indeed set off oscillations. Close loop gain must always be less than 100% for any servo loop to be stable.



So would somebody that frequents CN please advise him of these simple facts? I am not on CN, but have covered this topic here extensively.



Thank you.



Rolando





[Non-text portions of this message have been removed]


Stephen Winston
 

Hi Rolando,

I am the poster in question, so no need to send anyone to CN to set me straight :)

To be clear:  I'm debugging an oscillation pattern I in see in DEC, that only happens only on one side of the meridian.  In the  PHD2 forum post you reference above I was indeed trying different settings to see how they affect the observed DEC behavior.  

What I saw is that if I reduce MinMo enough so that DEC is basically making no corrections (equivalent to almost turning DEC guiding off), I don't see the oscillations.  The point of that test was to demonstrate that the oscillations were not being caused by some external input (e.g. dragging cables).  If the issue was being caused by dragging cables or shifting weight then it wouldn't matter what I set MinMo to.

Now, with MinMo set to 0.2 or lower, seeing will indeed induce correction pulses from PHD2.  However, the size of the resulting corrections (often around 5 arc seconds) way exceeds the seeing (of around 2 arc-s).  And this kind of over-correction is not seen when imaging on the other side of the meridian.

At this point, the issue looks most likely to be stiction.  However, I have tried APs suggestion of manually moving the gears to ensure they are not tight (they are not) and it only occurs on one side of the meridian (but maybe stiction can sometimes manifest this way?).

Anyway, the issue I am seeing is not "chasing the seeing".  I can guide for hours without no oscillations.  Once I do a meridian flip, all hell breaks loose, with no change to the PHD2 guiding settings.

I was avoiding posting here until I had completed debugging this with the PHD guys, as there has already been a contentious thread on this topic - I wanted to wait until I had all the data I could gather.

I'm glad to learn that you have been monitoring this on both CN and in the PHD forum.  If you have any advice on how I can debug this further that would be appreciated.

thanks,

Steve



Roland Christen
 


What I saw is that if I reduce MinMo enough so that DEC is basically making no corrections (equivalent to almost turning DEC guiding off), I don't see the oscillations.  The point of that test was to demonstrate that the oscillations were not being caused by some external input (e.g. dragging cables).  If the issue was being caused by dragging cables or shifting weight then it wouldn't matter what I set MinMo to.

Now, with MinMo set to 0.2 or lower, seeing will indeed induce correction pulses from PHD2.  However, the size of the resulting corrections (often around 5 arc seconds) way exceeds the seeing (of around 2 arc-s).  And this kind of over-correction is not seen when imaging on the other side of the meridian.
The above makes absolutely no sense. Reducing MinMove to smaller levels (first paragraph) does NOT result in no guiding.
Secondly, if the Min Move is set to 0.2 or lower (as in your second paragraph) I would indeed expect the mount to not be stable, especially if other settings are at their extreme also. There is no way to know what is happening mechanically to the entire system which may have subtle difference in motion and friction from one side to the other. Cabling, optics etc will vary their impact on the mount.

The whole idea is to set the MinMove to a level consistent with the seeing, not to some arbitrary low value that only works in an ideal perfect sky. I'm sure where you were shooting the atmospheric motion had to be quite large.

Rolando


-----Original Message-----
From: stephenjwinston@... [ap-gto]
To: ap-gto
Sent: Mon, Jul 9, 2018 7:47 pm
Subject: [ap-gto] Re: Things that customers do that drive me nuts on CN



Hi Rolando,

I am the poster in question, so no need to send anyone to CN to set me straight :)

To be clear:  I'm debugging an oscillation pattern I in see in DEC, that only happens only on one side of the meridian.  In the  PHD2 forum post you reference above I was indeed trying different settings to see how they affect the observed DEC behavior.  

What I saw is that if I reduce MinMo enough so that DEC is basically making no corrections (equivalent to almost turning DEC guiding off), I don't see the oscillations.  The point of that test was to demonstrate that the oscillations were not being caused by some external input (e.g. dragging cables).  If the issue was being caused by dragging cables or shifting weight then it wouldn't matter what I set MinMo to.

Now, with MinMo set to 0.2 or lower, seeing will indeed induce correction pulses from PHD2.  However, the size of the resulting corrections (often around 5 arc seconds) way exceeds the seeing (of around 2 arc-s).  And this kind of over-correction is not seen when imaging on the other side of the meridian.

At this point, the issue looks most likely to be stiction.  However, I have tried APs suggestion of manually moving the gears to ensure they are not tight (they are not) and it only occurs on one side of the meridian (but maybe stiction can sometimes manifest this way?).

Anyway, the issue I am seeing is not "chasing the seeing".  I can guide for hours without no oscillations.  Once I do a meridian flip, all hell breaks loose, with no change to the PHD2 guiding settings.

I was avoiding posting here until I had completed debugging this with the PHD guys, as there has already been a contentious thread on this topic - I wanted to wait until I had al l the data I could gather.

I'm glad to learn that you have been monitoring this on both CN and in the PHD forum.  If you have any advice on how I can debug this further that would be appreciated.

thanks,

Steve





Stephen Winston
 

>The above makes absolutely no sense. Reducing MinMove to smaller levels (first paragraph) does NOT result in no guiding

Sorry - typo on my part.  As you can see from the logs on the pHD2 forum, MinMo was increased to 0.3 to eliminate any seeing induced corrections.  Again, the point of that test was to demonstrate that the oscillation wasn't being triggered by dragging cables or some external input (as dragging cables don't care what MinMo is set to)

>Secondly, if the Min Move is set to 0.2 or lower (as in your second paragraph) I would indeed expect the mount to not be stable

0.2 is the standard recommended MinMo from PHD2.  It's what I have pretty much always used and as I mentioned above, I can guide for hours with no issues on one side of the meridian with those settings.

>There is no way to know what is happening mechanically to the entire system which may have subtle difference in motion and friction from one side to the other. 

Agreed.

>Cabling, optics etc will vary their impact on the mount. 

I'm confident that cabling, optics etc are not triggering the oscillation.  Now, could they affect the mounts response when PHD issues a corrective pule?  I don't know.


>The whole idea is to set the MinMove to a level consistent with the seeing, not to some arbitrary low value that only works in an ideal perfect sky. 

I don't set it to some arbitrary low value when imaging - I use PHD2 recommended setting of 2.0.  The low values seen in the PHD forum post and logs are being used to try debug what's going on, not for actual imaging.


>I'm sure where you were shooting the atmospheric motion had to be quite large.

Actually, no.  The oscillation was seen over last week when imaging M8 (low), M16 (38 degrees) and last night when imaging NGC7000 (almost overhead from my location) - once the mount did a meridian flip the oscillations began.

Again, I'm not, as Wade suggested, trying to "stir the pot", I just want to try figure this out.

And some history on why I've only recently started hitting this issue:  Previously I imaged "manually" and tended to only image on one side of the meridian.  Recently I started using SGP to automate everything and set up much longer imaging sessions, which include a meridian flip.

Steve


Bill Long
 

Steve

Some of the problem with the back and forth here is that you are talking about guiding in terms that are not normalized. When you say you set MinMo to 0.1 or 0.3 that is in pixels. Since we do not know the scale of the guiding solution you use, that is not very helpful. I know you do not mean 0.1 arc seconds or 0.3 arc-seconds, but generally you will want to translate that via your scale when you want to openly discuss this with other people. If you are guiding at exactly 1"/px, then those values are awfully low and likely are causing the mount to over-correct. 


To do this, just take the pixel value and multiply it by your guider scale in arc seconds/pixel. 


The other issue here is the idea that setting your MinMo to a larger value (i.e. 0.1 to 0.3) is somehow stopping your guiding in DEC altogether. Why do you say this? Is it because you see far less corrections? That would be doing it the right way. Your DEC axis should not be correcting every single pulse. I have seen good stretches where my DEC guiding doesnt correct for 10 pulses or more and I have wonderful stars as a result.


PHD cannot possibly have a "standard recommended MinMo" especially considering that value in their software is in pixels. They could not possibly tell everyone to guide at 0.2 pixels because they do not know what people are doing in terms of the guider image scale. They also do not know what everyone's seeing is like. There is a lot loaded into that comment that is likely driven from misunderstanding. 


If you use Roland's suggestion of determining the peak DEC error, setting MinMo to that, and moving on with life. It works very well. Just be sure to get the aggression dialed in nicely and the mount will track, guide and operate quite well on both sides of the meridian. If you want to further improve that, you can get APPM/APCC Pro and develop a pointing model, which will provide tracking correction for quite a few extra issues that are  going on that you may not even be aware of. 





From: ap-gto@... <ap-gto@...> on behalf of stephenjwinston@... [ap-gto]
Sent: Monday, July 9, 2018 6:23 PM
To: ap-gto@...
Subject: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

>The above makes absolutely no sense. Reducing MinMove to smaller levels (first paragraph) does NOT result in no guiding


Sorry - typo on my part.  As you can see from the logs on the pHD2 forum, MinMo was increased to 0.3 to eliminate any seeing induced corrections.  Again, the point of that test was to demonstrate that the oscillation wasn't being triggered by dragging cables or some external input (as dragging cables don't care what MinMo is set to)

>Secondly, if the Min Move is set to 0.2 or lower (as in your second paragraph) I would indeed expect the mount to not be stable

0.2 is the standard recommended MinMo from PHD2.  It's what I have pretty much always used and as I mentioned above, I can guide for hours with no issues on one side of the meridian with those settings.

>There is no way to know what is happening mechanically to the entire system which may have subtle difference in motion and friction from one side to the other. 

Agreed.

>Cabling, optics etc will vary their impact on the mount. 

I'm confident that cabling, optics etc are not triggering the oscillation.  Now, could they affect the mounts response when PHD issues a corrective pule?  I don't know.


>The whole idea is to set the MinMove to a level consistent with the seeing, not to some arbitrary low value that only works in an ideal perfect sky. 

I don't set it to some arbitrary low value when imaging - I use PHD2 recommended setting of 2.0.  The low values seen in the PHD forum post and logs are being used to try debug what's going on, not for actual imaging.


>I'm sure where you were shooting the atmospheric motion had to be quite large.

Actually, no.  The oscillation was seen over last week when imaging M8 (low), M16 (38 degrees) and last night when imaging NGC7000 (almost overhead from my location) - once the mount did a meridian flip the oscillations began.

Again, I'm not, as Wade suggested, trying to "stir the pot", I just want to try figure this out.

And some history on why I've only recently started hitting this issue:  Previously I imaged "manually" and tended to only image on one side of the meridian.  Recently I started using SGP to automate everything and set up much longer imaging sessions, which include a meridian flip.

Steve


steven ho
 

Because AP has a strong commitment to their products and customers that they naturally are dismayed when a customers experience is not satisfactory. I feel bad for Rolando and wish their was something I could do beside writing this supportive email.


steve hoffman



From: ap-gto@... on behalf of chris1011@... [ap-gto]
Sent: Monday, July 9, 2018 7:54 PM
To: ap-gto@...
Subject: [ap-gto] Things that customers do that drive me nuts on CN
 
 

So here is an entry on Cloudy Nights that a customer posted under the following thread:
https://www.cloudynights.com/topic/622947-mach1-dec-oscillations-our-experience/page-9#entry8692618
Post #199:

"I'm not the OP but I can tell you that my PI measured eccentricity goes from < 0.4 on one side of meridian to > 0.6 on the other side, due to the DEC oscillations I'm seeing, and the stars are obviously not round."

However, this same person posted this in the PHD Google groups:

"12:40: Disabled Backlash compensation.  Had no obvious effect - continued to see oscillations
12:46: Reduced MinMo from 0.20 to 0.10.  The more aggressive MinMo resulted in more frequent oscillations
12:55:  Increased MinMo to 0.40.  At this point I also removed the motor cover on DEC so I could watch what was happening! (hence the large excursions in DEC and RA at this point :).  With MinMo set to 0.40 however, guiding stays within the seeing limits and DEC oscillations disappear.
01:01: Reduced MinMo back down to 0.20.  
01:02: Reduced MinMo back down to 0.10.  Immediately start to see oscillations again
01:04: Increased MinMo back up to 0.30.  Oscillations stop
01:06: MinMo back down to 0.10.  Oscillations start again
01:08: MinMo back up to 0.30.  Oscillations stop etc"

So, he already knows how to stop oscillations or what I call chasing the seeing. SET the MIN MOVE to a level that corresponds to the seeing. There is never a time when the seeing is 0.1 arc sec, most likely it will be 0.5 to over 1 arc sec., and this can be seen by simply taking a few minutes of Dec data with guiding turned off. You will see the star bounce around +- X arc seconds. Using that data, set your Min Move to between 50% and 80% of that value. There is no use trying to get a guide loop to hunt down atmospheric motions of less than that because the error measured comes well after the fact and by the time a correction is sent to the mount the star probably is elsewhere. A lot of times the error gets compounded instead of reduced, and it begins a back and forth oscillatory motion.

The other issue is the amount of correction by adjusting the aggressiveness to less than 100%. Near 100% you may exceed the 100% loop gain and instruct the mount to move more than the error size, and this will indeed set off oscillations. Close loop gain must always be less than 100% for any servo loop to be stable.

So would somebody that frequents CN please advise him of these simple facts? I am not on CN, but have covered this topic here extensively.

Thank you.

Rolando


Virus-free. www.avast.com


Stephen Winston
 

Hi Bill,

>Since we do not know the scale of the guiding solution you use, that is not very helpful.

Fully agree.  Again, this is actually something I have been debugging with the PHD2 guys.  All the information and detailed calibration and guide logs are there.  As mentioned in my first post above, I was avoiding discussing it here until I had completed debugging with them, but Roland opening up this thread pulled me in :).

My guider scale is: Pixel scale = 2.97 arc-sec/px, Binning = 1, Focal length = 514 mm
My imaging scale is: Pixel scale = 1.51 arc-sec/px, Binning = 1, Focal length = 735 mm

>setting your MinMo to a larger value (i.e. 0.1 to 0.3) is somehow stopping your guiding in DEC altogether. Why do you say this?

Again, this was all done in the context of testing/debugging the issue.  Setting MinMo to 0.1 triggers PHD2 to issue frequent guide pulses, triggered by seeing.  On one side of the meridian (and only one side) these corrective guide pulses trigger large oscillations that are not seen on the other side of the meridian.  Setting MinMo to 0.3 basically eliminates seeing triggered corrections (for my local seeing) and again this was done to demonstrate that the oscillations were not being triggered by something external like a dragging cable. Hope that makes sense.

>PHD cannot possibly have a "standard recommended MinMo" 
Of course.  0.2 is the standard recommendation it makes for my imaging train based on my guiding pixel scale and based on the GA run that measures high frequency RMS and backlash in my mount.  Other peoples' recommended settings will of course vary.

>If you use Roland's suggestion of determining the peak DEC error, setting MinMo to that, and moving on with life

My RMS DEC error in last night's guiding session on the "good" side of the meridian was 0.17 pixels / 0.52".  Yes, I could set it to 0.3 or better 0.4 to ensure it never triggered an oscillation when guiding on the "bad" side of the meridian, but as you can tell from the guiding scale I'm using, 0.4 or even 0.3 is not what I'd expect from this mount, and as I keep repeating :), I get a whole lot better on one side of the meridian.

In retrospect, I probably shouldn't have responded to Rolando's post here and stuck to my original plan of completely debugging with the PHD guys first.
 
As I have mentioned in posts on the PHD forum and on CN, I believe that this is most likely a stiction problem (that's what the graph appear to show).  If that is the conclusion I come to with the PHD team (i.e. it's not some weird bug in PHD that only manifests on one side of the meridian), then my next step wiill be to dismantle DEC, give it a good cleaning/re-greasing, re-mesh the worm and see if that helps.

Once all that is done I'll report back here and on CN with my findings.

Steve



Bill Long
 

No, it tells everyone to guide at 0.2 MinMo. No matter what camera I use for guiding (I have 5 of them, all different pixel sizes) it tells me to change MinMo to 0.2 or 0.1. Its not consistent at all and IMHO not something people that use AP mounts should listen to, much like it telling you to set BLC on your mount. Why on earth someone would take the recommendation of a one-size-fits-all software package over the PHD/Engineer (Roland) that designed them and uses them himself, is beyond me. No offense man, that is not what I am trying to convey, but Roland and others like Ray have offered a multitude of great insights on what you are trying to do (and others in that thread) and it seems folks just want to ignore it and go off on their own. Thats cool to do, no one says you have to listen to them -- but when you get bad results... well, I think you can conclude on why.


I get you have posted data there, but I checked the log at the top and it does not include the calibration data. While you find that, let me ask you where in the sky did you do your calibration? Did you do it on the target you were imaging? 


Blaming "stiction" is blaming the mount. I dont think there is anywhere near enough evidence of that. Did you open the mount up and tinker with it?


So you set the minmo to 0.29" and had oscillations, then you set it to 0.58" and did not have them.  That seems logical to me. I guide my AP1100 at about 0.7" and get perfect results.


Can you find that calibration log?




From: ap-gto@... on behalf of stephenjwinston@... [ap-gto]
Sent: Monday, July 9, 2018 6:54 PM
To: ap-gto@...
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

Hi Bill,


>Since we do not know the scale of the guiding solution you use, that is not very helpful.

Fully agree.  Again, this is actually something I have been debugging with the PHD2 guys.  All the information and detailed calibration and guide logs are there.  As mentioned in my first post above, I was avoiding discussing it here until I had completed debugging with them, but Roland opening up this thread pulled me in :).

My guider scale is: Pixel scale = 2.97 arc-sec/px, Binning = 1, Focal length = 514 mm
My imaging scale is: Pixel scale = 1.51 arc-sec/px, Binning = 1, Focal length = 735 mm

>setting your MinMo to a larger value (i.e. 0.1 to 0.3) is somehow stopping your guiding in DEC altogether. Why do you say this?

Again, this was all done in the context of testing/debugging the issue.  Setting MinMo to 0.1 triggers PHD2 to issue frequent guide pulses, triggered by seeing.  On one side of the meridian (and only one side) these corrective guide pulses trigger large oscillations that are not seen on the other side of the meridian.  Setting MinMo to 0.3 basically eliminates seeing triggered corrections (for my local seeing) and again this was done to demonstrate that the oscillations were not being triggered by something external like a dragging cable. Hope that makes sense.

>PHD cannot possibly have a "standard recommended MinMo" 
Of course.  0.2 is the standard recommendation it makes for my imaging train based on my guiding pixel scale and based on the GA run that measures high frequency RMS and backlash in my mount.  Other peoples' recommended settings will of course vary.

>If you use Roland's suggestion of determining the peak DEC error, setting MinMo to that, and moving on with life

My RMS DEC error in last night's guiding session on the "good" side of the meridian was 0.17 pixels / 0.52".  Yes, I could set it to 0.3 or better 0.4 to ensure it never triggered an oscillation when guiding on the "bad" side of the meridian, but as you can tell from the guiding scale I'm using, 0.4 or even 0.3 is not what I'd expect from this mount, and as I keep repeating :), I get a whole lot better on one side of the meridian.

In retrospect, I probably shouldn't have responded to Rolando's post here and stuck to my original plan of completely debugging with the PHD guys first.
 
As I have mentioned in posts on the PHD forum and on CN, I believe that this is most likely a stiction problem (that's what the graph appear to show).  If that is the conclusion I come to with the PHD team (i.e. it's not some weird bug in PHD that only manifests on one side of the meridian), then my next step wiill be to dismantle DEC, give it a good cleaning/re-greasing, re-mesh the worm and see if that helps.

Once all that is done I'll report back here and on CN with my findings.

Steve



Stephen Winston
 

>I get you have posted data there, but I checked the log at the top and it does not include the calibration data

There have been several logs posted on that thread, along with extensive discussion of the tests I've been doing.  The latest logs posted there have calibration data from last night.

(for others, the thread can be found on the PHD forums at : https://groups.google.com/forum/#!topic/open-phd-guiding/Rt2dLPXqfzo

I will be gathering additional logs for them tonight and updating that thread.  I suggest that anyone interested in this topic follow it there.

>Blaming "stiction" is blaming the mount. I dont think there is anywhere near enough evidence of that. 

Sorry, but have you reviewed all the data and discussions on the PHD2 forum thread? If so I'm open to hearing alternative reasons for the 10+ arc-second pk-to-pk oscillations I've seen.

>Did you open the mount up and tinker with it?

I removed the DEC cover to confirm that I can freely turn the gears.  I also did this in the middle of a test session when the mount was exhibiting the oscillations (stopped guiding, disconnected the DEC motor cable and turned the gears by hand) to try confirm that it wasn't a localized tight spot at the point on the wheel.

Steve


Stephen Winston
 

>No, it tells everyone to guide at 0.2 MinMo.

BTW: Not to be picky, but this is not actually true.  If you run the Guiding Assistant it will recommend a range of values based on what it measures on your mount / local seeing conditions.  PHD2 often "recommends" MinMo or 0.15 or even 0.10 for my mount, but I have been sticking with 0.20.

You'll see on the PHD2 forum thread that Bruce (one of the PHD2 developers) already acknowledged that those recommendations are overly optimistic and I hope they will address that in a future update.

I believe that 0.20 is the "default" setting if you have not run Guiding Assistant to characterize your specific mount/conditions.




Bill Long
 

Not in my use of the software it doesnt. It suggests things you should not do, at all, ever.  Like set your MinMo to 0.2 (or 0.18, 0.11, 0.10, 0.13) as you did.


0.2 pixels of "sticking with it" means seeing needs to support 0.58" guide stars. That is not what you had.


https://groups.yahoo.com/neo/groups/ap-gto/files/Steve_Issue.JPG


Not sure that link is going to work, but that was the worst of the data you uploaded.  Lets look at this for a moment. On the far right is the plot of your guide star. Notice how its quite literally all over the place. You did not have seeing to support 0.29" guiding, or the small incremental differences you tried here. The largest you used was 0.53". Up above is the mass of the star you were guiding on. Notice how its spikes like mad. Now that we have looked at those two things, lets have a look at the DEC data in the guide graph. You are sending massive corrections every single guide pulse. Every. Single. One. So every second you are telling the mount to move massive increments, because of the limit you set (which was WAY WAY WAY too low). Now the dotted line represents the limit you set (MinMo). You have a small window where your seeing supported that, a very, very small one, then everything goes off the rails again. 


This is not a problem with stiction. This is a problem with you accepting what the GA told you to do, which was wrong, and not using the advice of the person that made the mount. 


If you want to use GA, then use it like this:


  1. Calibrate Guider at Celestial Pole | Meridian.
  2. Turn on GA.
  3. Let GA run for 300 seconds.
  4. Stop GA, and ignore the suggestions it makes.
  5. Look at Peak DEC error. It gives it to you in both pixels (which you need for PHD MinMo) and Arc-Seconds (which you need to talk to people with).
  6. Set MinMo to Peak DEC error value GA gave you.
  7. Guide, and let it guide for 300 seconds. Do not touch the MinMo at all. Leave it alone.
  8. If you see corrections that are go far past the center line, reduce the Aggression (which you also never changed in these tests) by 5 then let it run for 60 seconds, and adjust further as needed. Do not change both axis at the same time. 

Now once you follow that you should get good guiding results. Do not obsess over the PHD graph though. Look at the imaging results you get, keep in mind your seeing, and party on.




From: ap-gto@... on behalf of stephenjwinston@... [ap-gto]
Sent: Monday, July 9, 2018 7:50 PM
To: ap-gto@...
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

>No, it tells everyone to guide at 0.2 MinMo.


BTW: Not to be picky, but this is not actually true.  If you run the Guiding Assistant it will recommend a range of values based on what it measures on your mount / local seeing conditions.  PHD2 often "recommends" MinMo or 0.15 or even 0.10 for my mount, but I have been sticking with 0.20.

You'll see on the PHD2 forum thread that Bruce (one of the PHD2 developers) already acknowledged that those recommendations are overly optimistic and I hope they will address that in a future update.

I believe that 0.20 is the "default" setting if you have not run Guiding Assistant to characterize your specific mount/conditions.




Stephen Winston
 

>Not in my use of the software it doesnt. It suggests things you should not do, at all, ever.  
>Like set your MinMo to 0.2 (or 0.18, 0.11, 0.10, 0.13) as you did.

Bill, I can only assume you still haven't read the full PHD thread and are just picking isolated sections of guide graphs to share here.

First: In the section you posted when I was deliberately changing the MinMo all the way down to 0.10, I was explicitly demonstrating for the PHD2 team that the oscillations were not being caused by a dragging cable.  With MinMo set to 0.3, PHD2 will indeed ignore most of the seeing, and hence not generating any guide corrections.  If there had been a dragging cable causing the DEC spikes it would have been seen - but it was not.  WIth MinMo set to a more aggressive level, PHD2 starts generating guide pulses (yes, chasing the seeing) but these guide pulses trigger an immediate and repeating over correction.

I will upload the complete guide logs so others can have the full view of what is going on and make their own conclusions.


>This is a problem with you accepting what the GA told you to do, which was wrong, and not using the advice of the person that made the mount. 

GA recommended 0.15 and I used 0.20.  Is 0.20 overly optimistic for my seeing conditions?  Perhaps.  

Still doesn't explain why on one side of the meridian the mount + PHD2 has no problem guiding for hours with a 0.20 MinMo.

If not stiction, then what is causing the massive over corrections coupled with the fact that it take multiple guide pulses before the mount starts to respond?

Steve



Ray Gralak
 

What I don't get is why some think that the mount is entirely the problem. I think that the autoguiding software is at least part of the problem here. Autoguiding is not easy and can be extremely unpredictable.

MaximDL has been refining algorithms for 20+ years so I am pretty sure they have an order of magnitude more experience testing and developing (trade secret) autoguiding techniques than the entire PHD2 team combined. Yet, I do not think that MaximDL's autoguiding algorithms are able to predict all unexpected conditions.

Last year I discovered a couple of bugs in PHD2 in the course of one evening of testing. I can only guess that most of the current developers who work on this software are doing it for fun. The guiding techniques incorporated are nothing really new so it is not surprising that the PHD2 forum is often ripe with people with guiding problems.

Case in point is the current dec oscillation issue. Actual declination drift *very* seldom changes direction in the sky so if the mount is operating correctly the guiding software should very seldom need to issue a reverse direction move. Yet the software does... and way too often in some cases! Now this may just be a configuration issue but you can't expect a user to babysit the parameters and know how to change them when seeing changes or the mount is flipped to the other side of the pier.

I think new approaches to autoguiding are needed to move autoguiding out of 20th century techniques.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Monday, July 9, 2018 7:51 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN



No, it tells everyone to guide at 0.2 MinMo.

BTW: Not to be picky, but this is not actually true. If you run the Guiding Assistant it will recommend a range of
values based on what it measures on your mount / local seeing conditions. PHD2 often "recommends" MinMo or
0.15 or even 0.10 for my mount, but I have been sticking with 0.20.


You'll see on the PHD2 forum thread that Bruce (one of the PHD2 developers) already acknowledged that those
recommendations are overly optimistic and I hope they will address that in a future update.



I believe that 0.20 is the "default" setting if you have not run Guiding Assistant to characterize your specific
mount/conditions.








Bill Long
 

I've never used Maxim but I would suspect it does a great job of guiding. I use PHD, but I'm exploring other options. I have Sky X, but haven't heard much about its guiding.
From: ap-gto@... on behalf of 'Ray Gralak (Groups)' groups3@... [ap-gto]
Sent: Monday, July 9, 2018 8:38:27 PM
To: ap-gto@...
Subject: RE: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

What I don't get is why some think that the mount is entirely the problem. I think that the autoguiding software is at least part of the problem here. Autoguiding is not easy and can be extremely unpredictable.

MaximDL has been refining algorithms for 20+ years so I am pretty sure they have an order of magnitude more experience testing and developing (trade secret) autoguiding techniques than the entire PHD2 team combined. Yet, I do not think that MaximDL's autoguiding algorithms are able to predict all unexpected conditions.

Last year I discovered a couple of bugs in PHD2 in the course of one evening of testing. I can only guess that most of the current developers who work on this software are doing it for fun. The guiding techniques incorporated are nothing really new so it is not surprising that the PHD2 forum is often ripe with people with guiding problems.

Case in point is the current dec oscillation issue. Actual declination drift *very* seldom changes direction in the sky so if the mount is operating correctly the guiding software should very seldom need to issue a reverse direction move. Yet the software does... and way too often in some cases! Now this may just be a configuration issue but you can't expect a user to babysit the parameters and know how to change them when seeing changes or the mount is flipped to the other side of the pier.

I think new approaches to autoguiding are needed to move autoguiding out of 20th century techniques.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Monday, July 9, 2018 7:51 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN
>
>
>
> >No, it tells everyone to guide at 0.2 MinMo.
>
>
> BTW: Not to be picky, but this is not actually true. If you run the Guiding Assistant it will recommend a range of
> values based on what it measures on your mount / local seeing conditions. PHD2 often "recommends" MinMo or
> 0.15 or even 0.10 for my mount, but I have been sticking with 0.20.
>
>
> You'll see on the PHD2 forum thread that Bruce (one of the PHD2 developers) already acknowledged that those
> recommendations are overly optimistic and I hope they will address that in a future update.
>
>
>
> I believe that 0.20 is the "default" setting if you have not run Guiding Assistant to characterize your specific
> mount/conditions.
>
>
>
>
>
>
>
>


Bill Long
 

As I disclosed, I found the worst section and looked at it. In this case, 0.58" was way overly optimistic. I see Bruce suggested longer exposures and about a 1.2" min mo. That seems like a good test.
From: ap-gto@... on behalf of stephenjwinston@... [ap-gto]
Sent: Monday, July 9, 2018 8:37:10 PM
To: ap-gto@...
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

>Not in my use of the software it doesnt. It suggests things you should not do, at all, ever.  

>Like set your MinMo to 0.2 (or 0.18, 0.11, 0.10, 0.13) as you did.

Bill, I can only assume you still haven't read the full PHD thread and are just picking isolated sections of guide graphs to share here.

First: In the section you posted when I was deliberately changing the MinMo all the way down to 0.10, I was explicitly demonstrating for the PHD2 team that the oscillations were not being caused by a dragging cable.  With MinMo set to 0.3, PHD2 will indeed ignore most of the seeing, and hence not generating any guide corrections.  If there had been a dragging cable causing the DEC spikes it would have been seen - but it was not.  WIth MinMo set to a more aggressive level, PHD2 starts generating guide pulses (yes, chasing the seeing) but these guide pulses trigger an immediate and repeating over correction.

I will upload the complete guide logs so others can have the full view of what is going on and make their own conclusions.


>This is a problem with you accepting what the GA told you to do, which was wrong, and not using the advice of the person that made the mount. 

GA recommended 0.15 and I used 0.20.  Is 0.20 overly optimistic for my seeing conditions?  Perhaps.  

Still doesn't explain why on one side of the meridian the mount + PHD2 has no problem guiding for hours with a 0.20 MinMo.

If not stiction, then what is causing the massive over corrections coupled with the fact that it take multiple guide pulses before the mount starts to respond?

Steve



Ray Gralak
 

Hi Steve,

If not stiction, then what is causing the massive over corrections cou pled with the fact that it take multiple guide
pulses before the mount starts to respond?
One possibility... incorrect application of dec backlash compensation by the software, which might be incrementally increasing movements every cycle until it gets an overreaction.

Can you post the original PHD2, AP V2 driver (and APCC if used) logs?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Monday, July 9, 2018 8:37 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN



Not in my use of the software it doesnt. It suggests things you should not do, at all, ever.
Like set your MinMo to 0.2 (or 0.18, 0.11, 0.10, 0.13) as you did.


Bill, I can only assume you still haven't read the full PHD thread and are just picking isolated sections of guide
graphs to share here.


First: In the section you posted when I was deliberately changing the MinMo all the way down to 0.10, I was
explicitly demon strating for the PHD2 team that the oscillations were not being caused by a dragging cable. With
MinMo set to 0.3, PHD2 will indeed ignore most of the seeing, and hence not generating any guide corrections. If
there had been a dragging cable causing the DEC spikes it would have been seen - but it was not. WIth MinMo
set to a more aggressive level, PHD2 starts generating guide pulses (yes, chasing the seeing) but these guide
pulses trigger an immediate and repeating over correction.

I will upload the complete guide logs so others can have the full view of what is going on and make their own
conclusions.



This is a problem with you accepting what the GA told you to do, which was wrong, and not using the advice of
the person that made the mount.



GA recommended 0.15 and I used 0.20. Is 0.20 overly optimistic for my seeing conditions? Perhaps.


Still doesn't explain why on one side of the meridian the mount + PHD2 has no problem guiding for hours with a
0.20 MinMo.


If not stiction, then what is causing the massive over corrections cou pled with the fact that it take multiple guide
pulses before the mount starts to respond?

Steve





Stephen Winston
 

Hi Ray,

I certainly don't think the mount is entirely the problem.

I have been trying to debug this with the PHD2 team to try figure out what the root cause is.   I suggested to them that maybe it is a bug in PHD2 or bad settings, but what we have seen so far appears to point to stiction, But we could be wrong.

I am open to all possibilities, including user stupidity - wouldn't be the first time :)

And I agree, it can be tricky with changing seeing conditions, meridian flips etc I'm sure someone somewhere is working on a more robust solution :)

Anyway - I've uploaded some sample guiding logs and screen caps from PHD Log Viewer that show good and bad guiding examples.  Everyone is free to view for themselves, but I do ask that before jumping to conclusions on what I was doing in the specific test scenarios that you read the PHD2 forum thread first to understand what was going on.

Steve


Ray Gralak
 

Hi Bill,

options. I have Sky X, but haven't heard much about its guiding.
The Bisque's have been doing astro software probably longer than anyone. CCDSoft V5 autoguiding was generally considered to be very
good, at least on par with MaxmDL's . I think that CCDSoft has evolved to be the camera add on to SkyX, so I would expect similar,
if not improved performance.

Please post any observations once you've had a chance to use it for a while.

Best regards,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Monday, July 9, 2018 8:45 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN



I've never used Maxim but I would suspect it does a great job of guiding. I use PHD, but I'm exploring other
options. I have Sky X, but haven't heard much about its guiding.
________________________________

From: ap-gto@yahoogroups.com <ap-gto@yahoogroups.com> on behalf of 'Ray Gralak (Groups)'
groups3@gralak.com [ap-gto] <ap-gto@yahoogroups.com>
Sent: Monday, July 9, 2018 8:38:27 PM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] Re: Things that customers do that drive me nuts on CN



What I don't get is why some think that the mount is entirely the problem. I think that the autoguiding software is
at least part of the problem here. Autoguiding is not easy and can be extremely unpredictable.

MaximDL has been refining algorithms for 20+ years so I am pretty sure they have an order of magnitude more
experience testing and developing (trade secret) autoguiding techniques than the entire PHD2 team combined.
Yet, I do not think that MaximDL's autoguiding algorithms are able to predict all unexpected conditions.

Last year I discovered a couple of bugs in PHD2 in the course of one evening of testing. I can only guess that
most of the current developers who work on this software are doing it for fun. The guiding techniques
incorporated are nothing really new so it is not surprising that the PHD2 forum is often ripe with people with
guiding problems.

Case in point is the current dec oscillation issue. Actual declination drift *very* seldom changes direction in the
sky so if the mount is operating correctly the guiding software should very seldom need to issue a reverse
direction move. Yet the software does... and way too often in some cases! Now this may just be a configuration
issue but you can't expect a user to babysit the parameters and know how to change them when seeing changes
or the mount is flipped to the other side of the pier.

I think new approaches to autoguiding are needed to move autoguiding out of 20th century techniques.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Monday, July 9, 2018 7:51 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] Re: Things that customers do that drive me nuts on CN



No, it tells everyone to guide at 0.2 MinMo.

BTW: Not to be picky, but this is not actually true. If you run the Guiding Assistant it will recommend a range of
values based on what it measures on your mount / local seeing conditions. PHD2 often "recommends" MinMo
or
0.15 or even 0.10 for my mount, but I have been sticking with 0.20.


You'll see on the PHD2 forum thread that Bruce (one of the PHD2 developers) already acknowledged that those
recommendations are overly optimistic and I hope they will address that in a future update.



I believe that 0.20 is the "default" setting if you have not run Guiding Assistant to characterize your specific
mount/conditions.










Bill Long
 

Ray wrote the AP ASCOM driver you use. Logging is on by default and he can tell you what the mount was doing. Snag that log and share it.  ��
From: ap-gto@... on behalf of stephenjwinston@... [ap-gto]
Sent: Monday, July 9, 2018 8:54:27 PM
To: ap-gto@...
Subject: RE: [ap-gto] Re: Things that customers do that drive me nuts on CN
 
 

Hi Ray,


I certainly don't think the mount is entirely the problem.

I have been trying to debug this with the PHD2 team to try figure out what the root cause is.   I suggested to them that maybe it is a bug in PHD2 or bad settings, but what we have seen so far appears to point to stiction, But we could be wrong.

I am open to all possibilities, including user stupidity - wouldn't be the first time :)

And I agree, it can be tricky with changing seeing conditions, meridian flips etc I'm sure someone somewhere is working on a more robust solution :)

Anyway - I've uploaded some sample guiding logs and screen caps from PHD Log Viewer that show good and bad guiding examples.  Everyone is free to view for themselves, but I do ask that before jumping to conclusions on what I was doing in the specific test scenarios that you read the PHD2 forum thread first to understand what was going on.

Steve