i have a rotator… filter wheel orientation can be anything so i have to pick the most conservative angle.
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…
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
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
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.
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
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.
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
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
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
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
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
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??
@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
Does anyone have SGP’s pier flip working correctly with APCC when its meridian limits are set? If so, how?
If I understand things correctly, APCC will stop tracking (in my case) when it hits a limit, but SGP is waiting for the mount to go past the limit, which won’t happen since the mount stopped AT the limit. Hence SGP won’t do a slew that causes a flip.
It will only flip after PHD can no longer find the guide star and signals to SGP that something’s wrong, which causes recovery mode to issue a slew. But that takes a few minutes and in the meantime the plate solve prior to flipping will be off since the sky has moved but the mount hasn’t.
Or am I totally confused?
i have it working, but i don’t use the “send limit to SGP” because there’s the risk that the mount stops moving before the slew happens as you point out.
i have the limits in APCC set for about 45 minutes past the meridian, and SGP is configured to flip 5 minutes past the meridian. “wait for meridian” is not checked. i use an exposure length of 30 minutes, so in the worst case if exposure n-1 ends right before the SGP delay of 5 minutes, there’s 30 mins to do exposure n and 15 minutes for SGP to take care of business before the flip. a couple of times an autofocus has kicked in and i’ve gotten very close to APCC stopping the mount, but so far so good.
i had been using “wait for meridian” but i found that sometimes the system would sit idle for up to 30 minutes waiting for the meridian to be crossed. “wait for meridian” is probably safer though as SGP would tend to issue the flipping slew almost immediately after the meridian was crossed, thus eliminating the possibility that APCC stops the mount.
You are confused. I don’t know this mount but in general the mount and SGP do not communicate about a flip. You want to set SGP to flip before you reach any limits on the mount. A limit on the mount is just for safety and has nothing to do with SGP doing the flip. There are two ways the SGP can do a flip. For mounts that support it, SGP can command the mount to flip before (or after) the meridian. Otherwise, SGP has to wait until the mount is past the meridian and issue a slew. I believe the APCC is in the later category.
If I am right about the mount, set SGP to flip a little after the meridian (1 to 5 minutes). Set the mount to STOP after that for safety (3 to 8 minutes past the meridian). SGP has to be in complete control of the flip. If the mount flips uncommanded by SGP, it will ruin the current image.
except for the fact that with APCC it kind of is related, since ray put in the option to communicate the limit from APCC to SGP. as ray acknowledged upthread, he needs to pad this a little bit to avoid exactly the scenario @EricC is asking about. as we’ve both pointed out, there needs to be a difference between APCC’s limit and SGP’s programmed meridian.
correct; APCC-driven AP mounts and “driver-only” driven AP mounts are the same in this respect.
yep, and then you’re at the mercy of the SGP recovery mode code (which would probably save the day, but why risk it?)
pfile, thanks for the info. Are you using “meridian limits” (where you define the limit for various DEC values), or are you only using “meridian delay”? In my case (“meridian limits”) the limit varies by DEC so I would have to adjust SGP’s delay for each DEC and exposure length. For example, if the limit for the current DEC was 2 hours past the meridian and I was taking 30 minute exposures, I’d set SGP to wait 1h20m. Correct?
It sounds like “Send limit to SGP” in its current form doesn’t help, and it needs the padding Ray mentioned. Wouldn’t that eliminate the workaround of manually having to configure SGP?
If someone has APPC, meridian limits, AND “Send limit to SGP” working I’d like to know how. I suspect no one does have them all working.
DesertSky, pfile: in the scenario I described (APPC with meridian limits), APCC is not in that category. It won’t work for SGP to wait until the mount is past the meridian since it will never go past the meridian because the meridian limit defines where the “meridian” is, and the mount stops tracking when it hits the limit.
i am using meridian limits. i don’t change the meridian delay - haven’t had the need to. i’m OK with a pier flip right at the meridian, or up to right around 50m after the “true” meridian, hence the 45 min limit in APCC.
yes, that was the idea - since APCC can have varying meridian limits, SGP’s single delay value would have to be set to correspond with the most restrictive APCC limit to avoid the mount prematurely stopping. ken/jared provided an API call so that SGP’s meridian delay can be set by an external program, and ray set up APCC to use that API to transmit the current APCC limit to SGP. but i’m not sure it works because of the lack of padding.
that’s not correct - the meridian delay in APCC (or the driver, if you don’t have APCC) is what sets the point at which a slew would cause a meridian flip. the meridian limit is just that, a limit that the mount should not exceed while tracking. if that weren’t the case then my system would never flip (and it does 
)
i think part of the confusion here is semantic in nature. APCC’s meridian limits are independent of the meridian itself. SGP’s setting is actually a meridian delay, not a limit per se. so having APCC send its meridian limit to SGP’s meridian delay is a little bit of mixing up apples and oranges, and that’s why SGP’s meridian delay needs to be set some number of minutes earlier than the limit set in APCC. adding to the fun, SGP’s meridian delay must be later than whatever meridian is configured in APCC, or SGP won’t be able to flip the mount when it tries to.
as mentioned upthread, before i put my telescope on risers i had the need to flip pre-true-meridian at certain declinations. after the risers, i am able to track past the real meridian for at least 50 minutes even in the worst-case situation. so the ‘static’ configuration i described works fine for me.
i guess all of this depends on how married you are to imaging past the meridian. personally i don’t care to keep the mount in a counterweights-up state as long as possible. i just want 1) the mount to flip before the camera would hit the pier and 2) to not lose a bunch of imaging time waiting for the flip point. if that puts the flip at 5 minutes after the true meridian or 45 minutes, fine with me.
so yes, if the current dec allows you to go 2 hours past the meridian and you’re willing to go all the way, then i guess you can set SGP for 1h20m safely. in the case where SGP starts an exposure right at the 1h20m mark, that takes you to 1h50m and then leaves 10 minutes for SGP to save the image, platesolve (if you want it to) and then issue the slew that causes the flip. but your meridian delay in the driver needs to be set to something less than 1h20m so that if SGP decides to flip right at 1h20m, APCC interprets that slew as requiring a pier flip.