Star lost during RA calibration with OAG

[Kevin]

I have been (previously) successfully using PHD2 v2.6.9 with the following configuration:

• 180mm focal length 50mm guide scope
• ASI120MM-Mini guide camera
• 150mm f/4 Newtonian reflector (610mm focal length)
• Sony NEX-5R main imaging camera
• Skywatcher HEQ5
• Raspberry Pi 4 running Astroberry
• KStars/Ekos/INDI software stack for control, PHD2 running on the same device
  
• Synscan INDI driver for mount control
  

Last night, I tried switching out the guide scope for a ZWO off-axis guider, primarily as a test for when I do some imaging with a main camera with much smaller pixels so I can maintain adequate image scale for proper guiding, and to reduce the total system weight somewhat. I made sure to correctly adjust my focal length in PHD2 to 610mm which resulted in a recommended calibration pulse duration of 400ms instead of 1200ms which made sense and I accepted.

The test image of the guide camera view in PHD2 when using the OAG looked great, sharp with clear stars using 1-3 second exposures. No problem auto-selecting a star to start the calibration process.

However, when I went to calibrate I found that the calibration process would properly perform the first set of west steps, but then at some point the selected star would suddenly jump twice as far east as the mount had moved in all the west steps up to that point and I would get a star lost error as the star was now out of view and calibration would not succeed. Put another way, if the star had moved 20 pixels west of the starting point in the first calibration steps, it would suddenly jump to be about 40 pixels east of its current position (and 20 pixels from the starting position) in a single frame. This huge move caused PHD2 to lose the star, and the calibration would get hung up.

At first I thought my mount was skipping steps or binding, but I confirmed by watching the mount's current RA direction in software that the mount's known pointing position was actually jumping as well, indicating the mount itself had not slipped and still correctly knew the pointing direction. This implied that something had commanded the mount to jump a large distance in a single frame, but I could not determine what.

I tried a variety of settings in the field, restarting software, the mount, resetting PHD2 to defaults, and did not have any success so I instead imaged with the built-in internal Ekos guider (which I find pretty inferior to PHD2) for the night. That guider was able to calibrate without too much issue using the off-axis guider setup though, and otherwise worked in general.

I did some digging after the fact and examining my guide logs, I now have a suspicion that my problem is caused by a combination of the "Fast recenter after calibration or dither" option and possibly the "Max RA duration" of 2500ms. I'm not 100% sure I understand how that option works, but my current working assumption is that PHD2 is hitting the current 25 pixel calibration target distance then blindly issuing a 2.5 second east correction command to the mount, which is pushing the star farther than PHD2 can keep track of it (it's still well within the image frame, but far from the green "box") since I'm operating with a much longer guiding focal length using the off-axis guider, and then calibration fails.

I'm hoping to get some confirmation on if I'm on the right track here, and what my best options are for resolving this. Is this expected at an effective 610mm focal length with a sensor like the ASI120MM? Should I turn off the fast recenter option (what does this lose me), or should I reduce my Max RA/Dec duration instead (will doing this cause me any other issues)? If PHD2 automatically adjusts the calibration step to suit when I set the focal length, why does it not also reduce the max RA and Dec step size as well? Maybe I should be changing something else? Is anybody able to provide a more detailed description on the actions/algorithm PHD2 uses when performing the fast recenter so I can understand what's happening more completely? I'm still not 100% sure because I would have expected PHD2 would have to take east steps back to center the "normal" way during calibration (rather than making a sudden jump to center with a large single move) but I might just have an incomplete understanding of how the calibration process works when changing directions.

I have attached my guide and debug logs from the night, showing the repeated calibration attempts and failures. I also had some other weird behaviour where mode switches in PHD2 didn't seem to take the way I expected and I had a couple crashes, so any insight on those would be helpful as well before I go out next for imaging. Thanks for any help or info you can provide!

I have also included a previous guide log of a successful calibration and guiding run using the 180mm focal length guide camera instead of the off-axis guider for comparison, as this might provide some insight into characteristics of my setup that might be contributing to the issues I'm seeing.

Thanks,

-Kevin

[steve]

Hi

Hands on with an OAG and 120mm:

- Dismantle, re-grease and adjust the mount that it is nothing less than mechanically perfect.

- Make a new profile for the oag using bin2 (although bat only 610mm, you may get away with bin1)

