Jasem Mutlaq thanked Andrew in topic dslr - image info 2 days ago
Andrew replied to the topic 'dslr - image info' in the forum. 3 days ago

I tried another .fits only session last night it made 20+ images overnight Lights + Darks in .fits with 5184x3456, I didn't really touch anything - strange.
This morning I tried some bias frames and saw immediately EKOS fields change to 5202x3456, then no matter what I did in either INDI or EKOS it retained this, I tried setting each image size in INDI to the smaller frame, I tried setting offsets in both INDI and EKOS which didn't work as expected, each time the exposure would reset to the larger frame size.I even tried setting Native transport in INDI and left is FITs in EKOS.

In my workflow, and when I first noticed this issue, the Lights and Darks were OK just like this session (5184x3456) but bias and flats effected by larger frame size. so it seems it is capable of retaining the smaller frames! I start every session with INDI Capture Format to 'normal JPEG' since it speeds downloads for framing (set EKOS Format to Native. The result is a 5184x3456 image Preview, then by switching in INDI to RAW capture and in EKOS to FITS it retains a 5184x3456 FITs image.

It's an ugly workaround and when I tried to repeat it this morning it failed so I'll move back to Native CR2 since this is not a big issue really, but more importantly I think for DSLR workflow are the following issues which I notice every session:-
a. Bias setting min 0.001 : cannot set it lower i.e to 1/8000 (0.000125)
b. File name suffix for exposure is always '_0_' for sub-second frames (Flats and Bias) : is useful to see file list with exposures i.e. target_000125s_
c. Temperature in filename - from exif data, I mentioned this in wishlist for 2017 but thought it fits well here too but I recognise it is probably I much larger edit than the other 2 items.

thanks, Andrew.


Andrew replied to the topic 'dslr - image info' in the forum. 1 week ago

hi jasem, did you ever have luck checking this?

I had similar experience with 60Da. I use SIRIL to process images, it accepts .fits directly but I've always converted from .cr2.
A couple of weeks ago, in an effort to streamline workflow I tried to save some lights and darks directly as .fits which worked fine. However when I came to processing, I found my SIRIL library bias and flats (taken another day as cr2 converted in SIRIL to fits) had different sizes as reported by lhoujin.

I assumed I'd made an error when setting the image frame or it had changed between sessions, normally I just load a saved profile and it works fine for .cr2. since I don't use any EKOS functions to focus or guide with the 60Da .

I tried cropping the files using PyFits to same size but in the end had to scrap this session and decided to return to saving as .cr2 but I'd like to try .fits only workflow again!


Andrew replied to the topic 'some thoughts that came up doing native captures...' in the forum. 1 week ago

I agree some form of reduced window size that could be fixed between sessions would be great for native raw dslr.
I think another topic discussed fixing window sizes between sessions so maybe this could be combined?


Andrew replied to the topic 'Partial SOLUTION skysensor2000PC -Error reading RA/DEC' in the forum. 3 weeks ago

it is specific to Skysensor and Lodestar x2 but it is a hardware 'patch' so not sure how you want to handle that, I suppose a note with the skysensor driver and Lodestar x2 page refrerring to this particular pair need a hardware patch on Lodestar x2 outputs and refer to Starlight Xpress?

but I can confirm that guiding does work - I got my first ever 100% Linux image (Ubuntu,INDI/Ekos/Kstars, RaspberryPi and Siril).:)
I'll feedback some minor adjustments for DSLR workflow in seperate subject.

Thanks again


Andrew replied to the topic 'Ten Steps to Getting Off ASCOM' in the forum. 4 weeks ago

Thanks Rockstarbill, this is nice summary and pretty much the route I took except I use DSLR as CCD, it will save newcomers hours of fiddling and will make nice posting-.

I wanted to check point eight, para 3, since it relevant to my ongoing struggle to autoguide. I've failed to get RS232 working and finally found a solution this week via ST4. You seem adamant about only ST4 working with LX200 type driver, which is what I've found, did you try it at all?


Andrew replied to the topic 'Partial SOLUTION skysensor2000PC -Error reading RA/DEC' in the forum. 4 weeks ago

