Meridian Flip Failure Question

Sequence Generator
1

Please look this log file:

At 8:15:27 you will see the mount reported being on the west side. Then a bit later it does a slew to flip. Then it reports that the slew failed, however, there is no reason given. I was not at the scope when this happened but I went looked at it and it had flipped. I wonder if the scope reported the wrong side of the pier but I can’t tell from the log file. Could someone shed some light on why SGP thought the flip failed?

2

The only way this message is emitted is if the starting pier side and the ending pier side are the same.

bDidPierFlip = (pierSideStart != (int)tel.SideOfPier);

Also, you scope reported it was done slewing immediately after we asked it to slew:

[10/8/2015 8:15:27 PM] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 20.8684277777778 Dec: 31.4696833333333
[10/8/2015 8:15:27 PM] [DEBUG] [Telescope Thread] Scope reports it is done with synchronous slew, verifying…
[10/8/2015 8:15:27 PM] [DEBUG] [Telescope Thread] Scope has completed slewing

3

Thanks, doesn’t exactly answer the question but I suspect a pier side reporting problem. I’ve never been too happy with the ASCOM driver for the IEQ45 so I wrote my own. I’ll give it a try this evening.

4

Well, the issue is 2 fold like Ken mentioned:

  1. When we issued the slew the mount reported that the slew was complete immediately. This is problematic
  2. We queried the side of pier after the flip had completed and found that the post-slew pier side was the same as the pre-slew pier side…thus no flip occurred.

So 1 is likely the real issue. I can’t comment the pier side because SGP didn’t wait for the mount to actually get there (it told us it was done already).

Have you ran Conform against your driver? It can help to point out things such as these.

Jared

5

There have been lots of issues with the IEQ45 ASCOM driver. I thought it had gotten better though. We worked with iOptron to address many deficiencies in their CEM60 driver and firmware. I believe some of these were rolled into their IEQ45 drivers and firmware as well. Maybe someone can chime in with more recent results. That was over a year ago.

Jared

6

The iOptron driver does pass the conformance test. The thing I don’t like about it is they insist on bringing up a control panel in the driver against ASCOM recommendations. I’m going to have to physically watch the mount during a flip to see exactly what is happening relative to SGP.

However, I wonder if there is an issue with the way SGP detects the flip. According to my understanding of the ASCOM standards regarding side of pier, it indicates how the scope is pointing and not the physical state of the mount. (see “ASCOM SideOfPier Behaviour.pdf” in the ASCOM developer documents)

So I wonder if this sequence of events could be happening:

  1. The mount reports east of pier (i.e. pointing east)
  2. The mount crosses the meridian and now reports west of pier (eg pointing west but not flipped)
  3. SGP issues the slew, the mount flips but is still reporting west of pier (because it still pointing west) so SGP reports a failure.

This does not explain your observation that the slew for the flip seems to have taken very little time.
And, I am not familiar with the details of the SGP code so I could be way off base. I will pay close attention tonight to see if I can get a better understanding of the order of events.

7

The issue is that while the mount is flipping it is not reporting Slewing == true. This makes SGP think that the flip process is complete and SGP attempts to validate that is the case. This validation fails as the mount is still slewing and when SGP asks for the side of the pier it’s the same as pre-slew…therefore we make the assumption that no slew happened. This is solely because the slew did not block where it should have.

That is correct. Pointing state is nearly identical to Physical SideOfPier with one important distinction, when the gaze goes below the pole the side of pier flips. This is the model SGP expects. It is important to note that “pointing state” does NOT indicate the gaze of the scope, it (roughly) indicates the side of the pier the OTA is on.

Pasted image629×607 33.2 KB

Pasted image595×616 33.5 KB

This should be pierWest assuming you’re above the pole.

Passing the meridian should not change the SideOfPier.

Incorrect. SGP fails because the slew didn’t block and we IMMEDIATELY asked for the side of pier after checking if the slew is done.

The ASCOM document doesn’t really go into tracking through the meridian and says this:

EXCEPTIONS TO THE RULE
Flip margins, slew limits etc. are tools that mount designers provide to allow the observer to override the basic design principle that the telescope should choose the pointing state that puts the telescope above the counterweights at all times. Conform deliberately avoids testing in sky areas where these conveniences are frequently implemented. It chooses hour angles well away from the meridian and wherever possible chooses declinations that keep observation points away from the horizon and the pole

However I’ve never seen a mount that changed side of pier as it tracked through the meridian. And the Simulator (which should be considered a reference implementation) does not do this either.

Jared

8

Thanks for the explanation. Well, tonight same target same telescope driver and it works. Isn’t software control of hardware wonderful? So we can close this post for now - will reopen if I get more data during a failure if it happens.

9

Well, sounds like a timing issue then. In the setter for SideOfPier you may want to either set Slewing to true or block until the mount actually starts slewing. That would likely take care of any timing related issues.

Thanks,
Jared

10

Are you referring to the ASCOM driver? I was using the iOptron driver so I don’t have access to that. In my driver the setter for SideOfPier throws Not Implemented since the mount does not support it. Thus I suppose IOptron does not implement it either.

11

Sorry, I had assumed you were using your driver and for some reason though it used SideOfPier to flip. So that means we flip your mount by issuing a slew which should be synchronous, and it is returning immediately so we think the flip is done. Which is why the initial flip likely failed.

Thanks,
Jared

12

I stayed with the same driver so I could try to reproduce the problem but no luck. Now that I am past that I’ll try my own and see how it goes.

13

If you want to implement SOP in your driver then the best mount property to look at is the raw declination axis value. This will be in the range -90 to 0 to +90 for one side of the pier and -90/270 to 180 to +90 for the other.

Chris

14

Thanks, I was aware of that, however, the mount does not provide that information.

15

I have another example a auto flip fail and this time I was able to physically verify that the scope did not flip. However, after the fail I right clicked on the target and selected slew and it did the flip. Looking at the log file, it started with pier west and then the slew took zero time (i.e. it did not move) I have meridian flip set to 4 minutes past meridian in SGP. I’m beginning to suspect the SGP’s calculation of the meridian is not coordinated with the mount. Since the iEQ45 does not have a flip command, the only way to a flip it is to do a slew once it is beyond the meridian. If the slew is issued before the meridian, it will not flip which is the symptom we are seeing. How does SGP calculate the meridian flip time? Does it read the sidereal time from the mount? Calculating the Hour Angle is the only way I know to determine if the mount is past the meridian. (Or, perhaps read SideOfPier but Jared says he has never seen this happen on a mount)

Here is the log file: Dropbox - Error
Look at 8:52:32PM.