RA Autoguiding Setting for 2.6.11 dev4 + iOptron HEM44EC

[Parag Batavia]

Hello,

I'm seeing some very odd periodic spikes in RA while guiding with 2.6.11 and a HEM44EC. This is a new occurrence and I'm trying to track down whether it's something external (cable, etc) or an internal mechanical issue.

I saw that 2.6.11 dev4 has updates to deal with encoders, so I'm going to try that tonight. 

The one thing I'm not sure on is how the RA encoder interacts with RA tracking. The HEM44EC manual does not that you can turn off RA encoder tracking to accept guide commands from guiding software. 

Is that the right thing to do? Or is it better to let the encoders track RA, with fewer expected RA corrections issued by PHD2? 

If I keep the encoders on, then I assume I should be using 2-5s exposures. If I turn them off, I assume I should be using much shorter exposures (<= 0.5s). Yes? 

As far as my RA tracking issue goes - this is a log file that shows the large spikes in RA that occur outside of dithering. Most of the time PHD2 is able to get back on track - but even when it does the sub is ruined. 

https://openphdguiding.org/logs/dl/PHD2_logs_6ZQd.zip

Section 14 shows a large example of this. Section 10 shows a couple of examples as well. 

I'm trying to understand whether it's possible there is some interaction between RA encoder corrections and PHD2 which is causing this wackiness. 

This includes calibration data as well, which seems reasonable to me, even if the axes aren't completely orthogonal. 

This is exacerbated by my guide cam not being 100% in focus - resulting in the occasional "noisy image" that I've seen others post about. That should get fixed tonight - but I don't know if that's contributing because the RA spikes did not correlate with the occasional bad frames (which are in the log as star mass errors). 

iOptron offered to RMA it to look at it - but I'd really like to find some way to confirm this is a mechanical issue before sending it back. 

Also, this is a new issue which occurred after I shipped the mount and my rig to a remote observatory. I had packaged the mount in its original enclosure and packaging, and I unlocked the DEC axis. 

Thanks very much for any suggestions or guidance. 

[bw_m...@earthlink.net]

Hi Parag.  I’ve started looking at this but it would help if I had more context.  What is your overall setup in terms of imaging and guide scopes?  I assume you’re not using an OAG, correct?  Are you sure you have the right settings for longitude, time, and time-zone?  I’m looking at a guide session that says you were pointing 6 degrees below the horizon which I can’t picture.  Don’t start tearing things apart here, I’m not convinced there’s anything wrong with the mount.  If you can provide some more info, I should be able to give you some ideas fairly soon.

 

Bruce

--
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/de15f069-baa4-43cf-ab08-994c974924adn%40googlegroups.com.

[Parag Batavia]

Hi Bruce,

Thank you very much for looking at this. 

It's entirely possible I've done something dumb. The mount was originally set up and tested in Pittsburgh, and then shipped to Utah Desert Remote Observatory. I did update the time, timezone, and Lat/Lon in iOptron Commander for the mount, and can confirm that has "stuck".

I'm not using an OAG - I've got a PrimaLuce 60mm guidescope with ASI120mm guide cam. My imaging scope is an ASI6200, with a filter wheel + NiteCrawler focuser. 

I'm thoroughly confused about how it could think I was pointing 6 deg below horizon. For most of the guide sessions, I was pointed at Orion. 

Happy to provide any other information that's needed. Thanks again.

Parag

You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/B8IbJPDxWz8/unsubscribe.
To unsubscribe from this group and all its topics, 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/003901d95929%2494c4d8c0%24be4e8a40%24%40earthlink.net.

[bw_m...@earthlink.net]

Well, you’ve got a mess in terms of the scope knowing where it’s pointing.  Starting with the calibration you did at 23:44, the scope thought it was pointing in the general area of RA = 22:15 and Dec = 45 degrees.  It stayed in that area until you ended the session.  That’s somewhere in the area of Cygnus, close to or below the horizon.  Obviously, you weren’t really pointing there but something caused your mount to get lost.  Did you do a ‘synch’ on the mount coordinates using bad data?  For a remote operation, this is a real problem.  So we can only look at the guiding sessions before 23:44 which are unfortunately chopped up into short sessions.  But as you said, those were apparently pointing in the region of Orion. The initial calibration looks ok but you didn’t do it anywhere near Dec = 0 – is there a reason for that?  The subsequent Guiding Assistant session shows a large drift in declination, equivalent to a polar alignment error of 28 arc-min.  This could be caused by a bad polar alignment or possibly because you have a loose guide scope or cables that are dragging.  The large RA guide star excursions started shortly after that.  These may not be coming from the mount at all but from cable routing problems or movement/sagging of the guide scope assembly.  Did you visit the remote site yourself and insure that a meticulous job of cable routing was done?  Most of these big RA excursions were correlated with large Dec excursions as well – the Dec error just wasn’t as large.  This is an important thing to focus on because the Dec motor was inactive at the time.  With an encoder-based system, things like this might happen with wind gusts – do you know if it was windy?  But again, these things can be explained equally well by simple problems like some part of the guiding assembly moving around on its own, cables tugging on the guide camera, mundane stuff like that.

 

