Hello all,
I’m fairly new to the world of astronomy and AP. I’ve managed to get SGP up and running, controlling my CEM60 mount, QHY23 camera and its filter wheel, working with plate solvers – basically enough of the basics to have SGP run a session center on targets and grab the frames I need. But, I am scratching my head about who uses what epoch. It seems most everything uses J2000. If AstroPlanner or I manually set a target’s coordinates in J2000, who, if anyone, makes the conversion to JNOW so the scope points to the right place (at my image scale the difference between J2000 and J2015.1 for Archernar, a random star, came out to about 363 pixels – that is a big position error). I guess the simple question is what Epoch do I use for target coordinates? If JNOW, I understand how the scope ends up pointing to the right piece of the sky. If J2000, that seems to match what Astroplanner wants to output, and what all (most) catalogues use, but don’t I end up looking at the wrong place? Indeed, what epoch are plate solver coordinates in? I’ve tried searching manuals for SGP, CEM60, PinPoint, AstroPlanner, etc and mostly epoch, J2000, JNow, etc go either completely unmentioned or have a few words explaining what they mean but not which to use where. I hope someone can give me a better understanding. After all (RA,DEC) are a totally incomplete specification, (RA,DEC,Time) is what is needed, but most software and equipment seem to use an implied Time without actually telling you what Time is being used. So, I’m confused.
Richard
Hi Richard,
Yeah, it can be confusing! Does the CEM60 have a setting allowing you to switch between J2000 and JNOW?
In general, I find it easiest to leave everything J2000 because most solvers (Astrometry, Pinpoint, etc) use J2000, and the Framing and Mosaic Wizard is also J2000. The gotcha in my case is that my mount only supports JNOW. What happens in this case is that the mount is not technically pointing to where it thinks it is, and that’s ok as long as I have only 1 piece of software (SGP) talking to the mount, or certain everything else is also J2000.
The point you make about RA/DEC/Time is right on - the convention we use (RA/DEC alone) is the problem. Imagine if every computer system in the world used time without any notion of time zone! It’s a similar problem. Ideally, RA/DEC/Time or Epoch would be expected as and it would be up to each piece of software to convert as needed.
Unfortunately, this is not likely to be done anytime soon. AP has made it clear that they have no intention of supporting J2000 as the world would certainly fall into chaos, while other mounts (Celestron, et al) have the option to switch and it’s no big deal. In fairness to AP, they make the valid point that the controlling software should be making the call, as it knows the epoch and intentions of the user, so should handle translations when sending commands to the mount. If your mount supports both, I’d set it to J2000, and have everything else set to J2000 since it is the lowest common denominator. If you don’t know what a piece of software is using, you’d likely have to ask the author.
I think ASCOM has some features built in to do epoch translations. I believe Jared/Ken are looking into this, but I imagine the issue isn’t the math as much as how/where to handle translations.
Funny I was just about to ask a question about this myself. In my case it’s the SkyX which uses Topocentric. My understaning is that J2000 and JNow refer to adjustments in the coordinates taking precession into account based on the year 2000 vs now. What exactly is Topocentric referring to in this regard?
Yup, that’s what I thought — the world is confused not me 
Well, I’m still confused. But I think maybe I now see how things are better than I feared. Please let me know if I’ve got this right.
The CEM60 does not have any setting for epoch either documented or in its HC setting menu. It is probably fair to assume that its internal catalog is J2000. It is probably also fair to
assume that it does not precess its target coordinates to JNOW before using them. I think the bit I was missing, is that when I perform a polar alignment (I’m currently using Alignmaster),
what I am doing is aligning the scope to a J2000 sky model. If that is true, then I can just test this for myself (assuming I ever get to see the stars again!) by just inputting the
coordinates of say Capella into the HC in J2000 and seeing if it ends up dead center. Somehow I have been carrying around the notion that I now believe may be false that
the mount models the sky as it exists now — I’m beginning to suspect that is just wrong and it is seeing the world through J2000 eyes.
So, this that is correct, then if I stick with J2000 for everything and input everything in J2000 then everything just works — sort of. What is not quite right is when the mount’s HC says something is visible it will not always be right because it is presumably computing visibility in J2000 which is not always correct for J2015.1. Similarly when AstroPlanner translates RA/DEC for me into Alt/Az, it is probably not precessing the RA/DEC to JNOW before doing the computation (it does not document what it does) so these are not quite right
But now my thesis does not seem to cover your mount. So, how does a JNOW only mount work? I suppose it has an internal J2000 catalogue (assuming it has a catalog) and precesses coordinates as needed to JNOW before use. It then expects JNOW target coordinates and builds a JNOW sky model. I see you predicament. You can easily translate your plan coordinates into JNOW (at least AstroPlanner does that), but PinPoint, for example, does not seem to give you a choice of epochs so when you hit center now it brings you off target —- very precisely. Yuck! I gotta say, AP is probably right — the mount should live in a JNOW world but it seems to be fighting against a whole lot of inertia from the backend world.
Sure would be nice if there was a group with the power to influence everyone to adopt (RA,DEC,Time) universally. Then there would never be any doubt and every device and piece of SW could translate its input into whatever epoch made the most sense for it. Also, the looming (well, not for me, I’ll be dead) J2050 switch will be a non issue. Everything will just work and J2000 and J2050 can coexist in harmony.
Thanks for your help,
Richard
We plan on adding automatic epoch translation in a future release of SGP. Either 2.5 or a maintenance release to 2.4 which should help to alleviate some of the issues mentioned here.
Thanks,
Jared
That would be so appreicated!
Can you tell me how Topocentric fits into all this?
[quote=“Martyk22, post:6, topic:989”]
Can you tell me how Topocentric fits into all this?
[/quote] Strictly it seems to be the Altitude/Azimuth coordinates for your location, but what may be meant for an equatorial mount is equatorial coordinates for now at your location.
Chris
I think it would help to clarify the terminology here. The main problem isn’t epoch - it is equinox.
Epoch is somewhat independent of equinox and includes the impact of proper motion - which over 15 years is non-trivial even though most stars are slow. So plate solvers need to know the date of the image - so they can use the correct epoch to know the exact relative location of the stars.
I think any plate solver including the one I wrote would use the J2000 equinox to do all that stuff - so that the locations of the stars, including proper motion, are specified in the J2000 equinox - which amounts to a specific RA/Dec coordinate system.
So the plate solve inherently generates coordinates for the center of the image in the J2000 equinox coordinate system - but in the Epoch of the image.
At that point you can convert the J2000 equinox to another equinox - and the two main ones are J2000 or JNow.
The main shift that causes a problem is just precession of the equinox, but there is also a small contribution from nutation.
But at the arc-second level there is also aberration due to the velocity of the observer - and parallax for nearby objects. To get to that level you need to specify whether the observer is on the surface of the earth, center of the earth, or center of the solar system.
So the main problem here is that plate solvers tend to output in the J2000 equinox coordinate system - while mounts use the JNow equinox because they have to or else polar alignment would be off. In addition they may or may not include nutation and other things. So you would really need to know everything about what the mount expects when it receives coordinates - so you can properly prepare them for the handoff to the mount.
Frank
Jarad,
That sounds like a very good addition.
Frank,
Sorry, my ignorance may have introduced some further confusion here. Clearly I have a lot to learn as I confounded epoch and equinox and while I have a surface level only understanding of precession and nutation, I have not taken the time to dig into celestial mechanics yet. It is becoming clear that I should fix that. Any pointers to a good entry level resource?
So, from what you wrote, it seems like my initial thought that mounts live in JNow was correct so I’m back to being very confused. One simple question (which I can answer myself if I ever see the stars again): if I carefully polar align my CEM60 mount, what coordinates, J2000 or JNow, do I feed it to have the scope centered on the object in question? Or, lets take the mount’s accuracy and sky model out. I have SGP set up with a plate solver and camera. I believe from all I’ve gathered that Plate Solvers, lets take PinPoint which I now trying out, live in J2000 and spit out J2000 RA/DEC. So, if I tell SGP my target is the J2000 RA/DEC of say the Bubble Nebula and hit center scope, how does it come to pass (or does it) that the scope ends up pointing at the exact (JNow) center of my target?
Sorry if my question is loaded with misconceptions, I try to get my head around when to use JNow and when to use J2000 and why.
Richard
Hi-
I didn’t mean to direct anything at anyone specifically. This issue comes up often as an Epoch issue - and I brought the same thing up as an Epoch issue here some time ago - so I made the same mistake. But when it comes to plate solvers and mounts and all these things I think it helps to use the right terminology. Sources I like are the Meeus books, and the explanatory supplement to the astronomical almanac.
If a mount just uses star coordinates from the J2000 epoch then it really is using J2000 epoch if it doesn’t include proper motion - but it is using JNow equinox. The equations for precession with nutation are not that bad, so I expect mounts and planetarium programs use them. To get the moon right they would need to use topocentric observation coordinates - but whether they use them for all solar system objects I don’t know. And then the final thing is aberration and I assume TheSky includes that, on the arc-second scale.
The mount can use whatever it wants - and the application can use whatever it wants. But when coordinates are exchanged - the donor and receiver need to agree on what kind of coordinates are being provided.
Frank
Frank,
I looked up Meeus on Amazon and first came upon “Astronomical Algorithms” by Meeus, the reviews suggested I read “Textbook on Spherical Astronomy” by W.M. Smart first to gain a solid theoretical underpinning. Does this make sense? It is a bit pricey, but the comments suggest that it is a classic and must have gotten things right in content and exposition to have lasted more than 75 years in essentially the same form.
Re your last point — that is the source of my confusion. I know the donor and receiver must agree on how to interpret the coordinates, I’m just having a hard time figuring out what each one gives or gets — documenting that does not seem to be a priority. My mount’s manual, for example, is silent on how it interprets RA/DEC. I guess I’ll just figure it out by myself like I’m sure all my predecessors in the hobby must have
Thanks for your efforts to shed a bit of light on this whole area!
Richard
Frank – thanks for the info in your posts! Definitely valuable.
Rich – I’m no expert and what I’m saying here is likely accurate enough for non-scientific work – but in short, I don’t think it matters what your mount uses**, it matters that the software is consistent. If I look at an object in Sky Safari and it’s giving me the JNOW RA/DEC, I’m going to have a problem if I try to center on that object if my plate solver uses J2000.
** clarifying the above, while ideally the mount should be sent JNOW and not J2000 if it only expects JNOW, if you are only using SGPro pointing will be accurate. This is because the mount will be corrected via plate solve. Suppose you set up the mount and it has a perfect model, you center on Capella and there it is, dead center. If you solve and sync from SGPro, it will take an image, and solve it to J2000, and sync the mount to the J2000 coordinates. The mount is told it is looking somewhere slightly off from where it thought it was, but that’s ok. As long as I’m feeding it J2000 coordinates consistently and not mixing them, the pointing will be accurate (enough).
Where you run into trouble with this approach is if you start using the hand controller or other software that is talking to the mount using JNOW.
Hi-
Yes things will definitely work well if you tell SGP to center on an object based on an image of the object. But if you use Ra/Dec you will need to give it the correct equinox when you enter the values in sgp. I guess it wants J2000 since that is what the plate solve used.
And even if you do a sync to the mount - it will all be fairly ok even if the mount is given j2000 and the mount wants JNow. It isn’t ideal - but it will force the mount to use J2000 locally - and it should work ok.
The problem comes when, like me, you also have TheSky hooked up and it suddenly sees the mount switch from JNow to J2000 after the sync. It will cause the cursor to be offset because TheSky thinks the mount is providing JNow coordinates.
The main thing is - I think the SGP developers know this is happening and have a plan to fix it in a subsequent release.
If you look around the web you will see many people having related problems with totally different mounts and software. Hopefully everything will come together. As a start, the mounts should state clearly what coordinate system they expect in a sync. Celestron says it wants JNow in a sync and I think most mounts do - but I guess some don’t even say.
If someone writes a book and lists objects and their coordinates, it would make no sense to use “JNow” because it would only apply to when the book was written. So I think most coordinates passed around for objects in the sky are J2000 equinox.
Frank
Thanks Frank,
It is becoming clearer. I just was not expecting the astronomy world to have not worked this stuff out by now so I assumed I was just missing some well known critical piece of the puzzle. Turns out the piece of the puzzle I was missing is that it is not worked out, not terribly well documented and you have to just figure out all the combinations of equipment you have and find a working solution. Clearly this is doable judging by all the fantastic images the AP community is turning out! I will proceed with the assumption that everything in my world wants J2000 equinox, set any pieces of my world where equinox can be specified to J2000 and go about my business – if something does not work as expected, i’ll just, as they say, deal with it
Thanks again for taking the time to teach
Richard
This would be a big big help to those of us who use Paramounts or TheSkyX since TheSkyX works with Topocentric instead of J2000 that the framing and mosaic wizard uses.
Another BIG help would be doing differential slews instead of using syncs as an option since syncs from recentering pollute the pointing model within TheSkyX. Some other automation software has that as an option for Paramount users. But that is another topic.
Hi Jared
I’m a relatively new user and loving your program!
Did you ever implement this and if so is it transparent as I cannot find the option to select an epoch.
Not a huge problem as I can set my other software and mount to J2000.
Cheers
Gary
Yes, been in SGP for a while and it is completely transparent as the mount tells us what Epoch it’s using.
Thanks,
Jared
Thanks Jared
I’ve set all my other software to J2000, out testing today and should have my first sequence running tomorrow night. Then 4 clear nights in a Bortle 1 sky a few hours from home. Ticking off my checklist so I have as little troubleshooting to do as possible.
Love your work, SGP is amazing! 
Best regards & thanks again; Gary