Help required with Mosaic centering options

I’m having some repeated issues on a sequence that used the mosaic and framing wizard to set up a single tile target. I do not use the wizard that frequently and in this case when the sequence starts from park and at present, it does not slew to target but plate solves the wall of the obsy and eventually times out with the centering process. I have dozens of successful sequences prior to this, set up via astroplanner, where upon sequence start, the mount unparks, slews and centers.

I have a feeling it has something to do with the ‘slew to target and then center’ options. I cannot recall which option I chose in the wizard but in the sequence, both slew and center options are both ticked. To me the option wording is not entirely clear and I do not really understand all the differences: So, what specifically happens in the three cases?:

  • Precision centering with plate solve (precise)
  • Slew telescope (imprecise)
  • Slew to target and then Center

I always use Slew to target and then Center…works for me from a horizontal park position.

Here is the thing Martin. In the sequence’s target options, both slew and center are enabled, but it ignores the slew - as if I only selected ‘precision centering with plate solve (precise)’ maybe?
The only way to prove/disprove my hunch is to create three dummy sequences tonight with all three options and directly compare their behavior. I know if I do not use the wizard feature, it works from Park, as I have been doing that for the last few years without any issues.

Sounds like you’re just using the precision centering option. We should almost remove this as the slew first option is always better.

  • Precision centering with plate solve (precise)
    ** Scope solves and syncs and current position before moving
  • Slew telescope (imprecise)
    ** Scope slews to Target coords only, no sync
  • Slew to target and then Center
    ** Scope slews to target coords then centers on target cords.

Thanks,
Jared

Good morning Jared. I tend to agree, but when I check the sequence’s target options, both slew and center are enabled - so is there some other setting made by the wizard that is stored in the SGF file and that is acted upon but not displayed, which overrides the slew and sync options on the target options? If that is the case, it is a bit of a logic bug maybe?

It should be getting direction from that dialog. If you can post a log I
can check.

Thanks,

Jared Wellman
– Co-Founder and Developer
www.mainsequencesoftware.com

@Jared
Whatever I do , I cannot stop SGP taking a platesolve before slewing at the start of any sequence, regardless of the sequence centering settings. If I move the mount to the rough position, the plate solve comes up with a result, then it slews and centers to the first target. I have re-installed the Beta, and deleted the AppData files, but with no difference.

I tried creating the same sequence without the wizard, with slew and center and angle options. No luck.
I thought the mount was not receiving an unpark instruction. If I unpark it first, it still plate solves before the slew.

Looking through the log file - I think it might be the use of a manual rotator. I do not normally use this control - it looks like it is trying to sync the rotator angle before doing the slew. Is that correct? That would explain quite a bit, since the mosaic normally makes a fuss if there is no rotator?
sg_logfile_20171128172710.txt (152.9 KB)

[update] I’m using a manual rotator and I disabled rotation for the first target of a multi target sequence. Same issue.
When I disabled rotation in the second target as well, it slewed ok. So the logic appears to be if there are any targets in a sequence that need manual rotation, SGP checks the rotation angle before slewing to the first target. Is that correct?

I also posted a thread about this a while ago: Plate solving in the beginning of a sequence - Sequencing - Main Sequence Software

The problem turned out to be the manual rotator. SGP indeed seems to check the rotation angle before slewing.

Thanks - I guess that poses the question - if we request Ken and Jared to swap the order, I’m guessing it is probably easy to implement but what impact would it have on others?

It’s probably just an issue with all rotators. I can’t really think of a reason that doing the sync for the rotator after the slew would be problematic. Seems slew should always come first if selected.

I’ll see about adding this into the next beta.

Thanks,
Jared

Except…mine very specifically doesn’t do that. (AP Mach1 GTOCP4 latest AP ASCOM driver)

I’ve got a mosaic session I’m working on right now…set up with the FMW, using “Precision Centering”, and every target has “Center On” checked, and “Slew to” unchecked.

When the target starts, the scope is at park. It unparks, slews to the target area, then plate solves for the first time.

So…some combination of settings/options/ASCOM maybe? Something somewhere is inconsistent…

Here’s a log snippet from last night demonstrating this. [11/28/17 22:00:01.115][DEBUG] [Telescope Thread] Center telescope message recei - Pastebin.com

Note starting at line 9 :slight_smile:

[11/28/17 22:00:01.423][DEBUG] [Telescope Thread] Performing auto center step 3 (scope)...
[11/28/17 22:00:01.423][DEBUG] [Telescope Thread] Auto center slewing scope to match reference...
[11/28/17 22:00:01.429][DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 6.56212777777778 (06h33m43.66s) Dec: 5.24426944444444 (05°14'39.37") 

No plate solve prior…plate solve doesn’t happen until after the slew.

@gboulton That is odd indeed and not what I would have expected. I wonder if that is particular to the AP mount. (I will try an experiment tonight)
Do you have an angle set in your sequence? - the issue I am seeing seems to be related to rotation.

I’ve wondered that as well. In talking with others who own various Celestron or Orion mounts, they observe the behaviour Jared described. SGP solves then slews to the target.

I do not.

I just tried your settings with the Paramount / TSX . I disabled ‘slew to’ and the rotation feature and it remained parked. When I enabled rotation, I plate solved the obsy wall again and fell over. Another post on tracking says that AP have an intelligent option that knows when to turn on tracking / slewing. Not sure of the full details.
So - in summary, if Jared is able to move the sequence of confirming angle and slew commands in the next beta, that would be wonderful.

Seems to me the obvious solution is to paint a mural of space on your obs wall. :wink:

A painting won’t be good enough because the sky is moving. A display showing a live view of the sky in the direction the OTA is looking when it’s parked may do the trick.

In fact having a display fitted to the front of the OTA that shows the sky in the direction it’s pointed could work for all imaging even if it’s cloudy. The display would need to be rotated when a pier flip is done.

ASCOM - All Sky Celestial Observing Mural ?

It could be a continuous loop…on rollers, see…

This will have an ASCOM interface, right?

And there you have its name. lol

Well, you could eliminate the OTA, filterwheel, focuser and camera and have an ASCOM camera that downloaded the image from the cloud. The camera gets it’s position from the telescope

I’ve done that for the DSS image source.

1 Like

All joking aside - I have an outreach event to do at a school - in case of bad weather what Chris describes is a wonderful way to image through clouds !