I think you are probably a long way from demonstrating that the mount drive/encoder system has problems.  I think you need to spend some time isolating these problems without trying to image anything.  Set aside the image automation app for now and devise a series of tests that will show what the mount is doing on its own.  Start with another fresh calibration and do a long Guiding Assistant run (e.g. 15-min) just to watch how the mount tracks.  If you continue to get a large amount of Dec drift, track that down and eliminate it.  If the remote support crew botched the polar alignment, you should be able to work with them remotely.  Use the PHD2 drift alignment tool and just give the support people specific instructions on how to make adjustments.  Also be sure they have really tightened things down after you are satisfied with the results.  You should also have them re-tighten all the fittings on the guiding assembly and send you photos of how the cables have been run.  With a long GA run, you should be looking for the large excursions that you saw before.  If possible, do this first with the mount encoders disabled.  Do the tests on both sides of the meridian pointing near Dec  = 0 and within 15 degrees of the central meridian.  If you don’t see problems, enable the encoders and repeat the tests.  If you can replicate the problems with the GA, you will be much closer to knowing where the problem lies and then talk to iOptron. 

 

Good luck,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CALFZKiEQPHLSa%2BOEtGi38unLqb3Uc670cucoz7igMz0q9SDgDw%40mail.gmail.com.

[Parag Batavia]

Hi Bruce,

Thank you for the reply and spending so much time on this. I had already started last evening's tests before seeing the below - but we did fix a lot of what you mentioned, and things are much better. 

The below is more information than you need, but putting it here in case anyone else decides to jump in the deep end before really learning to swim. 

Specifically:

1) Re-did the polar alignment. It was originally done by the observatory folks using a PoleMaster - and my mount has an iPolar, so we used that this time. However, it's still not perfect - it got moved a bit when they were locking it down. So it's still in the 15-20 arc / min range. At home, I typically get 3-5 as/min with the iPolar, so we'll get there. 

2) Re-did the cables. I did not visit the observatory myself - but there's dozens of scopes here, most installed by the observatory, including Planewaves and much higher performance than mine. Regardless, they showed me the new wiring, and it's appropriately double looped, secured, etc. And everything is tightened down on the pier. 

3) Regarding the mount coordinates - my typical operation has been to NOT do a sky model with the mount, but rather to rely on NINA and plate solving to slew to the correct location. This has always worked well whether or not I sync the platesolved coordinates to the mount - and I'm pretty sure I didn't do that this time, but will start doing that regularly going forward. 

4) Re-focused the guide cam. This is still a problem. The combination of a PrimaLuce 60mm guidescope and ASI120mm should work fine - but we can't get great focus. GA still reports that I should work to improve focus. I will likely replace this with an Orion 50mm, as that's always worked well in the past. 

5) Re-did PHD2 calibration in the right location close to DEC 0 / RA 0. In my home setup, for some reason, nothing was ever very sensitive to where I did calibration, and so I'd normally do it at DEC 30+. Bad habit. 

6) It was not windy that night. So unsure why there was a movement in DEC as well.

I did manage to do two runs - one of 8 minutes, and another 25 minute run before I ran into an unrelated issue and had to stop. The 8 minute run got interrupted by the "noisy camera" issue I've seen others talk about. Basically the guide cam image started looking like broadcast TV static, and everything stopped working. Rebooting fixed the issue. I don't know if this is a USB cable thing, or a problem because the guide cam focus isn't great. Both the runs were good. 

The 25 minute run showed an RMS of 0.66 arc/sec total, which is what I'm used to getting on my home rig. This was at the same location I calibrated, near 0 DEC. 

In case you're curious or if you're able to see any other issues that I still may be missing, logs are here:

https://openphdguiding.org/logs/dl/PHD2_logs_bqA9.zip

So yeah - I don't think there's anything wrong with the mount. I do think I rushed into a bunch of stuff on the first night, expecting things to "just work" - and need to be more methodical. 

