Failed meridian flip with AP1100 mount and APCC Pro

Good morning,

Last night, the sequence aborted due to a failed meridian flip. I am trying to understand if the issue is with the configuration of APCC Pro or SGP. Looking at the log, it appears that SGP reported an issue because the side of pier did not change. Meridian limits are set up so that the scope would be well in the West at the declination of the target when the meridian flip is triggered. Any suggestion is appreciated.

Best,

Luca

Mount: AP1100 running APCC Pro with meridian limits.

Aprox time of issue: 2:57am

Link to Logs

Useful Info

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.457
.NET: 4.8

You might want to post at ap-gto Groups.io and include logs from APCC and A-P V2 ASCOM driver and Ray Gralak may be able to help you.

https://ap-gto.groups.io/g/main/topics

I have A-P1100 but no APCC and never had issues with Meridian Flips.

Peter

Hi Luca,

Can you provide the APCC logs using APCC’s log zipper utility?

The SGPro log, which you provided, won’t help much to figure out what happened except the approximate time (3:12am).

Thanks,

-Ray

Hi Ray,

Here is the link to the APCC log files:

Thank you,

Luca

Thanks Luca, I have downloaded them.

-Ray

From the SGPro logs, it seems as though the mount was well past the meridian and when SGPro issued the command to slew to the current position, it was ignored.

Ken,

Thanks for taking a look. It was well past the meridian because it physically can - APCC Pro allows one to set meridian limits for each declination. This doesn’t mean that a meridian flip is not necessary eventually.

Ray is taking a look on the APCC side of things. It is possible that I simply did not setup APCC correctly.

If everything worked properly, the telescope was supposed to be on the West side of the mount, pointing West (Counterweights up) and after the meridian flip the telescope was supposed to be on the East side of the mount, pointing West (counterweights down). Is there a way from the log to tell if:

  1. Did the slew happen?
  2. what was the initial and final side of pier?

thanks,

Luca

According to SGPro it did, but it was clearly ignored

west and west

Hi Luca,

It looks like there is a configuration conflict. You should uncheck one of the checkboxes to slew within East/West limits and uncheck the Limit to meridian checkbox. If you have both East/West checked as your screen shot shows then the mount won’t flip within that range, which looks like what happened. I suggest you enable only slews within West limits, uncheck the limit to meridian checkbox, and increase the flip offset time to at least 5 minutes more than your exposure time.

Also, I noticed the mount’s firmware is out of date so you might want to get the latest from A-P.

-Ray

Ray,

I made the changes you recommended and the behavior is still not as desired. This is a little puzzling because I have been using APCC Pro and SGP with my Mach1 for well over a year without any meridian flip issues (with the settings as in the screenshot). The AP1100 is a new to me mount that I have recently started using and I simply copied the configuration from the Mach1.

So tonight I ran a test close to Zenith.I made the changes in the Meridian limit configuration you recommended. I let the mount image until it went counterweights up. From the log, it appears that SGP thought the mount was East side of pier (even when it was pointing West, counterweights up) and never issued a Meridian flip command. Ultimately, APCC Pro issued the slew command while SGP was in the middle of an exposure, when the meridian limit timer ran out.

I am at a loss here. I don’t understand what changed and why this is not working.

Logs from tonight’s run:

SGP:

APCC Pro:

Thank you to both of you for the help.

Best,

Luca

Luca,

Can you share a screen shot of your APCC meridian tab settings?

-Ray

Here you go, Ray. Can you explain what does Limit to Meridian do? I don’t understand the explanation in the APCC documentation. Also, isn’t it correct that to enable pre-flipping the mount for targets in the East, the East Limits checkbox should be clicked?

Thanks again,

Luca

From the SGPro log it looks like the limit was never reached which is why the scope did not do a pier flip.

-Ray

Luca,

In order to do pre-flipping on the East side the right side of the meridian limits (WEST) would need to be reflected onto the East side (negative/left of 0 hour angle) and both East and West Limit check boxes would be checked. However, you are able to accomplish the same thing (entire image sequence on one pier side) with the options you have set and this APCC configuration is more intuitive.

-Ray

i have had trouble with this of late and if the weather ever clears i will post the log. basically if i remember correctly SGP tried to flip before the meridian had been passed. i’m of course using the feature you put in to communicate the limit (with the offset) and had not changed the setting in forever. the offer is such that SGP should wait until the meridian is passed before trying to flip.

after having the problem i reduced the offset a tad and it started to work again but that doesn’t prove anything as the problem was intermittent in the first place.

Ray,

