Ok I misunerstood your point, you ment the desktop menu. This permit to lower the icon size which has an effect to kstars but make all desktop very very small.
I finally managed to get it right: in my /boot/config.txt I changed
hdmi_group=2 % DMT mode
hdmi_mode=82 % mode 1920x1080
hdmi_ignore_edid=0xa5000080 % ignore edid informations (if not set the screen goes to 1024x768)
hdmi_group=1 % CEA mode
hdmi_mode=16 % mode 1920x1080
#hdmi_ignore_edid=0xa5000080 % ignore edid informations (if not set the screen goes to 1024x768)
and all works fine without lowering the desktop icons.
This is all misterious to me but the problem is solved!
Thanks for your reply. However, I already tried all possible menu I think.
I don't see any "preference" menu. Could you be more specific.
When I lauch Ekos it's so big that it is very difficult to manage.
I precise I use the 3.5.0 version and the first menu I have "view" or "configuration" but no "preferences" nor "Appearance settings"...
I recently got a raspberry pi 4B 2Gb and decided to install raspbian OS ans kstars on it.
I managed to install folowing the indilib.org steps:
wget -O - www.astroberry.io/repo/key | sudo apt-key add -
sudo su -c "echo 'deb www.astroberry.io/repo/ buster main' > /etc/apt/sources.list.d/astroberry.list"
sudo apt update
sudo apt install indi-full kstars-bleeding gsc
it all went very well, but when lauching kstars on the 1920x1080 screen, at first the banner is very big and pixelized, and then it shows the sky also for much too big and pixelised.
Moover, it connot be reduced using zooming options.
Kstars returns on the command line is clean.
Do you have an idea of what the problem is?
Thanks a lot for helping.
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....