Looks like the remote observatory is going to have clouds the next few nights, so I might not be able to test more again until later. 

At that point, I'll do the specific tests you recommended below.

Thank you again for putting time into this, and providing such helpful advice. And for developing PHD2!

Parag

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/004801d95945%244f8a27d0%24ee9e7770%24%40earthlink.net.

[bw_m...@earthlink.net]

Hi Parag.  It’s good that your session went somewhat better but unless the techs did something you haven’t mentioned, I don’t see that anything really got fixed.  See comments below:

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Parag Batavia
Sent: Saturday, March 18, 2023 7:10 AM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding] RA Autoguiding Setting for 2.6.11 dev4 + iOptron HEM44EC

 

Hi Bruce,

 

Thank you for the reply and spending so much time on this. I had already started last evening's tests before seeing the below - but we did fix a lot of what you mentioned, and things are much better. 

 

The below is more information than you need, but putting it here in case anyone else decides to jump in the deep end before really learning to swim. 

 

Specifically:

 

1. Re-did the polar alignment. It was originally done by the observatory folks using a PoleMaster - and my mount has an iPolar, so we used that this time. However, it's still not perfect - it got moved a bit when they were locking it down. So it's still in the 15-20 arc / min range. At home, I typically get 3-5 as/min with the iPolar, so we'll get there. 

 

Using the Drift-Align tool will produce the best results without all this external equipment foolishness.  It isn’t hard.

 

2. Re-did the cables. I did not visit the observatory myself - but there's dozens of scopes here, most installed by the observatory, including Planewaves and much higher performance than mine. Regardless, they showed me the new wiring, and it's appropriately double looped, secured, etc. And everything is tightened down on the pier. 

 

Securing the cables is good but routing is equally important and that is specific to every unique setup.  You have to be sure that cables don’t “catch” on stationary surfaces as the mount moves to different locations.  Technicians often like to use cable ties or ribbed conduit to keep the cables from swinging around but those things usually have protrusions that can very briefly catch and release when the cable slides over a stationary surface.  Believe me, I speak from bitter experience.

 

3. Regarding the mount coordinates - my typical operation has been to NOT do a sky model with the mount, but rather to rely on NINA and plate solving to slew to the correct location. This has always worked well whether or not I sync the platesolved coordinates to the mount - and I'm pretty sure I didn't do that this time, but will start doing that regularly going forward. 

 

I’m not suggesting you change your procedures but you need to figure out how this got screwed up or at least watch it very carefully until you are confident it isn’t a problem.  This is one way people end up with pier collisions.

 

4. Re-focused the guide cam. This is still a problem. The combination of a PrimaLuce 60mm guidescope and ASI120mm should work fine - but we can't get great focus. GA still reports that I should work to improve focus. I will likely replace this with an Orion 50mm, as that's always worked well in the past. 

 

You should be using some kind of quantitative measure of star size to focus the camera – the PHD2 Star Profile tool, another app like SharpCap, or even a simple Bahtinov focus mask.

 

5) Re-did PHD2 calibration in the right location close to DEC 0 / RA 0. In my home setup, for some reason, nothing was ever very sensitive to where I did calibration, and so I'd normally do it at DEC 30+. Bad habit. 

 

5. It was not windy that night. So unsure why there was a movement in DEC as well.

 

The problem isn’t always sustained wind speeds but wind gusts.  Every setup and site is different but if you’re situated in a big roll-off roof structure, you may be more sensitive to wind gusts than what you’re accustomed to.

 

I did manage to do two runs - one of 8 minutes, and another 25 minute run before I ran into an unrelated issue and had to stop. The 8 minute run got interrupted by the "noisy camera" issue I've seen others talk about. Basically the guide cam image started looking like broadcast TV static, and everything stopped working. Rebooting fixed the issue. I don't know if this is a USB cable thing, or a problem because the guide cam focus isn't great. Both the runs were good. 

 

The 25 minute run showed an RMS of 0.66 arc/sec total, which is what I'm used to getting on my home rig. This was at the same location I calibrated, near 0 DEC. 

 

In case you're curious or if you're able to see any other issues that I still may be missing, logs are here:

 

https://openphdguiding.org/logs/dl/PHD2_logs_bqA9.zip

 

So yeah - I don't think there's anything wrong with the mount. I do think I rushed into a bunch of stuff on the first night, expecting things to "just work" - and need to be more methodical. 

 

Looks like the remote observatory is going to have clouds the next few nights, so I might not be able to test more again until later. 

 

