iOptron HAE43-EC Won't Calibrate: RA and DEC Guide Rates Differ

[KJRitch]

First time post. About 1 year experience with imaging and guiding with AVX Mount (another story)

Here is the link to the logs for this problem. These is the only ones I have that have the Guiding Assistant.

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

PHD2 version 2.6.13

Equipment list:

iOptron HAE43-EC mount (Strain wave design on RA and DEC axes, RA axes has an  encoder the DEC axes does not. Purchased used, second owner, 1 week ago, mount is 2 years old). Replacing AVX Mount

Celestron C8 SCT

Celstron OAG with ASI174mm mini guide camera (1442mm FL)

Starizona Focal 7x focal reducer, 1442mm FL

Bortle 4 area, almost full moon near zenith

Using minipc with NINA 3.1 HF2. I use the Three Point Polar Align (TPPA) to polar align. I usually can get to below 1 arc second.

Guide camera exposure is set to 4 seconds.

OTA with image train and other accessories is about 19.5lbs. Mount has a 43lb payload.

I have to set up and tear down every session so I have to polar align, PHD2 calibrate every time.

My workflow consists of:

Set up tripod and level.

Attach mount, find Polaris and the sight along the saddle and center Polaris.

Install OTA, image train etc. I have a rough measurement of the OTA center of gravity and  marked the dovetail. I center that mark in the middle of the mount saddle so the DEC is roughly balanced.

Power up, connect all devices in NINA and take a test image. Test plate solving

Open PHD2 and select Calibration Assistant. Use the Slew command to get to the DEC 0 area. I forget which side.

Calibration fails because the RA and DEC guide rates differ. PHD2 expects 7.5 a-s/sec for RA and Dec. RA is 9.155 a-s/sec and DEC is 7.412 a-s/sec  Note: this may. not be what is in the attached logs but the data always shows the RA guide rate is higher.

I ran a Guiding Assistant and took a screen shot of the backlash graph and the red dots on the downward slope are next to the white dots and follow the slope so there is very little back lash. The DEC is a strain wave design, not worm and ring gear.

Here is the link to the logs. This is the only ones I have that have the Guiding Assistant.

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

Before I decided to reach out to this help forum I deleted all my PHD2 profiles and rebuilt new ones. The first one I had selected in the Profile Wizard the encoder option. The new profiles I haven't check the encoder option.

I've built two new profiles, one with DEC = Resist Switch and the other DEC = Hysteresis (suggestion by seller). The RA on both is Hysteresis.

Despite having the most up to date mount firmware, I decided to install a fresh copy in case of possible corruption. I ran an encoder calibration. I've set the guide speed to 0.50x in the mount driver and it matches the new PHD profile.

Due to weather I have not tested these changes. Hopefully this weekend.

I've read the troubleshooting area of the PHD2 manual regarding Questionable RA and DEC rates. It states the common reason is excessive backlash but I have no way to adjust it being a strain wave design and the backlash graph seems good. I get a warning stating the RA rate is 128% of the DEC rate. The Dec rate is what PHD2 expects.

Can you give me a clue what My RA rate is almost 30% higher make recommendations?

When I test my new profiles I will make sure I take screenshots and save the PHD2 log files. Anything else I should provide?

Should I run calibration data on East and West sides with Guiding Assistant?

Should I install the PHD2 version 2.6.13 dev7 tor the next test.

I've attached a couple of screenshots but not necessarily accompanies the log files.

Thank you.

KJR

[Jens Scheidtmann]

Dear KJR,

according to this thread: https://groups.google.com/g/open-phd-guiding/c/OVuft3bLMns/m/nFy0X-dXAwAJ PHD2 is able to handle different guide speeds through calibration. The warning can be ignored, if this difference is expected.

But generally the recommendation is to set the same guide speed in the mount's driver for both axes to something like 0.9 sidereal. Please check the settings in the driver. And if it's still not working as expected, I would contact iOptron. 

Checking the mount's documentation for operation with the hand controller, I cannot see any hint that different guide speeds for RA and DEC are default for this mount. This would be highly unusual, too. Did the previous owner set that? 

If you flashed the driver, I would expect that these were also factory reset. That's at least the behavior for my SkyWatcher mount.

