Failed meridian flip with APCC and SGP and AP900 mount

Hi everyone,

I use an AP900 mount with CP3, APCC and SGP.

Had a failed meridian flip the other night with SGP saying "[02/03/22 22:30:49.537][DEBUG][Main Thread][SQ;] Sending Notification: Error - Cannot Run Meridian Flip:

-Telescope must be pointed across the meridian to pier flip.:.

[02/03/22 22:30:49.530][DEBUG][Sequence Thread][SQ;] Running blocking meridian flip…

[02/03/22 22:30:49.530][DEBUG][Main Thread][SQ;] Adding sequence level notification: Running automatic pier flip…

[02/03/22 22:30:49.532][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Running automatic pier flip…

[02/03/22 22:30:49.535][DEBUG][Main Thread][SQ;] Adding sequence level notification: Cannot Run Meridian Flip:

-Telescope must be pointed across the meridian to pier flip.

[02/03/22 22:30:49.537][DEBUG][Main Thread][SQ;] Sending Notification: Error - Cannot Run Meridian Flip:

-Telescope must be pointed across the meridian to pier flip.

This is the second time this has happened.

Has anyone had this happen to them?

Clear skies.

John K.

Seems like maybe you might be trying to flip just a smidge too early and your mount doesn’t support it. Assuming your mount can track across the meridian for a few minutes try setting flipping 3 to 5 minutes after you pass meridian.

Thanks Ken.

Here are some screen shots:



Right, so I’m not 100% certain this is the issue, but change the “Minutes Past Meridian to Flip” value from 0 to somewhere between 3 and 5 (ish)

Thanks Ken.

@Ken, it looks like Meridian limits were off in APCC so the flip point was the meridian. Shouldn’t SGP make sure the scope has reached the meridian before trying to do a pier flip?

-Ray

Well certainly. We don’t have any logs in this case so the origin of the flip is not clear. We can take a look if @Johnk can provide them.

Hi guys,

Here is the link to the log file:

https://drive.google.com/file/d/1eRAlPShz3TE6JCHhZezwc365p8EMl0Vj/view?usp=sharing

Oh my… that log has dozens of entries in it showing that the connection to the mount was lost at around 22:15 (maybe a cable management issue?). For that I cannot account, but what we can do is guard against these default values when this situation occurs:

[02/03/22 22:30:49.530][DEBUG][Sequence Thread][SQ;] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 0 >= 0

@Ken, those “loss of connections” seem to happen right after SGPro is serializing a camera image. Could that be causing SGPro’s GetCurrentPos to fail? What exactly does GetCurrentPos() do? That is not an ASCOM method, is it?
[02/03/22 22:28:25.982][DEBUG][MF Update Thread][SQ;CC;] Performing serialize…
[02/03/22 22:30:18.589][DEBUG][CP Update Thread][SQ;CC;] ASCOM Telescope: Error in GetCurrentPos

[02/03/22 22:30:37.990][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: exposure complete, waiting for camera to report image ready…

Anything is possible I guess, but I suspect that this problem would be fairly widespread if it were true (especially since this version of SGPro has been around for more than 2 years). In addition to that, despite being consecutive logs statements, those events are about 2 minutes apart (meaning that many successful communications with the mount have occurred between sequence serialization and the first communications loss). It’s likely just a weighted coincidence since, when SGPro is waiting on integration, the only thing it does is auto save the sequence and update the UI (which is what those log statements are about).

Yes and no. That specific method is SGPro’s wrapper around the ASCOM function. The error is a hybrid error where “ASCOM Telescope: Error in GetCurrentPos” is from SGPro and the latter part of the message “Lost communications with mount.” is from the ASCOM layer or the AP layer. In this case, SGPro just relays the driver’s message.

@Ken, yea but this seems too much of a coincidence to ignore that every “communications failure” happens when there is an image download. For example, it could be a USB bus bandwidth problem if both the camera and scope are sharing the same port or pair of USB ports on the computer. So, claiming a cable management issue doesn’t seem correct to me. :slight_smile:

-Ray

The scope uses a an ASI1600mm camera with 2 x USB ports and with a USB3 cable. A starlight express camera and OAG is then attached to one of the ASI1600mm camera USB’s. The USB 3 cable then plugs straight into my laptop.

@Johnk , are the two USB ports on the laptop next to each other? The hardware for USB ports in most computers is designed in pairs, so even if you use two discrete USB ports there can be a bandwidth issue if the two devices are using the same pair. If you have a third USB port on your laptop, try connecting the mount to that port to see if the issue goes away. Also, consider trying ethernet or wifi if there is still an issue or if you don’t have an extra USB port.

-Ray

If that were true, I wouldn’t disagree. I think you are misinterpreting the logs. Despite many log occurances, there are only 2 instances of the loss of communication. One at 22:04 and one around 22:30. There really isn’t enough data here to establish any kind of pattern. That said, of the two failures, only one follows “Performing serialize…”, most notably, the first at 22:04 does not. Second, if during integration wait periods, there are only 2 things that happen, update the UI and save the sequence, it holds true that “Performing serialize…” will probabilistically always be directly in front of or behind a failure during this same time. Last, “Performing serialize…” refers to saving the sequence to disk and is not related to the CCD image or it’s download in any way. The first loss of communication happens nowhere near camera download (or even saving the sequence). In any case, saving a sequence takes less than 1 second and is very unlikely to affect USB communication.

I don’t claim a cable management issue, I claimed I don’t know why it’s happening and it’s a thing to maybe check and I still stand by this as a possible cause.

@Ken, there were 4 instances in the entire log, but there may be more than one cause. It’s hard to say what the actual problem was because I don’t see that the sgpro log exposes the actual exception from the ASCOM driver so it’s impossible for me to say why GetMountPos() timed out and threw an exception. Here are the places where serialize occurs before a string of timeouts:

[02/03/22 22:05:37.102]
[02/03/22 22:30:18.589]
[02/03/22 22:31:04.955]
[02/03/22 23:50:48.727][

-Ray