Paramount now failing meridian flip

I had this working without trouble for a couple weeks, but in trying to reduce the amount of time lost while waiting for meridian flips, I messed the with TSX settings, and now SGP occasionally reports that meridian flips fail.

Does the hour angle for the flip in TSX need to be set to precisely zero, since I’ve set it to zero in the SGP automatic meridian flip box? While the little red box on the TSX sky chart looked accurate, tonight when I opened the Bisque TCS dialog I noticed that Parameters>Flip Hour Angle was off by about 0…01. Would that explain it? I manually entered zero for it tonight.

Two logs with meridian flip fails are below.

Kevin

Any ideas on this? Flips that are required because the rig is slewing to a new target succeed, but when it tries to flip on the same target, it fails. Last night it failed about 2:30am. A link to the full log is here, but I think the important snippet is pasted below. It looks like SGP checked for side of pier only one second after issuing the flip command, so the start and end sides were the same. Any idea why that happened?

[11/11/17 02:30:07.732][DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[11/11/17 02:30:07.735][DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[11/11/17 02:30:07.735][DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using slew
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] Telescope: Using “OFFSET” sync option, updating slew cooridnates with offsets:
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] RA: 0.381148457829244 hours
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] DEC: 9.21469243816783 degrees
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 5.71722686743867 (05h43m02.02s) Dec: 9.21469243816783 (09°12’52.89")
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting…
[11/11/17 02:30:07.749][DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 5.73364175612542 Dec: 9.2207299378915
[11/11/17 02:30:08.765][DEBUG] [Telescope Thread] Scope reports it is done with synchronous slew, verifying…
[11/11/17 02:30:08.767][DEBUG] [Telescope Thread] Telescope: Slewing has completed
[11/11/17 02:30:09.267][DEBUG] [Telescope Thread] ASCOM Telescope: Failed to flip because starting pier side and ending pier side are the same!

Kevin

What’s probably happening is that the slew position sent to the mount does not need a pier flip and so the mount reports that the slew to the current position has finished rapidly, then the check on side of pier correctly reports that the pointing state has not changed and SGP gives up. Things such as sync may mean that SGP thinks the position is past the meridian while TSX thinks it isn’t.

Setting a delay in SGP so that the pier flip is only attempted after the mount has moved significantly past the meridian may help. I suggest about 4 minutes.

If I was developing SGP I’d do the meridian flip differently so that a failure to flip is not considered to be fatal but to continue, maybe collect another image, and try again. The additional time will allow the mount to track sufficiently past the meridian that a subsequent attempt will work.

1 Like

Thanks as always for the help, Chris. I had Minutes Past Meridian to Flip set to 0 and Wait for Meridian checked. I’ve increased the Minutes Past setting to 4.

Checking my planetarium software, the target was 35 seconds past the meridian when SGP recorded the meridian flip command. Are you thinking that something in TSX might reject a flip command? Or is it that the Sync Behavior settings in SGP create some internal confusion within SGP? I’ve got Sync Behavior set to Target Offset, and Inhibit Sync to Protect TPoint is checked in the ASCOM setings dialog.

Kevin

PS: checking the logs above, I see three other fails. Two happened when the target was about 1.25 minutes past meridian, but one happened when it was 31 minutes past meridian. So I’m not sure adding 4 minutes will help. But I’ll try it.

There is no flip command, just a slew command. In theory if TSX thinks the mount has tracked past the meridian then the slew will require a flip and not it won’t.

You are using offset sync so it is entirely possible that SGP thinks the mount is past the meridian while, because of the difference in position that the offset can generate, TSX thinks it isn’t.

I’m not sure about the 31 minute difference but if the offset sync can handle that amount of difference then it’s possible that the offset is of this magnitude. In that case you might need more than 31 minutes delay.

Hi Kevin,

Actually SGP uses minutes of time for the meridian delay. So, the delay corresponds to 4 x 15 = 60 minutes of arc.

SGP uses the ASCOM standard to communicate with the telescope and ASCOM has no “flip” command. The flip is implemented by issuing a “Slew To Coordinates” command. If the target is past meridian, the telescope will automatically flip as a well behaved telescope controller will try to reach the target with a “weigths down” configuration. As Chris allready explained, the issue is that by having the meridian delay set to zero, SGP might think the target is already sligtly past the meridian and will issue a “Slew to Coordinates” command. On the other side, TSX might think that the mount can reach the target coordinates without having to make the flip and will just go to the requiere coordinates w/o flipping.

Kind regards,
Horia

So SGP doesn’t command a flip at all? It just issues a slew command, relying on TSX to conclude a flip is necessary, and then SGP checks to make sure side-of-pier has changed. If not, SGP aborts the sequence. All correct so far? And we’re thinking that by postponing the flip until several minutes past meridian, TSX will agree that a flip is necessary and thus perform one, so SGP will find that side of pier has changed?

The thing is I’m kind of surprised that when the target is already a minute (time, not arc) or so past meridian that TSX wouldn’t agree that it’s time for a flip. Anyway, TSX is set to flip at meridian - as near as I can tell, I don’t have any delays set up in TSX. But maybe there’s some setting I need to check?

Thanks for all the help.

Kevin

Yes, correct. That’s what we have been saying in numerous posts.

Is doesn’t matter if you think the position is past the meridian, or if SGP thinks the position is past the meridian, it’s what the mount thinks that matters. If the mount doesn’t think it needs to do a flip then it won’t.

The reason for all the syncing is that there is disagreement about the mount position relative to the sky and given that there must be uncertainty about when the flip will happen. Once you start syncing, especially offset sync, you don’t know where the mount thinks it is pointing and so when it will expect to do the flip.

In addition it may be possible that an advanced mount such as a Paramount can be set to have the flip position set differently to the meridian. Even the Celestron mounts can be set so the flip happens up to 20 degrees before or after the meridian.

This is why I’m suggesting that SGP should have some sort of retry when a flip fails. This would allow the sequence to continue with no consequences other than a delay.

Chris, thanks for patiently explaining this. I think I’m finally starting to get it. Hopefully the delay will help. And yes, the Paramount can be set to flip wherever the user wants. Right now mine is set to flip at the meridian, though I could go 15 minutes past before a pier crash. I’m in the process of modifying my setup to allow 40 minutes or so,

One extra factor that I didn’t think to mention is that I use a pre-Edge C11 - meaning mirror flop. I’m guessing that might be throwing things off even further.

Kevin

Can you set the Paramount so the flip point is slightly before the meridian? This would help to ensure that when SGP expects to flip the mount will do it. The down side to this is that if you slew to an object that’s just before the meridian the flip will already be done and SGP will fall over because of this. But that’s more under your control.

Also ensure that the mount alignment is close to reality so that the sync offsets that SGP uses are small, smaller than the tolerance that the flip delay is there to correct.

I have a MX and similar clash conditions. Set the Paramount flip points to just within your safety limits and set SGP to say 5 minutes. That should be sufficient. I would also recommend enabling the ‘wait for meridian’ option in SGP, so that there are no early slews (say when you have 20-min NB subs).

Chris and Buzz, thanks for the good advice. Buzz, when you say to set the Paramount flip points to just within my safety limits, you mean the software slew limits in Bisque TCS? I can safely go 15 minutes past meridian. If I set that as my flip point and set SGP to flip at 5 minutes past meridian with wait for meridian checked, I would have thought that SGP would issue a slew command to flip at 5 minutes past but TSX wouldn’t flip, since it’s waiting for 15 minutes past? Wouldn’t this result in an error and an abort in SGP?

Kevin

Kevin - there is no ‘flip’ command as such from SGP. Just a slew command, which, once the mount is on the other side of the meridian, causes a flip. So, in your case, with 15 min limit in Bisque TCS and 5 in SGP. If after the last exposure in SGP, it realizes it will go past 5 minute on the next exposure, SGP does not start the next exposure. With the wait option, it simple stops exposing and waits for the 5-minute past before issuing another slew.

It is easier to see than describe. Just select a star 10 mins from the meridian and set up a sequence of 5 min exposures and watch what happens. You can always disengage the clutches if you do it wrong.

Followup. I made some hardware modifications - I swapped pier top plates between my two piers and redid some cable management - and now I can track 1h20m past the meridian. So I set the flip for 30 minutes after the meridian, and unchecked Wait for Meridian. I just watched it do a flip without trouble. Thanks to Chris, Buzz and Horia for all the help on this.

Kevin