Acapulco Rolf is friends with Andrew

For what its worth I'm still hacking around this issue (python resize script) for my 60Da see

I got headaches from the geometries caused by my specific workflow, just 1 example:
- I need to catch 30 rapid dusk/dawn flats with constant light so I use local download (Raspberry Pi 3) and CR2
- these later converted to FITs for Siril processing.
- python check all options 5202/5184 x 3405/3465 and outputs only 5184 x 3405

I'm surprised the 600D indeed all canons don't suffer from same issue since as I understand the root bug lies in libraw.


Thanks Jasem, and happy 2019 to you.
Delighted you found the issue without full logs, I've been trying to tweak overall speed so turned logs down.

I've picked up a couple more apparent minor bugs for Canon driver and still can't get SS2K to park but will send/start new post.


I'm using Kstars 3.1.0 Welcome to KStars 3.1.0 Build: 2018-12-30T07:03:57Z30T07:03:57Z on Ubuntu 18.04 with Lin_guider 4.2.0 on remote Raspberry Pi using Mate 18.04 (indi-full 1.7.6~201812ˆ€, indi-sx 1.13~2019010 )

I noticed recently that guiding would instant crash Kstars for example when clicking 'guide' button in EKOS to start or restart guiding. I tried initialising Lin_guider by ssh commands and over VNC with similar crashes.

If I start Lin_guider (calibrate and guide start) before running Kstars all works well but as soon as I stop/restart a guide session from Ekos I get a crash.

I've been reduced logging on these runs so nothing appears in Kstars logs, just abrupt end . I will try some verbose full logging later. At this stage just reporting the change in behaviour

Anyone else having this issue?

1 Example of Head and tail of crash Kstar log:-

[2019-01-03T22:59:56.380 CET INFO ][ org.kde.kstars] - Welcome to KStars 3.1.0
[2019-01-03T22:59:56.381 CET INFO ][ org.kde.kstars] - Build: 2018-12-30T07:03:57Z
[2019-01-03T22:59:56.381 CET INFO ][ org.kde.kstars] - OS: "ubuntu"
[2019-01-03T22:59:56.382 CET INFO ][ org.kde.kstars] - API: "x86_64-little_endian-lp64"
[2019-01-03T22:59:56.382 CET INFO ][ org.kde.kstars] - Arch: "x86_64"
[2019-01-03T22:59:56.382 CET INFO ][ org.kde.kstars] - Kernel Type: "linux"
[2019-01-03T22:59:56.383 CET INFO ][ org.kde.kstars] - Kernel Version: "4.15.0-43-generic"
[2019-01-03T22:59:56.383 CET INFO ][ org.kde.kstars] - Qt Version: 5.9.5
10 pix at sub-arc second guide - all OK, crasjed immediately after clicked 'guide' in EKOS to restart a run.
[2019-01-03T23:21:03.545 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] CMD <:GR#> "
[2019-01-03T23:21:03.594 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] RES <05:42:35> "
[2019-01-03T23:21:03.594 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] VAL [5.70972] "
[2019-01-03T23:21:03.596 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] CMD <:GD#> "
[2019-01-03T23:21:03.627 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] RES <-02�15:07> "
[2019-01-03T23:21:03.628 CET DEBG ][ org.kde.kstars.indi] - SkySensor2000PC : "[SCOPE] VAL [-2.25194] "


Hi Jasem,

I was eager to test the new ss2k park function last week but clear sky abound for once!

Anyhow I did a quick first test at the end of last night session confirmed:-