- Turn off fast re-centre.

- Allow tracking to settle; track for 5 minutes or so before calibration

- Increase the size of the box so as to not lose the star during calibration.

- Use PPEC for RA, (or multistar GPG with EKOS' internal guider).

HTH

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/876f911a-b4f4-44da-ba4c-257304fbcd5an%40googlegroups.com.

[Richard Beck]

Kevin,

Are you trying to use the 120MM Mini in 16-bit mode?  Try it in 8-bit mode to see if you have better results.

My 120MM Mini would drop to 8-bits without warning or notice when I used it in 16-bit mode.  I raised an issue with the INDI folks, and the primary maintainer said that dropping to 8-bit mode was a "feature" of ASI's driver which only applies to the 120 cameras.

[Bruce Waddington]

This is really a mess, but the problem isn’t being caused by the PHD2 calibration routine.  To start, you evidently didn’t run the new-profile-wizard to create a new profile for your OAG setup.  You must do that – trying to take the cowboy approach by just changing a few of the parameters you can think of is a bad idea.  So start over with a new profile.  That said, the problem is likely to remain because the gear seems to be behaving badly.  So here are some basic things that need to be figured out:

 

1.        Make sure you don’t have *any* backlash compensation enabled in the mount.  That will be a recipe for disaster, and it would explain the behavior you see when the guide star zooms too far to the east.

2.       Figure out why your mount is reporting nonsense values for pointing position.  PHD2 is being told that its pointing altitude is -27 degrees with an hour angle of nearly 12 hours – I assume you weren’t pointing at the ground.  Are you sure the mount is correctly initialized?  Is it in some kind of counterweights-up position?  Are the time/date/time zone values all correct?

3.       Discontinue use of any imaging or automation apps while you’re trying to get a calibration – everything must be done manually at this point.

4.       If you sort out the first two points and still have the problem, you can turn off the fast re-center option.  That feature is only there as a way to speed up the calibration process but there is no way it can create problems on a properly working mount.  But you can disable the function and see what happens.  Don’t start fooling around with guiding parameters like Max RA Duration – those have nothing to do with your problem and will only create new problems if you get past the calibration failures.  If disabling fast re-center sidesteps your problem, that’s ok but it will point toward a problem in the driver or the mount itself that may bite you down the road.

5.       Before you start the calibration, clear the Dec backlash manually, using the hand-controller to move the mount *north* until you see the stars in the image window start to move.

 

If the calibration still fails, use the Manual Guide Tool and the Star-Cross test tool  to manually emulate what is done during calibration.  This will generally expose underlying mechanical problems.  Those tools are described in the trouble-shooting section of the PHD2 manual.

 

Hope you can track it down,

Bruce

--

[Kevin]

Thanks for all the suggestions so far. Responses and additional info in order:

• The mount is new, and I have not gone deep enough into it to fully dismantle and re-grease the main bearings yet. I have replaced the spur gears with a Rowan belt kit and this has improved a fairly strong 13.6s (each tooth on the pinion gear) periodic oscillation on the RA axis I had previously, but I was hoping/expecting to at least be able to get the OAG setup to work before having to completely rebuild the otherwise new mount. I will get to this eventually, though, because I think it could be smoother - with the clutches loose there's still a bit of friction, but I don't have much frame of reference on what's expected/possible as this is my first mount.
  
• I will give 2x2 binning a shot, I definitely don't need the full image scale at this focal length, even with a much smaller imaging sensor than what I'm currently using. While I'm guessing this won't fix the core issue, it would probably mitigate it as it will cut all apparent pixel distances in half.
  
• I will try increasing the box size and testing with fast recentre off to determine what impacts that has. I did leave the mount for a while before starting the guiding calibration, so it should have been settled.
• My reading of the GPG mechanism was that it was intended for RA-only mounts, is it appropriate to use this on a two-axis mount and is it a better approach than just using PHD2?

Good hint about 16/8-bit mode. I have noted camera lost connection errors a few times on previous nights and assumed it was something about my USB setup on the Pi but had not investigated further as I was still getting decent guiding. I will give 8-bit a shot and see if it makes a difference.

• I initially did not do a full profile re-creation because I remembered the settings that were assigned during that setup and the only thing that would have been altered between my guidescope and OAG setups was the guiding focal length (and calibration step derived from that), which I adjusted. Halfway through the night I re-ran profile wizard creation from a fully defaulted PHD2 and it made no difference to the behaviour anyways.
• As mentioned a few lines up, the mount is new and I have never enabled any backlash compensation on it; does an HEQ5 come with some form of backlash compensation pre-enabled? I took a look in setup and both RA and Dec backlash is set to zero with the hand controller. The only compensation I ever activated was within PHD2 previously while using the guide scope, after running a guiding assistant where it recommended about 180ms of Dec backlash compensation which I accepted. I have since turned this off to eliminate confounding factors (it would likely need to be re-adjusted for the OAG setup anyway but I haven't gotten far enough to re-run the assistant) but it had no impact either way.
• Date/Time/Zone are all correct, mount was aligned with the normal Synscan hand controller routine before starting the guiding attempts with no obvious problems and Goto was working well and seemed accurate. I was pointing at Markarian's chain while trying to set this up, and it was definitely above the horizon; no lower than 40 degrees. Not sure why the PHD2 logs are showing strange Alt/Az values, but I do note that my previous log I also attached from the 3rd of April using the guide scope also showed a negative Alt value without apparently preventing calibration from succeeding and working for guiding at least to some degree. I do see that the RA and Dec that PHD2 is reading from the mount via the driver is correct, though.
  
• I was not doing any meaningful imaging or automation while trying to set up guiding; I had the rest of the software stack only running enough to have INDI/Ekos started so that PHD2 could connect to the mount and camera using the drivers, but had otherwise not activated anything else.
• I will leave the Max duration values as-is and will only play around with disabling fast re-center as a troubleshooting step to try and narrow down the actual root cause.
• On at least a few attempts I did clear the Dec backlash manually by nudging north before starting, but I didn't bother doing this consistently as I wasn't even successfully getting to the Dec step so it seemed like a waste of time until I could get RA calibrating properly without star loss.
• I will play around with the manual guide and star cross test and see if it highlights anything new, but I didn't notice anything odd/off when nudging the mount around in any direction during testing - it moved exactly as expected in all four directions - no obvious differences in guide rate or substantial backlash that I saw.

Thanks for all the tips so far, let me know if you have any more ideas with the above additional information and I will follow up next time I can run some tests at night.

-Kevin

[Brian Valente]

Kevin

what is GPG mode?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/84a9f298-0546-44e6-ab4c-1b9ff236c690n%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Kevin]

Steve mentioned it above; it's an alternative guiding mechanism available in Ekos (see below screenshot) but it looks like it's for RA-only guiding so I have not used it or tried it out at all. I know it exists, but no experience working with it.

Thanks,

-Kevin

[Richard Beck]

Looking at the indilib forums, GPG is the EKOS internal guider's implementation of an algorithm similar to PPEC in PHD2.  DEC guiding is unaffected (i.e., algorithm is unchanged).

[Kevin]

I had a chance to do some imaging last night, with the following additional updates/feedback:

• I had no problems/warnings that I saw of the camera dropping out this time after forcing the ASI120MM to operate in 8-bit mode in the driver, but I'll keep an eye on this. It appeared that it was already attempting to use 8-bit mode, but the configuration option was yellow in INDI until I manually toggled it, not sure what that means.
  
• Turning off fast recenter was sufficient to get the mount to accept a calibration, with no other settings changes. There's definitely something still off about how the mount is moving in RA, but it at least passes calibration and is able to guide. Accuracy was 1-2 arcseconds RMS, which is good relative to previous performance I've been able to get but I think the mount should still be able to do better if I resolve whatever is affecting the motion of the axes.
• I did a star cross test (I opted for 12 seconds in each direction), and have attached the results. For reference, the vertical line is RA motion and the horizontal line is Dec motion. Each axis moves in a very straight line in isolation, but the Dec line (horizontal) is not centered along the RA line, which implies there's something about the RA axis that's making it guide quite differently depending on if the corrections are east or west I think. This is corroborated by the calibration results (also attached) that indicate very different "steps" in the west and east directions when calibrating (the east steps go right off the chart).
• I did not have time to do a guiding assistant run, so I was using the PHD2 defaults with no Dec backlash compensation. Even still, things seemed to work ok.
• Examining the guiding logs, I notice that the guiding error scatter plot is "asymmetrical", with more error in what I think is the east direction compared to west producing a teardrop-shaped plot. North and south seem pretty balanced/even in their error rates, so it's mostly just the long "tail" that looks odd here.

Is anybody able to provide any hints/advice on what might be going on mechanically with my mount to cause this weird asymmetry in the RA axis between the east and west corrections, given the attached guide log and star cross test? I'm using 0.5x sidereal guide rate (confirmed as being set correctly in the mount/software) so I would have expected that the drivetrain would always be "loaded" in the same direction so that backlash/flop or any other biased back and forth motion wouldn't be a major factor, but maybe it's something else or that I'm missing something. In general, I balance the mount pretty "neutral" in both axes;  I have seen conflicting advice on this. I find that there's a fairly large region of balance where the mount will not swing on its own due to friction in the axes (with clutches released), but I'm not sure if that's normal/expected with an HEQ5 or if I should expect the axes to be very "loose" when unclutched and for small balance adjustments to cause the mount to cross the "tipping point" to sag in the other direction. At a guess, I probably need to move one of the counterweights a least a couple inches to go from the mount freely dropping one way to the other if that helps.

Thanks,

-Kevin

[steve]

On 14/4/21 9:12, Kevin wrote:

what might be going on mechanically with my mount

Hi

Hands on: You mentioned that RA does not revolve freely. At balance, a tiny touch with your little finger should cause the -either- axis to rotate easily. It looks like RA is sticking. Usually this is the cone bearing at the south end of RA which is over-tightened, especially ex-factory. The procedure to adjust RA  is outlined here.

Other stuff: EQ5s respond well to EKOS'  GPG for RA. Maybe I've misunderstood that guiding is working with the EKOS Internal Guider, but not with PHD2 (?). If so, then that narrows it down to a PHD2 setting, but my money would always be on the mount mechanics. There's only a certain amount software can do;)

FWIW, GPG is EKOS' implementation of predictive periodic error correction. It is not just for RA only mounts. The advantage you have is that you can take the default EKOS guider settings and compare the guiding with PHD2. It is a good way to isolate software issues. If it works OK with one... etc.

Cheers and HTH

[Kevin]

Ok, I will look into the cone bearing and nut on the end of the axis and adjust it to get better free play in RA to see if that improves the tracking.

I was able to to get guiding to work with the Ekos guider as-is, and I was able to guide using a guidescope with PHD2 out of the box. I had to uncheck the Fast Recenter option in PHD2 to get it to calibrate when using the off-axis guider, but it otherwise worked too. All of this to say that I think the Ekos guider and PHD2 with the guidescope are just a bit more "lenient" environments so the mechanical issues didn't outright prevent calibration from succeeding, but the same core issue affects both guiding tools.

The test I did with the Ekos guider on the night when I couldn't get PHD2 to calibrate worked, but I found the guiding results were generally not as good as PHD2, and it doesn't provide nearly as nice logging and diagnostics for troubleshooting and improvements. I can try it later with GPG enabled to see if it improves the guiding performance, but I also haven't gone nearly as far as I can with tweaking PHD2 to optimize it; I'll work more on that once I've resolved the mechanical aspects.

Thanks,

-Kevin

[Steve]

EKOS' guider logging is at the same level as PHD2. You can use phdlogviewer on the EKOS guider output if you like plus you have detailed diagnostics for both the internal guider and indi-eqmod.

JTOL: it may be easier to sort out the mount using indi with the internal guider before adding any external apps. Few are afforded the choice!

Cheers and clear skies

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5757cf5c-13e3-4724-8e34-3f3037136f58n%40googlegroups.com.

[Kevin]

Steve,

Thanks for the hint, I have now located the full guide logs from the internal guider - they were squirreled away underneath a hidden folder but the INDI documentation page on the guide module has a small note at the bottom pointing out the path. I had previously tried manually saving out the logs through the GUI and didn't get anything useful, so it's good to know the internal guider does produce PHD2 Log Viewer compatible log files.

Looking at those logs, I see the same long east "tail" in my guiding error scatter plot and if I exclude a few large excursions that are likely external effects, the overall guide performance is in the same ballpark as PHD2's with fast recenter turned off. This again leans towards the remaining issues being mechanical as I'm getting similar overall behaviour from both guiders. As you say, I'll have my choice of guide tools once I get the mechanics figured out, so I'll play with both and use whichever works better for me.

Thanks for the help!

-Kevin