Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Visualization Tool for planning EAA sessions in Alt-Az mode

  • Please log in to reply
24 replies to this topic

#1 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 16 June 2019 - 05:37 AM

As I understand it, one of the problems we face trying to stack short exposure subframes using scopes on Alt-Az mounts is field rotation and worse tracking accuracy (compared to equatorial mounts).

After some research here in the forums I found out that those problems are correlated to the amount of "apparent motion" of sky objects. For fixed targets (stars and DSOs, whose proper motion is almost imperceptible from earth with amateur tools) this type of motion is mainly caused by earth rotation and therefore depends on the position of the observer on the earth and the current position of the target as projected on the sky dome (East and West have slow apparent motions, North, South and everything near zenith has fast apparent motion). See this graph Astrojedi posted a while ago (https://www.cloudyni...a/#entry7092459) and this paper (https://www.cloudyni...a/#entry7092230) roelb posted.

So I tried to find a software tool that would allow me to plot the apparent motion during the planned observation time window of all objects I was interested in. I figured that with the help of such graphical plots I would be able to decide which targets would have low field rotation and good tracking accuracy with my Alt-Az mount and I could decide on the best viewing/imaging order of selected targets.

Turns out there is no such tool (or at least I was not able to find one). SkySafari does show "Apparent Motion" values under Object Info but there is no way you can plot changes over a defined time window. AstroPlanner can generate nice plots for a lot of parameters but not for apparent motion.

Solution? DIY! Based on examples from astropy (Python Library for Astronomy, https://www.astropy.org) and astroplan (https://astroplan.re...s.io/en/latest/) I wrote my own script! hmm.gif

Here is an example plot for my last EAA session: (referring to 3rd attempt...)
Figure_1.jpg

To use this script you have to insert your location (latitude, longitute, elevation) and your timezone in the script text (only once if you don’t change your location). Then you adjust the start and end value of your observation time window. The target list is accepted as simple list („M51 NGC 2903 …“) and will be automatically resolved by SIMBAD (internet connection required).

Apparent Motion values below 15 arcsec/s seem to yield good enough imaging results, so I try to choose those objects and times that allow me to stay below this threshold.

It has to be said that this will only help you in refining your already existing list of targets, it is not suited as fully automated observation planner. First selection of targets still has to be done in advance (i.e. if target size will be a good fit for the FOV of your current setup etc.).

Thoughts, suggestions?

What is your workflow for selecting targets and planning?

Edited by Lorenz0x7BC, 16 June 2019 - 06:27 AM.

  • ccs_hello, rustynpp, saguaro and 8 others like this

#2 ButterFly

ButterFly

    Mariner 2

  • *****
  • Posts: 292
  • Joined: 07 Sep 2018

Posted 16 June 2019 - 06:34 AM

Very nice!

 

Only a few comments:

 

Color is very helpful as another dimension in a 2D plot.  You can start with green as initial field rotation (or minimum acceptable for absolute scales) and go towards red as it gets higher.  It can help you pick where to stop along a plotted track.

 

Hard-coding is almost always a bad idea.  Try converting your 15 arcsec/s into sensor size, target size as ratio of sensor, pixel size, and acceptable pixel drift at target edge.  You may go to a different camera someday, or some objects may be smaller than others. thereby permitting longer exposures.



#3 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 16 June 2019 - 08:04 AM

Very nice!

 

Only a few comments:

 

Color is very helpful as another dimension in a 2D plot.  You can start with green as initial field rotation (or minimum acceptable for absolute scales) and go towards red as it gets higher.  It can help you pick where to stop along a plotted track.

 

Hard-coding is almost always a bad idea.  Try converting your 15 arcsec/s into sensor size, target size as ratio of sensor, pixel size, and acceptable pixel drift at target edge.  You may go to a different camera someday, or some objects may be smaller than others. thereby permitting longer exposures.

 

Yeah, I was thinking about color as another dimension, but then I needed the colors to differentiate between the various targets... if there was another way to know which line represents which target, then I could do this.

 

The apparent motion threshold is not hard-coded. I just look at the plot in the upper left to see which targets are below those 15 arcsec/s during which periods of time. And then I look at the polar sky plot on the right to check if it is in a good sector (there are some directions on my garden where trees or houses obstruct the view).

 

But you are absolutely right that I could try to calculate this apparent motion threshold! (at the moment I'm estimating it based on the Imaging results). Any ideas for an adequate formula?



#4 RazvanUnderStars

RazvanUnderStars

    Viking 1

  • -----
  • Posts: 680
  • Joined: 15 Jul 2014
  • Loc: Toronto, Canada

Posted 16 June 2019 - 09:26 AM

Nice work, Lorenz!

 

I use Skytools4 for planning (it does have position trace but the most granular time period is a minute). It is not intended for alt-az imaging, though,but I find the features very useful nonetheless for SNR calculation.

 

What is your workflow for selecting targets and planning?



#5 GaryShaw

GaryShaw

    Ranger 4

  • *****
  • Posts: 331
  • Joined: 28 Nov 2017
  • Loc: Boston

Posted 16 June 2019 - 10:01 AM

Nice work, Lorenz!

 

I use Skytools4 for planning (it does have position trace but the most granular time period is a minute). It is not intended for alt-az imaging, though,but I find the features very useful nonetheless for SNR calculation.

Hi

On a tangential note, Greg at Skytools tells me that ST4 Imaging does not lend itself to EAA workflows so he plans to include EAA planning within the ST4 Visual application - but not its initial release. So add 4-6 months to when he releases ‘ST Visual’ and that’s probably when to expect the EAA version. 



#6 RazvanUnderStars

RazvanUnderStars

    Viking 1

  • -----
  • Posts: 680
  • Joined: 15 Jul 2014
  • Loc: Toronto, Canada

Posted 16 June 2019 - 10:51 AM

Not sure what could be extra for EAA, after all it's still a matter of stacking some subs. EAA is a simplified version of astrophotography (we don't stack images with different filters). We'll see. I'm quite happy with the imaging version. But back to the topic of this thread, as a programmer I'm positively impressed by the work Lorenz did. Looking forward to seeing it evolve.

#7 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 16 June 2019 - 02:01 PM

But back to the topic of this thread, as a programmer I'm positively impressed by the work Lorenz did. Looking forward to seeing it evolve.

Thanks, RazvanUnderStars! I am not a professional programmer but enjoyed writing my own little scripts and all kinds of little software tools since the 80ies (back then on Atari ST cool.gif ). BTW: I can post the source if anyone wants to test it, it is only ~200 lines of code. But you need to have Python 3 and the astropy library installed (Windows, Mac and Linux supported). And there is no sanity checking, if you insert values that make no sense, the output will be likewise. smirk.gif



#8 RazvanUnderStars

RazvanUnderStars

    Viking 1

  • -----
  • Posts: 680
  • Joined: 15 Jul 2014
  • Loc: Toronto, Canada

Posted 16 June 2019 - 09:32 PM

Ataris were cool (I learned programming on a Sinclair ZX Spectrum but had a friend who had an Atari ST, nice days they were...). It's up to you, of course, but you could put it on Github and who knows, it might evolve. Or create a web app out of it (with either a web GUI or a web interface with Flask) if you want to host it. 

 

 

Thanks, RazvanUnderStars! I am not a professional programmer but enjoyed writing my own little scripts and all kinds of little software tools since the 80ies (back then on Atari ST cool.gif ). BTW: I can post the source if anyone wants to test it, it is only ~200 lines of code. But you need to have Python 3 and the astropy library installed (Windows, Mac and Linux supported). And there is no sanity checking, if you insert values that make no sense, the output will be likewise. smirk.gif


  • Lorenz0x7BC likes this

#9 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 17 June 2019 - 12:15 AM

....................

What is your workflow for selecting targets and planning?

Very nice Lorenz!

I think the apparent motion/sky location issue is important and unfortunately is never a qualification in all the xhundred rule that non-tracking people want to know....

Thanks for the link to the chart/paper.

 

So I was curious how you arrived at the calculations/ equations to arrive at the data.

 

I was interested to see how the simulation of Stellarium compared, and 3 random spot-checks:

 

NGC 4244  11'54.88" /60s @00:00
=11x60 + 54.88 =714.88 arc"/60s
=11.91 arcseconds/seconds
v. ~13.5 arc"/s
M27   13'53.83"/60s @22:00
=13x60 + 53.83 =833.83arc"/60s
=13.897 arcseconds/seconds
v.~13.75 arc"/s
NGC 4565 13'25.86" /60s @22:00
=13x60 + 25.86 =805.86arc"/60s
=13.431 arcseconds/seconds
v. 25.0 arc"/s

spotcheck.png

From

N48deg12'36"
E16deg21'48"

UTC+2 on 7 June 2019

 

So I know I'm missing something.

Is the apparent motion only calculated for one axis?

Is Stellarium really useless for this type of astrometry?

Is there something interesting about your model?


  • Lorenz0x7BC likes this

#10 ButterFly

ButterFly

    Mariner 2

  • *****
  • Posts: 292
  • Joined: 07 Sep 2018

Posted 17 June 2019 - 04:08 AM


But you are absolutely right that I could try to calculate this apparent motion threshold! (at the moment I'm estimating it based on the Imaging results). Any ideas for an adequate formula?

 

It's not bad at all.  Start by getting the micron size of stars as a function of seeing and focal length to know how big "points" are:

 

e.g.: Matching a CCD Camera to a Telescope by Rob Kantelberg

 

Compare that to the pixel size of the sensor to get the pixel raidus of "points", call that "S".  This same formula also tells you how many pixels 1 arcsecond is.  Then it's just rotation geometry depending on how far the edges to the target is from the center of the sensor in pixels.  Tiny little planetaries near the center can be imaged longer before the edges of the target drifts N pixels than a large reflection nebula like in the Pleiades.  For a big glob, maybe you're fine with N = 3S at the edges to catch more core that evening.


  • Lorenz0x7BC likes this

#11 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 17 June 2019 - 06:52 AM

Very nice Lorenz!

I think the apparent motion/sky location issue is important and unfortunately is never a qualification in all the xhundred rule that non-tracking people want to know....

Thanks for the link to the chart/paper.

 

So I was curious how you arrived at the calculations/ equations to arrive at the data.

 

I was interested to see how the simulation of Stellarium compared, and 3 random spot-checks:

 

NGC 4244  11'54.88" /60s @00:00
=11x60 + 54.88 =714.88 arc"/60s
=11.91 arcseconds/seconds
v. ~13.5 arc"/s
M27   13'53.83"/60s @22:00
=13x60 + 53.83 =833.83arc"/60s
=13.897 arcseconds/seconds
v.~13.75 arc"/s
NGC 4565 13'25.86" /60s @22:00
=13x60 + 25.86 =805.86arc"/60s
=13.431 arcseconds/seconds
v. 25.0 arc"/s

attachicon.gif spotcheck.png

From

N48deg12'36"
E16deg21'48"

UTC+2 on 7 June 2019

 

So I know I'm missing something.

Is the apparent motion only calculated for one axis?

Is Stellarium really useless for this type of astrometry?

Is there something interesting about your model?

Someone is trying to replicate my results… cool, t_image ! :-)

 

So, let's do this…

 

1. My location was not exactly where you guessed it was, I went to a darker site in the suburbs. but for this comparison I will take the same coordinates as you did (Vienna center): in degrees 48.210000, 16.363333, this exact spot has an elevation of 187m (my site was at 402m)

 

2. For the apparent motion calculation I do the same as you did but with a different granularity: you measure the alt/az position delta from one minute to the next and then you divide by 60. In my script I do the same, but directly per second.

 

3. Obviously we use different data sources: my calculations are based on astropy's model (coordinates and SkyCoord classes) and the data for DSOs is retrieved from SIMBAD

 

4. So let's first compare the DSO's coordinates for all data points you chose: (I  did a new calculation with the modified location in astropy and added SkySafari comparison data, please add your Stellarium values at those specified times)

 

* NGC 4244 @2019-06-08 00:00:00
  * astropy @00:00:00: Alt: 47°30'45.1869" Az: 277°53'39.0811"
  * astropy @00:00:01: Alt: 47°30'35.2586" Az: 277°53'48.7924"
  * astropy @00:01:00: Alt: 47°20'49.5991" Az: 278°03'21.116"
  * SkySafari @00:00:00: Alt: 47°30'47.4" Az: 277°53'51.8"
  * SkySafari @00:00:01: Alt: 47°30'37.5" Az: 277°54'01.5"
  * SkySafari @00:01:00: Alt: 47°20'52.1" Az: 278°03'33.8"
* M27 @2019-06-08 22:00:00
  * astropy @22:00:00: Alt: 18°10'30.8976" Az: 75°52'28.3727"
  * astropy @22:00:01: Alt: 18°10'40.618" Az: 75°52'38.7841"
  * astropy @22:01:00: Alt: 18°20'14.3387" Az: 76°02'53.1191"
  * SkySafari @22:00:00: Alt: 18°13'40.6" Az: 75°52'50.8"
  * SkySafari @22:00:01: Alt: 18°13'50.3" Az: 75°53'01.2"
  * SkySafari @22:01:00: Alt: 18°23'22.4" Az: 76°03'15.6"
* NGC 4565 @2019-06-08 22:00:00
  * astropy @22:00:00: Alt: 61°21'09.3916" Az: 227°03'45.8543"
  * astropy @22:00:01: Alt: 61°21'02.053" Az: 227°04'09.5662"
  * astropy @22:01:00: Alt: 61°13'47.696" Az: 227°27'23.972"
  * SkySafari @22:00:00: Alt: 61°21'09.7" Az: 227°03'11.7"
  * SkySafari @22:00:01: Alt: 61°21'02.4" Az: 227°03'35.4"
  * SkySafari @22:01:00: Alt: 61°13'48.2" Az: 227°26'49.6"
 

as you can see above even astropy and SkySafari do produce quite different coordinates although I entered exactly the same values for location, elevation, timezone and time (the discrepancy is most marked for M27: the altitude is more than 3 arcminutes off between those two programs, I have no idea why).

 

next step would be to compare the apparent motion values, will do this later today…



#12 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 17 June 2019 - 11:11 AM

Here's my values.
  * astropy @ 0:00:00 Alt: 47°30'45.1869" Az: 277°53'39.0811"
  * astropy @ 0:00:01 Alt: 47°30'35.2586" Az: 277°53'48.7924"
  * astropy @ 0:01:00 Alt: 47°20'49.5991" Az: 278°03'21.116"
  * SkySafari @ 0:00:00 Alt: 47°30'47.4" Az: 277°53'51.8"
  * SkySafari @ 0:00:01 Alt: 47°30'37.5" Az: 277°54'01.5"
  * SkySafari @ 0:01:00 Alt: 47°20'52.1" Az: 278°03'33.8"
  * Stellarium @ 0:00:00 Alt: 47°30'52.7" Az: 277°53'18.1"
  * Stellarium @ 0:00:01 Alt: 47°30'42.8" Az: 277°53'27.9"
  * Stellarium @ 0:01:00 Alt: 47°20'57.4" Az: 278°03'00.3"
    
* M27 @ 6/7/2019 22:00   Az:
  * astropy @ 22:00:00 Alt: 18°10'30.8976" Az: 75°52'28.3727"
  * astropy @ 22:00:01 Alt: 18°10'40.618" Az: 75°52'38.7841"
  * astropy @ 22:01:00 Alt: 18°20'14.3387" Az: 76°02'53.1191"
  * SkySafari @ 22:00:00 Alt: 18°13'40.6" Az: 75°52'50.8"
  * SkySafari @ 22:00:01 Alt: 18°13'50.3" Az: 75°53'01.2"
  * SkySafari @ 22:01:00 Alt: 18°23'22.4" Az: 76°03'15.6"
  * Stellarium @ 22:00:00 Alt: 18°13'40.6" Az: 75°52'20.7"
  * Stellarium @ 22:00:01 Alt: 18°13'50.5" Az: 75°52'31.1"
  * Stellarium @ 22:01:00 Alt: 18°23'22.6" Az: 76°02'45.4"
    
* NGC 4565 @ 6/7/2019 22:00   Az:
  * astropy @ 22:00:00 Alt: 61°21'09.3916" Az: 227°03'45.8543"
  * astropy @ 22:00:01 Alt: 61°21'02.053" Az: 227°04'09.5662"
  * astropy @ 22:01:00 Alt: 61°13'47.696" Az: 227°27'23.972"
  * SkySafari @ 22:00:00 Alt: 61°21'09.7" Az: 227°03'11.7"
  * SkySafari @ 22:00:01 Alt: 61°21'02.4" Az: 227°03'35.4"
  * SkySafari @ 22:01:00 Alt: 61°13'48.2" Az: 227°26'49.6"
  * Stellarium @ 22:00:00 Alt: 61°21'07.6" Az: 227°02'25.4"
  * Stellarium @ 22:00:01 Alt: 61°21'00.2" Az: 227°02'49.1"
  * Stellarium @ 22:01:00 Alt: 61°13'46.2" Az: 227°26'03.6"


Edited by t_image, 17 June 2019 - 03:18 PM.


#13 HxPI

HxPI

    Surveyor 1

  • -----
  • Posts: 1505
  • Joined: 05 Sep 2013
  • Loc: Virginia Beach, VA

Posted 17 June 2019 - 02:26 PM

Following this with great interest. Thanks for sharing!

 

Ciao,

Mel



#14 nic35

nic35

    Viking 1

  • *****
  • Posts: 896
  • Joined: 08 Sep 2007

Posted 17 June 2019 - 03:00 PM

L-7BC

 

re:  as you can see above even astropy and SkySafari do produce quite different coordinates although I entered exactly the same values for location, elevation, timezone and time (the discrepancy is most marked for M27: the altitude is more than 3 arcminutes off between those two programs, I have no idea why).

 

I wonder if the difference is the way the programs deal with atmospheric refraction, which would be greatest near the horizon, and less so higher up.

 

john


  • Lorenz0x7BC likes this

#15 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 17 June 2019 - 03:22 PM

...Haha,  was having trouble subtracting coordinates. Had the thought of Pythagorean theorem,

and it was Gettysburg University that reminded me I could use it!

http://www3.gettysbu...uals/Ast_sm.pdf

p.20

Here's my results:

angpersec.png


  • Lorenz0x7BC likes this

#16 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 17 June 2019 - 04:15 PM

...Haha, was having trouble subtracting coordinates. Had the thought of Pythagorean theorem,
and it was Gettysburg University that reminded me I could use it!
http://www3.gettysbu...uals/Ast_sm.pdf
p.20
Here's my results:
angpersec.png


t_image, those are the exact values I had calculated too! Funny thing is, I DID have a typo in my code which I discovered today, thanks to your challenge, which basically transformed my formula into the Pythagorean theorem.

But I think that things are more complicated here because the Pythagorean theorem assumes that the distance we want to calculate lies on a flat surface. In the sky we have to take into account that stars and sky objects are projected on a globe.

I tried to implement the formula from this:
https://space.stacke...nge.com/a/22057
If you scroll to the top you will see that the OP asked for calculating the angular separation in alt-az.
In the plot above I used the second formula with the square root and my typo rendered the cosine expression inside nearly ineffective (almost always 1), so therefore like Pythagoras.

But tonight I had success in implementing the first formula (I had to use another math library with better float precision). Tomorrow I will post the updated plot.
  • t_image likes this

#17 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 17 June 2019 - 04:45 PM

So for the life of me I can't figure out what the angle measurement tool in Stellarium is doing.

I will look at the link!

I was thinking the flat v sphere was small due to scale (seconds). Again I wasn't aiming at full granularity because was trying to ascertain graphical measurement tool....


Edited by t_image, 17 June 2019 - 05:11 PM.


#18 Howie1

Howie1

    Mariner 2

  • *****
  • Posts: 292
  • Joined: 22 May 2013

Posted 17 June 2019 - 05:50 PM

Hi Lorenz,

 

Great idea to make a script for this! Congrats.

 

The amount of rotation is one thing, but just how much field rotation is acceptable depends on your camera pixel size and how much the amount of field rotation is pushing light from the object to "cross-over" two or more pixels at whatever focal length / arcsecs/pixel you are operating at, as well as the Alt and Az of the target object. 

 

When I used Alt Az mounts I used an article by Bill Keicher (link to his pdf is down below) to calculate my own personal max exposure times chart for my latitude and camera sensor and tolerance for blur as light spanned multiple pixels. Both the charts and also the formula in Bill's pdf in the link below may help you both in how to present the info in your python script, as well as increase it's effectiveness by including the camera pixel "blur" factor for ones equipment. Be sure to read the last page in Bill's article as that is where he puts the formula's. 

 

https://visns.neocit...Rotation V3.pdf

 

Cheers


  • Lorenz0x7BC likes this

#19 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 18 June 2019 - 04:41 AM

Ok, t_image, I think I finally figured it out!

But I am really not good at mathematics, so if anyone knows better, please chime in.

I think we both had an error in reasoning. I will try to explain: the measurement you did in Stellarium does indeed measure the angular separation between two points in space as projected on the sky globe and I believe it is very much correct. Moreover, when I finally had my code error solved yesterday what I got was a value nearly identical to Stellarium's. The only problem was: it did not change over time and it did not reflect the apparent motion we are looking for! The plot was a straight line for every target. I thought: huh??

But then it occured to me: we are looking at fixed sky objects here! The only (perceptible) movement they do, is because of earth rotation. And earth rotation is uniform! So when we calculate the angular separation between the two points an object is moving from and to (in fixed intervals like every second or every minute), it will always be the same! because earth rotation is also the same in this time interval!

So, in summary:
1. measurements in planetarium software are fine to measure the real angular separation between two points on the projected globe
2. they are not suited to reflect the apparent motion because the used formulas to calculate angular separation do indeed eliminate motion due to projection phenomena
3. to measure the amount of motion due to projection phenomena ("apparent motion" for fixed targets) I think it is actually a good idea to use the Pythagorean theorem with delta-Alt and delta-Az because it will be like coordinates on a globe that are projected on a straight surface, which is exactly what we want to measure
4. fun fact that my code error in the first plot resulted in the correct solution
5. any other ideas or corrections are always welcome!

Edited by Lorenz0x7BC, 18 June 2019 - 05:51 AM.


#20 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 18 June 2019 - 02:49 PM

But then it occured to me: we are looking at fixed sky objects here! The only (perceptible) movement they do, is because of earth rotation. And earth rotation is uniform! So when we calculate the angular separation between the two points an object is moving from and to (in fixed intervals like every second or every minute), it will always be the same! because earth rotation is also the same in this time interval!.....................................................

 

O.K. follow me if you will here. I was thinking you may have seen something I didn't and could explain it to me, but let me share my musing of yesterday.

 

Firstly let me clarify an important distinction because I can see where this may confuse the issue beyond its current complexity.

And I think you start in this post with the term "apparent motion" as it is used in astronomy to differentiate between the real/proper motion of stars in 3-D space. I think you are not using it precisely now.

I read your first post to mean "apparent motion" depended on where different objects are located, not that the same object would change its apparent motion.

I think you are intending to mean this:

 

The link Howie posted that you also referred to in your first post and Hiten's found graph already take into account field rotation effects of a tracking alt/az mount, yes?

[at this point my mind is mush and don't necessarily want to consider how this complexity fits in at the moment]

 

I interpreted your "apparent motion" to mean just not field rotation but apparent motion and the graph to be only the first stage in this calculus.

with the labeling, looks like:

given a time on x-axis,

y-axis plots at a given point:

  • the apparent angular distance change,
  • in relation to time (per second)....
  • of an object,
  • describing its movement across
  • a fixed framed image (not tracked),
  • since Alt/AZ coordinates are relative to fixed points describing[raise scope(alt) and rotate it(az)]
    the observer at a given location.

My real-world go-to for grasping alt/az is Geostationary satellites that stay in a fixed alt/az position in the sky relative to observer and location because they fly the same rotational speed as the Earth's rotation and are thus fixed above a specific location on Earth at the Equator....

 

Given that EAA use is to track stars,

but Alt/Az and "angular distance" normally firstly describes the change from a fixed referent (a camera on a photo tripod),

before considering the interference of the "rotational effect" when tracked by a robotic alt/az mount....

 

 

My first interest,

is the answer to this question:

 

If one sets up a camera/scope fixed,

(not tracking),

pointed in the direction,

and FOV,

so that a particular celestial object goes from one side of the frame to the other,

(and therefore pre=planned and rotated the fixed orientation of the camera so the movement is just on x-axis for ease of calculations),

Say in a time of one minute,

 

From a given same location,

will that same object go across the same amount of pixels (rotated fixed ahead of time so only x-axis movement),

at a faster or slower rate depending on where the SAME object is located in the sky over-the-horizon?????

 

Start with a simple scenario:

observing at the Poles.

Clearly the answer is NO change here. The circular speed of the Earth's rotation is constant, so the rate of change for an object of a particular Right Ascension would not change its rate across the same camera's FOV no matter where it is.........................

 

Now offset the RA/Dec grid and Alt/AZ by changing observation location.....

 

Let's get wild and go to Equator to see if this shakes things up. edit[best example of offset between RA/Dec and Alt/AZ]

Nevermind.

If you've used a GEM mount you know the RA clockdrive of a perfectly polar-aligned mount will track a celestial object at the same rate across the sky. It doesn't speed up or slow down....

edit:but I didn't take into account the translation needed when Alt/Az and RA/Dec grids are offset......

And as you realized, your chart of apparent motion then should be flat lines.....edit[@ Poles]

 

Sorry to distract you on this. As I get you are aiming to calculate the field rotation issue that is affected by where the same target is depending on where it is in the sky.

And as said including the imaging spatial resolution to determine the sensitivity of a system(camera/optics) to notice the field rotation will be a key add.....

 

Here's my additional musing on conceptualizing positioning of objects:

Consider the benefit of the Coordinate systems of astronomy,
measured logically by angles because otherwise how far away do you place the grid to describe 2-D points to refer to sky objects?

--Consider an ancient looking out a window and putting a grid on the window to describe the stars' positions.....

This would be a useless non-stand way to describe positions....

Also the difficulty of the translation to the 3-D world, not dependent on waiting for the objects to pass by that particular window.

 

So then,
additionally the observer is located standing on an approximate sphere (if you believe NASAlol.gif ,just kidding)....

So this also adds to the benefit of a concept of an "outer-sphere" to map celestial objects to [hence measuring distance between coordinates people imagine require spherical trig calculations]...

 

Additionally the Earth rotates, so it is also helpful that the coordinates describe 'fixed' celestial sky objects with a spherical concept.....

 

However from my musings,
the Spherical concept for coordinates (which are really in themselves descriptions of angles edit[not RA) is first and foremost based on the utility of the observer's perspective....IE a coordinate RA/Dec or Alt/Az are measured angles from a given reference point....

 

The outer sphere diagram that many illustrations map to describe the astronomical coordinates is helpful when we talk about closer objects that do orbit the Earth.
Consider an ideal example: an artificial satellite in a circular orbit around the Earth, maintaining the same [height altitude in reference to ground (NADIR-point directly below)].
Here the simple trig math can describe its positional change across the sky because it remains "on/in" an artificial illustrated sphere around the Earth.

But stars/galaxies are in a matter of scale of infinite distance (like "infinity" focus) and fixed in space.

They aren't stuck all in one thin illustrated sphere surrounding the  Earth..... There are in more of a cubic 3-d coordinate system out there.....

However,
[for illustrate let's discount real motion of everything speeding through space and the real motion of the celestial objects]....
Consider if the stars are fixed in a cubic system,
the rotation of the Earth creates from the observer's perspective that they maintain a constant altitude above the Earth (at Nadir) in 'their orbit' since a globe is rotating under them and the momentary Nadir position on Earth does really stay the same distance from a fixed position star...

And although an orbiting satellite in an illustrated thin sphere shell above the Earth is 'close' and the spherical distances cause noticeable changes in perceptible distances over time (slow at horizon, speeds overhead),

stars in a conceptual sphere would be relatively at an infinite distance away so this perceptual change would not be noticeable.
Atmospheric refraction I believe would have more of a perceptible effect.....

edit:still processing all this...

Cheers!


Edited by t_image, 19 June 2019 - 12:16 PM.


#21 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 18 June 2019 - 10:48 PM

t_image, my head is spinning crazy.gif

 

I must apologize for my English and inaccurate use of technical terms. This is surely contributing to the confusion, but things are not so easy for me in a foreign language... sorry for that. A few clarifications: with "projection phenomena" i refer to effects of field rotation. "Apparent motion" is motion of sky objects as seen on the sky for a standing observer, it is composed of several factors: proper motion of an object (near zero for DSOs), earth rotation, field rotation effects, ...

 

I have a proposal, let's go back to your original question:

 

I was interested to see how the simulation of Stellarium compared, and 3 random spot-checks:

 

NGC 4244  11'54.88" /60s @00:00
=11x60 + 54.88 =714.88 arc"/60s
=11.91 arcseconds/seconds
v. ~13.5 arc"/s
M27   13'53.83"/60s @22:00
=13x60 + 53.83 =833.83arc"/60s
=13.897 arcseconds/seconds
v.~13.75 arc"/s
NGC 4565 13'25.86" /60s @22:00
=13x60 + 25.86 =805.86arc"/60s
=13.431 arcseconds/seconds
v. 25.0 arc"/s

attachicon.gif spotcheck.png

From

N48deg12'36"
E16deg21'48"

UTC+2 on 7 June 2019

 

So I know I'm missing something.

Is the apparent motion only calculated for one axis?

Is Stellarium really useless for this type of astrometry?

Is there something interesting about your model?

I think the explanation is really simple:

 

If you are measuring the position difference in Stellarium like this, you are excluding the field rotation.

If you measure the position after 1 minute and then divide this distance by 60, you are assuming that the path from one point to another is a perfect straight line.

The image you posted with NGC 4565 two times on it is defacto de-rotated.

 

But due to field rotation the path our object is taking (as seen from a point on earth's surface that is not a pole) is longer and curved and the object itself being rotated. In astropy's model this is reflected in different deltas for coordinates transformed to Alt-Az depending on the target's current position in the sky. (SkySafari has it too and calls it ... "Apparent Motion" for Azimuth and Altitude)


Edited by Lorenz0x7BC, 19 June 2019 - 06:45 AM.


#22 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 18 June 2019 - 11:37 PM

for the sake of completeness:

 

the same plot as above (first post), this time as seen from north pole and from the equator

 

Apparent Motion := √(ΔAlt² + ΔAz²)

 

Figure_2.jpg

 

Figure_3.jpg


Edited by Lorenz0x7BC, 19 June 2019 - 06:48 AM.

  • t_image likes this

#23 t_image

t_image

    Gemini

  • -----
  • Posts: 3298
  • Joined: 22 Jul 2015

Posted 19 June 2019 - 12:35 PM

I tried to edit my misunderstanding in previous post.

However this whole conversation has been most valuable for my use cases.

So I'm still working things out in my brain but I have been operating with misunderstandings of the spatial relations of the two coordinate systems and how they interface.

Alt/AZ is easy to access from the observer as all that is needed is a compass and angle gauge to measure the coordinates for a seen object, but changes every moment and is not location/time agnostic.

RA/Dec (of date)calibrates the offset with Equinox event but is pretty much time/date agnostic, is location agnostic, is not affected by perceived distortions,

and is the one to use in astrometry measurements.

Interestingly, the field rotation and perceptible distortion based on the SAME object but located in different positions in the sky can be anticipated by how the two grids (Alt/AZ) and (RA/Dec) intersect.....

Such may seem obvious as observing location changes things change and place in sky changes things, but grasping that the conceptualization of such can be modeled just by the interaction between the two coordinate systems is to me very helpful.....waytogo.gif


Edited by t_image, 19 June 2019 - 12:53 PM.

  • Lorenz0x7BC likes this

#24 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 19 June 2019 - 03:01 PM

waytogo.gif



#25 Lorenz0x7BC

Lorenz0x7BC

    Vostok 1

  • -----
  • topic starter
  • Posts: 147
  • Joined: 03 Apr 2019
  • Loc: Vienna Austria Europe

Posted 20 June 2019 - 04:11 AM

just one more because I find its results very interesting

(currently looking for possible targets)

 

Figure_9.jpg

 

NGC 3938 (green line) and NGC 3893 (purple line) start at nearly identical altitudes (@20:00) but because of a few degrees difference in azimuth the resulting apparent motion is quite different 




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics