×

INDI Library v1.9.3 Released (11 Nov 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones. Some highlights:

Re:New Polar Alignment Scheme and Features

  • Posts: 554
  • Thank you received: 138
The alignment of the axes used for the correction matters because the correction is calculated in that coordinate system.
I discovered this beta testing the original Celestron Polar Align when I tried adjusting the tripod leg length to centre the PA star. It didn't work, not even close.
10 months 3 weeks ago #66010
The topic has been locked.
  • Posts: 1941
  • Thank you received: 416
The polar alignment error is an angle calculated irrespective of the used coordinate system. The correction vectors are projections in the local azimuth and altitude system but could be any other coordinate system. As long as you make sure that the selected star ends up at the other side of those projected vectors, you’re good. Whether or not the mount is level is irrelevant.
Wouter van Reeven

ASI6200MM and 7 slot 2" filter wheel with a SkyWatcher Esprit 80 ED on a SkyWatcher HEQ5-Pro
ASI1600MM-Pro Cooled and 5 slot 1.25" filter wheel with an 8" TS Ritchey-Chrétien on a SkyWatcher EQ6-R
10 months 2 weeks ago #66016
The topic has been locked.
  • Posts: 117
  • Thank you received: 1
Hy,

Thought I'd share my first experience using the tool in the southern hemisphere (Sydney)

I ran the PA routine using the steps provided for when I don't have a view of the SCP. I set it to slew East 20 degrees at a time. The routine ran and showed the PA error and triangle. I adjusted the Altitude and azimuth until the selected star was in the cross hairs.

I then ran the routine again, selecting roughly the same section of sky as my starting point (just east of the meridian, near the zenith). I expected that the PA error would be pretty small given how close I got to the centre of the bullseye the first time. The result I got was a larger PA error. So I corrected it as before and ran it again. Same thing. The PA error was greater than before.

This seemed very strange so I ran the routine again, but this time I selected an area of the sky that was west of the meridian. The first run gave me an error which I corrected. I ran it a second time, and this time I got a very small error, which is what I expected. I corrected that and decided to end it there.

So from that quick test there appears to be some issue when doing a PA east of the meridian in the southern hemisphere.

Rene
Sky-Watcher AZ-EQ6
Sky-Watcher Esprit 100
Sky-Watcher EvoGuide 50 (guide-scope)
ZWO ASI294MC Pro
ZWO ASI120MM mini (guide cam)
Pegasus PPB
Pegasus Focus Cube v2
10 months 2 weeks ago #66024
The topic has been locked.
  • Posts: 728
  • Thank you received: 336
Rene

Thanks so much for testing!

Can you please say when you downloaded your code, assuming you compiled from source, or when you got your nightly, if you're running ubuntu.

That sounds just like an issue I fixed a few days ago.

Below is a recent 'git log' on my pretty up-to-date system, and the commit marked
Date: Wed Jan 13 01:01:14 2021 -0800 PAA: sample from the center of the image. Update test. minor bugfix.
is the one that fixed the issue I have in mind.

Are you running with that commit?
Hy
commit b90f3ef33d11933fef3bd91b96f75da8b8edd868 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Wed Jan 13 20:58:04 2021 +0300
 
    Set maximum temperature diff to 1 up from 0.1 as many cameras coolers are not usually accurate enough to 0.1. This would allow for first image to kick in a bit faster at least while the cooler stabilizes further
 
commit 05510da0e0517c9979791cba1cf79b237dd5dbe6
Author: Hy Murveit <hy-2@murveit.com>
Date:   Fri Jan 15 17:35:39 2021 +0000
 
    PAA--cleanup test. Update user messaging.
 
commit 53f886c33d992e5de0bfe7f03faa0a19e4c54d3d
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Fri Jan 15 02:56:14 2021 +0300
 
    Send ekoslive events even when not fully connected
 
commit e15ef966fc27acad80f67a08fabf96ef84e79671
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Fri Jan 15 01:34:28 2021 +0300
 
    Use KSNotification on device connection failure
 
commit f87c3ba289a3b7c0f0b472877de01aff50726ef6
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Fri Jan 15 00:57:21 2021 +0300
 
    Use KSNotification::event instead of direct KNotification
 
commit 26c615d944dde77098bb89dcd50319004dbb1434
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Fri Jan 15 00:31:06 2021 +0300
 
    Use more sane defaults for INDI message notification and starting step size for most focusers
 
commit 29cda560e9ce7fe8f5cbd032220a885753a538c7 (paa-v2-fix2)
Author: Jasem Mutlaq <mutlaqja@ikarustech.com>
Date:   Wed Jan 13 20:38:21 2021 +0300
 
    Use Blocking Queued Connection again since deadlock issue temporarily fixed on INDI side
 
commit 0fa3935718e6d6330dbde253f110eeb6d0b538f5
Author: Hy Murveit <hy-2@murveit.com>
Date:   Wed Jan 13 01:01:14 2021 -0800
 
    PAA: sample from the center of the image. Update test. minor bugfix.
 
commit b7ac3bd531a3d59ca36a882808ae342d05cd8199 (origin/paa-v2-fix1, paa-v2-fix1)
Author: Hy Murveit <hy-2@murveit.com>
Date:   Mon Jan 11 11:23:51 2021 -0800
 
    Fix PAA type (purple -> green).
 
commit cbe33115a418d64aa6f79186fb3096117552980e (origin/paa-v2, paa-v2)
Author: Hy Murveit <hy-2@murveit.com>
Date:   Sun Dec 20 22:00:15 2020 -0800
 
    New polar-alignment scheme
 
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser, GSO RC10 w/RSF focuser
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
10 months 2 weeks ago #66026
The topic has been locked.
  • Posts: 117
  • Thank you received: 1
It would have been 2-3 nights ago. I can't remember exactly. Before I run another test I'll make sure to download the latest nightly.

Rene
Sky-Watcher AZ-EQ6
Sky-Watcher Esprit 100
Sky-Watcher EvoGuide 50 (guide-scope)
ZWO ASI294MC Pro
ZWO ASI120MM mini (guide cam)
Pegasus PPB
Pegasus Focus Cube v2
10 months 2 weeks ago #66029
The topic has been locked.
  • Posts: 728
  • Thank you received: 336
Couple things.
1) If you downloaded software and compiled, please let me know the last git commit so I can see what you're running. (I've really got to put some version ID in this).

