Problems setting home position and strange behaviour using EQMod - Forums

Topic starter

Aug 7, 2024

Hi all,

maybe there is someone out there who can help me with a strange problem I have with EQMod.

I use 3 permanent setups. On two of them all is working fine. But on the third setup, I got some weird behaviour using EQMod. It all started several days ago. I tried to reset the home position of the scope. After I clicked the small icon with the two arrows I expected the display to show 90/0 for RA and DEC. But insted, the display changed to some weird values. DEC shows 88:xx.xx. The values of RA I don't have at hand at the moment. Whatever I do, I am not able to properly reset these values to the (what I think) correct ones. When I click on park after the reset, the scope is now moving about 20° east and parks there.

While trying to figure out whats going on, I used NINA for imaging during some nights. I moved the mount so that the scope is pointing to the north star and set this as park position in NINAs mount tab. This works, but if I click on park in EQMod, it parks 20° off. This is to be expected, because NINA parks to a specific RA/DEC position which is different than what is set in EQMod after my failed position reset.

If I start my sequence in NINA, the mount moves to the position it thinks the subject is. Then plate solving takes a lot of time. But is still able to find the position I'm pointing at. The RA error field shows a value of about 20°, which seems to be the same value, the park position is off when using EQMods park button. NINA tries to sync the mount coordinates without success. This usually happens only if I am too far off (which I am obviously). But NINA is clever enough to correct for the error in its own calculations and after plate solving the first one or two frames, everything works fine at least for the current photography session.

I don't know, why EQMod does not reset to the default values that my other two setups use. I tried several times to reset the position, but I always get the same result. With my current targets, this may not be a big issue. But my view to the sky is limited and I may get into trouble, when the scope is pointing 20° in the wrong direction and I end up taking images of trees or houses. Then plate solving might not work and it would take hours to start the sequence if I can't watch it. So I need to solve this issue.

Does someone have an idea what's going on in this case?

Thanks in advance

CS
Christian

Helpful

Darius Mihai

Aug 7, 2024

I've had similar issues but also many others with EQMod. Some of them were because I was trying to use the SynScan hand controller instead of a dedicated EQDir cable.
Some were because I was unable to get used to EQMod's complicated interface.
Anyway, I still had a few issues with EQMod even after I started using the PegasusAstro EQDir USB Stick, RJ45, for Skywatcher cable.

Long story short, after a few nights debugging out in the cold, I switched to Green Swamp Server and I never had any issues since then.
If you're using a skywatcher/synta mount, I highly recommend this instead of EQMod.

I'll probably try EQMod again if I ever get a mount that is not supported by GSS.

Helpful Supportive

Robert Habolin

Aug 8, 2024

Yeah I’ve had same issues with EQMod too. It parks to the right position, but it’s at 88 something rather than 90. And goes out of alignment for every night. I always have to reset sync for every session, even tho it’s polar alignment is spot on, gps is set correctly etc.

It also will go out of sync during a photo session when I’m locked on a target. It stays on target fine all night, the auto guider is locked and the images are all identical, but the planetarium ( maxim, cartes, stellarium, doesn’t matter which ) slowly goes out of sync. It thinks the mount is pointing slightly ahead of target, like the mount is reporting a slightly faster track rate than it should be.

Maybe that’s just inaccuracy in the mount ( eq6r pro is still only a mid range priced mount after all ) and maybe EQMod don’t send the corrections to the planetarium made by the guider. This itself isn’t a problem as long as I can stay on the target all night, if the target has a usable focus star. Cos if I need to find a nearby star to focus, then then it will be off center when I slew to it, as will the target when i slew back. Very annoying. I basically have to reset sync again, plate solve and center target again. Nina does this really well so not a problem really, just annoying that mount won’t report the right coordinates. I’ve never had EQMod and the mount work perfectly, so I’m really gonna try that GSS thing! Thanks for the tip.

Helpful

Christian Großmann

Topic starter

Aug 8, 2024

Hi Robert,

thanks for taking the time trying to help me. What makes me wonder is that I used this setup for years without issues. I don't use a hand controller and have the mount connected directly to the computer. I am sure, there is only a small thing I've done accidently, what causes these things to happen. But it seems to be the same issue you described in your first sentences.

I'm still hoping to find a solution to keep using EQMod. But in case I can't, I took a look at GSS. It seems to be really similar when it comes to functionality (why not?). The obvious difference is just the user interface. All the mounts I own are made by Skywatcher, so there should be no issue here. So thanks for the suggestion. Maybe I switch, but I'm still trying to keep EQMod.

I still hope someone can figure out what's going on.

CS
Christian

Robert Habolin

Aug 8, 2024

I wonder if this is a problem with the most recent update, I can’t recall having this specific problem before. I took a 4 year break from AP and just started back up again, so it might have been introduced in an update during my time off.

it would be easy to check with GSS tho, will try and report as soon as the skies clear.

Robert Habolin

Aug 22, 2024

So, I tried out GSS and havent looked back since. All the problems i had with EQMOD are gone. I don't know why, or how technically, but it just seems way more stable. And im now hitting the same home position every night.