For the interpreting the rest, let's have a look at what the experts say.

HTH, Jens

--
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 visit https://groups.google.com/d/msgid/open-phd-guiding/d0dbc991-7424-4509-a229-8d4f8256811fn%40googlegroups.com.

[KJRitch]

Thank you. I have checked the iOptron Commander and handset and both axes are current set at 0.50x for the next round of testing. My PHD profile is set at 0.50x. There may have been a mismatch, I don't know, but changing the guide rates I may have missed something.

I've noticed various youTube videos on running calibrations and Guiding Assistant and notice there calibrated showed the guide rate of the RA different from the DEC yet they didn't get any warnings. Is there a window where PHD2 doesn't care. My warning stated 28%. When does PHD2 not warn about RA/DEC guide mismatch. 

Maybe a factor is getting a good calibration is the moon is almost full and the sky seems washed out. I had to change exposure settings to get plate solving to work. 

The seller used to have an 10" RC OTA on this mount and says he didn't have calibration issues.

The first night I set up with this mount, I used NINA TPPA, ran it twice. PHD2 calibrated without warnings, finished and went to "Guiding" 

 The second, third and fourth night the warning about RA being 128% of the DEC guide rate. The first night I was very pleased because my AVX never was able to calibrate despite trying to tune the worm gear backlash.

I wonder if it's better to guide at BIN2. 

KJR

[Bruce Waddington]

Let's start with things we know to help clear the air a bit:

1. The mount firmware is reporting identical guide speeds on both axes, 0.75x sidereal, so there's no need to speculate about that.

2.  If the setup is working correctly, the spherical geometry of the sky tells us the RA guide rate, in units of movement on the guide chip (pixels/sec) should never exceed the Dec guide rate.  As the scope points closer to the pole, the measured RA guide rate will decrease relative to Dec; but it can't be larger than the Dec guide rate.  The measured guide rates in your logs violate this rule which is why you are getting complaints from the Calibration Assistant.  Of course, if the measured RA is too large and the measured Dec rate is too small, the difference will be amplified.  PHD2 uses a ratio calculation for this, and the alert is generated if the ratio is 20% larger than expected.

3.  You are running your guide camera in 16-bit mode - that's great - but you have the saturation level set at 255 which only makes sense for an 8-bit camera.  This is forcing PHD2 to ignore the best guide stars available and use guide stars of poor quality.  You need to change your SaturationADU setting or upgrade to the 2.6.13dev7 release and it will fix it for you.

4.  The Guiding Assistant consistently warns that you have a large polar alignment error, over 10 arc-min.  If you look at the graph, there is a lot of drift in both RA and Dec (RA in red):

The large RA drift is quite surprising.  Even more surprising is the somewhat "periodic" oscillation in Dec, keeping in mind that the Dec motor wasn't even running here. The usual reason for this is that some part of the guide assembly has rotated since the calibration was done - either by explicitly rotating the OAG or having that assembly move around on its own.  The RA drift could be caused by an RA drive system that is tracking faster than the sidereal rate - quite unlikely - or flexure in the payload that's riding on the mount.  Also, movement of the primary mirror in an SCT can also create these effects.

You said you are doing polar alignment using the Nina TTPA procedure.  That's ok but its accuracy can be degraded by various things such as pointing position in the sky, plate solve errors, or flexure of the payload.  The Guiding Assistant and all your guiding sessions indicate a large amount of Dec drift and an imputed polar alignment error of over 10 arc-min.  I think you need to spend some focused time just trying to isolate these effects rather than trying to image.  Start by using the PHD2 drift alignment tool and get polar alignment that way.  Make sure that the mount and tripod can't move at all as the scope is slewed around.  That means it can't be sitting on a soft surface or be subject to any sort of movement.  Problems like that can make a good polar alignment in one part of the sky become a bad one after the scope is slewed.  Then your goal should be to get repeatable usable calibrations.  As you suggested, you should try this on both sides of the pier, that might help identify the source of the flexure if that's what is causing the drift. You need to use the Calibration Assistant and let it slew every time, even if you think you're already in the same position as the last one.  That forcibly removes backlash.  Fix your  SaturationADU setting and for the purposes of the testing, try to use 1-second exposures for the calibrations.  That will reduce the elapsed time of the calibration.  Make sure all the clutches are tight and that the payload is well-balanced in both RA and Dec - not just "roughly balanced".  Be sure the cabling is well-routed and can't affect the smooth movement of the scope on either axis. Use the Guiding Assistant to look at the drift rates - I think you will have a tough time unless you can reduce them below what we see here.

