SGP and Auto Meridian Flip


#21

i have a rotator… filter wheel orientation can be anything so i have to pick the most conservative angle.


#22

I am not sure I understand here. If you want to flip several minutes before you hit the meridian, is there some reason you could not shift the meridian delay ahead of the natural meridian by the same number of minutes, and leave SGP’s value at 0? I guess my point is, if you want to flip early, just use AP’s meridian delay feature…you shouldn’t need a negative value in SGP…


#23

in my case i was talking about 40mins or so before the meridian, not just a few minutes.

regardless, SGP won’t issue the slew that causes the mount to flip over until it’s crossed its own meridian. so the earliest you can ever flip under SGP’s control is at the true meridian (0 minutes). [edit: on an AP mount or any mount that does not support setting SideOfPier.] even if APCC (or the AP driver) is programmed to have an early meridian, it won’t matter.

APCC has a meridian limit feature to flip the mount when the meridian limit is reached, but SGP would not be happy with any mount that just spontaneously flips. in the best case the recovery code would take care of it, but in the worst case, that flip might be the end of your imaging plan.

rob


#24

Rob,

regardless, SGP won’t issue the slew that causes the mount to flip over until it’s crossed its own meridian. so the earliest you can ever flip under SGP’s control is at the true meridian (0 minutes). [edit: on an AP mount or any mount that does not support setting SideOfPier.] even if APCC (or the AP driver) is programmed to have an early meridian, it won’t matter.

A-P mounts will “flip” based on the set meridian delay, so if SGPro issues any slew the mount’s meridian delay controls the flip point (not SGPro). So, in APCC you could set a negative Meridian Delay for both East and West pier sides such that any slew to a target withing the negative limits will force a counterweight up slew and SGPro would not have control over that.

-Ray


#25

but this is exactly the problem. SGP will not issue a slew inside of the currently executing target unless it believes the mount has crossed the meridian. for SGP’s purposes, this is either at the true meridian (0 minute delay) or some number of minutes past the true meridian. so it doesn’t matter if an early meridian is set in the AP driver or APCC - SGP simply will never issue the slew that would cause APCC/the driver to flip the mount.

if SGP allowed setting a negative number in it’s meridian configuration, then SGP would ostensibly issue a slew before the true meridian is reached, and then if there is an early meridian set in the AP software, the mount would flip. but SGP apparently won’t allow a negative number in that field because the AP driver/APCC makes SideOfPier read-only.

i don’t know what else to say except that i’ve tested this over and over again and there does not seem to be a way to cause SGP to issue a slew before the true meridian, regardless of how APCC is configured with respect to meridian delay and meridian limits.


#26

Sorry, because of a technical issue (I’m waiting for a new camera) I have not had a chance to test this yet. But, say the meridian delay is set to -3 hours for both East and West side of pier. If the first target is 2 hours before the meridian a slew to the target’s RA/Dec would thus cause the mount to end up in a counterweight-up position pointing 2 hours to the East of the meridian.

How would SGPro know not to do such a slew? All SGPro knows is to send RA/Dec and that automatically results in a counterweight up position because of the meridian delay in the mount.

-Ray


#27

Ray, we’re talking about two different things here. the mount will of course do whatever the mount is programmed to do when SGP issues a slew. that’s not the problem (and in fact, flipping by virtue of a slew is what SGP is counting on.)

specifically, OP’s question is about the SGP feature called “auto meridian flip.” this is a feature intended to flip the mount when the target being imaged crosses the meridian. i don’t think this is particularly controversial or unique, since pretty much any serious imaging package has a feature like this. in the absence of this feature, camera crashes into the west side of the pier are very likely to occur.

SGP has implemented this feature two ways. on a mount that allows writes to SideOfPier, SGP writes SideOfPier when it decides the target being imaged has crossed the meridian. if the mount does not allow writes to SideOfPier, it waits until the target has crossed the meridian, then issues a slew which it assumes will cause the mount to flip.

SGP has its own meridian delay configuration, which it consults to determine if it thinks the target currently being imaged has crossed the meridian. an implementation detail is that if the mount does not support writing SideOfPier, then negative values in the meridian delay value (meaning meridians earlier than the true meridian) are not allowed. hence, any mount with read-only SideOfPier can only be flipped at or after the true meridian. AP mounts belong to this class of mounts.

so i hope you can see what i’m talking about now. it won’t matter what the meridian delay is set to in the driver or APCC. SGP simply will not issue the slew necessary to flip the mount until it’s crossed its own meridian, which is limited to be at or after the true meridian. what the mount does when that slew is commanded is up to APCC or the driver, but SGP’s intention is for the mount to flip at that point. incidentally that means that if APCC or the AP driver has a later meridian configured than SGP, SGP won’t actually succeed in flipping the mount and later on you’ll probably have a pier crash.

