Looking at your log files, I saw two communication errors. In the first file,
[2019-10-30T10:23:21.998 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":d1\", 4 bytes written " [2019-10-30T10:23:22.021 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=8\", 9 bytes read " [2019-10-30T10:23:22.023 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":d2\", 4 bytes written " [2019-10-30T10:23:22.032 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=3B0980\", 8 bytes read " [2019-10-30T10:23:22.032 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "Error: Invalid range for RA Steps (AUXENCRASteps). Valid range is from 0 to 1.67772e+07. Requested value is 4.29497e+09 "
[2019-10-30T11:26:33.698 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j2\", 4 bytes written " [2019-10-30T11:26:33.711 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 9 bytes read " [2019-10-30T11:26:33.714 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetDEEncoder() = -759 " [2019-10-30T11:26:33.715 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=7163292 DE=-759 " [2019-10-30T11:26:33.722 GMT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "Error: Invalid range for DE Steps (DEStepsCurrent). Valid range is from 0 to 1.67772e+07. Requested value is 4.29497e+09 "
You say that the mount has worked for months before, maybe you could check your serial/USB cable.
Don't use backlash, I made that for a home made mount hardware, I will disable it. The calibration process takes care of that.
Select the ASI120 in the menu to use its ST4 port.
And try again using the default settings. That should work, I use the same setup
Anyway your last log file was almost empty.
I think you did not select your ASI120MM as guiding interface, but EQMod Mount. If you use a ST4 cable between your ASI and the mount, guiding commands should be sent to the ASI camera, so select your camera as guiding interface in Ekos. I don't have it under the hand so can't precisely say how, but this is set in your Ekos profile before starting.
I looked at the log and considered a guide pulse (line 38858) 1000ms@0,5x):
- it starts at 22:20:50:556, and the actual track speed modification occurs at 22:20:50:656. There is a 47ms delay between the two first log messages, 0ms between all the others, but the last, with a 53ms delay which may be due to the real serial comm occuring here.
- the end of the pulse occurs at 22:20:51:715 (line 38897) after the end of a mount probe started at 22:20:51:372, The actual speed modification occurs at 22:20:51:832.
I have thought serial comm could be the problem but in the first part, a ':f1' serial command gets its response in the same millisecond, but the same command in the second part took 50ms. I believe the timestamps in log messages are added by the indi framework and thus we see when they have been processed, not when they have been queued. Furthermore the indi-eqmod driver uses the timer callback mechanism of the indi framework too, that explains why they may be delayed by the normal mount probe processing. I think we have to look at the eventloop of the indi framework as the timer callbacks are managed with select timeouts. Anyway a first idea would be to delay the ReadscopeStatus callback while pulse guiding.
Now none of this happens when you use ST4 guiding, you could do that with your ASI120MM and your AZ-EQ5.
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.
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.
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.