Andrew replied to the topic 'Parking scope without Park capability (LX200 & Skysensor)' in the forum. 22 hours 13 minutes ago

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
indiclient.sendNewSwitch(telescope_on_coord_set)
I make complete code and tests and send update then see what Jasem and experts think.

Read More...

Andrew replied to the topic 'Parking scope without Park capability (LX200 & Skysensor)' in the forum. yesterday

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.
Andrew

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))
try:
serialobject = serial.Serial(port, 9600, timeout = 5)
if(serialobject.isOpen()):
print("port is connected")
#wakeup sleeping telescope
serialobject.write("#:hW#".encode())
print("trying to wake scope")
else:
print("-- scope not ready! --")
serialobject = "notready"
except:
print("serial port open error - already open?")
serialobject = "serialerror"
return(serialobject)

def get_telescope_position(serialobject):
#get RA and DEC
serialobject.write("#:GR#".encode())
RA = serialobject.read(10).decode('latin-1')
time.sleep(1)
serialobject.write("#:GD#".encode())
Dec = serialobject.read(10).decode('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#"
else:
print(" alignmode not recognized...defaulting to altaz..")
command = "#:AA#"
print('alignment mode set to {}'.format(amode))
serialobject.write(command.encode())
time.sleep(1)
serialobject.reset_input_buffer() #flushInput()
return

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

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()
serialobject.write(alt.encode())
serialobject.write(az.encode())
command = "#:MA#"
serialobject.write(command.encode())
return

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

so = start_telescope('/dev/ttyUSB1')
for x in range(3):
get_telescope_position(so)
get_alignment(so)
set_alignment(so,'Land')
go_lcd(so)
get_alignment(so)
halt_scope(so)
so.close()

Read More...

Andrew replied to the topic 'indi 1.7.4 : possible small bug in skysensor' in the forum. 5 days ago

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.
Andrew


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

2018-08-10T09:05:56: Driver indi_lx200ss2000pc: read setSwitchVector SkySensor2000PC CONFIG_PROCESS Ok
CONFIG_LOAD='Off'
CONFIG_SAVE='Off'
CONFIG_DEFAULT='Off'
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">
Off
</oneSwitch>
<oneSwitch name="CONFIG_SAVE">
Off
</oneSwitch>
<oneSwitch name="CONFIG_DEFAULT">
Off
</oneSwitch>
</setSwitchVector>

2018-08-10T09:06:16: Client 0: read newSwitchVector SkySensor2000PC ON_COORD_SET
SLEW='On'
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
RA='1.69197'
DEC='1.23823'
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">
On
</oneSwitch>
</newSwitchVector>

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

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
MOTION_WEST='Off'
MOTION_EAST='Off'
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">
Off
</oneSwitch>
<oneSwitch name="MOTION_EAST">
Off
</oneSwitch>
</newSwitchVector>

Read More...

Wilson Muchenje thanked Andrew in topic Starlight Express MX5 7 days ago
Andrew replied to the topic 'Starlight Express MX5' in the forum. 7 days ago

hi Will, I have one but had to drop it since the indi drivers don't work with it.

Peter and I tried hard to make a fit (see indilib.org/forum/general/7-starlight-xp...cluded-in-sx.html#20 ) without success which is a pity since it remain a great ccd for guiding and mine is still working on XP virtual machine.

Andrew

Read More...

Andrew created a new topic ' indi 1.7.4 : possible small bug in skysensor' in the forum. 7 days ago

firstly great thanks to the team for latest release, I only got to try it this week and was very excited to see improvements that jumped out, several that were on my wish list:-
- camera temperature indication for Canon (would be great to have tickbox option to add this to filenames)
- better integration of lin_guider
- the pulse guide option for skysensor (not tested yet)

During first run of v1.7.4 with new Raspberrypi 3 using ubuntu mate, I noticed what might be a bug with skysensor slew control while following my normal workflow :-
1. connect skysensor, canon and lodestar guider, check focus, take some flats, start guide calibration - all OK
2. after starting guiding (lin-guider) on remote, I normally use client kstar to slew target using mouse select target, then right click option for skysensor 'slew' or use ekos mount control to move.

Here I got no slew and after setting debug I saw error reported in the remote indi.log

"Driver indi_lx200ss2000pc: indi_lx200ss2000pc dispatch error: Property EQUATORIAL_EOD_COORD is not defined in SkySensor2000PC.

after checking several options I also noticed any attempt at mount control using ekos 'keypad' or indi control panel motion control resulted also in this error

"Driver indi_lx200ss2000pc: indi_lx200ss2000pc dispatch error: Property TELESCOPE_MOTION_NS is not defined in SkySensor2000PC."

I can resolve the issue by clicking 'connect' in kstar (from right click then skysensor) - which is odd since I'm sure I was already connected.

The client kstars (log attached) from a daytime test run doesn't seem to record any errors like above.

I never noticed this before, maybe I've slipped somewhere but could somebody check? I can send skysensor logs if required.

thanks
Andrew

Read More...

Alfred thanked Andrew in topic Question re FITS/CR2 conversion 4 months ago
Andrew replied to the topic 'Question re FITS/CR2 conversion' in the forum. 4 months ago

I also ran into similar issues with mixed image sizes during sessions which still persists. I understand it is a long standing bug in dcraw. It was a pain to resolve because I use also Siril, I wrote some python code to check and convert all session images into same size before using Siril.
see indilib.org/forum/general/2931-image-geo...rsus-fits.html#21889

Read More...

Andrew replied to the topic 'Image geometry different when using native versus fits?' in the forum. 6 months ago

Hi Jasem, Magnus,
This looks like same libraw bug (see indilib.org/forum/ccds-dslrs/1895-dslr-i....html?start=12#16190 ) that I stumbled upon a year ago.
I can verify from this weeks session it is still present i.e. with Canon 60Da some FITs files (bias and flat) have different dimensions to lights 5202 vs 5184 and makes processing a mess.
I can understand a longstanding bug in libraw, but why does it impact say bias and not light exposures from INDI?

If we want to stay only with FITs workflow is the subframe workaround i.e. add 5202-5184 = 18 still the only option?
Andrew

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 6 months ago

Just to reconfirm that all working fine - first time use of internal guide 'via' lodestar worked all night.
Option Via skysensor also available , I'll test tomorrow.

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 6 months ago

hello Jasem,
I upgraded to latest versions on server and client and can see indi-sx is 1.12-20180203 for example.
But I still cannot select 'skysensor' using the 'via' field in the EKOS guider options, it remains as just one choice 'SX CCD Lodestar'.
I assume that I should be able to choose to guide via RS232 or ST4 right?
I see Skysensor is online and I can use INDI control panel to Motion Control the scope so the RS232 is working.
Let me know if you need some logs.
Andrew

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 6 months ago

Well jasem, I'm not sure who disabled but you re-enabled it , see #15105. Hopefully I can try the new ppa tomorrow and I'll feedback.
Andrew


indilib.org/forum/mounts/1821-skysensor2....html?start=12#15105

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 7 months ago

Thanks Jasem, will check, maybe by this weekend and happy to find that issue.

While I have your ear - in the past when we looked at these Skysensor driver issues you mentioned that pulse driving had been deactivated, you switched it back along with a precision parameter too. Could you just double check and reconfirm that it is still enabled?

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 7 months ago

Thanks rlancaste, that is clear and understood regarding PHD. Can't wait to see it in action.

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 7 months ago

I think I saw some of your work PHD output in EKOS, it looked very nice since the graphics needed some work, but I didn't see it yet working.:-( , hopefully I will soon and can contribute some feedback.

My previous issues were from a year ago, Jan 2017, and were specific to using PHD and the Skysensor in serial (RS232) mode, PHD setup with no 'on-camera' setting so that SX CCD as guider and mount as Skysensor. But actually I had same problem with 'internal' guider. I still suspect the skysensor driver has minor bug in guiding.
The link I gave ( www.indilib.org/forum/mounts/1821-skysen...dec-not-in-logs.html ) is the whole debug story.

I keep sane because I can still switch back to windows/ASCOM without touching the system and happily guide BUT INDI/EKOS is a better system overall.

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 7 months ago

Thanks for looking Jasem, the problem is that there is no selection, the box is pre-filled with SX CCD and no selection is proposed.
I know in the past I could select either SX CCD or Skysensor.

Read More...

Andrew replied to the topic 'Did EKOS guider option 'via' change?' in the forum. 7 months ago

Well I did select "Guiding:Internal" in the Profile editor, saved and connected as usual. Normally this would be set to PHD.
I double checked just now to see if the setting was saved, it is. I did log the whole session, would that be useful?

Read More...

Andrew created a new topic ' Did EKOS guider option 'via' change?' in the forum. 7 months ago

I had some problems again guiding via ST-4 using PHD2 and lin_guider from Raspberrypi (setup below).

ITrying to debug decided to try the serial cable using EKOS 'intrernal guide' knowing that II never resolved the issues last year (link below).

However I couldn't get to testing because I cannot choose 'via' option in the EKOS guide tab, I want

'via : SKYSENSOR'

It will only allow me to set:-

'via : SX CCD LODESTAR'

The skysensor loads in EKOS correctly and I can move the mount via EKOS mount control. I've set the skysensor to 'guider OFF' and even pulled the ST-4 cable out. I see in the EKOS log screen that ' Guider port from SX CCD LodeStar is ready'

Am I missing something or is this option no longer available i.e. guide via serial cable?

Thanks
Andrew


setup Jan 18
========================
Client side
Ubuntu 17.10 (linux 4.13.0.32)
Kstar 2.9.2 Kstars-bleeding 5:17.12
Libindi1 1.6.3

Server via wifi Raspberrypi 2 - Ubuntu 16.04 powered USB hub
Libindi 1.6.3
indi-gphoto 1.6
indi-sx 1.12

(sudo indiserver -vvv indi_gphoto_ccd indi_sx_ccd indi_lx200ss2000p)

Orion Optics 200mm F/4 SN with GP-DX mount
Skysensor2000pc, RS232 serial/USB FTDI converter
Canon 60Da
Vixen 60mm F/7
Lodestar x2 autoguide custom ST-4 cable into SS2k


old issue last year:
www.indilib.org/forum/mounts/1821-skysen...dec-not-in-logs.html

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!