Polar Alignment without Polaris (workflow)

Discussions on extending SharpCap using the built in Python scripting functionality
fly_n
Posts: 26
Joined: Wed Oct 02, 2019 7:54 pm

Re: Polar Alignment without Polaris (workflow)

Post by fly_n »

Hello Jean-Francois,
it works... almost.

The error with the starting location was due to the 58° AZ being in another quadrant (NE opposed to SE).
Based on the quadrant I needed to introduce a correction factor, otherwise the math did not work out (sin, cos, tan).

This is solved now, also with the "number of pictures" instead of "increment angle".

What is semi broken is the End AZ.
It runs to an end, that is at the correct End AZ, if you follow a parallel to the HA line down to the horizon.
The actual End AZ is somewhat left or right, depending on the Altitude and the angle between DEC and ALT.
So perfect only for End AZ = 180°

The math somehow does not easily convert an known DEC, AZ and LAT to either HA & DEC or ALT and AZ.
I think I will need to additionally add the Euler coordinates and work with rotation matrices.

Kind regards,
Norman
Attachments
no_polaris_no_problem_v031.zip
(12.26 KiB) Downloaded 10 times
Last edited by fly_n on Thu Jan 07, 2021 9:44 pm, edited 1 time in total.
Jean-Francois
Posts: 82
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: Polar Alignment without Polaris (workflow)

Post by Jean-Francois »

Hello Norman and Robin,

I write in the past 2 hours a long message during my tests of the script.
I write periodically some words or sentences, so that I was still login.

But, when I press the button "Submit", the forum page change to the login page !
So my message is lost … I have now really no motivation to write it again.


Jean-Francois
User avatar
admin
Site Admin
Posts: 5725
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Polar Alignment without Polaris (workflow)

Post by admin »

Hi,

sorry to hear about that - it's probably too late now, but I have sometimes found that pressing 'back' in the browser does get back your message when I've seen that problem on other forums.

Robin
fly_n
Posts: 26
Joined: Wed Oct 02, 2019 7:54 pm

Re: Polar Alignment without Polaris (workflow)

Post by fly_n »

Hello Jean-Francois,

sorry to hear you lost your work.
Maybe I can lighten your spirits with the following results of today.
The End_AZ problem is solved. Instead of solving the astronomy, I iterate to the solution by trying different Alt values until I have the fitting one.
What are computers there for anyways.
In my trials the slewing finds the correct beginning and the correct end.
I'll be adding slewing on the west sometime.

I thought about your observation with the precession and Epoch. As far as I know the mount positions itself to JNOW.
The plate solving in PlateSolve2 as well as ASTAP reports back in J2000. So yes, as it stood an error was being made, trying to correct the polar axis into the J2000 optimum.
I used SkySimulator to generate a set of data. In the RScript I turned the refraction off to see just this error.
The error I found was close to 10 arcmin.

So the R Script now treats the input as J2000 and converts it to JNOW based on the JD which is stored in the transfer file. I knew it would come in handy some time.

With refraction off and correcting to JNOW, I get an reported error of 3 arcsec (!).

I'll clean up the scripts and upload them tomorrow. Maybe I'll add a button to turn refraction off, to make testing easier.

Kind regards, Norman
fly_n
Posts: 26
Joined: Wed Oct 02, 2019 7:54 pm

Re: Polar Alignment without Polaris (workflow)

Post by fly_n »

Hello Jean-Francois,
I've updated the links with the current version, which seems to be working.

Please let me know what you think.

I'll also implement the JNOW correction for the bright star function, which also currently slews to J2000.
(which I found acceptable a few days ago, but now would like to update)

Kind regards,
Norman
Jean-Francois
Posts: 82
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: Polar Alignment without Polaris (workflow)

Post by Jean-Francois »

Hello Norman,

Thank you for the different scripts.
I test now the v035. It works good ... as long as I set the correct parameters.

For example, I change to default_sleep = 1 (sec) ... it was too short and a lot of image plate solving were not fitting.
I change now to 7 sec and ASTAP found I guess above 95 % of the time.

One point stays ... in which direction do you calculate the FOV ? (horizontal, vertical or diagonal ?)

