Since receiving my AP1100 mount, I’ve had a lot of great success except for one problem area: the AP mount only supports JNOW (well, local apparent, but for pointing I think JNOW is close enough).
My one main frustration has been dealing with this. Framing & Mosaic Wizard does J2000 from what I recall, the AP mount will only do JNOW, Pinpoint only J2000, and Astrometry will do either. I’m looking into Pinpoint for APCC and other reasons, and when I asked Bob Denny about this in the DC3 forum, he indicated for his setup, he uses J2000 across the board and only at the last minute when slewing the mount is the conversion to JNOW done (if needed).
Any chance to see this support in SGP? Not sure of the best way to handle this, except for an option in the telescope setup like ‘Translate coords to JNOW when slewing’; unfortunately, this seems to be one of those, “well, the other program should really handle that…” situations!
If you fully operate your mount with SGP it should not be an issue, the mount itself doesn’t know anything about epoch just the HC, but if you skip the HC you should be fine.
I am not familiar with AP software but AFAIK AP mounts doesn’t build a sky model just one point sync (similar to TAK Temma) so it should not be an issue, just sync the mount with plate solve and you are good to go, of course if use your HC to drive the mount the objects will be off, but you could skip the HC with SGP frame and focus or with skysafari or any other planeratium.
I have 2 mounts right now an Atlas and an EM200 both mounts operate without HC and they are driven exclusively by SGP using reference images or frame and mosaic wizard. Since all the components behind SGP speak the same EPOCH everything works fine.
Thanks Jose – thank makes sense. I must’ve had something configured wrong (perhaps astrometry.net set to JNOW?) because when I used Framing and Mosaic Wizard to set up a single frame of an object, it was off-center by what seemed to be the epoch difference.
I’ll have to play around with it, and appreciate the pointers!
I believe that the newly released APCC (at least the Pro version) will build a sky model and it will depend on PinPoint.
Even though I think your suggested strategy will still work if you are mobile and don’t build a sky model for each outing, I think the OP’s feature request is useful.
Accepted in 2.4.X. The “common” epoch in SGPro will move to JNow. All entries and displays within SGPro will be JNow. If your mount does not speak JNow, we will handle this for you (you don’t need to be concerned with it).
To be a little more transparent… this will likely be a 2 step process.
The official epoch of SGPro will be J2000 (in all the UI… all text, all entry fields, will all remain J2000, just like now). The big difference here is that we will actually consider if your mount does not like to talk J2000. If it wan’s to talk in JNow coordinates, we will handle that for you. This will be completed shortly and should resolve a lot of these issues for you… even if you are not fond of J2000, at least your movements and interactions with the MFW will be correct.
Move the official epoch of SGPro to JNow. All display and entry will be JNow (probably more appropriate). This is more complex and will introduce more risk by virtue of the sheer number of changes and will likely be released in 2.5.
I am all for handling the equinox better - as it is preventing me from doing any plate solves, since a sync with my celestron mount would introduce an undesirable offset. But I do not think (2) is a good idea. Coordinates of objects are usually handed around using J2000 equinox. This is where Epoch and Equinox have an important distinction. A comet’s location has an epoch associated with it - since it is moving across the sky. But you can define its coordinates using any equinox you want - and it is usually J2000 - even though it is moving.
If you want to stick to the most common use cases and defaults - mounts are pointing to the sky in real time at a given moment - so they absolutely need to use JNow internally - and I think most mounts will want to receive JNow coordinates for a sync. But when a user looks up the coordinates of an object like M42, or even a newly discovered nova - the coordinates they read will probably be J2000 - and those are the ones they would enter in the SGP sequence dialog.
So - I would leave almost everything exactly the way it is - except that when you sync to a mount that expects JNow, you would convert either the plate solve result or the user-entered coordinates from J2000 to JNow before handing off.
As long as you are under control of the equinox used by plate solvers - you should be able to convert appropriately and under full control. For maximum flexibility the user-entered coordinates would have an option to specify an equinox other than j2000 - but the default would be j2000.
That’s my suggestion anyway - and it matches the way I do this stuff - and the way other software that has been around for a while handles equinox. For software like TheSky - it presumably uses JNow internally - since it is doing something in real time - but it provides J2000 coordinates to the user also.