APCC feature request


Paul
 

I measured my scope's cone error with ConeSharp (great tool btw!) last night and found I have about a 7 arcmin error. (Mounted on a Mach1 fyi).


Shimming the scope I'm not sure I want to do. It'd be a pain (it's an RC8 on an SBD2V on a DOVELM162. I keep the SBD2V always attached to the scope, but take the scope + SBD2V off the DOVELM162 between sessions - it might therefore be possible to shim between the SBD2V and the RC8 Vixen dovetail)


I use it only for imaging (with plate solving via SGP), so there's not really any pressing need to fix the error, other than just nerdy obsessiveness!


But let's say I wanted to fix the problem. I am concerned that shimming may introduce some sort of issues with reducing mechanical robustness. Hence my request .......


APCC Pro of course offers a full pointing model, but I don't want/need that, since I set up every session afresh. But it would be a nice feature in APCC to allow the user to simply enter a cone error value they've worked out themselves (e.g. from ConeSharp as I did) and that could be used as a very basic correction in lieu of a full pointing model. It'd probably get rid of the bulk of my initial error on gotos. Currently after a meridian flip I'm say 17 arcminutes off (I assume there's a bit of flexure/sag/mirror flop somewhere too but say about 14 arcmins of that will be from the cone error).


I admit it's a bit of a weak argument for a feature request, since I've argued above I don't even need to fix the error for my use case!! But visual users could certainly benefit. And perhaps I haven't thought of a case even for imaging use where it might be of value.


Comments appreciated.


Paul



John Shutz
 

Hello Paul,
I haven't yet set up my never used 2011 900GTO, bought it three years ago and at that time I made a promise to myself I would sort out my current mount issues first before I tackle the learning curve of the AP mount.  Anyway, I know I have cone error and orthogonal issues, my first goto during this mount's alignment routine is always far outside the FOV of my 60Da live view screen.  Instead of doing things like shimming or other remedies, I accept the first star error, but then use the mount's sync function on the second star and fortunately that star always lands absolutely dead center in the live view screen.  From that point on my gotos are very accurate.  I guess you can say my method is the lazy man's solution, but it does work.  I would rather not have to do it this way, but I'm tired of fumbling with the mount.  The other method is to go through a three star alignment process and that also resolves any cone or orthogonal errors, at least that is what I've been told.  My ability to perform various sky routines has been pretty much shot down since I have a limited view from my small backyard night sky now.  My neighbor's trees have grown quickly the last four years, so longer imaging sessions has become impossible.  I'm not really concerned about finding long term solutions on any of this anymore because I'll likely step away from the hobby anyway due to physical limitations.  Despite the many frustrations with the mount and other issues that goes with the territory, stuff I understand, it doesn't look like the 900GTO will ever see first light because I'm now facing my seventh and eighth operation since a near fatal motorcycle accident in late 2005.  The situation sucks and I have considered all the options and nothing comes up that appeals to me, outside of moving to a house with a larger back yard to accommodate an observatory.  Isn't that the dream of 99% of amateur astronomers?

John


Cc:

Sent:
15 May 2019 03:31:42 +0000
Subject:
[ap-gto] APCC feature request


 

I measured my scope's cone error with ConeSharp (great tool btw!) last night and found I have about a 7 arcmin error. (Mounted on a Mach1 fyi).


Shimming the scope I'm not sure I want to do. It'd be a pain (it's an RC8 on an SBD2V on a DOVELM162. I keep the SBD2V always attached to the scope, but take the scope + SBD2V off the DOVELM162 between sessions - it might therefore be possible to shim between the SBD2V and the RC8 Vixen dovetail)


I use it only for imaging (with plate solving via SGP), so there's not really any pressing need to fix the error, other than just nerdy obsessiveness!


But let's say I wanted to fix the problem. I am concerned that shimming may introduce some sort of issues with reducing mechanical robustness. Hence my requ est .......


APCC Pro of course offers a full pointing model, but I don't want/need that, since I set up every session afresh. But it would be a nice feature in APCC to allow the user to simply enter a cone error value they've worked out themselves (e.g. from ConeSharp as I did) and that could be used as a very basic correction in lieu of a full pointing model. It'd probably get rid of the bulk of my initial error on gotos. Currently after a meridian flip I'm say 17 arcminutes off (I assume there's a bit of flexure/sag/mirror flop somewhere too but say about 14 arcmins of that will be from the cone error).


I admit it's a bit of a weak argument for a feature request, since I've argued above I don't even need to fix the error for my use case!! But visual users could certainly benefit. And perhaps I haven't thought of a case even for imaging use where it might be of value.


Comments appreciated.


Paul



W Hilmo
 

I would also appreciate a solution for cone error. This would benefit me for visual.  For imaging, APCC Pro has me well covered.

It would be a great CP4 feature.  It might also be interesting to have a dovetail saddle with the ability to make the adjustment mechanically.  I would update to something like that from my current DOVELM162.  My telescope’s dovetail plate would be difficult to shim otherwise.

Of course, the downside to a dovetail saddle solution would be that it’d be a different adjustment for each scope.

On May 14, 2019, at 11:32 PM, privatekey42@... [ap-gto] <ap-gto@...> wrote:

 

I measured my scope's cone error with ConeSharp (great tool btw!) last night and found I have about a 7 arcmin error. (Mounted on a Mach1 fyi).


Shimming the scope I'm not sure I want to do. It'd be a pain (it's an RC8 on an SBD2V on a DOVELM162. I keep the SBD2V always attached to the scope, but take the scope + SBD2V off the DOVELM162 between sessions - it might therefore be possible to shim between the SBD2V and the RC8 Vixen dovetail)


I use it only for imaging (with plate solving via SGP), so there's not really any pressing need to fix the error, other than just nerdy obsessiveness!


But let's say I wanted to fix the problem. I am concerned that shimming may introduce some sort of issues with reducing mechanical robustness. Hence my request .......


APCC Pro of course offers a full pointing model, but I don't want/need that, since I set up every session afresh. But it would be a nice feature in APCC to allow the user to simply enter a cone error value they've worked out themselves (e.g. from ConeSharp as I did) and that could be used as a very basic correction in lieu of a full pointing model. It'd probably get rid of the bulk of my initial error on gotos. Currently after a meridian flip I'm say 17 arcminutes off (I assume there's a bit of flexure/sag/mirror flop somewhere too but say about 14 arcmins of that will be from the cone error).


I admit it's a bit of a weak argument for a feature request, since I've argued above I don't even need to fix the error for my use case!! But visual users could certainly benefit. And perhaps I haven't thought of a case even for imaging use where it might be of value.


Comments appreciated.


Paul



Joe Zeglinski
 

Hi Wade,
 
    I don’t understand your concern, about needing a different saddle adjustment for every scope.
You are shimming the saddle “for the mount” orthogonality error, not for each of the scopes. Once you have the saddle orthogonally corrected, ALL other scopes will then be automatically now aligned to the new correct offset position.
 
Joe


Roland Christen
 


You are shimming the saddle “for the mount” orthogonality error
Generally the mount won't have an orthogonal problem. The orthogonal problem usually occurs in the telescope tube assembly when the optical and mechanical axes don't coincide. This normally occurs in Cassegrains, and in the tube rings of refractors.

Rolando


-----Original Message-----
From: 'Joseph Zeglinski' J.Zeglinski@... [ap-gto]
To: ap-gto
Sent: Wed, May 15, 2019 10:31 am
Subject: Re: [ap-gto] APCC feature request



Hi Wade,
 
    I don’t understand your concern, about needing a different saddle adjustment for every scope.
You are shimming the saddle “for the mount” orthogonality error, not for each of the scopes. Once you have the saddle orthogonally corrected, ALL other scopes will then be automatically now aligned to the new correct offset position.
 
Joe



W Hilmo
 

Astro-Physics mounts don’t have orthogonality errors J

 

Any cone error is coming from the OTA.  My C14, in particular, has some cone error.  I could fix it by using a shim between the dovetail and the scope itself, but the Celestron dovetail is not easy to work with.  I’ve considered switching to a Losmandy dovetail, or even rings, but then the OTA would not fit into my JMI case.

 

From: ap-gto@... [mailto:ap-gto@...]
Sent: Wednesday, May 15, 2019 8:24 AM
To: ap-gto@...
Subject: Re: [ap-gto] APCC feature request

 

 

Hi Wade,

 

    I don’t understand your concern, about needing a different saddle adjustment for every scope.

You are shimming the saddle “for the mount” orthogonality error, not for each of the scopes. Once you have the saddle orthogonally corrected, ALL other scopes will then be automatically now aligned to the new correct offset position.

 

Joe


Paul
 

Indeed. I should have stressed in my original suggestion for the new feature that my presumption is that this is an issue with my OTA and not my mount.

I just want to be able to put an OTA on it and give APCC a figure for that OTA's rough cone error (value in arcminutes towards/away from saddle front).


Paul
 

A general question related to my previous request for an APCC user entered field for cone error correction. Just asked out of interest ......


Is there a reason that AP handsets and drivers/APCC do not support 3-star alignment? I appreciate that cone error (and PA misalignment) are non-mount issues, but on other (lesser!) mounts whose software supports such multi-star alignment the model from a quick 2 or 3-star alignment goes a long way towards making gotos relatively accurate.


I use my Mach1 for imaging and so use plate solving. But if I was doing visual, I wouldn't want to be forced to correct cone error with every scope I put on it. I'd just rather do a quick polar alignment and then a 3-star alignment. After that, especially with the accuracy of an AP mount, subsequent gotos would be very good I'd imagine.




Christopher Erickson
 

Lesser mounts NEED 3+ star alignments to compensate for the many sins of the wiggly mounts and wobbly optics.

A tight, rigid mount and OTA that is orthogonal only needs a good polar alignment and one more star (basically a 2-star alignment) to be right on the money.


On Sun, Jun 16, 2019 at 5:54 PM privatekey42@... [ap-gto] <ap-gto@...> wrote:


A general question related to my previous request for an APCC user entered field for cone error correction. Just asked out of interest ......


Is there a reason that AP handsets and drivers/APCC do not support 3-star alignment? I appreciate that cone error (and PA misalignment) are non-mount issues, but on other (lesser!) mounts whose software supports such multi-star alignment the model from a quick 2 or 3-star alignment goes a long way towards making gotos relatively accurate.


I use my Mach1 for imaging and so use plate solving. But if I was doing visual, I wouldn't want to be forced to correct cone error with every scope I put on it. I'd just rather do a quick polar alignment and then a 3-star alignment. After that, especially with the accuracy of an AP mount, subsequent gotos would be very good I'd imagine.






Paul
 

Sure. But my point is that often we will have a non-orthogonal OTA on there. Shimming is a pain. And if you're setting up and taking down for every session, not even practical if it's not repeatable.


Assuming perfection is fine - but that is often not what we have to deal with.


Christopher Erickson
 

Shimming only needs to be done once. After a careful collimation.


On Sun, Jun 16, 2019 at 6:51 PM privatekey42@... [ap-gto] <ap-gto@...> wrote:


Sure. But my point is that often we will have a non-orthogonal OTA on there. Shimming is a pain. And if you're setting up and taking down for every session, not even practical if it's not repeatable.


Assuming perfection is fine - but that is often not what we have to deal with.




Paul
 

Sure. But you don't have to do it if the software compensates.


And if you're constantly setting up/earing down and/or changing scopes then I doubt it'd be that easy to keep them all orthogonal.


But I guess my question is in there any reason why it's not offered as an option in the software? It's not hard to add.


Dale Ghent
 

On Jun 16, 2019, at 11:54 PM, privatekey42@yahoo.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

A general question related to my previous request for an APCC user entered field for cone error correction. Just asked out of interest ......

Is there a reason that AP handsets and drivers/APCC do not support 3-star alignment? I appreciate that cone error (and PA misalignment) are non-mount issues, but on other (lesser!) mounts whose software supports such multi-star alignment the model from a quick 2 or 3-star alignment goes a long way towards making gotos relatively accurate.

I use my Mach1 for imaging and so use plate solving. But if I was doing visual, I wouldn't want to be forced to correct cone error with every scope I put on it. I'd just rather do a quick polar alignment and then a 3-star alignment. After that, especially with the accuracy of an AP mount, subsequent gotos would be very good I'd imagine.

In the case of using APCC with a mount just do a software plate solve and call it a day (night).

In the case of pure visual and having only a keypad at your disposal, a crosshair ep and your eyes are, in effect, the plate solver. Do your normal polar align and start from a known park position. Select an object in the keypad and command the mount to slew to it. If it lands off, then punch buttons until it's on the crosshair. Then sync it. Done.

All of this is covered on page 55 of the keypad manual:
https://astro-physics.info/tech_support/mounts/keypad/keypad-manual.pdf

/dale


Paul
 

But then slew to an object on the other side of the meridian and (if you have cone error) you'll be considerably out and have to do the same alignment again.


It'd be a nice feature to have that's all and was just wondering if there is a technical reason why it's not supported as an option. (of course, there is the full on modelling in APCC, but that is not for a one-off session).


Dale Ghent
 


On Jun 17, 2019, at 2:01 AM, privatekey42@yahoo.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

But then slew to an object on the other side of the meridian and (if you have cone error) you'll be considerably out and have to do the same alignment again.
Considerably? If the difference can be termed *considerable*, then I'd assert that your time would likely be better spent addressing the cone error itself than trying to dampen its effects in software. A little cone error is annoying. Considerable cone error means you should be getting out the shims or reconsidering your dovetail, rings, or other such hardware.

But the topic of cone error is addressed in the manual on page 56:

"If orthogonality issues are affecting your pointing accuracy, use a smart strategy to compensate. Organize your observing around one or several regions of sky. The regions can be on opposite sides of the meridian, but slews within the region should not require you to cross the meridian. When you finish a region, slew to a bright star in the next region and re- calibrate. As long as you are not swapping sides by crossing the meridian, you should be able to slew to objects within a reasonable radius of your calibration star with satisfactory accuracy. The useful radius will simply depend on the degree to which your system is not orthogonal, but you should be able to observe in a radius of 20 to 30 degrees before re- calibrating."

The take-away for me is just do a quick sync (and it is a near-effortless task) after transiting the meridian, and one can minimize such transits by planning their session accordingly. Visual is also something that is way more accommodating to cone error. I'm usually looking at DSOs, so while a GoTo operation puts the object right in the middle of my field of view, I'm usually always tapping the arrow buttons to move it towards one side or the other for better framing or orientation for averted vision - GoTo accuracy is just not a huge deal for me in that specific case. But if you have mondo cone error constantly getting in the way of things, then honestly I'd work on fixing that. Judging from the wording in the passage about this in the keypad manual, I gather that's also A-P's philosophy on this.

It'd be a nice feature to have that's all and was just wondering if there is a technical reason why it's not supported as an option. (of course, there is the full on modelling in APCC, but that is not for a one-off session).
My guess is that such a thing would likely be a CP4/CP5-only feature, because to support a new feature on on CP3 (and earlier) control boxes would require a new chip upgrade to store the configuration and process it. Keypad firmware would also need to be updated to grok the feature as well. I understand that keypad firmware is going through an overhaul to support Mach2/CP5 features and features in generally will be easier to add to that code base as a result. Ability and willingness to add a given feature that touches both the control box and keypad is something only A-P can comment on, though.

/dale


Paul
 

Right. I was fishing for an AP comment :-)


(and by considerable I just meant out of the field of view. So depends on the eyepiece, but 5 arcminutes error might be enough to cause an issue as that would cause a 10 arcminut error, so if you have a 20 arcminute wide field of view that'd just push you out of it from the centre).


Christopher Erickson
 

Because it usually isn't required for quality mounts and OTA's.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Sun, Jun 16, 2019, 7:39 PM privatekey42@... [ap-gto] <ap-gto@...> wrote:


Sure. But you don't have to do it if the software compensates.


And if you're constantly setting up/earing down and/or changing scopes then I doubt it'd be that easy to keep them all orthogonal.


But I guess my question is in there any reason why it's not offered as an option in the software? It's not hard to add.




Paul
 

But if you have a cheap OTA on an AP mount (as I do!)....


As I said, I image only with this mount and so it's not a must have for me.


Though my original nice-to-have request still stands for adding in a field to APCC where I can specify my cone error as a rough first approximation to offset the error just to make meridian flips a bit closer and my plate solves even quicker :-)


Christopher Erickson
 

I don't know what type of OTA you have but even the floppiest of OTA's can be carefully collimated and orthogonally squared up pretty well. And unless something significant happens to the OTA, the ortho won't need to be done again.

Mirror flip and/or focuser sag might create some residual dynamic ortho error that can't ever be dialed out completely but almost any OTA can be improved significantly.

I hope this helps.

And FWIW, I suspect that AP will eventually add software ortho compensation to their hand controller(s) for situations exactly like yours.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   


On Sun, Jun 16, 2019, 9:14 PM privatekey42@... [ap-gto] <ap-gto@...> wrote:


But if you have a cheap OTA on an AP mount (as I do!)....


As I said, I image only with this mount and so it's not a must have for me.


Though my original nice-to-have request still stands for adding in a field to APCC where I can specify my cone error as a rough first approximation to offset the error just to make meridian flips a bit closer and my plate solves even quicker :-)




Paul
 

Thanks. Yeah, as I said. I image with plate solving and so don't need it (though I'd appreciate that cone error setting I suggested just for flexibility and convenience). But I was just curious and pondering re 3 star alignment and visual work and why it wasn't supported by AP, as without it the AP mounts are lacking as compared with the convenience of other mounts.

Re my specific OTA, yes, most of the cone error can be eliminated with a bit of effort. But it shouldn't be a necessity to do this. And for anybody setting up from scratch for each session it may be that their cone error setting won't hold up between session. It can be hard to eliminate it completely in any case, and it just seems common sense to let the software take care of what's left.