Couple of Ideas

Couple of items.

  1. Multiple mount parking “home” locations (like EQMOD).

  2. Within the sequence have an option to center and focus between targets (don’t see the option for this. If sequence is paused at the end of one target it will resume to the next target without centering).

  3. Ability to pick a error threshold for centering object.

  4. Ability to perform actions based on different environmental variables (eg. parking, etc…)

Thanks!

  1. Agreed, would be a useful feature.

  2. Are you talking about between events? You can definitely auto-center and auto-focus between targets. Check the plate solve tab and auto-focus tabs.

  3. Error tolerances can be set under the plate solve tab.

  4. Perhaps you can use a script either before or after an event (in the event options).

I though this was the case and I have those options selected but for some reason last night it was skipping those and going right to imaging. I wonder if the problem was that I added the target right before the last sequence was ending… hmmm…

We interface with mounts via ASCOM. To the best of my knowledge, this interface only provides provision for one park location and one home location. EQMOD has direct access to the mount and is not subject to this contract.

SGPro can auto focus after a filter change or after any mount movement. Not 100% sure about the pause part.

See @HomerPepsi above.

Are you looking for more script triggers or something else here?

Yes maybe a script that would have the option query environmental values and perform actions based on that. For example it wind speed is 25m/s it could either alert you or just park everything. I guess it would be possible as well to write a script that would query ascom as well to gather this information.

As for the multiple home positions, Is it possible to set the parked position through ASCOM? If so you could have saved positions. Apparently if you send the command string “:PARK,parkmode#” # being the position identified in the EQASCOM interface. So maybe even a script can do this as well.

incomplete sentence sorry:

Apparently if you send the command string “:PARK,parkmode#” # being the position identified in the EQASCOM interface it should be able to park to any of your pre defined positions.

It may be worth describing what you want to do which you believe requires multiple park positions. It could be there’s a different way to do it.

You should be able to do this with a simple script - that moves the scope to a certain alt/az and then turns tracking off. You could fire off the script at end of event or sequence.

Ok I guess this might help, but no laughing :slight_smile:

this is one example.

So I live somewhere where weather changes in an instant (Hawaii). My garage is facing due north and I can see Polaris about 5 degrees above the tree line. So what I do is setup my equipment under the eves of my garage. My scope being a refractor sticks past the eve in its home position. It sticks out far enough where I can get, say Bodes Galaxy from where it rises to where it sets. That said, if it where to rain I would park my scope in a position that was parallel to the eves of my house thus saving my equipment giving me time to cover everything up without messing up my polar alignment. Now after the weather clears I could home the scope (point back to Polaris) so the Platesolver could get a bearing on where it is (when parked it is facing a wall).

Feel free to tell me I’m crazy but I’m working with what I got and with the conditions I live in. I bet if people would realize what they could do with a similar setup they would make of use of it as well. For instance last week I got three hours straight of the heart nebula.

That all said, I know first hand of other application of this where observatory roofs and scopes will collide if not parked first.

buzz,

Yes I can do this, but I’m thinking that this is a good feature in general for non-coders and script kiddies that hopefully could be implemented with little effort into SGP with great benefit.

I don’t see a need here for any other park position than the position that you describe where the OTA is parked hidden under the eaves of your house. Park is the position that you want your scope to be where it’s safe and can be shut down.

The Home position can be different, normally this is some fixed reference position, ideally defined with switches on the mount, which can be used as a starting position for an alignment. It is frequently with the mount pointed at the pole with the counterweight shaft pointed down. The Home position isn’t changeable.

If a mount has both Park and Unpark implemented then Unpark should take the mount out of the Parked state and restore the alignment. You should then be able to slew to your start position and continue.

Much of this is up to your mount and what is implemented.

True - I wonder if it makes sense to have a little resource page with a few robust sample scripts that SGP users can modify and apply? It would have to have caveats that these are user-supplied scripts with no contingent liability etc.

For instance I made up one to delay the start of sequence until the altitude reached a certain level.

Yes this is exactly what I am talking about. Correct me if I’m wrong, but within SGP there is only a Park option. Granted yes I could just switch back into the EQASCOM interface, select the alternative home/park position and park, but I was thinking that the SGP team has done such a great job of interrogating the devices and ASCOM information so the user does not need to switch back and forth between apps why not try it in this instance. Like you said, if the mount supports having both a home and parked position this should be universal (can you think of any modern mounts that wouldn’t?). I know so far all the mounts I have messed with have (Synta, AP, Paramount, Celestron).

In the meantime I’ll have a Windows hotkey that fires off a script like buzz said.

I don’t think it is what you are talking about. SGP uses the ASCOM Park command to Park the scope. Park does more than move to a position, it stops tracking and prevents further movement. Turning tracking on or trying to do a slew will generate errors because the mount is Parked.

I don’t know what EQMOD does with their multiple Park positions.

Think of it like your car, if you put it in park you can’t move it and it will resist being moved.

Yes, sorry I was assuming that all the intermediate processes like tracking (starting/stopping) are happening as they usually would during a park/un-park.

Scope (pointed somewhere in the sky) → Park (turns off tracking and slews to park position) → When coast is clear → Unpark → Slew to home position → resume tracking

Did I miss a step?

I haven’t implemented it yet via a script but the logic seems quite straight forward on the ASCOM to Mount communications (thank goodness)