Update, I have purged both park options data and configuration. It appears to park with the cursor pointing at polaris now but when I click on a target and issue a go to it always slews east - no matter whether the target object is in the east of west. You can see the cursor moving and it always heads in the same direction no matter what the target. I have also noticed that if I look at an objects coordinates in kstars and then look at the object position in the eqmod mount control, the coordinates do not match.

A log files from earlier today is attached.

Also to note, when attached to a windows laptop running ascom, this issue does not occur and the mount slews correctly.

I am guessing nobody has any thoughts suggestions based on the logs?

Hello!
I’m having the exact same issues, with the exact same equipment, the only difference is that I’m using Astroberry on my RPi4.
I’ll try to gather logs of the system to post them here.
Thank you!

I fixed my system by simulating the GPS on INDI, and this time I used the correct coordinates. My GPS Dongle doesn't really pick up signal from my balcony... (great location for testing and learning how to use my system, horrible for GPS signal)
I was incorrectly putting positive degrees when my location is Eastwards. To avoid negative numbers, I did 360-East coordinates.
Also, avoid mixing Longitude with Latitude.
Once that was fixed, it worked fine.

I hope this helps!

Hi
I have the same problem, it is driving me crazy, using the N / S / E / W controls it moves in the correct directions with all the applications, but from CdC, Kstars, etc. the same thing happens to me,
It parks well, I point to one star, I tell him to move to one that is visually up in the sky and moves as if it were down, the same, if I point to one that is down it moves up, all the time like this.
Reinstall astroberry in RBPi4, reconfigure everything and it stays the same
I use Astroberry, EQMod, EQ5 and AstroEQ, I live in the south hemispere, in Argentina
Best regards

Glad you got it working. I checked and rechecked coordinates several times ensuring they were correct. I also ensured that latitude and longitude were not mixed up (as a sailor I am very aware of that!).

To be honest, I have got fed up with trying to make it work and have found dealing with a Linux based system not the easiest - for example trying to run off an SSD which I got working eventually, but only after finding that the drive enclosure I had bought had a chipset that didnt work with the PI and spending several days trawling forums to work out how to do it. Also tried to install a USB wireless adapter - not joy after following various forums to find out how to get it to work.

Have had no feedback after posting my logs and required information other that from you.

Therefore, I have decided to give up on Stellarmate and INDI and go back to working with a windows based ASCOM sytem where at least installing a basic peripheral does not take several days! Am going to sell the Raspberry Pi with Stellarmate and put it down to experience...

A shame that you have fallen out with indi / linux, from my point of view it has its problems but linux being open source, which does not happen in windows, it has an active community that is more proactive to give a hand and correct problems, including this INDI community.
I hope you find and I find what the problem is so you continue with INDI / Astroberry

Sorry for mi bad English
Best Regards

Mount slew issue like this are almost 99% related to the following:
1. Time or time zone is incorrect. This is not the case with your logs. Time and time zone both check out. The logs show all of this happening about 6 PM your time, I presume this is correct?
2. Location: You were not supposed to manually change the longitude. The log shows this: EQMod Mount : "[INFO] Observer location updated: Latitude 51:28:59.2 (51.4831) Longitude -2:39:00.0 (-2.65) "
This is incorrect, the longitude should have been left at 357:21:01 which is the correct value since INDI counts eastwards.

Now the logs do not show detailed EQMod communication going on. The INDI and Mount checkboxes need all to be checked. Usually, you'd want to power on EQMod at home position (Looking north with counter-weight down). Then from there, slew to a nearby star about 20 degrees or MORE away (Polaris should NOT be used). Then use "Capture and Solve" until the star is in the center of the frame. Usually subsequent GOTOs are then pretty accurate.

The final reason could be due to some incompatibility with EQStarProEQ5 , but the page says they're indeed compatible with INDI already.

Knro,
Thank you for your reply. I have retried with location updated by kstars and conforming to my location i.e. longitude now correct. Still the same problem.

I statrt with scope in home position and the scope location when I slew seems completely wrong. I can even see the cursor of the scope moving in the wrong way. If I click on an object say andromeda galaxy and then tell it to go to, the cursor does not go to there but off in a completyely wrong direction. Logs attached.

DrWho,
The description of your problem matches exactly mine.
In my case it was the longitude that was wrong. The hemisphere obviously also needs to be the correct, and lastly the hour.
I suggest you have it gathering the hour from the system to troubleshoot, but ideally you would get coordinates and time from the GPS.
The key aspect is that if the time or longitude are wrong the calculated Zenith is pointing on the wrong direction.

One more critical aspect.
My DEC always starts with a full rotation Eastwards, regardless where the target is. I don’t know why, but it does once at the begging of a session IF I didn’t park at the end of the previous session. If I park it, it never does that full rotation. If I don’t park it, it always starts with a full rotation (once I start slewing)

Give it a try. Apart from these little tricks, I super pleased with the portability of the RPi.

What if you don't have a GPS?

No GPS shouldn’t be a big deal.
I got a super-cheap one on amazon... I think it was less than 10€...
Eitherway, if you set the system hour manually you won’t be too far off. Just double check the hour needed by the system (local, UTC, daylight savings, or similar).