1. park function appears in INDI Main control panel Parking: Park UnPark.
2. INDI Site Management appears to enable setting of Park Position as AltAz D:M:S
as test I input Alt 0:30:0, 260:0:0 and Set, then in Park Options I hit Write Data (I assumed this would be saved but this morning no data appeared after reconnect despite INFO screen showed 'Saved Park Status/Position)
It seems I forgot to do Options : Save Config since I re-did this morning and the Park position was saved.

3. at end of session I went to remote site so I could observe the Park function in action (always wary of runaway mount)
I saw there were several ways to operate Park function. from Kstars right click Skysensor then Park/UnPark or from INDI Main control or from EKOS Park or EKOS Mount Control Park. This is great I assume they all use same 'code'.

1st try : from INDI Main - after clicking (vnc from phone to PC) there was beep from handset (good) and audible change in motors but no movement towards park position.

2nd try : from EKOS Park.
handset beep and INDI panel shows ERROR error slewing to 260:0:0 0:30:0 Object below horizon
Tried setting Alt 2:30:0, 260:0:0 same result
By feeling the motors I can tell they are still tracking RA.

I Unparked and slewed to random spot and tried all again with same result.
It seems like same result when I tried my pyindi code i.e. there was comms with mount but the final 'goto' doesn't work.

The functionality feels great, if we can get it to work on ss2k it would be awesome.

Unfortunately I'd set logging off while I was imaging, sorry I know you need this, so I'll have to send logs from new session maybe tonight. Anything particular you want me to try?


Thanks Jasem, I'll try to test this weekend.

But as T-Studio points out there is a wider need (other drivers) and requirement for personalisation (Alt-Az park point). For example you've given functionality to select a point on Kstar sky map (Ra Dec), but we need a fixed know land (Alt-Az) point, i.e. Input box "Park position (Alt-Az)" = x,y


Yes Jasem, that is the root issue.
For me park is required to get to a fixed point to take flats and let the scope 'sleep', for other there are different reasons.


HI Jasem,

I'm still working on getting pyindi basics working to simulate a 'parking' in mounts without the function.

As you know with python serial I got simulated park working with my skysensor using lx200 codes.

I couldn't get pyindi to work. After many debug cycles I reduced the issue back to telescope_on_coord_set switch explained below.

I attach the debug code (.py as .txt) its focussed on the 2 commands:-

1. telescope_on_coord_set[0].s = PyIndi.ISS_OFF # or ISS_ON
2. indiclient.sendNewSwitch(telescope_on_coord_set)

I attach the output using simulator. You can see the switch cycle ON - OFF but I see no effect in the loop showing RA,DEC. I expect when track ISS_ON to show repeated same RA,Dec values. I get same result in both simulator and real skysensor both local and server.

Could you have a quick look to see what I'm missing?


Sorry for delayed reply it was clear here so priority went to photon collection!

Firstly Jasem,
The SS2K serial commands I used to 'park' (since park doesn't exist only 'Land') are in the code extract I gave in #28610 which works but needs more tests, the LX200 codes are published online (i.e. .

Here is key points extracted from my code:-
command = "#:AL#" (set mode to Land)
command = "#:MA#" (slew to AltAz coordinates previously given )
command = "#:Q#" (halt the scope) followed by with "#:hN#" (like sleep)

Even if I get this code working/hardened it requires dedicated serial connection using pypi serial, so its not a good INDI solution, hence I'm trying to implement using pyindi. I'm having some ON_COORD-SET Switch issues that I'll send in separate post for checking.

For T-studio,

I'll keep working on a PyINDI solution with my skysensor and simulator setup, if I get it working and hardened we can work on how to integrate it but at present it requires these things:-
a. A know 'park' position to be input in AltAz coords (dms)
b. The precise geodetic EarthLocation (gps, with elevation, locatime is converted to UTC by code)
c. mount setup in accordance with b (obviously will fail if mount thinks its somewhere else, as you say it's dangerous)


Jasem saw my issue without Park last week, so please feel free to share just be aware I'm not a real coder so somebody had better check that code!
Also I realised it would probably be easier to integrate using PyIndi code and I have found below step that act as a parking function in three steps:
1. find RaDec of your park (altaz position) - uses astropy module.
2. slew to that using PyIndi
3. switch off tracking using this
telescope_on_coord_set = device_telescope.getSwitch("ON_COORD_SET")
telescope_on_coord_set[0].s = PyIndi.ISS_OFF # TRACK
telescope_on_coord_set[1].s = PyIndi.ISS_OFF # SLEW
telescope_on_coord_set[2].s = PyIndi.ISS_OFF # SYNC
I make complete code and tests and send update then see what Jasem and experts think.


For the record I did resolve this using a python code and serial interface module (pyserial - see code extract below). So now I'm able to effectively 'park' the scope at a 'land' location (fixed AltAz LCD screen) so the scope stops tracking and then sleeps enabling me to take flats etc.

The options I tried:
a. Using the INDI module PyIndi - but couldn't find any commands to set land mode , sleep or park.
b. A hardware switch on the skysensor to turn it off - this still meant coding to get the scope into position

Let me know if you want more info.

Python 3.5 code extract

import serial
import time
#import string, re

def start_telescope(port):
#connect to the scope on a port #linux: /dev/ttyUSB0 (check with lsusb)
print("trying to connect to port:{} ".format(port))
serialobject = serial.Serial(port, 9600, timeout = 5)
print("port is connected")
#wakeup sleeping telescope
print("trying to wake scope")
print("-- scope not ready! --")
serialobject = "notready"
print("serial port open error - already open?")
serialobject = "serialerror"

def get_telescope_position(serialobject):
#get RA and DEC
RA ='latin-1')
Dec ='latin-1')
pos = [RA, Dec]
print('telescope pos is RA:{}, DE:{}, pos{}'.format(RA,Dec,pos))
return (pos)

def set_alignment(serialobject, amode): #set to land, polar or altaz mode
serialobject.reset_input_buffer() #flushInput()
serialobject.reset_output_buffer() #flushOutput()
if(amode == "Land"):
command = "#:AL#"
elif(amode == "polar"):
command = "#:AP#"
elif(amode == "altaz"):
command = "#:AA#"
print(" alignmode not recognized...defaulting to altaz..")
command = "#:AA#"
print('alignment mode set to {}'.format(amode))
serialobject.reset_input_buffer() #flushInput()

def get_alignment(serialobject): # find the alignment mode
serialobject.reset_input_buffer() #flushInput()
serialobject.reset_output_buffer() #flushOutput()
command = chr(0x06)
result ='latin-1')
if (result == 'A'):
mode = "altaz"
elif (result == 'L'):
mode = "Land"
elif (result == 'P'):
mode = "polar"
mode = "unknown"
print('alignment mode is {}, {}'.format(result,mode))