Good luck,

Bruce

[KJRitch]

Thank you.

I'm using the ASI drivers and not the ASI's ASCOM drivers. I have two ASI cameras. In NINA I can select my main camera, ASI071MC Pro, which is using the ZWO native driver. I finally figured out how to use the ASCOM driver for the guide camera and the ZWO driver for the main camera without PHD2 selecting the main camera. The ASi174mm is a 12 bit camera. When using the PHD2 Profile Wizard and I choose ZWO ASi Camera and the camera is detected PHD2 will choose 8 bit. If I choose ASI Camera Ascom it gives me a choice between 8 bit and 16 bit. Which do I choose for a 12 bit camera? Should I use the ASCOM driver vs the ZWO driver if 8 bit my only choice? When I choose 16 bit the Saturation by Max ADU Value is 65535. When I choose 8 bit the value is 255. If I choose 16 bit the camera being only 12 bit will use the full value of 2 to the value of 12 = 4095 or does it go to 65535.

I notice the SNR showing in the PHD2 window o the bottom border is over 300. I know increasing the exposure rate will increase it but when I was using the AVX and experimenting with exposures I never saw anything higher than 50-60.  Do I just adjust the gain or do I have to change the Saturation by Max ADU Value or a combination of the two?

 One reason I purchased this mount, iOptron HAE43-EC was for the RA encoder. I could use longer exposures to allow my OAG guide camera to obtain more stars. So its OK to calibrate at 1 sec and then change it for imaging to 3 or 4 seconds?

Is flexure movement of my equipment such as vibrations? I'm retired and live in a motorhome. I'm currently at a state park in Arizona and next to I-10 and a major RR line where container trains can be active on certain days and nights of the week. The I-10 is always busy with semi trucks. I measure the line of sight distance from my campsite where I image and I-10 with the adjacent train track is only 2000ft away. The campground is built upon alluvial material from the volcanic mountain peak, the main feature of this park, near Tucson, AZ. Could that be causing the waves in the Guiding Assistant? The mount is on an iOptron Literoc tripod and it's on the asphalt, not as heavy as the AVX tripod and the legs are only 1.75" vs 2" for the AVX. There always is a light breeze here, under 5mph. We are moving tomorrow to another state park but here isn't a train track or interstate next to it. I can't remember if there was a lot of traffic. Trucks always.

I have in addition to NINA TPPA is iPolar and optical/electronic device that can plate solve and calculate were the NCP is and how far off you are. Since the mount doesn't have a polar scope I usually sight along the saddle base plate and get Polaris centered and just above the saddle base plate. TPPA usually complains I'm about 8 degrees or slightly more and I end up doing two routines. The second doesn't give me a warning. I can usually get down to less than 1 arc-second. The first night the starting error is worse because I have to adjust the Alt most of the time. Sometimes it takes a long time to polar align with TPPA. I've only used Polar once and I was pretty happy with the experience. I was able to polar align in less than 10 minutes. Accuracy I don't know. I'm also thinking of getting Sharpcap. 

I've never down a drift align. I'll read up on that.

I guess even strain wave mounts have some backlash. They are marketing as not having but they have more PE that is why I purchased the HAE43-EC with the RA encoder, to have reduced PE. Should I enable Backlash Compensation in the DEC Algorithm? Running Guide Assistance with Measure Backlash can then make the adjustments?

Thank you again for your time.

Kelvin

[Bruce Waddington]

