Is it possible to set a custom park position weights up?

Please supply more details! How are you trying to set the park position? (APCC, ASCOM driver, A-P hand controller?)

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Mark Townsend
Sent: Thursday, September 2, 2021 7:05 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Custom Park Position Weights Up

Is it possible to set a custom park position weights up? I slewed to my weights up position and set it to
custom park however later when I use this custom park position it parks weights down and on the wrong side
of the pier.

My needed weights up park position looks out the door of my observatory and needs to be on that side of
the pier.

Thanks.

Hi David,

some of the numbers I'm getting for the model parameters are many orders of magnitude different
than the usual values.

The all-sky model requires data in a larger area of the sky to accurately determine the pointing terms, so you cannot count on the all-sky pointing terms being accurate with just a few rows of declination arcs.

If you are in a permanent setup, the ideal way to get the advantages of declination arc tracking accuracy and all-sky modeling is to capture a lot of data points (400+) so that there are many declination arcs throughout the entire sky.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Thursday, September 2, 2021 6:10 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Strange numbers in APPM model #APCC #Mach2GTO

[Edited Message Follows]

I've been using the Dec Arc feature, and it seems to work well. Thank you for implementing it. However,
some of the numbers I'm getting for the model parameters are many orders of magnitude different than the
usual values. For example, I'm doing a model with two arcs, one at 61 degrees N declination and one at 63
degrees. Below you can see what it looks like. The resulting model numbers are also shown below. Notice
some of the "west" parameters.

The mount tracks well, so it's not a functional issue, but it puzzles me that the numbers are so different. Is
this caused by doing the two arcs close together and no points elsewehere? If so, would I have major issues
if I tried to do regular tracking correction away from the two arcs? I doubt I would do that, because I'm
obviously concentrating on a target between the two arc declinations, but I do sometimes change targets for
unforeseen reasons, and maybe if I do I should just turn tracking off if I don't want to do another model?

Can you post a screenshot of what you are seeing?

For reference, you should see something like this:

https://www.gralak.com/apdriver/help/index.html?tour_of_the_handbox_window.htm

-Ray

Is it possible to set a custom park position weights up? I slewed to my weights up position and set it to custom park however later when I use this custom park position it parks weights down and on the wrong side of the pier. 

My needed weights up park position looks out the door of my observatory and needs to be on that side of the pier.

Thanks.

I've been using the Dec Arc feature, and it seems to work well.  Thank you for implementing it.  However, some of the numbers I'm getting for the model parameters are many orders of magnitude different than the usual values.  For example, I'm doing a model with two arcs, one at 61 degrees N declination and one at 63 degrees.  Below you can see what it looks like.  The resulting model numbers are also shown below.  Notice some of the "west" parameters.

The mount tracks well, so it's not a functional issue, but it puzzles me that the numbers are so different.  Is this caused by doing the two arcs close together and no points elsewehere?  If so, would I have major issues if I tried to do regular tracking correction away from the two arcs?  I doubt I would do that, because I'm obviously concentrating on a target between the two arc declinations, but I do sometimes change targets for unforeseen reasons, and maybe if I do I should just turn tracking off if I don't want to do another model?

Since the V2 driver can talk to APCC using a virtual COM port and my ATrack program uses COM port communications with Voyager, it would be easy to add a COM port command as above, sent to APCC.

Craig

For my project it would be easy enough to call APCC with the filename of the model to be loaded.  Since I only do 4 targets I could create these models ahead of time.  If the tracking for a particular target shows 'age' then I can make a newer model for that target, or all the targets. 

So a simple APCC call: "Execute DEC ARC(model file name)" is all I would need.

Craig

On Sep 2, 2021, at 16:31, Craig Young <craig.young.m8@...> wrote:

If the same target is observed with NINA, will APPM be requested to do a new map or does it use an old one? In my case I would be observing the same 4 targets throughout the year. If NINA could build a DEC ARC for each target and use them each night I believe that would work.

I want to move my NINA plugin in that kind of direction, with it being able to tell APPM to generate a dec-arc model on demand for each target, but there are some prerequisites that are needed on the APPM side of things to make this a programmatically smooth thing to do. I've talked to Ray about these needs and he'll look into implementing them if they're reasonably feasible. So, no guarantees on timeline or anything, but we've talked about the concept.