anyway, the only known workaround for this behavior was posted by @benkolt over at CN (and maybe here as well) - you have to split your SGP target into two targets, with the 2nd target start time carefully crafted to line up properly with your meridian delay configuration in APCC/Driver. this forces SGP to issue a slew to the same target, which will cause the mount to flip. if you’ve done it right, you can cause SGP to flip the mount before it has reached it’s own idea of the meridian.


#28

Rob,

The whole point of the East side meridian delay is for SGPro to never have to do a pier flip. The mount starts in counterweight up position via the first slew to the target. And there will not be a pier crash if you also use the horizon limit to stop tracking if the mount ever gets that far. What am I missing?

-Ray


#29

Also, if you have a negative East and West meridian delay and the target has not yet reached the limit a slew will result in counterweight-down with pier side = West, But, you could also configure APCC to do an automatic pier flip at the limit. You might lose an image at that point but SGPro would probably have been waiting for the flip point anyway.

-Ray


#30

do you think it is reasonable to start in a counterweight-up position if the target is 30 degrees above the eastern horizon? on almost everyone’s rig, that’s going to put the telescope squarely under the pier and likely result in a crash if the declination puts the camera anywhere the pier or tripod legs. this is not a situation i would choose to be in with automation software. even if i’ve configured all the APCC limits such that the telescope never slews or tracks into the pier, all i’ve done is pretty much guarantee that SGP fails to image anything, or spends a bunch of time in recovery mode trying to figure out why the telescope is not pointed where it should be.

most, if not all people are going to want to start imaging targets as they rise in the east, with the telescope above the pier. personally, i could certainly wait to start imaging until it’s safe to be in a counterweights-up position but i’d lose imaging time, and i’d have to think every single night about all my target start and end times.

as for preventing pier crashes, yes, APCC can prevent that with the various limits. the AP driver can not. AP driver users are going to rely on the auto-meridian flip feature to prevent crashes. furthermore as explained above, AP driver users who need to flip before the true meridian can not do that unless they do the 2-target trick. bottom line is that they may suffer a pier crash unless they jigger their SGP sequence start/end times to either avoid starting a target with the telescope pointing to the east from above the pier, or do the 2-target trick.

all of this would be solved if SGP could somehow recognize that there is an early meridian set in the driver/APCC.

SGP will not necessarily be waiting for the meridian because it has a configuration option to go ahead and take an image even if it will not complete before the meridian is reached. and even if you turn this off, SGP won’t be waiting for any early meridian configured in the driver or APCC because it doesn’t know about it. in both cases, telling APCC to just go ahead and flip the mount causes you ruin an image and risk that SGP’s recovery code does not recover the sequence. if this happens in the middle of the night, you lost a night of imaging unless you want to wake up to fix problems.

bottom line here is i don’t believe the right answer to “auto meridian flip needs improvement with AP mounts” is “configure APCC to obviate meridian flips”. i guess we just have to agree to disagree on this.

regarding the “send limits to SGP” in APCC, if you set the meridian delay for 1h late, does APCC send “60” to SGP? or does it only send 60 to SGP if there is a meridian limit set for 60 minutes past the meridian?

rob


#31

APCC’s meridian limit editor allows you to configure limits for every declination value on both sides of the pier so that an application-invoked pier flip will never hit the pier.

Second, I thought the point of the negative meridian delay is to prevent a pier flip for the entire duration of imaging a target? If you start imaging targets before the flip point then why not just leave the flip point alone, or set a western (positive) flip point if you want to image through the meridian?

as for preventing pier crashes, yes, APCC can prevent that with the various limits. the AP driver can not. AP driver users are going to rely on the auto-meridian flip feature to prevent crashes.

Sorry, but a driver-only situation cannot prevent a pier crash. For instance, a pier crash could happen if the user sets the wrong meridian delay value or even if SGPro or the computer hangs. That won’t happen if APCC is being used with properly defined horizon limits and meridian limits for each declination because the mount will stop tracking if the mount hits a horizon or meridian limit, or loses communication with APCC.

-Ray


#32

APCC sends the limit to SGPro after each slew (as the limit may change if declination changes), or when you enable the option. I believe if you disable the option it sends “0” to SGPro.

-Ray


#33

I’m probably the only one who finds this interplay between SGP and APCC meridian limits to be very confusing and non-intuitive to say the least. Anyone know of a video tutorial that can take me by the hand and walk me through this??


#34

@GeneralT001 The “interplay” is a one way communication (APCC->SGP) where APCC tells SGP the flip point currently set in the mount. You don’t absolutely need to use it so you may want to ignore this thread.

One purpose is to allow the mount to image through the meridian without having to do a pier flip. This might be handy if you are using an off axis autoguider with a narrow field of view, because when the mount flips the camera also flips orientation and there might not be a good autoguider star after the flip. As an alternative to imaging through the meridian you could use a camera rotator to rotate the camera 180 degrees when doing a flip to restore camera orientation and thus get the same autoguider star.

-Ray


www.mainsequencesoftware.com