At that point, I'll do the specific tests you recommended below.

 

Thank you again for putting time into this, and providing such helpful advice. And for developing PHD2!

 

The latest log showed one giant RA and Dec excursion at 21:10 – do you know what caused that?

 

If you continue to get good results near Dec = 0, you should then re-run tests in the area of the sky where you encountered problems.  If you see sudden big guiding excursions, you should have one of the support guys immediately look at cables or anything else that can jostle the guide camera.  Many of the big guide excursions that were causing trouble were equivalent to movement of the guide camera by less than 50 microns.  In other words, less than the thickness of a human hair.

 

Good luck,

Bruce

 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CALFZKiFyJG8e-%3Dm2wncaLUVg534tn8EWRdnuExWESSBX0Ncc5w%40mail.gmail.com.

[Parag Batavia]

Hi Bruce,

Agree with all of the below. I wasn't completely explicit on things. 

1) Agree on drift-alignment. Issue is trying to get the remote obs folks to do it. But yeah, it makes sense that the PHD2-native tool would provide the best results for tracking. Historically, when I've had good PA with the iPolar, I've had good tracking. Hopefully that holds up in this new location. 

2) As of right now, I don't have evidence that the new cable routing is a problem - but it's something I agree we need to keep an eye on. Because the observatory has 20+ active scopes, there's limitations on what can be done in person with lights on after astronomical dark. 

3) Yep. I agree. I don't know how it got screwed up to begin with - except I was doing a lot of things, all at once, trying to get everything running without being methodical. But I'm 100% going to plate solve and sync in the beginning now - and then keep an eye on mount coordinates.

4) We actually used PHD2's star profile tool for this - and the focus we had, which was not great, was close to the best we could get - it gets worse in either direction of focuser travel. I don't know why that is. I did reduce camera gain back down to about 60% which did seem to help. But, I've had a working / good focus configuration with an Orion 50mm + 120mm camera for a couple of years - and it's a cheap and easy replacement. So this may be one where I replace the issue instead of look for a root cause.

5) The giant excursion at 21:10 is what I was mentioning earlier - the guide image from the 120mm camera became pure noise. Looks very much like broadcast TV static. When that happened, it lost track, and things went south. What I'm reading online is that PHD2 is very sensitive to focus - and that marginally focused images can result in this type of noise pattern. If that's the case, then that's another reason to replace the guidecam. I thought briefly it could be USB3 bandwidth issues, but I wasn't capturing from my imager cam and nothing else is on the USB3 bus. I rebooted the computer, and picked back up at around 21:18, and that's when I had 25+ minutes of good guiding. 

6) Agree on checking it out if there are any future large displacements. I guess I never really appreciated cable sensitivity. My home rig is... less than elegant. Cables are tied to avoid binding, but some are just draped and hang almost to the floor (power, ethernet), and I've never had issues here. 

Thanks again. Definitely curious about your thoughts on #5. 

Parag

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001601d959e0%24e45ee170%24ad1ca450%24%40earthlink.net.

[bw_m...@earthlink.net]

Hi Parag – with regard to question 5:

 

The comment that PHD2 is very sensitive to focus is probably a misinterpretation of our often-reiterated best practices.  PHD2 doesn’t actually know whether the camera is well-focused, it is just looking in the camera image for things that look like stars and then computing where they are located on the chip.  All of the common forms of guiding are sensitive to the signal-to-noise ratio (SNR) of the distinguishable bright areas in the camera frame.  The positions are typically calculated using a centroid algorithm, and the accuracy of that calculation depends on SNR.  As the camera goes out of focus, the SNR values of the stars drop fairly sharply, so multi-star searches will find fewer usable guide stars and the centroid accuracy of the remaining stars is degraded.  At some point, there may not be any usable stars at all.  That isn’t PHD2 being particularly sensitive to focus, it’s just the mathematics of how star positions are calculated.   When we urge people to pay attention to focus, that’s really a best practice, not a software requirement or some foible of PHD2.

 

If you are getting corrupted guide camera frames, that can indeed create these apparent large guide star excursions.  For example, a timing problem with the camera download can create a frame that is offset from its correct registration with only noise along one edge of the frame.  One thing to consider is that not all camera drivers that were written for USB 2.0  will work correctly on a USB 3.x port.  USB 3 and 2 are backward-compatible from a hardware point of view but not necessarily from the point of view of the camera driver.  Beyond simple bandwidth questions, you also have to be sure the camera is getting the full power it needs to operate correctly – marginal power can also create these weird intermittent problems.  To diagnose camera frame problems, you should enable the Diagnostic Image Logging features in PHD2 using the controls on the ‘Global’ tab of Advanced Settings.  There are a variety of trigger conditions there such as “any lost star” or two different kinds of error thresholds.   When the condition occurs, PHD2 will save 5 successive camera frames centered in time around the trigger event.  This makes it quite easy to see exactly what data was returned from the guide camera.  You can read the details in the User Guide.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CALFZKiFDYT5f91AB2h8sn3Lhm6hzVTJE9CY-pdZYc56AmZ%2B0cA%40mail.gmail.com.

