Re: Another APCC question


Ray Gralak
 

Hi Dale,

Thanks for the great feedback! There is a reason why Lat/Long have been restricted to being set at initialization. If they are
changed after initialization the mount may require a sync operation to properly recalculate the scope's pointing position. If a user
fails to do this the mount would think it is pointing to the wrong position. It was thus deemed safest to only allow the user to
change Lat/Long at initialization.

In that regard, I agree that the AP V2 driver documentation and user feedback should be more clear. The only place that you can
change Lat/Long is in the AP V2 setup dialog, which is usually run when the driver is not connected. And in the help section for
"Initialization Setup" it states that most of the options (including "Set Latitude/Longitude") apply only when the mount is
initialized. I think a more straight forward statement there is needed.

https://www.siriusimaging.com/apdriver/help/initialization_setup.htm

However your thought about applying Lat/Long from a "known" parked position may be possible. I will talk this over with Howard to
see if there is a "safe" way that this can be done.

Thanks again for the feedback, Dale!

Best regards,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Friday, August 3, 2018 12:44 AM
To: ap-gto@...
Subject: Re: [ap-gto] Another APCC question





On Aug 2, 2018, at 8:32 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...>
wrote:

Hi Dale,

You wrote:
One suggestion on this front is that this stipulation be made more clear in the APCC/driver config UI. It took me a
while to deduce this on my own when I first noticed that the CP's lat/long would fail to update after I would move
to
a new site, get set up, and start getting the software set up.
The APCC help file, which you can get to by clicking the round "?" button on APCC's site tab says this:

"The information in this group box comes from the selected site data saved in APCC. Note that you can select a
site in this group
box WITHOUT sending its information to the mount. Site information is only sent to the mount during initialization."

Do you have any suggestions on how why might improve this?
I don't have APCC, so my experience is based on the UI as it is in the V2 driver and its Setup Telescope tool. The
V2 driver's help file does /not/ appear to cover this particular operational idiosyncrasy of the mount.

I think it might be helpful to look at it this way: Let's put the Location or Lat/Long setting elements of the driver UI in
the context of its intended function, and the intended results:

1. The mount requires that it knows where it is on earth (its Location)
2. The driver provides a user-facing method for programming the mount with the Location, through direct Lat/Long
entry or selection of a preset.
3. The driver interacts with the mount to convert user Location input into protocol commands that the mount
consumes and acts upon.
4. The driver provides feedback to the user regarding what it wants the mount to think its Location is, as well the
actual Location that the mount thinks it is at.

So that covers intended function, so what about intended results?

1. The mount reports that it is calculating based on the user's intended Location. Life is good.

-OR-

2. A mismatch exists between the user's expected Location and the mount's actual Location.
- Such a mismatch is denoted by red highlighted Lat/Long text in the driver UI, which alerts the user to take
corrective action.
- There is no obvious method (button, checkbox, etc) which allows the user correct the mismatch.
- There is no error message which explains to the user the mount's requirements around effecting the correction, or
why the driver cannot correct the condition on its own.

In the case of (2), I think we run afoul of the Principle Of Least Surprise[1] - The driver knows there is a problem, it
reflects that there is a problem, but there is no obvious or intuitive route for the user to take in order to correct the
problem - secondary help files should not be considered a stand-in for this. Compounding the problem, other
functions of the driver and mount appear to work fine (unpark, park, slewing, changing tracking speeds, etc.) which
can add to the confusion. I would say that having to power-cycle the CP is not an obvious place to start, especially
when programming the mount with a Location appears on the outset to be an ordinary and unexciting thing to do.

How to address this? I think a modal window (ie, a pop-up) isn't suitable here, so I'd advise against that. Without
drastically changing how the UI is laid out, I think a reasonable way to add more context to the situation is to display
an informative tool tip when the user mouses over a red-highlighted Lat/Long setting in the Site Info area. As for the
driver's help file, there should be a more detailed explanation there, but a help file should not do the job that the UI
should be doing immediately upon an error - reporting to the user what is wrong and pointing the way to fix it.

As for the inability to set Lat/Long on an already-initialized mount, this does seem like a strange issue. Would it be
possible to allow Location settings be done while the mount is parked?

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Join main@ap-gto.groups.io to automatically receive all group messages.