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...
Yes, mirror flop was the first thing jumping to my mind when reading this. Like Hy, I think PA should not be affected by cone error. Mirror flop would explain it. As well as play in the optical train. Is it all threaded connections?
With an EC mount you should be able to just track (unguided) through meridian and watch for a systematic shift of the image. How far can you track past meridian? iOptrons aren't particularly good at that
Read More...
20 degrees is a LOT. The only thing immediately coming up as explanation would be a too tight declination gear meshing that makes the motor lose steps when slewing. Are you close to the mount? Can you hear 'strange' noise?
Read More...
Running self-compiled 3.6.6 here.
I updated the satellite data (which stopped with an error halfway, not finding Gorizont data; found no way to proceed past that point).
I can see them in the download list (clicking on the '>' symbol). With 'Show Satellites' enabled they are drawn on the star map, and I get info for them.
They do however not show up in the Find Object dialog, so I have no way to search for a specific one
Read More...
Great! Will test it ASAP (but we are plagued by a low-pressure system at the azores, and the mountain is in clouds since almost a week (
I also saw some changes regarding the fit ("long tail" whe the fit isn't good) As I also experienced those I'm curious if that helped...
Read More...