I may be wrong, but if I understand the math being used to determine the alignment of the RA axis, it seems that the images being mirrored should not affect the result... or at least, if it does affect the output somehow, I'd consider that a bug. Astrometry.net is capable of handling images of either positive or negative parity (i.e. "normal" vs. "flipped,") so unless the Astrometry.net settings are incorrect, such as being told to only search for positive-parity solutions when the images actually have negative parity, they should still solve. Each of the three solved plates equates to a great circle on the celestial sphere, defined by the central coordinate of the image and its rotation, neither of which should be affected by the parity of the images, and these three great circles should intersect (or roughly intersect, accounting for error) at two points corresponding to +90 and -90 degrees declination. That's not to say that mirrored images definitively aren't to blame, simply that there's no practical reason why the system wouldn't be able to handle them, as far as I can tell.

Read More...

What version of KStars are you running? Are you on 2.9.6 or are you running a nightly/bleeding-edge build? If the version you are using was built after June 3, perhaps it's possible that these changes are responsible? It seems likely to me that this is a regression of some sort, as I seriously doubt that the Polar Alignment Helper could have been broken ever since it was introduced a year ago and nobody would have noticed. It does look like some fairly major changes were made, so perhaps the bug was introduced there? These changes were made after 2.9.6 (the latest stable version) was released though, so unless you're running the bleeding-edge version, the problem would have to be older than that.

Read More...

Interesting... the fact that the RA offset afterwards is almost exactly twice the original value, and almost exactly the same angle, does seem to strongly suggest that the correction guide is telling you to go the wrong way. I can't see how this could possibly have anything to do with your mount, but at the same time, it seems strange that no one else would have encountered this and brought it up already. I've had fairly inconsistent results with trying to do polar alignment corrections myself, but I never seem to get to the point where the star is perfectly centered in the crosshair, mainly due to camera/plate solving issues that show up during the "refresh" phase. Anyway, I think that what you're seeing here certainly merits a closer look, since your results are quite telling and I don't see any reason why you'd be experiencing this and others wouldn't.

Read More...

Keep in mind (if this isn't obvious to you already, in which case I apologize) that the adjustments you make to your mount, and the resulting motion of the star within the image will be diametrically opposite. To use a hypothetical example, say that you use the polar alignment utility, and it tells you that the NCP is 30 arcminutes up and to the left of your current center of rotation. That is, you need to adjust your mount's polar alt/az knobs to bring your RA axis upward and leftward by 30 arcminutes. When you do this, the camera moves up and to the left, so the star will appear to move down and to the right within the frame. Once you've finished correcting for the polar alignment error, the star will be 30 arcminutes down and to the right of its original position in the image, the opposite direction of the adjustment you made.

Another observation that I can offer, as someone who likewise has struggled with getting accurate polar alignment, is that the adjustments you will need to make to the mount's alt/az knobs are very small. For reference, if you own a Telrad, 30 arcminutes is the angular diameter of the smallest circle at the center of the reticle. You may end up only turning the knob 1/16 of a turn, or something of that magnitude. I usually try to take it slow, check the refresh images, and make the smallest possible adjustments that I'm physically capable of making until eventually I get there.

Read More...

Try this:

sudo add-apt-repository ppa:mutlaqja/indinightly
sudo apt install indi-gphoto

libnova is in the standard Ubuntu "universe" repository which should be enabled by default. You just need to include the version number in the package name, since there is no single package with the name "libnova".

sudo apt install libnova-0.14.0 libnova-dev

That might do it. I was so focused on the fact that "RawProcessor.recyle()" should actually be "delete RawProcessor" (since the object is not being reused) that I didn't check that it was present in all possible branches. Good find, I bet that's it.

Read More...

Interesting... I think I may have isolated a memory leak, but just doing a quick calculation, it doesn't seem like it would account for anywhere near the 33 MB per exposure that you're observing. Right now I can only account for about 280 KB leaked per exposure, unless I'm missing something... there is definitely something fishy about the way that INDI is handling libraw though, and it definitely is leaking memory, I just need to do a little more digging to figure out why it's leaking so much. I want to make sure that this bug is actually responsible for the whole 33 MB before celebrating, since there's quite a difference between 33 MB and 280 KB. If I can determine where that other 32.7 MB is coming from, I'll submit a bugfix patch.

Read More...

I've encountered this same bug/error using the indi_gphoto_ccd driver with my Canon T6, also using a Raspberry Pi as a remote INDI server (although mine is a 3B+.) I'm able to take about 80 exposures before receiving the "Insufficient Memory" error, and then if I restart INDI, I'm able to take another 80 before receiving the error again. I would reproduce it and post my logs, but I'm not sure how much it would help given that you've posted your logs already and they're probably almost identical.

At some point, when I get the time, I'll need to investigate this more closely, as this definitely has been a pain for me (having to stop and restart my sequences every time this happens.) Seems to be a memory leak somewhere in INDI, I would guess, since restarting the INDI server corrects it immediately.

Read More...

I just tried the polar alignment process again with the nightly build and can confirm that the bug is resolved with today's changes. It now reaches the final "correction vector" screen properly, rather than failing after the third image is taken. Thanks for the fix!

j2fzoho.png

Read More...

Awesome! Great response time, by the way. I will run another test tonight using the nightly binary and confirm that the issue is resolved. Thanks a ton!

Read More...