I'm aiming to use an old Starlight Xpress camera (SXVR-H9) as a guide camera. I'm testing it out as the main imager in EKOS using the SX CCD driver and a telescope simulator. I'm using kstars 3.6.9. The camera connects fine and everything seems to report ok. I can cool it down to -10C without issue, and I've set a temperature tolerance of 0.5C. The cooling does not seem to have a problem staying within that range. When I do some individual test captures, all is well and the image transfers. But if I do a sequence, such as a dark library run,

like in the attached screenshot, then it will usually hang at the point of image transfer during one of the exposures. I've checked that this is not an issue with the camera heating up above the set threshold. I attach an example log file, but I don't see anything obvious. The last lines of the log show me cancelling the run and stopping INDI, but there's nothing obvious happening just before that as far as I can see. I've tried swapping to a different USB port (using both USB2 and USB3 ports) but the same issue occurs.

Any help/insight appreciated.

Read More...

This feature request is, I suppose, for EKOS rather than INDI but I guess the development team is the same or similar?

So my request is for EKOS to have a tab dedicated to the technique of deep-sky lucky imaging (DSLI). The DSLI technique is explained here: www.cloudynights.com/articles/cat/cn-rep...-lucky-imaging-r3220

DSLI basically allows you to remove some of the effects of atmospheric turbulence for deep-sky observations, allowing higher resolution imaging.

Deep-sky imaging cannot employ standard lucky imaging techniques as the exposure times typically used are too short to capture enough photons for image selection and stacking. So the idea behind DSLI is to use exposures of a few seconds, shorter than typically used for most deep-sky imaging but long enough to gather enough photons on brighter stars in the field to assess image quality. For many urban observing sites seeing is dominated by thermal currents near ground level that vary on timescales of several seconds. Removing these variations can therefore bring big improvements to image quality. Removing such variations can be done by selecting the subset of short exposure subs with the best FWHM or HFR and discarding the rest.

However, restricting exposures to a few seconds would entail producing a lot of images that would  quickly fill up a hard drive during a nights observing, and most of these exposures would be unused due to their poor image quality. The optimal solution is to capture images, measure their image quality and selectively stack the good ones in memory, then write the stack out to disk after some predetermined cumulative exposure. For example a user could request a series of 30-sec stacked images to be created from 3-sec individual exposures that pass some user specified thresholds on FWHM or HFR size.  Poor quality images would be discarded from memory and not written to disk.

To do this each captured image needs to be calibrated in memory with darks and flats before being measured for FWHM/HFR and added (or rejected) from the cumulative stack being held in memory. Once the stack reaches the requested cumulative exposure (or some minimum number of high quality subs) it is written to disk and a new stack is initialized. This continues until all requested stacks have been obtained or the session reaches some user-specified time limit. The resulting output will be a set of stacks of guaranteed image quality and that are already full calibrated. Obviously all this assumes the user is autoguiding or has an extremely accurately aligned setup so that subs do need to be geometrically aligned within a given stack. (I guess if WCS is enabled then it could be possible to use this to align if needed?)

The DSLI tab would need to be able to allow the user to input/select the individual image exposure as well as either the output stack exposure or, equivalently, the number of subs per stack. It also would need to be told what dark and flat calibration frames to use and it would be useful to be able to specify the max number of stacks to output and a session time limit as well as have a button to abort an ongoing session. A live graph showing the HFR or FWHM distribution of all images obtained so far (good and bad) would be useful to inform the user FWHM/HFR selection. There could even be an "preview" mode where EKOS just loops exposures and updates the HFR/FWHM distribution to allow the user to work out what the best FWHM/HFR cut might be. In preview mode there would be no outputting to disk (a bit like the loop mode in the camera tab) and the use just terminates it when they want to. Some live percentile stats would be useful here too.

I imagine the DSLI tab being perhaps a self-contained alternative to the standard camera exposure tab in EKOS. But it could equally be more minimal by inheriting all other camera values (camera device, gain, binning, filter etc) from the camera tab, in which case the user would need to fill out information in both the Camera and DSLI tabs to fully set up a run.

ok, so that's it. Unfortunately I have no C++ experience so cannot help to develop this but if someone wants to take it on I'd be happy to test it.

Read More...

Hi Jasem,

Terrific! Just tried it out and it does the job - camera is now producing images again. In case it's useful I attach a log using an identical run to yesterday - 1-sec exposures with the 130M and 183M cameras. All worked fine.

Thanks very much for your help and thanks to you and the development team for such an excellent set of software.

Eamonn.

Read More...

Hi,

I'm really hoping that someone can help out on this. I've continued to try to get this camera working but so far no luck,

Just to give a more detailed report - I have two Altair cameras a 130M guide camera and a 183M Fan cooled main camera. I'm running KStars 3.5.4 with INDI 1.9.1 on Ubuntu 20.04. Both cameras have been working flawlessly until recently. The 130M guide camera still works fine but EKOS appears not to be to execute a successful capture anymore with the with 183M. Both cameras work fine on the same system with the AltairCapture software so it is not a hardware issue. I attach a full log with EKOS INDI and Capture as well as CCD driver logging set to verbose. I also attach a screenshot of the EKOS camera tab that show it apparently executing a 183M exposure and waiting for the image. In this test session I connect just the two cameras, no other equipment. I set up a 1-sec exposure in the queue at standard setting for each camera, 130 first then 183M. On running the queue for the 130M exposure it succeeds first time. But on running the queue for the 183M exposure an image fails to materialise despite EKOS automatically restarting the exposure attempt many hundreds of times. Eventually EKOS disconnects from the INDI server and KStars closes itself down.

Would be interested to know what might be the cause, or if anyone else has experienced a similar issue recently. Also happy to run any further specific tests that might help pin down a cause. Any help appreciated.

Read More...

Hi,

Until recently I have been successfully using my Altair 183M camera mounted on a Meade LX90 with Kstars/EKOS on Ubuntu, until the latest INDI release. I'm using Kstars 3.5.4 Stable from the kstars-bleeding package. Now when I try to expose with the camera it almost always aborts the exposure. On the rare occasion that it does do something the image then fails to retrieve to the Kstars image viewer. The logs repeatedly report errors like the following:

[2021-08-09T18:08:37.603 BST INFO ][           org.kde.kstars.indi] - Altair AA183MPRO :  "[ERROR] Failed to snap exposure. Error: Unexpected failure "[2021-08-09T18:08:37.603 BST INFO ][   org.kde.kstars.ekos.capture] - "Capture failed. Check INDI Control Panel for details.
"[2021-08-09T18:08:37.606 BST INFO ][   org.kde.kstars.ekos.capture] - "Restarting capture attempt

The INDI Control Panel does not provide any additional info. The camera works fine on the same system using the linux version of AltairCapture. So the camera and cable do not seem to be the problem. I also found the same problem when rolling back to an earlier Kstars version that had worked before. The only component I have not rolled back is the INDI library itself, which leads me to believe that the fault lies with it somewhere.

I'd be grateful for any help - Kstars/EKOS is a really great piece of software and I love using it.

Read More...