UPDATE - with partial solution.:)
with help from Terry at Starlight Xpress we found that the Skysensor2000pc needed a signal input adjustment to work with Lodestar x2.
I can now confirm it works fully enabling me to autoguide via the ST4 port using Lin Guider, openPHD2 and indi (first night RMS 1" in dec and ra over several hours).

I'd still prefer to use the RS232 option but this still fails with the indi lx200ss2000 driver and as far as I can tell this is a bug and not hardware. I'm happy to try to help resolve this if there is a demand.


Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 1 month ago

thanks jasem, I'll test on tuesday night and report back, forecast clear all week here :-)
a couple of users on the ss2k group confirmed they guided with lx200 settings (ascom) so hopefully by reactivating it we should have some success - lets see...


Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 1 month ago

Update - my SS2K autoguider function is broken.

So I'd like to contribute to editing SS2K driver to make it work with pulsedrive commands as it does in ASCOM. I only have limited programming skills (fortran, Basic, Python and script) but I see the ASCOM script is in VB and updated fairly recenty 2013 (LaurieY 6.1.7b github), so if somebody could hint were I could start, with a little help and if there is wider demand we might finish it! what do you think?.

Surely if one of the LX200 drivers is using pulseguide is it not just a case of editing that for differences? I notice I can select either Indi_lx200generic, basic or classic and I think even 16 worked, anyhow all partially worked at least enabling calibration and short guide until mount runs away,

Actually a SS2K pulseguide is might last hope to use INDI since below is my last failed test on the SS2K and ST4 autoguiding:-


ST4 failure confirmed

I opened the SS2K to check the continuity into the back of the RJ12 socket and it seemed to be OK, I mean no pins were electrically disconnected from the solder board.

There it seems the problem is within the SS2K circuit but I don't have the skills to debug that far. Although I assume the circuit is a fairly simple switch type mimicing the N.S.E.W buttons anyhow for now it's broken.

I tested the whole system again - 1st RS232 with Windows/PHD and Astroart using ASCOM drivers works 100% as per last 10 years. Switching to linux on Raspberry Pi or a PC fails on all SW, OpenPHD/Indi drivers and Sx drivers wil only guide in 2 directions. ST4 fails on Windows and Linux it will only guide in 2 directions.


Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 2 months ago

Thanks Camiel,
For the moment, with clear sky, I'm back to Windows/ASCOM system (BYEOS and PHD) which is OK, guides very well but lacks the complete suite that INDI offers. BTW - In this setup SS2K supports pulse-guide via the RS232 using ASCOM driver with PHD.

I tried Lin-Guider and it shows I probably do have an issue with my ST4/Rj12 autoguide cable, I tested with multmeter but cannot find fault. I'll probably invest €20 in professional cable and report back since this combination seems perfect with INDI.



Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 2 months ago

Sorry Jasem I don't have any guiding extras for ss2k, I suppose they could be extracted from ASCOM driver?
Looks clear for tonight so I'll try autoguide ST4 again with a tighened backlash on Dec motor.


Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 2 months ago

thanks everyone,

So if I understand the various inputs here :with my setup using the ss2kpc driver will not work since the controller doesn't accept the commands.The only option for guiding is to use the autoguide ST4 port. I'll try this again next clear night.

But why was a ssk2pc driver created if it cannot guide, what advantage does have over say a LX200 driver?



Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 2 months ago

Thanks Jasem, to answer you question:-
1. Lodestar is the new component in this system so initially I tried direct autoguide via ST4 port but it failed and started this whole hunt. Actually I understood it was best to use drivers rather than ST4 autoguide , I got that from PHD best practice, do you recommend ST4 autoguide for indi/ekos? I've been using lx200ss2kpc driver and only asked about lx200 as possible way to test my setup and the lx200ss2kpc driver.

I'll correct my dec backlash by adjusting gears and try all tests again based on your feedback.


Andrew replied to the topic 'skysensor2000PC -driver query (Error reading RA/DEC not in .log' in the forum. 2 months ago

UPDATE 2 - sorry for lengthy post.

I've been working this debug on the Skysensor forum based on Jasem's feedback pointing to an equipment fault (dec motor). I've returned since the root cause again points towards the SS2k driver. Here's the outline logic why:-

I stripped the whole system down looking for electro-mechanic faults, checked each connector/contact, tested for breaks etc but no luck in finding the culprit. I took the motors apart, re-greased mount, adjusted the encoder nuts etc, switched motors but no obvious pointers like broken wires.

So with hope I put it all to the test again. Starting with Raspberry Pi with indiserver; goto, slew, track all fine. Calibrated guiding in indi, great, but lost guide each time at random point with West drift. I could restart guiding by stopping the West drift using the Centering buttons in the indi panel, but each new guide was broken by West drift.

Next I tried PHD on the pi with INDI drivers but with same failure mode.

Next I plugged the USB hub (Lodestar, Skysensor, Canon) into a laptop/ubuntu and ran the whole series of tests again INDI/EKOS first, then PHD and PHD providing guide frames to indi/ekos - same failures with west drfit killing the guide but otherwise everything working fine.

So two different softwares, two PC hardwares with same failure mode. In both setups I tried various software settings and also tried both the ST4 autoguide port and guide via skysensor. By this time I'd also ticked off some other failure candidates like the USB serial convertor (seems OK) and found from PHD logs that polar alignment was OK (sub-minute) but with a large dec backlash (whih could be adjusted).

As desperate last step went back to Windows system that worked for many years on the same laptop/usb hub using PHD/Ascom ss2k driver and BANG, first time calibration then several guide sessions of ~0.3 rms guiding over 10mins. I can just tell that the system is solid and working correctly and would guide all night. I also tested with Astroart both using ascom skysensor drivers.

For me the above seems to point to the indi ss2k driver, it is one item that changed that I can't cross test. I attach
a failed guide log from indi session and pose some questions:-

In log file I see each guide instuction to move (CMG <:M_#>) is followed by a halt (CMD <:Qw#>) :-
CMD <:Mw#>
CMD <:Qw#>
but sometimes the "halt West" is missing and it seems to be associated with a dual-axis guide - see log_20:53:35 @ 2017-02-20T21:47:03.42 and shortly after this guiding is lost (West drift).

a. I guess this sequence is only required for Dec corrections but thought it worth cross checking, could it be source of my troubles, dual-axis guide?

b. What is the correct lodestar binning setting for lodestar when guiding, is it 2x2?
I wondered if somehow the image changed to hires or 1x1 thus causing a misreading of guide corrections.

c. As a test, would guiding in indi work with a LX200 driver?

Any further assistance to resolve this would be appreciated otherwise I'll have to return to the dreaded Windows and a laptop!


PS I attached kstars log since it was easier for me to read let me know if you need a different log or more details.


Andrew thanked giuseppe in topic CR2/NEF/ARW files required 2 months ago
Andrew replied to the topic 'skysensor2000PC -Error reading RA/DEC not in .logs' in the forum. 3 months ago

Thanks camiel and jasem for feedback.
It's been windy but clear here so not ideal for tight guiding but I continued with some tests to rule out variables, here's an update.

I tried starting server with -vvv option and enabled verbose logging, it created client Ekos log and server log both attached following a kind of dummy session i.e. startup, track/sync to target, plate solve, guide calibration ending in guide fail. So then I did some guiding movements N,S,E,W to ty to check instructions are being followed.

On first read logs are a bit overwhelming but I guess they will mean more to you. I noted several things during session
a. On screen, I could see a high precision RA/DEC stream, like 12 decimals in the server SSH window
b. in the Ekos log at about 19:37 calibration fails (typical state)
c. but at 19:40 I got calibrated, but this soon loses track and fails after about 2 mins (typical)

So, after i tried adjusting guide variables without success. exposure, reticle, guiderate 0.5/1.33, rapid on/off, RA only etc etc - no success.
It seems in general from the logs that guide instructions are being sent and acted on. As I noted before when I do a simulated guide by manually hitting NSEW buttons I can see movement on screen (star moves), in client and server panels RA/DEC output moves and this is confirmed in the log. See around 23:32 guide south movement is shown albeit to low precision (but as you say this is just output not calcs which appear to be done on high precision):-

2017-01-16T23:32:29.605 - DEBG - SkySensor2000PC : "RES <-01�50> "
2017-01-16T23:32:29.628 - DEBG - SkySensor2000PC : "VAL [-1.83333] "
2017-01-16T23:32:30.612 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:30.686 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:30.711 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:30.740 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:30.777 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:30.802 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:31.751 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:31.839 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:31.863 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:31.882 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:31.920 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:31.946 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:32.921 - DEBG - SkySensor2000PC : "CMD <#:GR#> "
2017-01-16T23:32:33.029 - DEBG - SkySensor2000PC : "RES <05:40.7> "
2017-01-16T23:32:33.055 - DEBG - SkySensor2000PC : "VAL [5.67833] "
2017-01-16T23:32:33.082 - DEBG - SkySensor2000PC : "CMD <#:GD#> "
2017-01-16T23:32:33.107 - DEBG - SkySensor2000PC : "RES <-01�51> "
2017-01-16T23:32:33.128 - DEBG - SkySensor2000PC : "VAL [-1.85] "
2017-01-16T23:32:34.312 - DEBG - SkySensor2000PC : "<HaltMovement> "
2017-01-16T23:32:35.011 - DEBG - SkySensor2000PC : "CMD <:Qs#> "
2017-01-16T23:32:35.035 - DEBG - SkySensor2000PC : "Movement toward South halted. "

SO, assuming for now the guide algorithm is working correctly (can you check?) with my setup - I see about 1.3sec between capture and receive guide frame, the guide exposure being 1 sec. I decided to rule out any lag in the network and moved Ekos/indi onto the Pi/Ubuntu at the observatory and ran in local mode.

I also setup openPHDs on the server and ran that directly - I got calibration and guided for 2-3 mins, >4" errors which is to be expected windy, no PEC, no darks etc. It showed orthogonal axis error so I changed Skeysensor guide mode to X-Y (was RaDec) - was better.
I ran Ekos/indi and got calibrated , again 2 mins then lost guide. I ran out of time and didn't setup logs but it looks more promising.

I'll test the server/local setup correctly tonight, check everything and send the logs. Hopefully this will prove local setup working at least.

Aside from not getting guiding working the whole setup is working very well, impressive.


Andrew replied to the topic 'Canon DSLR Preview Window' in the forum. 3 months ago

I had similar issue with my DSLR (60d) but found best workflow for me was setting the initial image size in the profile to a small JPEG, rather than RAW, enables very rapid framing/downloads (almost instant even on remote wifi with Raspberrypi). Once everything is set for the main imaging session I edit the profile back to full size RAW.


Andrew replied to the topic 'What would you like to see in Ekos in 2017?' in the forum. 3 months ago

To help DSLR procesing I'd like to see a way to pickup and record the relative DSLR sensor temperature estimate and import into the filename.

I understand this is probably a big ask since it involves some magic with EXIF fields, would vary with each DSLR model and may require some collaboration to calibrate for each case but it is useful in the overall workflow.


Andrew created a new topic ' skysensor2000PC -Error reading RA/DEC not in .logs' in the forum. 3 months ago

My setup is as follows, I'm trying to debug to get first autoguide session:-

Client side LAN Ubuntu 16.10, linux 4.8.0-34
Kstar 2.7.2 Kstars-bleeding 5:16.12

Server wifi Raspberrypi 2 - Raspbian jessie 4.4.34 v7 with powered USB hub
Indi Library 1.3.1 (sudo indiserver -vvv indi_gphoto_ccd indi_sx_ccd indi_lx200ss2000p)
Orion Optics 200mm F/4 SN with GP-DX mount
Skysensor2000pc, serial/USB converter
Canon 60Da
Vixen 60mm F/7
Lodestar x2 autoguide cable into SS2k

This is a new setup, all works fine except autoguiding and the need to run indiserver as root to control the Canon.

I'm now debugging the autoguider. It's nearly working, 2-3" errors for 1 minute then aborted. Trying to rule out latency errors I'm trying Rapid Guide with autoguide cable between Lodestar and SS2K.

But my question is related to "Error Reading RA/DEC". It appears randomly in INDI control panel, sometime 2-3 per minute.

I attach .log but I only see errors in the INDI control panel, maybe it's hidden in log i.e. strange character in RES which also appears on client control panel as RES <+88�27> could this be the issue?

Once I manually Sync/Track the error appears much less i.e. every few minutes.

I don't think it's an important error at least not for autoguiding but can I resolve it?
My logs and INDI control panel shows UTC timestamp is that normal?

I'd welcome any assistance.
Hopefully then I can complete a first light session using this great piece of software.




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!