I finally wrote 2 script to sove this issue:
The fisrt scrip is lauchin kstar and them enter in a loop test to see if kstar is still alive. If it is not I send an email and I restart kastar using the second script.
The second script is based on xdotool that allows to automate mouse click relative to windows: with this one I relauche Ekos, reload the scheduled file (with is always named the same) and restart the scheduler.
Here are the 2 scripts:
1) First script
while true; do
ps h -C kstars>/dev/null
if test $status -eq 1
2) Second script
Kstars=`xwininfo -name "KStars" -int|grep "Window id"|cut -c22-30`
Astuce=`xwininfo -name "Astuce du jour — KStars" -int|grep "Window id"|cut -c22-30`
xdotool windowactivate $Astuce mousemove --window $Astuce 518 300 click 1 sleep 2
xdotool windowactivate $Kstars mousemove --window $Kstars 919 45 click 1 sleep 10
Ekos=`xwininfo -name "Ekos — KStars" -int|grep "Window id"|cut -c22-30`
xdotool windowactivate $Ekos mousemove --window $Ekos 1055 109 click 1 sleep 20
xdotool windowactivate $Ekos sleep 10 mousemove --window $Ekos 116 34 click 1 sleep 10
xdotool windowactivate $Ekos mousemove --window $Ekos 1476 105 click 1 sleep 10 type "/media/Astro/tst.esl"
Open=`xwininfo -name "Open Ekos Scheduler List" -int|grep "Window id"|cut -c22-30`
xdotool windowactivate $Open mousemove --window $Open 775 600 click 1 sleep 5
xdotool windowactivate $Ekos mousemove --window $Ekos 650 615 click 1 sleep 5
Even quicker a mode "SD-Card" only with no local or client saving or previewing would be nice to allow very short poses (planetary/Sun/lucky imaging).
I experience some kstars crash one night every too.
I would like to restart it automatically when it crashes.
For this I have a process that tests the kstar process and that is able to relaunch it when it deseapears.
I would like to know if there is a proper commend line to relauch kstars and activate the scheduler in order to restart from where it was before the crash.
Thanks for your help!!
I would like to test your new driver but I am not sure how to update it.
sudo apt-add-repository ppa:mutlaqja/indinightly
sudo apt-get update
sudo apt-get install indi-full
but I seem that /usr/bin/indi_synscan_telescope was not updated....
Am I the only one working on very short exposures to go under the turbulence limit??
With the current option, your are obliged to wait at least 3 seconds between 2 images because Ekos always want to transfer the images locally or remotely.
Would't it be nice to have a option not to transfer images?
Thanks for your thoughts
Hi, some update:
I received today a FTDI USB cable (see below the dmesg of the RPI)
I slew to an object and the tracking has now been running for 2 hours without any failure!!!
Thanks you very mush STASH for your suggestion!!!
[334932.601293] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[334932.728768] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[334932.728789] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[334932.728802] usb 1-1.2: Product: FT232R USB UART
[334932.728814] usb 1-1.2: Manufacturer: FTDI
[334932.728826] usb 1-1.2: SerialNumber: A50285BI
[334933.920049] usbcore: registered new interface driver ftdi_sio
[334933.920112] usbserial: USB Serial support registered for FTDI USB Serial Device
[334933.920262] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[334933.920369] usb 1-1.2: Detected FT232RL
[334933.923480] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[335001.991928] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[335002.095577] usb 1-1.3: New USB device found, idVendor=04a9, idProduct=3145
[335002.095597] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Did you try to adress the "synscan mount not responding, abort mount " problem I reported recently in this version?
I made a mistake, my cable seems to be a Prolific one: this is the kernel report
[702426.075714] usb 1-1.2: new full-speed USB device number 15 using dwc_otg
[702426.177946] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303
[702426.177960] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[702426.177967] usb 1-1.2: Product: USB 2.0 To COM Device
[702426.177974] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[702426.178794] pl2303 1-1.2:1.0: pl2303 converter detected
[702426.191602] usb 1-1.2: pl2303 converter now attached to ttyUSB1
Thanks for you advice STASH
I use a DB9 to USB cable with a CH340 chipset. The fact is that this is a very chip cable.
I will try to get a FTDI cable and test....
For the synscan/eqmod thing, the interest of the synscan is that you can still use the handset without unplugging and reseting, etc.
This is already exactly the type of connection I use from the handset to the RPI.
Today I tried "iwconfig wlan0 power off" but I had the same problem occuring ofter 1àmn of tracking....
I precise bit more: when the problem occurs, the tracking is aborted by the driver.
A least it would be good idea not to abort the tracking which goes perfectly well.
I just tried th 3.1.0 version on raspberry pi and it works fine. Thanks again