trouble with eqmod mount disconnecting

Ok, I understand what you mean now, Concerning the indi-eqmod crash, did you use alignment ? A sequence of capture/solve/sync on the same target as ekos does may cause an issue in some circumstances. Besides I've seen in a preceding post that you leave your mount parked and powered a day long: be warned that parking the mount does not stop motor powering, there is no (direct) way to disable the driver ICs but using the power switch.

No I didn't use alignment. The scope being in the basement, I only ticked "Track" in Ekos for my tests.

About motor ICs remaining powered, I'm not sure I understand what your warning applies to. You mean that it could be damaging in the long term, or that it still consumes power even when parked? I plan to have a power controller in the observatory to shut down supply in some situations, but with the current code I don't think a park/unpark operation in Ekos or INDI could be linked to that control.

-Eric

I was hopeful, but last night I had it fail 3 times while guiding. I should still have logs, so will send them. Have any of the other logs been helpful @knro? Anything else I can do?

This was with kstars-bleeding-2.9.5-2.4.x86_64

sent.

I hope this resolves my own issues. I have been struggling with mount disconnection for a while. It would say 'tty read failure...'
I believed there were hardware issues for longest time because it would be relatively stable indoors, but became very unreliable outdoors in the cold. So I was suspecting something temperature dependant.

Hi,
I'm not sure that performing retries after a disconnection is a good idea. I did not look at the driver update but having a clear disconnection in Indi is a good thing (thanks Jasem). Now I believe that the reconnection should be manual. The logs before the disconnection are not very helpful, from the driver point of view this happens in the kernel space (tty_read, tty_write). The reason may be either between the computer and the serial adapter (usb/bluetootth), between the adapter and the mount motor controllers, or in the motor controllers if there is a power glitch and they reboot. I believe that in the first case the kernel will reassign a device at the reconnection (from ttyUSB0 to ttyUSB1 for instance), in the second case there will be either read/write faliures or bad characters, and in the latter case, there will only be write failures or maybe a read timeout while the controllers are rebooting. The problem in the latter case if you automatically reconnect, is that the driver will think that the mount is uninitialized, and it will consider that it points to the Celestial Pole. The next goto may be risky in that case...
So it may be a good idea to make automatic reconnection optional, so you may disable it if you are in an automated sequence for instance. Also people reporting disconnections may try to investigate by looking the status after the disconnection: do motor controllers have rebooted? where is the serial adapter ? maybe try to speak directly with the mount using picocom to test the connectivity.
Lastly I'm thinking that power issues may eventually come from the mount capacitors, if you think that your power connection is correct. But I'm not an expert here.
Jean-Luc.

Ok, let's see if that resolves the issue. I think that the controllers would have time to reboot/reset during the retries. I wonder how will the driver behave after a motor controller reset and if this could be useful to make it recover from that situation.

In my case, tracking stops when this happens, but the boards must not be resetting as I can manually reconnect and everything works fine. I just have to slew the mount back to the object because of how far it may have drifted depending on how long it was disconnected before I catch it. I am hoping the retry will just reconnect right away and go on about its business. The issues others people have may not be the same as mine though.