Skywatcher AZ-EQ6 mount encoders and EQMOD in conflict - Forums

Topic starter

Mar 19, 2021

I really like the AZ-EQ6 mount from SkyWatcher, it provides good and stable tracking and guiding even with a heavy payload, but I have a serious problem with the pointing accuracy on the DEC axis that has been puzzling me for more than a year by now.

My mount has the following setup at the beginning of an imaging session:
- An accurate polar alignment and the telescope is pointing nicely at Polaris.
- The mount is connected to a PC through EQMOD and Stellarium (I don't use the HC). Imaging software is Sequence Generator Pro.
- Both Eqmod and Stellarium agree that the scope is pointing at Polaris.
- Lat / Lon and the local time has been checked probably 100 times and they are correct in both EQMOD and Stellarium.
- EQMOD starts off fresh with a clear memory and has no synced points.

After this initial setup, I select the coordinates of Betelgeuse in SGPro and command the telescope to slew to this target, at the moment located roughly south. What happens then is this:
- The telescope slews and lands quite close to Betelgeuse and I can manually verify the star in the finder scope.
- EQMOD reports that the RA coordinate is quite correctly at Betelgeuse, but the DEC coordinate is way off. At my location, Betelgeuse is located at 35 deg above the horizon, but EQMOD is reporting 57 deg!
- Stellarium agrees with EQMOD, indicating that the scope is at 57 deg, so far off that it is not possible to sync to this target unless I do a plate solve in SGPro to convince EQMOD to accept that the scope actually is pointing at Betelgeuse.
- After this slew command, I command EQMOD to park the telescope, and it then lands at a skewed position 22 degrees off polaris.

Even after having forced plate solving on a few targets in the area where I have planned the imaging, the final object centering often becomes a nightmare, with the scope indicator in Stellarium jumping back and fourth. It seems obvious that the internal mount encoders and EQMOD are not in agreement and sending mixed signals, but I have not been able to solve the dispute What I have tried is this:

- Repeat the slewing to Betelgeuse, but this time approaching from the East instead of West, but the same thing happens. The telescope is close to Betelgeuse, but EQMOD reports the scope to be 55.5 deg above the horizon (20.5 deg off). This should indicate a small cone error, but not enough to explain the 20+ degrees error in the DEC axis.
- Use Stellarium to slew to the target instead of SGPro. The telescope then points 22 degrees below the target instead of above it, but Stellarium and EQMOD both say that I am spot on Betelgeuse.
- Install newest EQMOD and other required software on a fresh PC, (tried several variants) but the exact thing happens every time.

I will be very grateful for any tip to solve this mystery…

Well Written Helpful Engaging

Rod Kennedy

Mar 19, 2021 · Edited: Mar 19, 2021

Do you actually mean you’re setting up the mount to point at Polaris (which is not the North celestial pole)? Check your mount is actually polar aligned to the pole because that easily explains what you’re seeing. You can check by observing if a star drifts in an eyepiece near the meridian and equator.

I have the same mount and EQMOD running. Rod

Helpful Insightful Concise Supportive

urban.astronomer

Topic starter

Mar 19, 2021 · Edited: Mar 19, 2021

No, sorry for being unclear and thank you, Rod for noticing this.

The mount is properly polar aligned with Polemaster to point at the NCP with high accuracy, and the telescope at f/10 shows Polaris close to the center of the frame and focus image.

Martin

Rod Kennedy

Mar 19, 2021 · Edited: Mar 19, 2021

I’m not familiar with polemaster but I’d check actual polar alignment with drift methods. If you have a guide camera on your setup then EQMOD can do this for you in a minute.

I’ll carefully reread your post to see what else it could be. Rod

What is your observing latitude?

David Moore

Mar 19, 2021

I have an AZ EQ6 mount with EQMOD. Cartes du Ciel and Sharpcap. Plate solving left any object I tried centering off centre. I did 3 things, one or other or all of these enabled me to centre any object I slewed to at dead centre. The first thing to try was taken from a Sharpcap 4 beta forum by a real expert. He said switch from J2000 to JNOW coordinate systems otherwise there is a pointing error.
The other thing I did was disable encoders using the hand control unit.
I also made sure that I had downloaded all the appropriate sky charts needed for plate solving as I was missing a few. Hope that helps.
I don't know which of these worked as I only tried them very recently.

Helpful

Elmiko

Mar 19, 2021

Make sure you have your location correct in Stellarium and Eqmod. Iknow it sounds silly, but you never know.

Wim van Berlo

Mar 20, 2021

I also have the az-eq6, with a good polar alignment according to ekos and phd guide assistant. I have turned off the encoders in eqmod, and pointing accuracy is good, but not spot on on the initial slew. After the first added point in the ekos pointing model, I have good pointing accuracy and the mount always returns to the set parking position. My advice: if you don't use the "freedom find" function and manually move the mount, turn off the encoders in eqmod. They are of little use. If you want to use them, reset or resync them on a regular basis.

good luck and cs,

Wim

Helpful

urban.astronomer

Topic starter

Mar 20, 2021

I have turned off the encoders in eqmod, and pointing accuracy is good, but not spot on on the initial slew.

Thanks for the advice, Wim

I know I can turn off the mount encoders through the handset, but is there another option to turn off encoders in the EQMOD software?

Martin

urban.astronomer

Topic starter

Mar 20, 2021

I have an AZ EQ6 mount with EQMOD. Cartes du Ciel and Sharpcap. Plate solving left any object I tried centering off centre. I did 3 things, one or other or all of these enabled me to centre any object I slewed to at dead centre. The first thing to try was taken from a Sharpcap 4 beta forum by a real expert. He said switch from J2000 to JNOW coordinate systems otherwise there is a pointing error.
The other thing I did was disable encoders using the hand control unit.
I also made sure that I had downloaded all the appropriate sky charts needed for plate solving as I was missing a few. Hope that helps.
I don't dknow which of these worked as I only tried them very recently.

Thanks, Moorefam

For some reason, my setup is using J2000. Will try to change that and see if it becomes clear tonight. Will also look into the encoders in the handset as well.

Martin

urban.astronomer

Topic starter

Mar 20, 2021

Rod Kennedy:
I’m not familiar with polemaster but I’d check actual polar alignment with drift methods. If you have a guide camera on your setup then EQMOD can do this for you in a minute.

I’ll carefully reread your post to see what else it could be. Rod

What is your observing latitude?

The Polemaster is an electronic polar scope that has an easy way to get a very precise polar alignment in a few software steps. Drift curves are typically completely flat afterwards if the telescope is well balanced.

My observing latitude is 59 deg 55' in Oslo, Norway.

Martin

Well Written Concise

Gernot Schreider

Mar 20, 2021

Just another idea where the problem could be: When you use multiple software to command the mount you need to go through POTHHUB as this module coordinates the multiple incoming commands. So this is why you need to use POTHHub as virtual mount when connecting your software to it. This is when you are using ASCOM drivers, what I am assuming here.
So in Stellarium you need to connect to POTH Hub and likewise in other software as well. Only the POTH Hub then is connected to the mount driver. The POTH Hub sits in between to channel and coordinate communication to/from the mount to the other software modules.

I suggest you check this setup to be correct

Cheers
Gernot

Helpful

Wim van Berlo

Mar 20, 2021

but is there another option to turn off encoders in the EQMOD software?

I don't know about EQMOD/ASCOM but in the INDI EQMOD driver this option exists. It is in the mount INDI control panel.

Wim

Laguy442

Mar 21, 2021

Gernot

I am probably confused but in looking at the 6.5 ASCOM release notes they had this comment:

"A new Telescope / Dome / Focuser hub called Device Hub has been added to the Platform.

This makes the POTH, Hub, Pipe and ASCOM Dome Hub components obsolete and we recommended that you migrate to the Device Hub because the obsolete hubs will be removed in a future Platform update."

https://ascom-standards.org/Help/Platform/html/3417e177-f705-497d-8127-fb30e8519d50.htm

Helpful

Gernot Schreider

Mar 21, 2021

Laguy442

you are right, I am using ASCOM 6.4 and they introduced this new device hub in version 6.5. I did intentionally not migrate to the latest ASCOM version due to known issues.
The main idea however remains the same. If you are using multiple clients to connect via the ASCOM driver to a device you need to configure the hub as the virtual device to connect to.

Cheers
Gernot

Helpful

urban.astronomer

Topic starter

Mar 21, 2021

Gernot Schreider:
Laguy442

you are right, I am using ASCOM 6.4 and they introduced this new device hub in version 6.5. I did intentionally not migrate to the latest ASCOM version due to known issues.
The main idea however remains the same. If you are using multiple clients to connect via the ASCOM driver to a device you need to configure the hub as the virtual device to connect to.

Cheers
Gernot

***
Thanks to Gernot, Laguy442, and you others in helping me out on this issue.

During the weekend, I tried both options. First, I found an old link on the web that pointed to the last released version of Poth (from 2012) which required ASCOM 6.1 to run. This worked, but Sequence Generator Pro did not accept to cooperate with this old version.

After a bit of reading, I found that Poth is now integrated in ASCOM, and I then upgraded to ASCOM 6.5 and found the Device Hub, which seems to be doing the same thing, plus a lot more. Stellarium and SGPro both connected easily with the Device hub, and they both seemed to agree where the scope was for once!

Again, I ordered my telescope to go from Park position to point at Betelgeuse in two different ways: First through Stellarium by clicking at Betelgeuse and then start a slew, and secondly through SGPro, after having manually dialed in the target coordinates for Betelgeuse and ordered a "center on target". SGPro and Stellarium (now connected through the Device hub) both sent the telescope roughly 22 degrees below the actual Betelguese. In previous trials, as described in a previous post, this behaviour did also happen before when using Stellarium, bot NOT in SGPro, when this software was connected directly to EQMOD.

The only thing I can make of this, is that there are several encoders at play, and they are obviously not in sync, and different software packages read from different encoders.

My next steps will be to disable the auxilliary encoders in the mount, and start looking for any setting in EQMOD that could point to how it obtains its coordinates from the mount and if there are any settings out of the ordinary.

I also noticed that the pointing error between the mount's actual position and the position reported by Stellarium / EQMOD / Device hub is growing linearly with the distance from Polaris. It is like EQMOD is amplifying the movement in the DEC axis by a factor of 1.25.

Martin

Helpful Respectful

urban.astronomer

Topic starter

Mar 26, 2021 · Edited: Mar 26, 2021

I also have the az-eq6, with a good polar alignment according to ekos and phd guide assistant. I have turned off the encoders in eqmod, and pointing accuracy is good, but not spot on on the initial slew. After the first added point in the ekos pointing model, I have good pointing accuracy and the mount always returns to the set parking position. My advice: if you don't use the "freedom find" function and manually move the mount, turn off the encoders in eqmod. They are of little use. If you want to use them, reset or resync them on a regular basis.

good luck and cs,

Wim

Finally, the problem is solved thanks to the solution suggested by @wimvb

The challenge was to find out how to turn off the auxilliary encoders in the mount. As I have not used the hand control ever before, I was hesitant to this solution, and eager to find a way through ASCOM / EQMOD.

After searching, I was able to find a line in the eqmod.ini file stating pretty clearly that encoders were activated:

ENABLE_HW_ENCODERS=1

But I could not locate any tick box in the GUI that suggested a change to this setting. The only step further was a ticker in the EQMOD setup (lower right) were advanced options can be enabled, as shown below.

With advanced features enabled, the EQMOD software itself revealed an augmented area called "Development Testing Area" as shown below. When connected to the eqmod simulator, I still could not see any option for disabling encoders. However, when it was connected to the actual mount, suddenly an extra drop down menu appeared in the development area (unfortunately I don't have a screen shot) and bingo! There it was, a setting to disable encoders. The lesson is that actual settings for your specific mount will dynamically appear in EQMOD when available.

With encoders turned off, the mount works like a dream. Slewing almost spot on straight from park mode, even without any calibration stars. Centre on target in SGPro can be done in two iterations, landing only 2-3 pixels off target.

Thanks again,
Martin

Helpful Engaging

Stefan

Mar 26, 2021

Thanks for sharing the solution.