And additionally apparently its not best practice to be connected to mount via the ui and a web browser AND external control software such as stellarmate or theskyx.

So you can get into the Ui first via web browser setup the mount /or in my case force the dec to be a dec /other settings/ then close that connection/refresh browser, then connect to the mount via ekos/kstars.

So
Turn on mount without turning on stellarmate
setup mount via web browser as required
close browser
turn on stellarmate ensure antenna is best positioned minimise usb 3 interference
connect to mount and gear from ekos/kstars
avoid using the stellarmate os taskbar once connected

setup

You and me both it would seem.

I will try again tonight and take the mount outside, to see if that makes a difference. I also use the Brostrend dongle, but I will try different ways to connect to the mount to see if it makes a difference. I’ll try different connections, including a small repeater to see if that makes a difference.
How do you guys orient the external Antenna of the dongle, can’t remember reading anything about that?

I have the mount outside now. I connect exactly as instructed above and it connects fine. Stellarmate is connected to the mount via the Brostrend dongle and it shows a solid connection.
At first connection to the mount, the driver shows that tracking is off and the mount is unparked. That is correct the tracking is off, in motion control no movement is shown.
First goto to a star in the east works fine no serial read error. I perform a sync, still no issue at all. Goto a star in the west causes a meridian flip and works perfect, but I get serial read error: timeout error, every 30 seconds or so and it ends with a serial read error:read overflow.
Next I select park. Immediately I get a Mount parking failed, several timeout errors again and the mount only moves the RA axis to the home position.
Still in the main control window of the driver I now tell the dec drive to go to declination 90 degrees and it moves there without an issue.
To me it seems that something goes wrong with the park command, why is it not parking the dec drive ( a move command to 90 degrees dec works fine).
Also after it is parked with tracking turned off I push unpark and I get a message that the mount is already unparked, the dot in front of Park/unpark is white when I do that , but turns red immediately when I tell it to park, even though it does move the RA drive correctly.
It does not look like any of the timeout messages cause any wrong behavior though, except when parking.
Manual motion controls work fine as well but tend to throw a few timeout errors some seconds after the commands are executed.
Also interesting. In motion control the is an encoder tab. When I try to set 0 on both hour angel and declination, it also only moves the RA drive but not the dec drive and the dot in front of it turns red, so similar behavior as the Park command. So apparently I can command the dec drive to go to a certain declination but it does not react to a command to go to a certain encoder position, does that seem correct? I don't know if there is a difference in commands between those two, but I assume there are. It now just sits outside with tracking off and ever so often it throws a timeout error, about once or twice a minute for a few minutes now. When I turn tracking on it throws both timeout errors as well as read overflow.
So at least in my case, the dec drive does react to specific declination commands, but not to encoder commands. Via the mounts interface the dec encoder shows 100%

Hope this helps to troubleshoot what is happening.

Maybe it's about time AstroTrac test this driver directly themselves to see what's going on? There could be issues in the way the data is read after all that might lead to such timeouts. If you increase the polling time under Options from the default 1000ms to say 2000 or even 3000, does this make them less likely to occur. I think AstroTrac needs to be involved more at any rate to check these issues out.

Hi Jasem,

Thanks for your answer. I will try out changing response time to see if that makes a difference. I do have a feeling that something like that is causing the errors.
Trying to get Richard involved is going to take some effort, but I can at least ask him to help.
It’s too bad that this is taking so much effort from you guys. I am working with a guy on cloudy nights as well, who is trying to adjust the standard interface to incorporate at least some basic goto capability. He was able to create a very rough outline of it so far, which is starting to work.
For now I will test with the different response times to see if that makes a difference.
Any idea why the encoder commands on the dec axis is not working? As well as the parking command, could that also have something to do with response time?
Should I ask Richard to contact you guys directly? I believe you guys have talked before right?

Peter

Hi Jasem,

Well some good news at least. When I change the polling time in the settings to 3000ms the timeout errors seem to be gone. At 2000ms I still get one occasionally, so that definitely seems to have an effect on those.
The only thing that remains is the problem with the park position. It is not moving the dec drive and the same goes for encoder position changes. Works for RA, not for dec. Setting a different declination in the driver however does cause it to move!
You think you can figure out why that is?

That is interesting about the polling.

So basically indi is querying the mount every 3 secs? and that stops the timeout errors.

What does that signify? Is 3 seconds sufficient time to ensure that appropriate parameters from the mount a read in a timely fashion.

If that fixes it for good that is excellent.

Also I agree richard needs to take a more active role in the development as even TheSkyx Has the same serial timeout error. It maybe worthwhile communicating with him about appropriate polling rates for the mount for external software. Within the console a code outputs an answer about encoder status in ms <20ms . But indi is chatty so maybe every-time it polls it may involve more information provided/checked that may cause the errors.

Getting Richard is the difficult bit, he had some issues but I understand that is all recovered.

It would be useful to work with him with regards to this.

I’ll go ahead and send him a message about it. Let’s see what he says.

Are you having these issues with the home position as well, or is that just me?
In the mean time I have sent Richard a mail, explaining the situation and asked him for his involvement.

I don’t think I have got that problem with the unpark/park.

But when I first connect the mount in ekos.

I got to park and physically press unpark then park again to force it to park. For some reason the mount always begins unparked and tracking. This is default firmware behaviour since the mount is technically designed to be turned on and immediately start working. When using an external software one has to trigger a park event first for the program to “take over” I feel all our problems are related to something with the native design of the mounts firmware.

Also there is new firmware and UI files from Astrotrac on there website. I am yet to update them as well not sure of they make a difference. I am also assuming your astrotrac driver for indi is uptodate.

I have not used my mount due to weather and other commitments for some time , but will likely start again soon and I’ll probably update the firmware and UI first.

I hope Richard participates in this discussion.

For me the TheSkyX plugin was also unusable due to frequent timeout errors although I never tried with a high gain antenna etc.

I also suggest what sameer told me use the ethernet cable to connect to the pi inside whilst testing to eliminate some latency. Unfortunately there is no way to connect a wired connection to the mount. I feel if it could that would fix all our problems for good. Not sure how to go about doing that.

Strange that I am showing the park problem. I think Sameer was saying he sometimes sees that but not all the time. And I can remember from a while back that it was not doing that either, making things even stranger. I did do all the updates of the drivers, and also the firmware of the drives. I’ll try and switch the units and see what happens then. I have tested with StellarMate both wired and wireless, does not seem to make a difference.
I have also tried the unpark park routine, but the dot before the park option immediately turns red when I do that and only the RA drive will park.
I’ll setup and switch drives now and see what happens.
I too hope that Richard will join in on this. Before the mount came out he basically promised all this functionality, but he doesn’t seem to involved lately. I am sure he has his reasons.
Again I am working with Jerry on Cloudynights. He is trying to add to the current UI to give it goto functionality and the basics look pretty good so far.
wired connection is definitely something we could’ve used. I wonder if it could be added to the board, shouldn’t be too hard I would think.