SX-AO won't calibrate

[jerrym...@gmail.com]

I have connected up my new SX-AO unit using the USB connection to serial port com 10, it all seems to connect up fine.  Device Manager shows COM10 exists and PHD2 says everything is connected fine.  But when the AO calibration starts it never seems to finish and the cross hairs just circle around in a small area indefinitely.

After several attempts with the same result, I reconnected the cables to just use the Lodestar X2 in simple OAG mode and that worked great. In that mode I got dramatically better guiding than I ever did with my separate Orion Short Tube 80mm guide scope using the same X2.  Four minute frame offsets went from 5-10 pixels between frames to 1 pixel over 20 frames.  OAG really works.  But I am really anxious to see what the AO can do.  

I cycled back and forth a couple of times between the two modes.

Attached are several PHD logs of these attempts.  The three long ones are the AO attempts.

Thanks for any help on this.

Jerry

[Andy Galasso]

Hi Jerry,

The debug log shows that the AO is getting as far as position X=-31, Y=-44 then failing to move any further, reporting it has reached its limit.  PHD2 expects the AO to be able to move 45 steps in each direction (like to position X=-45, Y=-45).

I think you should contact Terry at Starlight Xpress and see if he has any suggestion about getting the AO to be able to move the full 45 steps in each direction. Feel free to CC me when you contact SX.

A secondary problem is that PHD2 is not handling the failure correctly: it should report the error rather than repeating the calibration moves indefinitely. We'll fix this in PHD2 (Issue #539) so that it will fail with an error message rather then repeating the failed moves indefinitely.

Andy

[jerrym...@gmail.com]

Thanks for the help Andy.  Terry gave me the following suggestion:

"New units can be a bit 'stiff' at the extremes. I suggest using our AO utility to run in the drive - select 50 in the 'Amount' box and then press 'Repeat Calibration'. It will perform 50 calibration cycles and should be free running after the operation."

which I will try tomorrow.

I am a little confused about AO the calibration process.  It apparently is just for the AO motion.  What about the usual mount calibration process?  Will that get done automatically?

[Andy Galasso]

On Fri, May 27, 2016 at 7:14 PM <jerrym...@gmail.com> wrote:

I am a little confused about AO the calibration process.  It apparently is just for the AO motion.  What about the usual mount calibration process?  Will that get done automatically?

Yes, the AO is calibrated first, followed by the Mount.   Since you have not been able to get past the AO calibration you have not seen the Mount calibration start.

Andy

[jerrym...@gmail.com]

Hi Andy,

Per Terry's suggestion I ran the AO utility several times.  I also removed the entire AO unit from my focuser so I could insert a small screwdriver to check the 4 screws.  All 4 turn very easily at least one turn in each direction, so none of them are binding up as if they had reached a limit.

Then on rerun I get exactly the same apparent results.  Logs attached.

Do you think I have a faulty unit, or is there something else I can try?

Is there any chance as indicated from the logs that I do not have it connected correctly?  Seems pretty simple.  Power is connected, USB cable connects to USB hub for the serial communication which shows up as COM 10. Mount Correction Output cable goes to the Auto Guide port on the Gemini 2.

What I see in PHD2 during the calibration process is the star moves steadily up and down then when it says it is calibration Left, it does not move left or right.  After a few tries it puts out the error message.

Thanks for any help on this.  It would be super to get this working.

Jerry

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

Hi Jerry,

Sorry to hear you are having trouble with it.

The PHD2 Debug log shows the AO was able to move 32 steps to the left, but no further.  PHD2 expects the AO to be able to move 45 steps in each direction, including diagonally (e.g. 45 right and 45 up).

There is no indication of any connection problems, you can definitely rule that out.

You should be able to reproduce this problem with the SX AO utility.  Try using the SX AO utility to center the AO then move Left one step at a time.  If you cannot move 45 steps left, then phd2 will not be able to do so either and calibration will not succeed.   You will need to talk to Terry to see if he has any ideas to allow the AO to move 45 steps in each direction.