[Parag Batavia]

Hi Bruce,

This makes sense. I understand that at some point, the SNR just isn't good enough and you can't accurately find the centroid(s). In general, I've found PHD2 to be way more robust to blurry stars than I would have expected. I think my guidecam focus just isn't great.

I'll activate the diagnostic image logging. I knew it was there - but didn't look at the documentation and assumed naively that it dumped every image. 

Back to guiding... Had a good run last night. There are some things that I have noticed though, which may be issues:

1) I'm back to wondering whether there is some slip in the RA axis. The mount will have trouble driving my payload at max speed. While this doesn't sound surprising, iOptron insists that the harmonic drive has more than enough torque to drive my payload at max speed from any configuration. At lower speeds, it seems to drive fine. 

2) Related to that.. On startup, I sync'd the mount to a platesolve'd location (the difference between original location and platsolved location wasn't that great). I then did a slew from home to Orion. On my CEM40, that would typically get me to within a minute of RA, and then another slew would get me perfectly on target. This time, the initial slew was off by 40 minutes in RA, and almost spot-on in DEC. Two additional slews were needed to get on target. 

3) Completely separately - I noticed that, using iPolar, that the polar alignment target was moving a bit based on telescope orientation. This implies there is some minor flex / motion in the system, somewhere. 

Practically - none of this affected guiding last night. I had no odd RA excursions. I did a 25 minute guide-only run pointed at Orion, with a total RMS of 0.65". Then I did a second image gathering run of just under an hour, with dithering every 6 minutes or so, with a total RMS of 0.71" 

What changed from previous:

1) Re-did the polar alignment

2) Sync'd mount position to a platesolved location

3) Reduced gain on guide cam to 0.5 (didn't see any noisy images either)

Logs at

https://openphdguiding.org/logs/dl/PHD2_logs_FD6f.zip

So it's getting there. Practically, if I can maintain this total RMS level consistently, then I'm good. My imaging is 1.62" per pixel, so half-pixel guide accuracy is good enough for what I'm doing.

Thanks,

Parag

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/004101d95a0f%2470f4a1f0%2452dde5d0%24%40earthlink.net.

[Brian Valente]

Hi Parag

>>>This time, the initial slew was off by 40 minutes in RA, and almost spot-on in DEC.

Is that RA offset consistent across all your gotos? I wonder if it's a setting issue with your mount and computer not agreeing on date/time/timezone/location

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CALFZKiG_Sbqa5%2BfcYZFn-HLHDFagErR0y2CfV5xX7FKKgU%3DqQw%40mail.gmail.com.

--

Brian 

Brian Valente

astro portfolio https://www.brianvalentephotography.com/astrophotography/

portfolio brianvalentephotography.com 

astrobin https://www.astrobin.com/users/bvalente/

[Parag Batavia]

Hi Brian,

I haven't done enough yet to check - but that will very much be my next step and test. 

I'm pretty certain time / location / TZ are consistent. The iOptron mount has a "SYNC from PC" option, which grabs time / date information from the PC. And I know the PC is correct for the remote installation location.

Thanks,

Parag

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i6rzuqOuDTWwLA6jGH2f%3DpXfh4vvOheF%2BUfjaaXhf379A%40mail.gmail.com.

[Brian Valente]

Sync from PC is often helpful, but sometimes timezone or DST can mess things up.

Definitely worth a look, but again, it would really only be if all targets were off by the same amount in RA

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CALFZKiGDZdo6xUCa7kbjea2uJVuBUpxzmjxFODvjUR4xZ2P9Tw%40mail.gmail.com.

[Parag Batavia]

Yep - agree. And testing multiple go-to's is absolutely something I need to do. The mount does show the correct time offset from GMT, and the DST box is checked. So I think that's good. If I see a continuous issue I'm going to lean towards needing some RA belt tightening at this point. 

Parag

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i4VVOqqrOi50TcvQW82L6QL%2BthSR3SO0HG0Dgri6A2E2w%40mail.gmail.com.