A word of advice if you try it, the flip zone is set to 20 degrees by default, this was well enough to make my scope hit the tripod. No idea why it's that high. set it to 1 or 0 degrees if you dont wanna image past the meridian. I couldnt for the life of me figure out why the mount wouldnt do a flip… just kept going.

Ive been running it with NINA for a couple of weeks now and it just works. Finds the target every time, flips perfectly. Plate solve is a breeze.

Helpful Engaging Supportive

Darius Mihai

Aug 26, 2024

Robert Habolin:
So, I tried out GSS and havent looked back since.

I'm glad it works for you too.
Thanks for pointing out the default 20 degrees. I'll keep this in mind and change the setting asap.
Although I didn't run into such issues yet, I did see the scope go very close to the tripod a few times. I guess I was just lucky and I just wrote it off as "meh, a glitch on my part".

Well written Respectful

Peter Nielsen

6 days ago

Hello, I just found this thread from last 2 year ago,

I am running two EQ6-R with EQMod for many years without such a problem. In one, howewer, I now face the same problem with a wrong Park position. Platesolving can handle it but it takes more time to find the correct postion at night. As the EQ6-R has no encoder, I am wondering why so many collegues have these kind of poblems and no one has a good explanation for this wrong behaviour and no solution in my case. I spend almost one day with KI to find a solution, but only got stupid information.

I tried everthing? to convince the mount that is has to accept from me the correct home position at start when power ist getting on. It does not show RA 0 and DEC +90 which I would accept as the correct home position.

If I slew to an arbitray position using the buttons in EQMOD, the mount stops on the Park command some distance from zero bith in RA and in DEC. If I correct these wrong postions in EQMod to my zero position, the RA and DEc values shown up are clearly different from the beginning.

EQMOD seems to have a secret position which I cannot set to zero by now.

Is there any help for me in 2026?

CS Peter form Northern Germany

Tony Gondola

Frequent contributor

Exemplary contributor

6 days ago

A simple solution would be to switch to Green Swamp Server.

Peter Nielsen

6 days ago

Hi Tony,

thank you for the reponse.

I just tried GSS but on the first look it also did not seem to solve my problem. The mount does not refind back its home position. This would indicate that the EQ6-R mount is the main problem.

Greetings Peter

Respectful

Tony Gondola

Frequent contributor

Exemplary contributor

6 days ago

If that is the case I would tend to agree.

Peter Nielsen

5 days ago

Hello friends,

Thanks again for your support, my problem ist solved

Yesterday I invested several more hours trying to find the cause of the incorrect park position OF my EQ6-R. My AI kept producing supposedly clear new insights about what could be wrong. Wasted time. 👎

After a rather frustrating detour into the Green Swamp Server (GSS) world, I experimented a lot again.

The breakthrough came when I moved the axes back into the park position separately. That worked without any issues. But moving both axes together (as in real operation) systematically failed. Then I deliberately observed that the red LED on the EQ6‑R control board always blinked at the end of the park run: conclusion — critical power supply!

I have a stabilized 12 V power supply that should deliver 20 A and never drop below 12 V, and I’ve been using it for years. The EQ6‑R supposedly needs at least >11 V. For years this worked flawlessly.

But… now it seems that the smoothness of the worm gears has changed after years of use, and under full load with both axes moving, the power supply becomes critical, causing the movement to stop. The connection to EQMOD or NINA, however, strangely remained intact, so the issue wasn’t immediately obvious.

Now I connected a stronger power supply (>13 V) with short cables — and everything works perfectly again, as if nothing ever happened.

So the problem was not EQMOD and not NINA — not an electronic issue but an electrical one. Time to think about regreasing and possibly installing new bearings.

CS Peter

Well written Helpful Insightful Respectful Engaging

Tony Gondola

Frequent contributor

Exemplary contributor

5 days ago

Peter Nielsen · Jul 5, 2026, 09:04 AM
Hello friends,
Thanks again for your support, my problem ist solved
Yesterday I invested several more hours trying to find the cause of the incorrect park position OF my EQ6-R. My AI kept producing supposedly clear new insights about what could be wrong. Wasted time. 👎
After a rather frustrating detour into the Green Swamp Server (GSS) world, I experimented a lot again.
The breakthrough came when I moved the axes back into the park position separately. That worked without any issues. But moving both axes together (as in real operation) systematically failed. Then I deliberately observed that the red LED on the EQ6‑R control board always blinked at the end of the park run: conclusion — critical power supply!
I have a stabilized 12 V power supply that should deliver 20 A and never drop below 12 V, and I’ve been using it for years. The EQ6‑R supposedly needs at least >11 V. For years this worked flawlessly.
But… now it seems that the smoothness of the worm gears has changed after years of use, and under full load with both axes moving, the power supply becomes critical, causing the movement to stop. The connection to EQMOD or NINA, however, strangely remained intact, so the issue wasn’t immediately obvious.
Now I connected a stronger power supply (>13 V) with short cables — and everything works perfectly again, as if nothing ever happened.
So the problem was not EQMOD and not NINA — not an electronic issue but an electrical one. Time to think about regreasing and possibly installing new bearings.
CS Peter

That’s a good catch Peter. A lot of times people (myself included) don’t think about power so that was a good call.

Respectful Supportive