Concerning the starting position ... try this:
Starting ALT = 10, Starting AZ = 30 and AZ end = 175.
You do some meridian flip check ... that is good, while any meridian flip has to be avoid ... the alignment principle needs a constant DEC without any movement in DEC.
DEC movement ... do you know that some mounts slew to a position with lower RA and DEC and then proceed with a small +RA and +DEC ?
In the ASCOM telescope set of commands ... does exist a single slew command ? means only slew in RA without any movement in DEC.

Concerning the air refraction and JNOW/J2000 ... I test several settings. It is necessary to change in the ASCOM telescope simulator setting page the wanted status.
=> "not" Refraction on, Equatorial system = Local (=JNOW), and in the script to set "refraction off" ... only with these settings it was possible to calculate some arcsec alignment error.

In the case that a mount works only with activated air refraction ... then I guess it will be not possible to use the script completely automatic.
Alternative could be to have a manual RA step by step (with the hand controller) sequence.


Regards,
Jean-Francois
fly_n
Posts: 26
Joined: Wed Oct 02, 2019 7:54 pm

Re: Polar Alignment without Polaris (workflow)

Post by fly_n »

Hello Jean-Francois,

yes I forgot to reset the default_sleep to 15s that I had in there originally. For testing I reduce it, otherwise it takes too long.

ASTAP is looking at the height of the images.
FOV = CCD_chip_height * (3438 arcmin) / focal_length
So in my case with AS120MM and 240mm guide scope it works out to:
FOV = 3.6mm * 3438 arcmin / 240mm = 52 arcmin

I did not know that some mounts come in low and then reduce the slack with RA+ and DEC+ movements at the end. Quite ingenious, unless you want to leave the DEC unchanged.
No, in ASCOM there is just the SlewToAltAz, SlewToCoordinates and SlewToTarget, which both take a RA and DEC value.
In the script I go through the SharpCap.Mounts.SelectedMount.SlewTo so I do not need to specify the ASCOM driver.

Do you know of any mounts that apply a refraction correction to the GoTo input they receive?
For the mount to correctly do that, it would need to know the barometric pressure and outside temperature.
Although not really expensive to provide, I haven't seen it implemented in a consumer mount.

As far as I understand the TeenAstro I'm using, it corrects for refraction only in the tracking speed, but not the GoTo.

To fully compensate in the script would not be easy, as you'd need the same set of data the mount is using plus also know how they implemented it.
To be close enough would seem do-able.
But let's see, if we can find someone with that specific problem, first.
Manually moving the RA would be fine, too. The points do not need to be equidistant.

Lastly, the Bright Star function now centers the J2000 objects correctly, too.
I found an ASCOM function to do the work for me.

Kind regards, Norman

#################################
clr.AddReference("ASCOM.Astrometry")
from ASCOM.Astrometry import *

# Connect ASCOM Transform
v = Transform.Transform()

# push coordinates to ASCOM
v.SetJ2000(RA_J2000,DEC_J2000)

# transform coordinates in ASCOM
RA_JNOW = v.RAApparent
DEC_JNOW = v.DECApparent

SharpCap.Mounts.SelectedMount.SlewTo(RA_JNOW, DEC_JNOW)
Jean-Francois
Posts: 82
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: Polar Alignment without Polaris (workflow)

Post by Jean-Francois »

Hello Norman,

OK for ASTAP field of view. Yes, it works better with the field in vertical direction.

For the mount slew ... I check it with my new mount ... the mount moves a little bit before the point and then perform the last movement in +RA and +DEC. If the new position is already in +RA or +DEC, then no additional + movement is performed.

I do this evening more experiment in my kitchen. I'm waiting for clear sky, but the last time was last year (OK, 9 days ago).

I install the new script on my EAGLE2 computer. I modify all the path and I use the real mount/movement with the (camera) Sky-Simulator.

First
- SynScan software running
Than
- Sky-Simulator software running
- SharpCap software running
- Prism software running
all 3 software running with the telescope driver SynScan App Driver.

- with SynScan software: find home and 1-star alignment on Hamal star
- follow the movement of the telescope in Prism star chart
- verify that the star field is changing in the Sky-Simulator and SharpCap software