Nearly all guide cameras - including ZWO - will scale 10 or 12-bit data to 16-bit values if they are operating in 16-bit mode.  Your camera is doing that, the peak data values for your stars are at or near 65K.  You can know that by using the Star Profile tool and pointing at a bright star.  Your SNR values are fine, that's irrelevant.  You should set the camera gain at the value recommended by the manufacturer for minimum noise and leave it alone.  Your choice of exposure time in PHD2 has to strike a balance between finding usable stars, suppressing the effects of seeing, and sending guide commands often enough to keep the mount on-track.  I'm suggesting 1-sec exposures for calibration to shorten the total time it takes to do the calibration.  What you use for imaging is up to you. Flexure is the slight mechanical "flex" of material under gravitational load but in this context I'm talking about any sort of sag or unwanted movement in the payload riding on the mount.  I think you need to come to grips with the level of precision we're talking about for guiding.  On your system, any unwanted movement of the guide camera sensor by 14 microns will produce a 2 arc-sec guiding excursion and you will be unhappy with that.  The average human hair is about 50 microns thick.  If you can feel the ground moving or vibrating, you will have problems. There's no reason to be talking about backlash here, it has nothing to do with your problems.  I suspect your procedures for set-up are flawed and you're having problems retaining polar alignment or aren't achieving it in the first place.  After you've made mechanical adjustments in altitude and azimuth, those adjustment points must be tightened correctly.  Otherwise, they will shift as the mount is slewed around.  I was trying to get you to use a repeatable process for doing calibration - the same way, every time.  That's why I suggested you use the 'slew' button each time.  As I said, you have to concentrate on getting a usable calibration, and that shouldn't be a one-in-ten-tries sort of thing.

Good luck,

Bruce

[KJRitch]

Thank you for your advice.

I'm going to use the ZWO Ascom driver for my next session. It allows you to choose 8bit or 16 bit, vs the ZWO ASI Camera driver. I tested this and the Max saturation is now showing 65535 and not 255. If the PHD2 Camera configuration shows the Max Saturation as 255 but the camera is scaling to 16 bit, does that cause a rate guiding problem when using PHD2 Version 2.6.13 or do you think is more polar alignment error. I have to set up and tear down every session.

I use Calibration Assistant for slewing to the optimum location.

I'm going to work on the polar alignment. I'm wondering if after polar alignment I hav not tightened the ALT/AZ knobs and pins enough to prevent so slight movement. Someone suggested using SharpCap to display the polar alignment. I need to research that option. I suppose I could slew via Calibration Assistant, then slew back to home and run another polar alignment to check if something moved.

I have upgraded to PHD2 2.6.13(dev7).

My new profile shows Max Saturation at 65535.

I think the unity gain is about 179 on the ASI174mm mini. I have my gain set at 60. I think the range is 0 - 400 on this camera.

I will make sure I obtain screen shots and save the PHDlogs

I'll post the results of calibration and the logs after the next session, hopefully Saturday night.

Thanks

Kelvin

[Bruce Waddington]

The saturation level has nothing to do with calibration.  I think your polar alignment is wrong - or moving around - and I'm concerned that either the guide camera or the entire OAG assembly is able to rotate by small amounts.  We don't need screen shots, in fact those just clutter up the forum messages.  We just need the log files.

Bruce

[KJRitch]

