Sequence math for aborting sequence at meridian may be wrong

Discussions, Bug Reports and Issues related to Beta versions of SharpCap
Post Reply
lowenthalm
Posts: 152
Joined: Mon May 07, 2018 12:27 am

Sequence math for aborting sequence at meridian may be wrong

#1

Post by lowenthalm »

This happened when using the latest May 15th release of Sharpcap.

Running the following sequence to capture multiple live stacks:

SEQUENCE
SET CONTROL "Background Subtraction" TO Off
SAVE MOUNT COORDINATES
STOP AT -10 FROM MERIDIAN
UNLOCK CONTROLS
LOOP 6 TIMES
GUIDING CONNECT ABORT False
GUIDING DITHER NOW
DELAY 3
LIVE STACK FOR 70 FRAMES SAVING AS AllFormats COUNTING Stacked FRAMES
PLAY SOUND Alert
GOTO SAVED COORDINATES
DELAY 4
IGNORE ERRORS FROM ONERROR RUN ""
RETRY ERRORS UP TO 4 TIMES
MOUNT SOLVEANDSYNC
END RETRY ERRORS
END IGNORE ERRORS
DELAY 4
END LOOP
END UNLOCK
END STOP AT
PLAY SOUND Alert
PLAY SOUND Alert
END SEQUENCE

This worked fine tracking past the meridian when south of zenith (tracking from azimuth 170 to 190). When I tried it on a target north of zenith (tracking from azimuth 10 through 0 to 350) the sequence bailed as soon as the mount passed the meridian. So looks like a little bit of a math error. Would it be possible to have the abort based on the number of degrees your EQ mount has passed the meridian (ie based on HA value converted to degrees) rather than the azimuth? This would make this problem automatically go away. This would also better match the slew limit behavior in EQ mounts.

In addition, the live stack was closed and reset when the sequence aborted. In all prior Sharpcap versions (4.1 and 4.0), you could open live stacking manually and continue where the sequence left off if you wanted to finish live stacking up to the intended number of frames (70, in this case). This was a much more forgiving behavior.
User avatar
admin
Site Admin
Posts: 13350
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sequence math for aborting sequence at meridian may be wrong

#2

Post by admin »

Hi,

thanks for the report. I had only really envisaged that the 'Stop at X from meridian' step would be used when starting on the east side of the meridian waiting for the mount to hit the meridian. I can change it, but I have to be careful - I don't want to end up in situations where it will try to wait 24 hours if the mount has already just passed the critical position.

The hour angle idea though does sound like a good improvement.

As for live stacking, I changed the behaviour to be 'reset if the stack has been closed for more than 60 seconds' to try to improve the behaviour for the most common use case (close stacking, move to new target, re-open), but that is obviously breaking people's workflow. Sounds like it's going to need an option ...

cheers,

Robin
lowenthalm
Posts: 152
Joined: Mon May 07, 2018 12:27 am

Re: Sequence math for aborting sequence at meridian may be wrong

#3

Post by lowenthalm »

It was already resetting to the stack when you started one in a sequence, so I think it was a non-issue.

I don’t quite understand your discussion of the meridian issue. I just wanted it to auto-exit the script as I tracked past the meridian so I could do a meridian flip. I need to adjust counter weights, so it’s a more manual process than I would like.
User avatar
admin
Site Admin
Posts: 13350
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sequence math for aborting sequence at meridian may be wrong

#4

Post by admin »

Hi,

sorry, let me explain it properly (I understand it myself better now as I have re-worked the code yesterday).

What was happening when it tracked past north was that the mount changes from reporting that it is on the east side of the pier pointing west to reporting that it is on the west side pointing east. The check for near the meridian requires that the mount is west side pointing east before it checks anything else like the exact direction the mount is pointing.

So, when the mount side changes, the code started looking at the azimuth of the mount, which would be something like 1 degree, then offset that by your limit of -10 (10 degrees past the meridian), getting -9 degrees, which is converted to 351. Then it compares 351 to 180 and notices that the mount appears to be past the limit (oops) and the step finished :(

Anyway, I have what I think will be a fix for the next 4.1 beta update - this will use hour angle rather than azimuth and also only trigger the look to exit if the mount is in the 15 degree range (1 hour) after the limit. I think that will resolve the issue.

cheers,

Robin
User avatar
admin
Site Admin
Posts: 13350
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sequence math for aborting sequence at meridian may be wrong

#5

Post by admin »

Hi,

I have made the proposed updates in 4.1.10652, so hopefully it should resolve this issue.

thanks,

Robin
lowenthalm
Posts: 152
Joined: Mon May 07, 2018 12:27 am

Re: Sequence math for aborting sequence at meridian may be wrong

#6

Post by lowenthalm »

Thanks! Will try it out as soon as I can.
lowenthalm
Posts: 152
Joined: Mon May 07, 2018 12:27 am

Re: Sequence math for aborting sequence at meridian may be wrong

#7

Post by lowenthalm »

Tested stopping E and W of meridian on targets N and S of zenith. All worked great!

In addition, current live stack no longer resets when this occurs.

Thanks for the quick fix!
Post Reply