I had already closed APCC, so it’s not connected to the mount and doesn’t show where the flip happened. As I mentioned in my previous post, APCC started the flip when the mount reached the meridian limit. The problem is that the flip did not start within the previous 20 minutes at the behest of SGP. A quick scan of the SGP log seems to imply that SGP thought the mount was already counterweights down pointing to the West, and a meridian flip was not necessary.

If that’s true (and I can assure you that the mount was counterweights up and required a flip), it speaks to a breakdown in communication between SGP and APCC. Both are doing the right thing by themselves, given the circumstances, but they are not communicating relevant information.

Luca,

The logs show that APCC had sent values from 75-90 minutes delay to SGPro so the mount can definitely go into a counterweight up position. And imaging in a counterweight up position is the whole point of using the meridian delay in an Astro-Physics mount.

Here are the limits APCC sent to SGPro, including line numbers:

File: APCC-2020-03-16-192704.txt (20 hits)
Line 107571: 0107571 2020-03-16 20:05:58.515: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgGetFlipDelay, Params:
Line 107571: 0107571 2020-03-16 20:05:58.515: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgGetFlipDelay, Params:
Line 107573: 0107573 2020-03-16 20:05:58.681: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:87}
Line 107573: 0107573 2020-03-16 20:05:58.681: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:87}
Line 107574: 0107574 2020-03-16 20:05:58.762: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgSetFlipDelay, Params: {“DelayInMinutes”:90}
Line 107574: 0107574 2020-03-16 20:05:58.762: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgSetFlipDelay, Params: {“DelayInMinutes”:90}
Line 107575: 0107575 2020-03-16 20:05:58.771: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:90}
Line 107575: 0107575 2020-03-16 20:05:58.771: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:90}
Line 107576: 0107576 2020-03-16 20:05:58.771: Info, DelayToSGPro, Set SGPro Flip delay to 90 minutes
Line 107576: 0107576 2020-03-16 20:05:58.771: Info, DelayToSGPro, Set SGPro Flip delay to 90 minutes
Line 390753: 0390753 2020-03-16 21:44:14.150: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgGetFlipDelay, Params:
Line 390753: 0390753 2020-03-16 21:44:14.150: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgGetFlipDelay, Params:
Line 390754: 0390754 2020-03-16 21:44:14.153: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:90}
Line 390754: 0390754 2020-03-16 21:44:14.153: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:90}
Line 390755: 0390755 2020-03-16 21:44:14.153: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgSetFlipDelay, Params: {“DelayInMinutes”:75}
Line 390755: 0390755 2020-03-16 21:44:14.153: Debug, SGPro_SEND, SgProCam : Sending: http://localhost:59590/json/reply/SgSetFlipDelay, Params: {“DelayInMinutes”:75}
Line 390756: 0390756 2020-03-16 21:44:14.154: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:75}
Line 390756: 0390756 2020-03-16 21:44:14.154: Debug, SGPro_RESP, SgProCam : Response: {“Success”:true,“Message”:“Success”,“DelayInMinutes”:75}
Line 390757: 0390757 2020-03-16 21:44:14.154: Info, DelayToSGPro, Set SGPro Flip delay to 75 minutes
Line 390757: 0390757 2020-03-16 21:44:14.154: Info, DelayToSGPro, Set SGPro Flip delay to 75 minutes

-Ray

Ken and Ray:

Last night exactly the same problem as originally reported happened. I am not there at 3am to see if the slew happens but I ask the question again. Is it possible that SGP is reporting side of pier incorrectly when the mount is counterweights up? If I look at the SGP log, everything appears to have gone well until SGP aborts because it says that the side of pier is the same before and after the flip.

How does SGP determine side of pier? Does it receive that information from the mount or does it calculate it independently?

Logs:

Link to Logs

Dropbox - File DeletedScreenshot 2020-03-18 07.41.28|800x270

Useful Info

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.457
.NET: 4.8

Doing a little bit of digging in the log files. Correct me if I am wrong but I think there is an incosistency between the SGP and APCC logs.

SGP says side of pier before and after flip are both West.

AP ASCOM log says side of pier before flip is West, after flip is East.

I think AP ASCOM reporting is correct. Why are the side of pier reported differently between the two logs?

Hi Luca,

I mentioned that you had out of date firmware a couple days ago. Is there a reason why you have not updated your firmware yet? The reason I am asking is that there can be slight differences in behavior between versions. This is not likely the cause of the issue you are seeing but it is best to make sure you are running with the same or later firmware as what I test with.

Your mount is using “VCP4-P01-11” firmware. Please update to at least “VCP4-P01-13” as soon as possible. You can contact George at Astro-Physics if you don’t know how to get new firmware.

Thanks,

-Ray