Star coordinates of Hamal (@ 22:05):
SynScan: RA= 2h 08m 21s DEC= +23° 33' 42 "
Sky-Simulator: RA= 2:08 21.3 DEC= +23d 33 41
SharpCap Scope: RA= 02:08:21 DEC= 23:33:41N
Prism: RA= 02h07m10.4s DEC= +23°27'45" (2000), RA= 02h08m22.5s DEC= +23°34'15" (apparent)
and in Simbad: RA= 02 07 10.4057 DEC= +23 27 44.7032 (J2000)

Star coordinates of Capella (near zenith @ 22:15):
SynScan: RA= 5h 18m 15s DEC= +46° 01' 17 "
Sky-Simulator: RA= 5:18 14.8 DEC= +46d 01 17
SharpCap Scope: RA= 05:18:15 DEC= 46:01:16N
Prism: RA= 05h16m41.4s DEC= +45°59'53" (2000), RA= 05h18m12.3s DEC= +46°01'12.8" (apparent)
and in Simbad: RA= 05 16 41.3587 DEC= +45 59 52.7693 (J2000)

Also ... all the software (except Prism when explicitly in J2000) show the coordinate in "apparent" coordinates, mean JNOW ... but with or without air refraction.

Mount with refraction calculation ... I see in the ASCOM driver the capability to switch on/off the air refraction.
In Prism, it is possible to set the behavior of Prism regarding the ASCOM v1 capability of the air refraction in the mount or in Prism.
It is not necessary in the mount itself, it is the driver commanding the mount that can calculate the air refraction before commanding the mount.
It could be possible to set somewhere the air pressure and temperature.

I use your v035 script ... it works but in the opposite as with the ASCOM.Simulator.Telescope driver.
With the starting values 15, 80, 175 ... it moves in the other side of the meridian.
If I set the full east with AZ = 90, then the script command the telescope to the west.
With the simulator, the movement was from the horizon up to the meridian (from the E or the W).
With the real telescope (SynScan driver) the movement starts near the meridian and end at the horizon.
I prefer that the final position is near the meridian, it helps for the next step of the alignment.

Do you test with your mount ?

I perform several time the polar alignment with the script, at the end the AZ and ALT correction was each time = 0.0.
That sounds good, but with the telescope simulator I have each time a correction of several arcsec. Something is here not correct.


Regards,
Jean-Francois
fly_n
Posts: 26
Joined: Wed Oct 02, 2019 7:54 pm

Re: Polar Alignment without Polaris (workflow)

Post by fly_n »

Hello Jean-Francois,

concerning the refraction I see two possibilities.
One could be to query the mount if it accounts for refraction and plan the GoTo accordingly. This seems technically feasible, as there is an ASCOM property "DoesRefraction" and through SharpCap one could figure out which mount to ask with "SharpCap.Mounts.SelectedMount.Name", which reveals the ASCOM name.
Second option could be to run a best fit on the data, to see if a refraction modifier gives a better fit or not.
This is what initially drove me to implement a refraction correction. I noticed the closer I got to the horizon the larger the error was vs. the average of all data.

My preference would be not to modify GoTo data in the hopes of compensating something the mount is doing.
Something I do not see in ASCOM is an option to turn the refraction handling of the mount on and off, which would be practical in this case.

In my tests my mount (G11 with TeenAstro) was moving as expected and in line with what the telescope simulator was predicting.
I don't know why your mount would move opposite, but not in the simulator. You can look at the Log-File that was generated on that day.
It contains the RA and DEC values the mount was commanded to. In Stellarium, you could double check that those would be correct or not.

Let me know, if you find anything odd in the Log-File.

Kind regards, Norman
Jean-Francois
Posts: 82
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: Polar Alignment without Polaris (workflow)

Post by Jean-Francois »

Hello Norman,

I test the script this evening with the following driver: "Telescope Simulator for .NET" and with the EQ8-R mount connected with SynScan and EQMOD.

The telescope simulator works good (moves on one side and perform the wanted movement).

Both connection with the mount are not OK.
The script moves the mount to 1 star in the east and 2 stars in the west (after a meridian flip).

Here the 3 log files.
log_20210112.zip
(3.17 KiB) Downloaded 7 times

It is visible that the SIDEREALTIME is calculated only with the telescope simulator, both other is = 0.00000.

Note the following start values:
15, 80, 175: "Telescope Simulator for .NET"
15, 80, 175: SynScan
0, 90 ,175: EQMOD


Regards,
Jean-Francois
Post Reply