But say such a thing does become possible, where you can drop a "Create Dec-Arc Model" instruction into your NINA sequence template and it'll do just that based on the target's declination, then there would be some additional considerations around reuse of the model that comes out of that instance.

When APPM creates a model, it saves it as a .pnt file under C:\ProgramData\Astro-Physics\APCC\Models. These pnt files contain various metadata about the run, such as the date it was created, the location, various options that were selected, and so on. For Dec-Arc models, APPM would also need to note the declination in the metadata of each dec-arc model pnt file.

If the above were to be done, the envisioned "Create Dec-Arc Model" instruction could look at those pnt files and build a list of model creation dates and the declination they were created for. This would allow the plugin to match up an existing model to the target's declination. The model creation date would tell the instruction how old it is. Thus, using a user-suppled date limit measured in hours or fractional days, the instruction can decide if any existing model for a given declination is too old to use and instruct APPM to create a new one, or tell APPM (or APCC) to load the existing model and run with that instead. This interface - telling APCC to load a particular model - is a programmatic interface that I'm not sure exists or not. I recon it does, as APPM already seems to have a way to tell APCC to load the model it just created.

Anyway, there are some efficiencies in time that can be automated with this. If one is reasonably sure of their models as they age, they can set a use-if-no-older-than length of time in the plugin's configuration and not have to worry about time being wasted if you do a multiple night run on a specific target coordinates where you don't necessarily need a new Dec-Arc model each time. This is clearly up to user discretion, obviously, and I don't know if Dec-Arc models have any differences in sensitivities towards age compared to all-sky models.

This expiry date concept is something I could put in to the existing "Create APPM model" instruction in my plugin, though, since all that would be interested in is the creation date. No sense in creating a new model if one feels that their existing one is still valid. The instruction would then be a no-op at that point.

/dale

Does this mean there is an API available for APCC for use by 3rd party software?  If so I could build the 4 DEC arcs and when I switch targets ATrack could send a request to APCC to load a previously saved model and turn on DEC ARC tracking.

Craig

Roland,

Thanks for your reply, I just found your in-depth description of the Mak astrograph on the other Forum.  Interesting scope.  I would love to see some photos of some of your prototypes and other scopes that never came to market.  I live in the Washington, DC area and it is always a treat to see the AP 206 EDF at Company Seven up close and personal.

Bill 

If the same target is observed with NINA, will APPM be requested to do a new map or does it use an old one?  In my case I would be observing the same 4 targets throughout the year.  If NINA could build a DEC ARC for each target and use them each night I believe that would work.

Craig

Thank Christopher!  I just missed getting that one by about 5 minutes.  Fortunately there are a couple of guys on here who may be abut to help me! 

Thanks
Benton

What telescope was this shot using?  I have never heard of an AP 10 inch F6.3 Maksutov Astrograph.

Bill

Hi Bryan,

Thanks I read it and re-read it, got a bit lost, until I spoke with George.

Shailesh

Thanks Roland. I spoke with George and he was kind enough to walk me through it. I am all set. 

Shailesh

Linwood

A good explanation from the Troubleshooting section, but perhaps not answering your question is

"APCC has a sophisticated meridian limits mechanism that will allow you to define the limit the mount can track past the meridian at multiple declination values. Will this also prevent slews to these positions? I will often be starting imaging east of meridian but would like reasurance that GOTOs with a negative meridian delay won't hit anything. 

APCC (and also the ASCOM driver) have "safe slews" built into them to prevent slews that cause collisions in "counterweight-up" conditions. The slews occur in multiple stages. If you are starting a
slew from a counterweight up position (i.e. you have tracked past the meridian), the first part of the slew will be in right ascension only. The mount will move in RA until the mount enters a normal, counterweight down orientation. It will then slew in both axes until the RA reaches the meridian, and the Dec fully completes its slew. Finally, with the Dec having arrived at its safe position, it will then complete the slew in RA only to the starting point east of the meridian with the counterweight up."


Bryan

Shailesh

Complex topic!  I assume you refer to Meridian Limits.

I would suggest reading Section 6.16 (Meridian Limits) in the APCC documentation.  It's the same section whether you have APCC Std or Pro version.  Ray's cautionary words are in the first paragraph.

"However, like any powerful feature, you MUST understand how the meridian limits work. It is vital that you understand what they
CANNOT do as well as understanding what they can do!"

The section on Horizon Limits is useful as well.  Section 6.15

Bryan