2) Working great or not, I'd love a log from you, being in the southern hemisphere. Can you make sure that verbose logging is turned on to file for at least alignment, and then upload a log somewhere, e.g. google drive, that I could access?

Thanks,
Hy
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser, GSO RC10 w/RSF focuser
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
10 months 2 weeks ago #66030
The topic has been locked.
  • Posts: 554
  • Thank you received: 138
This is not correct. The axes used for the correction matter. If it didn't and any way of moving the scope to put the target star in the calculaed position was OK you could use Ra and Dec movements to do this. This would obviously have no effect on the polar alignment.
10 months 2 weeks ago #66041
The topic has been locked.
  • Posts: 1941
  • Thank you received: 416

It is correct. The PA routine works anywhere on Earth at any given time. In other words, for any given orientation and rotation of the mount wrt the rotation axis of the Earth. Therefore in a local frame it doesn’t matter at all if the mount is rotated (i.e. not level).

The fact that you cannot use RA and Dec to align the mount is because you are using the fine adjustment knobs to align the RA axis with the rotation axis of the Earth as well as possible. By doing so you compensate for the mount not being level by moving both axes. A remaining rotation over the Dec axis once the PA routine has completed results in a difference in local sidereal time which the mount and Ekos will correct for as soon as you do a star alignment or a plate solve with either Sync or Slew To Target enabled.

If this were not true then the previous implemtentation of the PA routine with the pink line between the location in the FOV where the star currently is and where it should be for perfect PA wouldn’t work as well. Both that pink line and the new lines, that are split up over corrections in azimuth and altitude, are merely projections to help you get the PA done as well as possible. It could have been a swirling line all over the FOV or even outside of it and it still would have worked.