def go_lcd(serialobject) :# only works if Land or AlAz True
alt= '#:Sa -0*50#' #:Sa sDD*MM#
az = '#:Sz 250*50#' #:Sz DDD*MM#
print('going to lcd at {}, {}'.format(alt,az))
serialobject.reset_input_buffer() #flushInput()
serialobject.reset_output_buffer() #flushOutput()
command = "#:MA#"

def halt_scope(serialobject):
serialobject.reset_input_buffer() #flushInput()
serialobject.reset_output_buffer() #flushOutput()
command = "#:Q#"
print('scope halted')

so = start_telescope('/dev/ttyUSB1')
for x in range(3):


Thanks Jasem,

I deleted the Skysensor configs under /home/mate/.indi and restarted with same result. I've copied extract of log below with my edit of actions.

I think this is triggered by me not tracking anything i.e. in day testing mode I don't complete guide calibration, obtain target, focus, guide and track.
And it seems resolved if I right-click in KSTARS - Skysensor then Connect or go to EKOS and hit Connect - see below tracking starts and all seems OK:

The only other thing I noticed and it appears an irrelevant and known item, is the log reports an warning:
WARNING 317.448158 sec : Could not process mount date and time: 2018-08-10T

I'll do a full night test tonight with normal workflow to see if the issue is resolved.

[AB added - output after setting new config for skysensor]

2018-08-10T09:05:56: Driver indi_lx200ss2000pc: read setSwitchVector SkySensor2000PC CONFIG_PROCESS Ok
2018-08-10T09:05:56: Client 0: queuing <setSwitchVector device='SkySensor2000PC' name='CONFIG_PROCESS'>
2018-08-10T09:05:56: Client 0: sending msg copy 1 nq 1:
<setSwitchVector device="SkySensor2000PC" name="CONFIG_PROCESS" state="Ok" timeout="0" timestamp="2018-08-10T09:05:56">
<oneSwitch name="CONFIG_LOAD">
<oneSwitch name="CONFIG_SAVE">
<oneSwitch name="CONFIG_DEFAULT">

2018-08-10T09:06:16: Client 0: read newSwitchVector SkySensor2000PC ON_COORD_SET
2018-08-10T09:06:16: Driver indi_lx200ss2000pc: queuing responsible for <newSwitchVector device='SkySensor2000PC' name='ON_COORD_SET'>
2018-08-10T09:06:16: Client 0: read newNumberVector SkySensor2000PC EQUATORIAL_EOD_COORD
2018-08-10T09:06:16: Driver indi_lx200ss2000pc: queuing responsible for <newNumberVector device='SkySensor2000PC' name='EQUATORIAL_EOD_COORD'>
2018-08-10T09:06:16: Driver indi_lx200ss2000pc: sending msg copy 1 nq 2:
<newSwitchVector device="SkySensor2000PC" name="ON_COORD_SET">
<oneSwitch name="SLEW">

2018-08-10T09:06:16: Driver indi_lx200ss2000pc: sending msg copy 1 nq 1:
<newNumberVector device="SkySensor2000PC" name="EQUATORIAL_EOD_COORD">
<oneNumber name="RA">
<oneNumber name="DEC">

2018-08-10T09:06:16: Driver indi_lx200ss2000pc: indi_lx200ss2000pc dispatch error: Property ON_COORD_SET is not defined in SkySensor2000PC.
2018-08-10T09:06:16: Driver indi_lx200ss2000pc: indi_lx200ss2000pc dispatch error: Property EQUATORIAL_EOD_COORD is not defined in SkySensor2000PC.

[AB added - after EKOS Mount Control motion arrow click ]

2018-08-10T09:07:57: Driver indi_lx200ss2000pc: indi_lx200ss2000pc dispatch error: Property TELESCOPE_MOTION_WE is not defined in SkySensor2000PC.
2018-08-10T09:07:57: Client 0: read newSwitchVector SkySensor2000PC TELESCOPE_MOTION_WE
2018-08-10T09:07:57: Driver indi_lx200ss2000pc: queuing responsible for <newSwitchVector device='SkySensor2000PC' name='TELESCOPE_MOTION_WE'>
2018-08-10T09:07:57: Driver indi_lx200ss2000pc: sending msg copy 1 nq 1:
<newSwitchVector device="SkySensor2000PC" name="TELESCOPE_MOTION_WE">
<oneSwitch name="MOTION_WEST">
<oneSwitch name="MOTION_EAST">