I had meridian flip set to 3 degrees past the meridian and ran into a problem last night that I can’t seem to explain. I’m assuming I’m missing something with the math. So, today, I changed it to 2 degrees past meridian. Here is a screen shot of what it was showing me. Can anyone explain the discrepancy between the number in the bottom right (which I assumed was when the flip actually occurred) and the top left (which is when SGP was telling me it would actually happen)?
Yeah something doesn’t seem right there. I always thought the lower right number was the time to meridian FLIP (not time to the meridian). I’ve never seen the message in the upper left.
Lower right is the time to or from the meridian. Not the time to the flip. Maybe this should change?
But your numbers make sense. Essentially you’re 1:51 minutes past the meridian and have the wait for meridian set and have 329s to go. Which is roughly a total of 8 minutes for the sum of those 2 (the time to track 2 degrees)
Jared
1 Like
Although “time to flip” will almost never be accurate unless you use the wait options. Same as the value in the Control Panel.
Jared
1 Like
Wow, that really explains a lot. I guess I was always using my ‘time to limit’ on my mount and comparing that against the time in the bottom right. I didn’t realize that I had to account for the ‘degrees’ past.
Is there any way to allow a tenth decimal place in the meridian flip dialog? I’d like it to be closer but 2 is a bit too close and 1 is on the ragged edge for me :).
Maybe we will just change this field to minutes before or after meridian (instead of degrees). This will mean that if you are not going to use the “wait” options (the only precise way to determine flip time), you must account for two variables (they would both be time based). While the functionality will remain the same, it might be easier to say: “my mount must be able to track minutes past the meridian to flip + minutes of my longest exposure past the meridian” (or I shouldn’t be using settings this permissive). No conversions necessary by the user.
1 Like
I think it would be great if I could tell SGP how far my mount can track past the meridian (minutes or degrees w/ 0.1 deg resolution), and then, since SGP knows how long my exposures are, let SGP manage things so the mount flips before the limit. That way I would not have to decide whether I need to choose “wait for meridian” or not.
As it is now, I need to choose “wait for meridian” depending on the length of my exposures. For short exposures I don’t need to wait, but for long exposures I do need to wait. If SGP knew my meridian tracking limit it could make the choice automatically and I would not have to worry about it. When I have to make the choice manually it introduces the possibility that I forget to set the correct option and opens up the possibility of a pier crash.
Andy
1 Like
How can you do this with any confidence? Doesn’t it depend on DEC? Or would you just choose the most restrictive number based on the worst placed DEC?
This is going to get lost in here. Moving to 2.5 to do “something”… not exactly sure what yet.
1 Like
Andy you have a g11 correct? That mount can flip prior to the meridian. Set your degrees to whatever negative value you can obtain on the other side of the mount. This will buy you more time. I’ll think about the options that you’re suggesting.
Jared
1 Like
I’m using an AP mount now. Life was a lot simpler with the G11. The G11 could flip before the meridian and had trustworthy safety limits. The AP mount will not flip before the meridian and also has no safety limits (!) , so that’s why I’ve been more vocal recently about meridian stuff.
Yes, right, I would like to be able to give the most restrictive number based on the worst placed DEC. That would give SGP a window for when the flip needed to happen – between the meridian and the limit. Ideally SGP would be smart enough to know if it could do the flip between subs or if it needed to wait until the meridian. Hope that makes sense…
Andy
1 Like
Well I’m obviously missing something here. I have a G11 and have it set to 0 deg past the meridian to flip. My exposures always start and finish around the meridian with no messages asking me to wait for flip and no user interaction. I’ve even seen cases with 30min exposures where the exposure started just 1min before the meridian, and the exposure completed and did the flip 29min past the meridian.
Mads image above that shows “the next frame length is longer than the time to the meridian flip…” is completely new to me. I’m assuming that’s because “wait for meridian” is enable. I guess I just don’t see the reason for the “wait for meridian” setting. Can’t most mounts easily track some distance past the meridian?
Correct. This happens only if wait for meridian is enabled.
Jared
1 Like
@Andy I spent a bit of time exploring the feasibility of this today (reviewing code, refreshing my memory on various parts of the sequencing engine). I even went so far as to make a partial implementation to see what problems popped out… This is a very invasive change.
The biggest problem so far is that AF must run AFTER meridian flip because meridian flip is an event that can trigger AF. On top of this, as you have noted before, the AF triggering logic is non-deterministic (some parts of it anyhow)… So this leaves us in a predicament. How do we know how long an exposure will really take to happen? It is not as simple as just using the frame’s exposure time. At a minimum, we must account for:
- Event frame integration time
- Event frame download time
- Possibility of auto focus (would need to refactor AF logic to do this…)
- How many data points in AF
- Exposure length of each AF point
- Download time of each AF frame
- Analysis of each frame
- Total time devoted to focuser movements during AF
- Possibility of several filter changes (how much time per)
- Possibility of focuser movement attached to each filter change
- Temperature compensation
I know many of these things are small, but there are enough of them to make the entire process “fuzzy”. This means that a high precision number for “My mount can track this many minutes past the meridian” is not super meaningful because of our lack of ability to quantify the future.
Ken,
Thanks for taking the time to look into this. I always appreciate how much you and Jared listen to your users.
I will manage for now by using the wait for meridian option.
Andy
You can set the meridian delay to say 1 hour east in the driver and the mount should flip up to an hour early. You likely already know but there are some nice limits features in APCC … Sadly I stopped using it as I was hitting a number of comm issues, but might be worth checking out.
Brian, thanks for the idea on the meridian delay, I may give that a try. APCC is not an option for me either (I won’t go into that here.)
Andy
1 Like
I know this thread goes way deeper than the changes I just made… but for 2.4, I have changed the meridian flip to options such that they now specify an approximate number of minutes to flip before or after the target passes meridian (instead of whole degrees). There is no change in the logic… just hopefully asking for parameters in a more natural way (especially since it seems people want to do time math… e.g. add this time to AF time, then add the exposure time, etc…). If this is not popular (or more intuitive), it is no big deal to return it to its previous state.
At the same time, this change gives you more precision (for whatever that’s worth right now). If you can track 1 degree past meridian, you enter 4 min… 1.5 degrees, enter 6 min and so on.
As a last note (as to why I decided to try this)… lots of folks may not know how many degrees they can track past the meridian. The answer may be be ascertained in an empirical manner and it is likely easier to say: “Meridian is at this time and for the worst placed DEC, my camera will impact in about a minute or so…” then do a quick subtraction of the 2 times and you have an approximate answer.
This is a small change. Just to avoid the possibility of a long thread full of panicked questions, there are no changes to the logic or operation… just how you input data.
2 Likes
Thanks Ken. Great fix!