It's also 'off' if you activate HiPS overlay....
I had already been wondering why, on startup, the BG always flashes blue for a short moment before the DSS is shown... 
Read More...
Yes, that is correct, you should run PHD2 using INDI, i.e., you need to start EKOS and INDI first, then you can select INDI devices in PHD2.
But definitely look at the internal guider of EKOS. Using that instead of PHD2 is much easier, and (IMHO) it is as capable as PHD2 in most cases (e.g., it had multi-star guiding before PHD2). I switched to it 3+ years ago and so far didn't find a reason to regret this step...
Read More...
Not sure if it is related, but I did have quite some issues due to the fact that devices that I had in my profiles had changed their names (in the context of the ASI -> ZWO name change). Maybe something similar also is the case for you?
Read More...
Hi,
after some hiatus, I started doing some astro-imaging again this year. So I compiled latest INDI and kstars, and (with some struggling from not remembering things....) got running. Like usual, I only watched the first hour and then went to bed, having EKOS do the work 
(this was only using the capture module, not the scheduler)
I'm now looking at the data and noticed that something went wrong when the meridian flip limit was reached during an auto focus session: The log has a notice that MF is planned, but it did not start after the AF was done. Instead, after a short time the mount did the flip itself (but without doing an align run). This was of course also stopping the guiding.
It stayed in that state (MF planned) for about an hour, until the sequence I was running finished. Only then it reported MF done. This again overlapping with the AF run of the next sequence. That one finished successfully, and directly started acquisition of the first frame. Only after that first frame, the alignment-after-MF was triggered, which eventually also restarted guiding.
Attached are kstars log and analyze data of that run. Maybe it helps to figure out if that was a bug or my fault....
Read More...
OK, some more info.
The GPSStartLine variable is from the libASICamera2 library. Grep-ing for it signals a match. This is with the lastest 1.31 version of libasi. The previous version I had installed was version 1.29. grep doesn't find the variable there.
I've now connected the 1600 to my laptop, removed all earlier camera configuration (.ZWO/ASIconfig.xml and .indi/ZWO CCD ASI1600MM Pro_config.xml*). Then started kstars and EKOS/INDI with a local configuration and only the ZWO camera.
As said before, it comes up with a value of 49152 for GPSStartLine (and 269 for GPSEndLine, FWIW).
I can take a preview in the capture tab that way. If I enter e different gain/offset and press preview it does still do a preview, but does NOT change gain/offset.
I then tried setting up a single-frame sequence. That one first immediately aborted, my fault. I had still refocus-on-T-change active and it wanted to focus first...
After de-activating it the sequence ran, but without changing the gain/offset to the requested values. Log shows an error
complaining that GPSStartLine has a value outside the allowed range, and obviously then doesn't continue to set parameters.
If I change it to the allowed maximum, as reported earlier the exposures will no longer finish.
Worth to note is that the maximum allowed value (3519; for both StartLine and EndLine) is the sensor height of the ASI166 minus one, which makes me think something is initialized wrong(?). Are those limits coming from the library? Or is it within INDI?
I've now downgraded libasi and indi-asi to the last working state I had, and again removed INDI and ZWO config files.
With that, everything works as expected.
Would be great if someone with an ASI1600 could verify/confirm this issue... (it seems cam-specific, at least my 2600 doesn't show those GPS* variables)
Attached is the logfile of my test session.
Read More...
Yesterday I updated my astro installation, i.e., compiled indi and kstars from git.
Since then my ASI1600 is missbehaving. Or rather, maybe kstars is.
It seems to be related to a configuration entry named GPSStartLine. I have not the foggiest idea what that is. But it's always showing up if I remove the configuration files for the 1600 in $HOME/.indi
The issue is that when starting up this variable has a value of 49152. And things work. But if I go to the indi tab of kstars, there to the 'Controls' tab of the 1600, this value is shown as current. But the value in the 'set' field is 3519. And this is the maximum value that I am allowed to enter. And if I want to set any value of another variable there, GPSStartLine gets set to those 3519.
And after that, the camera will not finish exposures anymore. The exposure counter runs down to 0.10, stays there for a second or so, and then restarts the exposure. After 3 fails I get an error...
I had tried downgrading to the previous version of both INDI and KStars, but still had this problem. So it might be already an older problem (I usually don't touch any settings of the 1600). So for now I can't change any setting of the cam without 'bricking' it 
Can anyone confirm this? Where is the 3519 in kstars coming from? The xml.default file also has the 49152 in....
Read More...
Absolutely cool feature Hy!
One suggestion would be a toolbar button to easily switch the overlay on and off.
Read More...
If you point to zenith, where do you end up?
If I do it here, the FOV is centered 1 RA minute (15 arc minutes) east of the meridian line. So if your experiment relied on the meridian line, the question is: Is that line drawn correctly?
Did you check hour angle at the position where you slewed to?
Read More...
Fitchie said:
But even the most expensive mounts/piers never will be completely rigid and in addition a small imbalance is desired to improve the guiding, so that there is always a small force against the leading or trailing edge of the worm.
As long as worm gear mounts are used without spring pressure on the worm, probably the backlash as result of using symmetrical positions before & after the meridian, will make a greater contribution to the PAA inaccuracy than the flexing caused by the imbalance. And of course FL and the weight of the telescope will play a major role.
However, with spring loaded mounts there seems to be an advantage by using symmetrical positions before & after the meridian to polar align, no matter how small the flexing / bending may be.
First, RA backlash is irrelevant. There is no requirement for accurate movement in RA, you just need any three positions. The selected step size, AFAIK, isn't used anywhere in the calculations.
DEC is another thing, so if there is substantial backlash that might affect the result. However, the assumption for the algorithm is that there is no movement in DEC, so in that case the asymmetric version (keeping the DEC gear always on the same edge) would be the better choice.
Imbalance of the scope will only affect gear meshing, on which edge you sit. I don't buy that even a more severely imbalanced scope will cause a noticeable static bending.
Or, the other way around: If it's so imbalanced that it causes bending, PA will be your smallest problem....
That said, I'm always doing my PA symmetric, starting at -45⁰ going to +45⁰ 
And I don't move back to home/park afterwards, and only revert direction for the next run (if needed).
Read More...