Andy

[Hans]

I have the same issue with SVX-AO-LF firmware version 121 with PHD2 on Linux.
I started to make PHD2 measure the max travel range so that the hardcode of 45 steps can be adjusted to whatever the various firmware versions changed it into, however I ran into unexpected issues and have not continued work on it since. I still want to finish this, but Real Life with its own time scedule gets in the way :-D

-- Hans

[jerrym...@gmail.com]

It looks to me like the firmware on my unit only allows travel of 32 units.  Can I get a versions of PHD2 that only uses 30 units in each direction?  If it works for me that might confirm that a hard coded value of 45 is not appropriate.

On doing the recommended tests with the SX AO utility, I am really in the dark about how to do this.  I can't find a manual for the SX AO utility on the SX site, and the user interface gives little help in figuring this out.  I assume all the feedback occurs on the bottom status line.  What responses should one expect for various actions?  What sequence of buttons would I press to move the AO "Left one step at a time"?  No Left is indicated on the dialog, just E W N S.  Hopefully there is a manual for this software somewhere.

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

On Sat, Jun 18, 2016 at 11:23 AM, <jerrym...@gmail.com> wrote:

It looks to me like the firmware on my unit only allows travel of 32 units.  Can I get a versions of PHD2 that only uses 30 units in each direction?  If it works for me that might confirm that a hard coded value of 45 is not appropriate.

Jerry,  I have no objection to adding an option in PHD2 to set the expected travel range.  But are you sure you want this?  If you limit the travel range you will require more frequent mount bumping which somewhat negates the benefit of the AO.  I would think that if Terry can diagnose why it is not moving the expected 45 steps and can provide a fix then you would be better off that way.

What responses should one expect for various actions?  What sequence of buttons would I press to move the AO "Left one step at a time"?  No Left is indicated on the dialog, just E W N S.

I have not used the AO Utility in a long time. I think the feedback about the step succeeding or failing is shown in the status bar at the bottom of the window.   For "left" I should have said "West".  Set the amount to "1" and click Guide.  Count to yourself each time you click and watch the status in the status bar. If I recall correctly it will say "G" each time you step, and then say something different like "L" when it hits the limit.

Andy

[jerrym...@gmail.com]

Thanks Andy for the great feedback.  I just did the stepping in all 4 directions.  West hit Limit at 47.  Then going East it hit Limit at 95 from the West Limit.  Also South and North get to about 52 before hitting the limit.

So it definitely will move 45+ steps in all 4 directions when it starts from a centered position.

Am I assuming correctly that when first connecting you enter a center command?  And when you do the first calibration and you step out to 45 in that direction, do you then step back the same 45 steps so you are again centered before calibrating in another direction?

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

On Sat, Jun 18, 2016 at 7:15 PM, <jerrym...@gmail.com> wrote:

Am I assuming correctly that when first connecting you enter a center command?

yes, correct

 

 And when you do the first calibration and you step out to 45 in that direction, do you then step back the same 45 steps so you are again centered before calibrating in another direction?

The calibration sequence is:

  start at center

  move down and right to bottom right corner (aka South and East)

  move left to bottom left corner

  move up to top left corner

  move down and right to center

The step size increment is the "Cal steps" setting in the brain.

It sounds like your AO is ok reaching the "sides" (x = +45, y = 0), but having trouble reaching the corners (x = -45, y = -45).

I added a setting in the brain to allow you to override the 45-step limit to a smaller value, and that will be available in the next development build in the next day or so.

Andy

[jerrym...@gmail.com]

I tried your exact calibration sequence.  Sure enough, it can reach the SE corner, but cannot move straight across to the SW corner.  It will move between any two corners with a box size of  72 (max offset from center of 36 in x or y).

Seems to me the calibration routine and normal guiding operation should be allowing motion within a circle of radius of x instead of within a square of side x.  For my AO unit, motion within a circle of radius 45 works great, but not a square of side 90.  That would allow a much wider range of motion for my unit that using a square.  I would guess that other units will behave in a similar fashion.

 

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