The only thing that matters is to get the star from where it was in the FOV to where it needs to be as well as possible. How you do that is irrelevant. I often move the entire mount left or right if the PA error is large because the fine adjustment knobs cannot move the mount far enough left or right. And still I end up with an as perfect polar alignment as I can get. I know because I check afterwards and the PA error then is close to 1 arc minute or less.
Wouter van Reeven

ASI6200MM and 7 slot 2" filter wheel with a SkyWatcher Esprit 80 ED on a SkyWatcher HEQ5-Pro
ASI1600MM-Pro Cooled and 5 slot 1.25" filter wheel with an 8" TS Ritchey-Chrétien on a SkyWatcher EQ6-R
Last edit: 10 months 2 weeks ago by Wouter van Reeven.
10 months 2 weeks ago #66045
The topic has been locked.
  • Posts: 246
  • Thank you received: 45
That makes no sense Chris. In effect you are saying that if the mount is out of polar alignment, e.g. because a previously polar aligned mount has been set up with a tripod leg not extended properly, then the calculated correction is going to be wrong simply because the mount alt and az do not correspond to terrestrial alt and az. If that were the case the tool would never work at all. Of course it is essential that only the alt and az controls are used and the scope is not moved from its position when the star is selected
But once the polar misalignment is known in alt/az it is fairly trivial to calculate to calculate what movement is needed for a given star in HA/Dec and display where the guide star should be moved. As long as it is moved using the alt and az controls only then polar alignment should be achieved.
It sounds like the same erroneous argument as to why a mount should be level to polar align it.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
10 months 2 weeks ago #66048
The topic has been locked.
  • Posts: 554
  • Thank you received: 138
I'll try yet again.
Yes, you can rotate the mount about any set of coordinates to correct for a polar align error. But the correction indication determined by using a reference star will depend on the position of the star determined in the coordinate system of the correction axes.
There are a number of positions which need to be avoided, for example for the normal Alt Az corrections a star at the zenith will be a poor choice for the azimuth correction because adjusting this axis will not move a star at the zenith. Similarly looking East or West won't work for the elevation correction. The optimum positions are fairly close to the meridian and away from the zenith. Avoid a band running overhead from East to West.

Your tripod leg length error will have the effect of rotating the mount about an axis defined by the other legs and in theory the required corrections could be determined in that coordinate system. You could then get a correction that could be corrected by adjusting tripod legs. That's going to be tricky to determine. Simpler to determine the error in the AltAz system and correct in that system.

Not having the mount level will make a difference but as I said previously the effect will be small for small errors, about one arc minute per degree of error or level.
10 months 2 weeks ago #66068
The topic has been locked.
  • Posts: 246
  • Thank you received: 45
I agree it is bad practice to choose a reference star in that band. But lets say you choose a star near the zenith. And the algorithm determines that a large azimuth adjustment is needed. When the corrected position is converted to HA/Dec it is more or less the same position as the reference star already. So the correction line will be very short or non-existent. And as you say, any error in the calculated position is small. So were you just being contrary for the heck of it ????
I'm actually more concerned about the calculated position being a moving target when far from the pole. Some folks need time to adjust alt/az and by the time they get there they could have moved to the wrong spot. So the position needs to continuously recalculated, if it isn't already.
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
10 months 2 weeks ago #66079
The topic has been locked.
  • Posts: 156
  • Thank you received: 28
I’ve been using it on Astroberry for the last couple of nights. It worked fine (north vision isn’t a problem, so I’m using the “classic” way of pointing towards Polaris).

The only glitch that I’ve found is that it doesn’t likes zoom changes. For example, after the correction triangle is draw over my image if I zoom in before clicking to move the triangle, then as I click it will reverse from left to right, invalidating the procedure.

If I zoom in before the triangle is drawn (before the three measurements finished) it works as expected.

It’s a minor delight to be carried on to a more consistent alignment. Thanks for this improvement!
10 months 2 weeks ago #66094
The topic has been locked.
Time to create page: 1.458 seconds