I'm using the Celestron OAG with ASI174mm mini. The telescope side adapter which is secured by three thumb screws. The focal reducer screws into the OAG telescope adapter. The focal reducer body then is inserted into a Baader SCT Click Lock which is screwed into the back of the SCT and secured with grub screws so it can't rotate (or isn't supposed to rotate).

The body of the OAG contains the prism assembly and the helical focuser and the guide camera tube. It uses two thumb screws to secure the camera. The camera tube has some slop in it so adjust one screw pushes the guide camera one way and the other screw, 90° off, pushes the camera in anther direction. I use a 1.25" par focal ring around the guide camera body held by grub screws. Once I obtain rough focus and tighten the grub screws place the camera in the tube and hold down on the par focal ring then evenly tighten the tube thumb screws. This seems to have helped preventing some "crescent" stars in the guide window.

I usually check the tightness of the thumb screws when setting up. I can't think of a place in the drive train where something could rotate.

In all the problems you helped users with have you seen a Celestron OAG have rotating or flexing issues? I'll check the Baader Click Lock to make sure the mounting rings is secure.

I have another question. I've read if you calibrate successfully but then rotate more than a couple of degrees, say to frame an object then the rotation voids the calibration.

I usually image several nights of the same target. I use NINA's Framing assistant to load a previous light frame, a reference frame, then plate solve it. Then I use this data to Slew, Center and Rotate. If I need to rotate and slack off the thumbscrews to rotate the OAG from the OAG body back to the camera. This keeps the guide camera sensor align with the camera sensor and hopefully gets with 1° of the reference frame. 

Should I change my workflow? Run a test on the rotation of my main camera, then slew to intended target and set up the rotation on the target. Then use Calibration Assistant to slew to the calibration coordinates. Finish Calibration and the slew back to target then start guiding?

Thank you.

Kelvin

[Brian Valente]

Kelvin

How are you rotating, manually or using an automated rotator?

My reaction to your workflow is that you should just recalibrate after you are finished with your framing. 

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/95ec2c9f-476b-4330-b872-e06ade3487een%40googlegroups.com.

--

Brian 

Brian Valente

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

[Bruce Waddington]

Oh jeez.  Well, this has turned into a goat rodeo.  If you rotate the guiding assembly or the guide camera, you invalidate the PHD2 calibration.  If the calibration is invalid, everything in PHD2 is invalid from that point on.  Calculations for polar alignment error, periodic error, overall guiding performance, all of it.  If we can't know how X/Y movements of stars on the camera sensor relate to RA and Dec, we're dead in the water.  So you can safely ignore most of the previous graphs, pictures, and discussion about guiding results, they are pretty much moot.  However you decide to do your framing, you will need to re-calibrate PHD2 once rotation is finished.  Since you don't have a motorized rotator connected to PHD2, you can investigate a plug-in that NINA has for a "manual rotator".

Good luck,

Bruce

[KJRitch]

First Question: If I plan to rotate should I slew to target, center then rotate. Then select PHD2 Calibration Assistant to slew to calibration area, finish calibration, then slew and center back to target.  I'm trying to save some time.

I was able to set up last night. Here are the logs. There are several calibration attempts. Only the first one didn't give me any warnings.

There is a gap in calibrations start at Log Section 9. Prior to that there was a guiding session form the calibration area and the mount hit the Meridian. It is set to stop tracking. I shut down guiding and used Calibration Assistant to slew to the West but a power cord came out and stop. I ended up have to reboot the minipc. There are two Guiding Assistant, the first was interrupted by the the mount stopping track at the Meridian. One thing I notice was the polar alignment looked good on the East but not as good on the West.

I used iPolar to polar align, then used NINA TPPA to check and adjust for the final polar alignment. TPPA didn't agree with iPolar.

The guiding at the end is on the west side. Seeing was getting worse as the moon was very bright.

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

Thank you for your time and advice.

Kelvin

[Brian Valente]

Kelvin

Do you have a manual or automatic rotator? If you have an automatic one, you can connect it in PHD and have this handled for you

If it's manual, the most important thing to remember is you must recalibrate after rotating. this means you will recalibrate for each target, so If you want to save time you can just calibrate at the target. It can get dicey if your target is near the pole, but generally it should be fine. If you find there's an issue with your calibration for a specific target, then yes you can use the calibration assistant and calibrate that way. That's the most reliable. If you really want to save time, consider purchasing an automatic rotator, it will be handled for you when you connect it in PHD.

But again, manual rotation = calibrate after each new target (assuming you rotate for each one). 

Brian

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/5445b399-4018-420e-bf55-4af891de6fc0n%40googlegroups.com.

[David McCallie]

Another possibility that might save time (for manual rotation) is to use the NINA planner and note the necessary rotation in degrees (for your planned target.) I have found this to be pretty reliable. First slew to the calibration location and use NINA/platesolve to manually reach the desired rotation angle.  Then calibrate.  Then slew to target. Rotation should be ready to go, if the planner was accurate.

I haven’t had a chance to try this, but it might save a slew or two.

—david

To view this discussion visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i5E623v4KBYR1QO6TyaVeHfkH3e_oxj77hZv0zyV-gLeg%40mail.gmail.com.

[KJRitch]

Thank you about the tip in NINA. Yes, I manually rotated on my SCT. I'll have to read about the NINA planner,

I usually only image one target per session, since I set up and tear down and I usually tear down by 1 AM at the latest. I'm not at the point I feel comfortable leaving my equipment out without me being awake.

KJR