There is a 'Dark' button/checkbox in the guider interface.
Basically you would use stellarmate to build a dark library for your guide camera, just like in PHD2 and then if you check the 'Dark' checkbox, stellarmate will use the master darks to eliminate hot pixels from the image before submitting it to the guider.
Read More...
You're welcome.
That may still be the case, but their website claims it's fully supported under INDI. These guys have been putting some effort into making things solidly supported in software.
Read More...
Hi, their website says this:
The mount fully supports ASCOM 6 and INDI framework. Sky-Safari is also supported allowing you to control the mount through your mobile device.
LX200 protocol is fully compatible with NYX-101. Sky-Safari works out of the box with the mount.
pegasusastro.com/products/nyx-101-harmonic-gear-mount/
Read More...
Thanks Jasem, tested and it looks ok!
Turns out the CEM-26 refuses connections after it has been parked for a while.
Read More...
I wanted to come back to this thread to report back on what I have found out.
Thanks everyone for your explanations and advice, it was useful.
So basically, things are as follows:
PHD2 does do it 'better', but this is actually irrelevant because it partially masked the real issue.
The entire system was horribly unbalanced. While I am aware of 3D balancing and I had thought I had done this correct, this was incorrect. I had RA and DEC balanced, but any movement would cause both axis to run away in one direction or another.
The internal guider had a much harder time coping with this than PHD2, but again .. irrelevant. Both results were bad.
While I have not managed to perfectly balance the system, it is now much, much better behaved and the internal guider is managing reasonably well.
Read More...
As per title.
Capture will remain in whatever train I left it last, which, if I was say fiddling with the guider and I forgot about it, I'd probably waste a lot of imaging time.
Read More...
I don't know how to reliably reproduce this yet. What happens is as follows:
1. Loaded a job into scheduler and turned scheduler on. This job has a sequence which will run 300s exposures
2. In capture, go after an entirely different target with an ad-hoc sequence set to 60s exposures NOTE: The job wasn't scheduled to run for an hour
3. I let the thing go and come back later, I realize I have very few images
So now I check the analyze module and I see it started with 60s captures, took about 4/10 and then continued on to take more, but swiched to 300s.
The really strange thing is that while it acted like it was doing 300s exposures, I don't believe that they were - the images look too tight (no guiding!) for 300s captures, and I would have expected most stars to saturate.
I think I had the logs for the CCD and Align turned on, unfortunately not for capture. I'm going to turn on logging in case it occurs again.
Read More...
Hi, this seems like a simple enough bug:
If I attempt to capture an image and the mount is not connected (or more likely, in some weird state and no longer wants to connect) ekos/kstars crashes.
Kstars 3.6.1
CEM26
QHY268
SV905C
iPolar
I tried with all 3 cameras, which seems to imply that the system wants some information from the mount and crashes when it cannot get it.
Read More...
So while I was able to image and salvage my images, this isn't completely resolved:
1) The focus module crashes if I try to take an image with the QHY268C
2) Just like the 268 was crashing before, attempting to connect to the SV905C now crashes ekos.
My indilib is still at 1.9.7 and I see in the update some of the debug symbol packages for the drivers (*-dbg) have been 'held back'. This makes me suspect that my installation is either somehow corrupt or it's in some sort of unstable situation, and I'm thinking the indilib not updating is probably part of the reason here.
Jassem, was kstars 3.6.1 built against indi 1.9.8?
Read More...
This is resolved. I don't know how it happened exactly, but basically when the camera would crash I tried a bunch of things including deleting the config files.
I found a couple of debian packages to roll bakc to for indi-qhy and used those. They didn't work perfectly but they worked well enough for me to achieve what I needed (now the question is, am I missing information in my images? The images I took before all of this were 60mb, now they're 52 ... maybe I'm just overthinking it).
So, for whatever reason those drivers did not auto-detect/write the RGGB filter field into the configuration.
I deleted the configuration, rebuilt it, and now the filter was in there automatically. It should probably be called 'bayer pattern', not 'filter' under the bayer property.
My images can be fixed by running astfits from gnuastro, so I'm very happy about that.
This was a weird misadventure but I learned a lot.
It would really be good to have a repository available that makes things available for rollbacks though.
Read More...
Understood, so additional info: My version of indi-full is still at 1.9.7 and refuses to go to 1.9.8, I don't know if this is an issue.
While thi sis being investigated - and I'll help however I can - what can I do to my FITS header so that say SIRIL and FITSviewer detect the bayer? It appears they depend on the property. Do I just need to set the BAYERPAT property in the FITS header? I know that it is RGGB.
Read More...