Time to meridian flip calculation?


#1

i was just watching SGP run; a subexposure ended about 32 minutes before the OTA would reach the meridian.

an autofocus run fired off, which believe it or not took 20 minutes (the temperature is changing rapidly leading to many more points than normal being necessary, and i’m focusing thru a narrowband filter, which takes forever. when focusing was finished, SGP went ahead and started the next exposure. there were 10 minutes to the flip point. the next exposure is 30 minutes long.

if the meridian limit were a hard limit, i think this would have driven the telescope into the pier. as luck would have it, for this particular declination i can go about 25 minutes past the meridian, so everything is going to be OK.

shouldn’t SGP check if there’s enough time to complete an exposure right before it begins exposing? or do i have something misconfigured?

thanks

rob


#2

Rob,
In the Meridian Flip Options, check “Wait for Meridian.” If the next exposure is less than the time to flip the sequence will wait for the meridian, flip, then start the next exposure. But you may lose 29min if a 30min exposure is needed 29min before the meridian.


#3

I should have mentioned that it was checked. I think this is a bug…

rob


#4

Have you tried using filter offsets and AF with Luminance filter for NB imaging?

Peter


#5

Definitely sounds like a bug. Time to meridian is most likely checked before autofocus is potentially run. If the AF run takes long, the logic fails.


#6

yes - the CFZ is too narrow, and the temperature falls too quickly for me to really get a good set of filter offsets for this OTA. works fine on my reflectors but i just couldn’t get offsets working reliably with this refractor.


#7

OK, I get what you’re saying now. Naavis is probably right: the next exposure is called for, then autofocus is called for and if AF takes a long time it deprecates the time to meridian flip. I wouldn’t call that a bug but it is worth looking at to see if the order of things can be changed.

In any event, I highly encourage you to consider filter offsets and focus with the LUM filter. It saves loads of time. I simply can’t imagine wasting all that time autofocusing. I understand that you may have good reasons for doing so, but I wouldn’t have the patience.


#8

it’s just not feasible for me to compute the offsets on this OTA. but it’s sort of irrelevant - focusing and restarting the guider take minutes in any case; if SGP is not computing the time to meridian immediately before the exposure starts, you might put the telescope into the pier in the corner case where there were just N+epsilon minutes left before autofocus, which is apparently what happened to me. so as long as the autofocus takes more than 0 seconds, it can happen.


#9

Logs, LOgs, logS, LOgs please. :wink:


#10

ok sorry… it’s Log, Log, Log! (from blammo)

seriously though my imaging computer is now on the rig so i’ll have to go uncover it to fire it up and retrieve the log.

rob


#11

here is the log:

https://drive.google.com/file/d/0B6cW4ae2KyMJM3IxUkhnMFVxRlU/view?usp=sharing

the process begins at 10:21:44, when SGP computes that there are 32.75 minutes to meridian flip.
at 10:45:02, autofocus completes (23.3 minutes later)
at 10:46:11, an 1800s exposure begins (24.48 minutes later; there are 8.267 minutes to the meridian)
at 11:16:32, SGP executes the meridian flip. that’s 22 minutes past the meridian and as luck would have it, about 2 minutes before the camera would have hit the pier. since i’m running APCC, there would be no pier collision, though everything would come to a grinding halt since APCC would have stopped the mount and locked out all slews.

[ a wider question is - is there an ASCOM mechanism by which SGP could ask the mount where its meridian limit is? APCC allows definition of a “surface” past which the telescope should not track, meaning that the stop RA is a function of the scope’s declination. also, there are a couple of places in my rig where the limit is actually before the meridian, which i think is pretty problematic as as far as i can tell i can’t tell SGP that the meridian limit is before the real meridian.]

thanks,

rob


#12

There’s nothing at present but there has been a suggestion that this be added. Something like TimeTheMountCanStayInThisPointingState and TimeUntilThePointingStateCanBeChanged. It’s going to be a long time before the definition is changed and even longer before there are drivers that support it - and a significant number will probably never change.

Chris R


#13

thanks for the reply… that’s a bummer!


#14

I can think of a way to make this work, but it would require exposing the “Minutes past Meridian to flip” value to an external application.

I could create a helper application that would continuously read the meridian delay value from APCC and then set the value in SGP when it has changed.

So, Jared and/or Ken, is it possible, or would it be possible, to set the “Minutes past Meridian to flip” value programmatically?

-Ray Gralak
Author of APCC
Author of the Astro-Physics V2 ASCOM driver


#15

Thanks. I needed to check a few things in the sequence to validate some suspicions. I have a fix that will abort the exposure if pre-exposure activities took too long. In this case, it will just wait for flip.


#16

@rgralak Jared and I can discuss this. Right now there is no method to control that setting externally.


#17

cool, thanks for taking a look at it & fixing it. do you think this will make it into the next beta?

ray’s suggestion would be a great workaround in the absence of real ASCOM support.


www.mainsequencesoftware.com