The serial times out errors are a problem.

I found that using a high gain external wifi dongle on the stellarmate via one of its usb 2 ports is the best bet with regards to minimising the errors. The antenna has to be setup just so and I’ve posted about my setup before. I feel that there must be some interference with the aluminium body of the mount and the stellarmate despite Astrotrac saying there shouldn’t be. I briefly discussed with Colin who wrote the theskyx drivers and he noticed frequent wifi issues even and timeout issues even when using a windows laptop.

Once you get a run of serial timeout errors its more likely to keep happening in which case I suggest disconnecting mount from ekos/k stars and reconnecting it. Also whilst the mount is doing slews etc avoid lookout at the taskbar of the stellarmate. I noticed everytime I hovered and pressed over the taskbar for example to check the network connection strength etc a serial timeout error would be triggered. And if I didn’t stop doing it it kept happening and in my view it “corrupts” the session so disconnect and reconnect renews the setting. This is whilst using vnc to connect to it from my mac.

Now no one seems to know why that error happens for sure but this is what I have found. On its own the wifi broadcast from the mount seems robust it’s just a matter of the other device consistently picking it up or not.

When I spoke to Richard from astrotrac he stated that during testing the wifi connection were tested for days at a time to check data transmission and integrity and apparently was ok. But obviously the same error happens on both the skyx driver and also this indi driver.

Maybe you all might have an idea.

But short of it is if use high gain antenna as desribed above and dont play around in the stellarmate /os taskbar outside of ekos/kstars it seems not to have any errors.

My observations are consistent with your findings. The serial error is definitely linked to interference. Happened to me indoors while testing the driver. Less often outside. Unfortunately, I haven’t had much sky time with the mount in the last few months.

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.