On Sun, Jun 19, 2016 at 12:13 AM, <jerrym...@gmail.com> wrote:

I tried your exact calibration sequence.  Sure enough, it can reach the SE corner, but cannot move straight across to the SW corner.  It will move between any two corners with a box size of  72 (max offset from center of 36 in x or y).

Ok, let's see how it does with the forthcoming dev build where you will be able to set the limit to 36 (down from the default of 45).

 

Seems to me the calibration routine and normal guiding operation should be allowing motion within a circle of radius of x instead of within a square of side x.  For my AO unit, motion within a circle of radius 45 works great, but not a square of side 90.  That would allow a much wider range of motion for my unit that using a square.  I would guess that other units will behave in a similar fashion.

I think you are on to something there. I added an enhancement request to the issue tracker (#542)

Andy

[Andy Galasso]

Jerry,

v2.6.1dev11 is now available with the new setting to limit the AO travel.

Andy

[jerrym...@gmail.com]

Thanks Andy.  Will give it a try tonight.

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[jerrym...@gmail.com]

I ran dev 11 last night and set the AO travel limit to 36.  It calibrated several times without a hitch.  Thanks Andy.

Now my question is what am I supposed to see that is different than running in normal non-AO mode?  To all appearances it was guiding exactly the same with AO as without AO.  I did enable the AO graph and it showed the position very near the center for the roughly 1 hour I ran it.  When I used Auto for exposure it seemed to have a cycle time for exposures of around 2 seconds.  The guiding results were very comparable both with and without the AO. 

I thought it would try to use a much faster exposure time that would vary with the seeing, but that did not happen.  

I did have a real problem with it choosing hot pixels for a guide star, even though I was using a dark library.  This was such a problem that I quit after about an hour.  Should I start a new topic for this guide star issue, or might it be related to the AO?

 

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

On Mon, Jun 20, 2016 at 2:45 PM, <jerrym...@gmail.com> wrote:

 When I used Auto for exposure it seemed to have a cycle time for exposures of around 2 seconds.  The guiding results were very comparable both with and without the AO. 

I thought it would try to use a much faster exposure time that would vary with the seeing, but that did not happen.  

If you use Auto for exposure duration, then PHD2 will adjust the exposure to keep the SNR value steady at the target SNR value you have in the brain (within the range of exposures you select.)

If you want to experiment with short exposures, make sure you enable sub-frames since that will dramatically reduce the image download time.

 

I did have a real problem with it choosing hot pixels for a guide star, even though I was using a dark library.  This was such a problem that I quit after about an hour.  Should I start a new topic for this guide star issue, or might it be related to the AO?

I would highly recommend using a Bad-pixel map with your Lodestar X2.  It is very easy to remove hot pixels using a bad-pixel map.   When using the Bad-pixel map with the SX ASCOM driver you must disable interlaced adjustments in the ASCOM driver settings.   Or, use the built-in SX camera driver ("Starlight Xpress SXV").

We do have some work in progress to make PHD2 better at avoiding selecting hot pixels, but generally the Bad-pixel map is the best solution.

Andy

[Andy Galasso]

On Mon, Jun 20, 2016 at 2:45 PM, <jerrym...@gmail.com> wrote:

I did have a real problem with it choosing hot pixels for a guide star, even though I was using a dark library.

Jerry,

If possible, next time you see this problem, could you save the image (File => Save Image) and post a link.  It would be very helpful to add your image to our collection that we use for developing the star finder.

Andy

[jerrym...@gmail.com]

I got a couple of hours of imaging in last night.  Guiding with the AO worked quite well.  With my X2 binned 2 and exposure set to .1 second, it pumps out corrections 10/sec and the SNR stayed around 60-100.  I was quite impressed.

However, the guiding errors were in the vicinity of .6 arcsecs, which was the same as I was getting with both 2 second and 4 second exposures.  Is this what I should expect, or does it require a lot more tweaking of parameters to get an improvement using the AO?

Andy, I am guessing that is what you are referring to when you mention "experiment with short exposures".  Have you been able to get significantly better guiding using the AO vs standard guiding?

Am I correct in assuming the when using AO, when it needs to recenter that is going to tend to produce elongated stars on the current frame?

The bad pixel map did a perfect job of removing all my bad pixels that were being selected as guide stars.  So my question is, what use is the dark library?  Why not just recommend use of the bad pixel map exclusively?

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

On Tue, Jun 21, 2016 at 6:46 PM, <jerrym...@gmail.com> wrote:

I got a couple of hours of imaging in last night.  Guiding with the AO worked quite well.  With my X2 binned 2 and exposure set to .1 second, it pumps out corrections 10/sec and the SNR stayed around 60-100.  I was quite impressed.

However, the guiding errors were in the vicinity of .6 arcsecs, which was the same as I was getting with both 2 second and 4 second exposures.  Is this what I should expect, or does it require a lot more tweaking of parameters to get an improvement using the AO?

Andy, I am guessing that is what you are referring to when you mention "experiment with short exposures".  Have you been able to get significantly better guiding using the AO vs standard guiding?

With shorter exposures you are chasing seeing more.  Depending on the characteristics of the turbulence, rapid corrections may make your guiding worse, or they might make it better sometimes (I have seen both cases).   I really like this video presentation by Gaston Baudat explaining the theory.

I primarily consider the AO as a way to overcome any imperfections in the mount. The AO has no backlash and it has a faster response time than the mount.

I always use my AO when imaging at 2100mm focal length. I use Auto exposures with a 0.5-3 second range and a target SNR of 20. I keep the aggressiveness high (85-95%) and a small hysteresis (5%). With that combination of settings I can just forget about phd2 as it will adapt to various guide stars and seeing conditions.

Am I correct in assuming the when using AO, when it needs to recenter that is going to tend to produce elongated stars on the current frame?

There should not be any elongation caused by the recentering, unless your "bump step" setting is way off.  I have my "bump steps" set at 1.75 which means each at each guide exposure the mount is bumped an amount equivalent to 1.75 AO steps. This is quite small and the AO is able to react quickly enough that the error is imperceptible.   If you set bump steps too low it may not be able to keep up with dec drift or PE, or the corrections might be so small that they are ignored by the mount, so you'll need to experiment to find a value that works well for you. Once you find it you can leave it alone.

 

The bad pixel map did a perfect job of removing all my bad pixels that were being selected as guide stars.  So my question is, what use is the dark library?  Why not just recommend use of the bad pixel map exclusively?

There are some cases where the dark lib might work better, like if the camera driver is modifying the image (e.g.: SX ASCOM de-interlacing.), or if there is a very high background gradient (amp glow) obscuring the guide stars.  Also, in general we are reluctant to take away a feature that users are using.

Andy

[jerrym...@gmail.com]

Thanks Andy for the excellent detailed feedback.  It all makes good sense.  I will try your suggested settings my next clear night, which looks to be a few nights away.

On the dark libraries, there are clearly cases where they can provide an improvement that just using bad pixel maps would not.  I was not suggesting to remove the feature.  But what I think would be an improvement would be to emphasize using the bad pixel map unless there is a specific reason to use the dark library.  In my case, I have always used the dark library approach because I thought it would do as good a job of removing hot pixels as a bad pixel map does.  It clearly does not, so I think the user should be actively encouraged to use a bad pixel map.  I have gone for a year getting inferior results because I did not know there was a big difference.

On Friday, May 27, 2016 at 9:54:08 AM UTC-6, jerrym...@gmail.com wrote:

[Andy Galasso]

Thanks Jerry, I think you raise a great point.  I agree that the BPM seems to be generally superior and it would make sense for the docs and the New Profile wizard work flow to reflect that.

Andy