I’ve searched the forum and found a similar post from 2015 but not exactly what my problem is. I’m using EQMOD 2.00q on an HEQ5 mount and the latest SGP. When I’m imaging in the south my meridian flips work perfectly. When I’m imaging in the north around Polaris my meridian flips DO NOT work if my target is to the west of Polaris. The “time to meridian flip” value is N/A. It makes it very difficult to image targets like NGC7822 as it rotates around Polaris. It seems to have something to do with the DEC value. If DEC is to the north of 90 degrees my time to meridian flip is N/A and it will not flip. If DEC is to the south of 90 degrees I do get a correct time to meridian flip and it does flip. All the time EQMOD is reporting a correct “time to meridian”.
In this image I set the RA axis to what you see in the photo below. The DEC axis is 10 degrees south of 90 degrees. Notice EQMOD and SGP look good. Meridian flip will happen.
In this image I simply moved the DEC axis north 20 degrees. So now it’s 10 degrees north of 90 degrees. No more meridian flip and mount will stop tracking when it hits the limits ruining my night.
Here you can see the position of the mount. EQMOD is reporting a couple minutes to the meridian. SGP is reporting N/A. If I let it continue it hits the EQMOD mount limits and stops tracking.
What am I missing here? Is this a EQMOD problem or a SGP problem? I tend to think SGP because EQMOD seems to be aware of where the mount is. PierSide appears to be reporting correctly.
Moving the dec axis through the pole, what you call North of 90, is how the mount does a meridian flip.
What should happen as you move through 90 is that the Ra should change by 12 hours and the pier side should change. Your images show the RA changing as expected but the pier side display does not change. It should and maybe what is reported through ASCOM does.
I would say that EQMOD is not reporting the pier side correctly. It should be using the fact that the dec axis is beyond +90 as the indication that the pier side has changed.
It’s one thing to be able to move the mount to a bad position by hand, using the move buttons, but can you slew to that position? If you had moved from Ra 08:50, Dec +80 to Ra 20:50, Dec +80 by doing a slew where would it have ended up and what would the pier side be? It may be worth trying this in daylight, using a different Ra because of the different sidereal time of course.
Thanks for the quick reply. In fact when the mount does a meridian flip it flips the entire RA axis and then does as you mentioned, moves DEC from one side of 90 to the other. What I’m doing is manually testing by positioning the scope as you see in the image (just before RA limit). Then just bump the DEC axis to one side or the other of 90 degrees even just 1 degree. EQMOD does not report any change in side of pier (west pointing east) which is physically correct and the RA angle does change as expected but SGP goes from a good meridian flip time to N/A. The side of pier is physically not changing for this test. I guess you could say it doesn’t work when the telescope is on the west side of the pier but looking west of the meridian. Does that make sense?
In a real world example, tracking NGC7822 which is RA 00h 01’ and DEC around 67 degrees. Just after dark in my area it is to the west side of polaris and my mount rotates so the telescope is reporting “west pointing east” and begins tracking. As the night goes on a meridian flip is needed. SGP will never do an automatic meridian flip on a target in this area of the sky. So I have to manually do the flip by rotating the RA axis so the scope is on the East side and re-center the target on that side of the mount. For all other locations in the sky the auto meridian flip works perfectly, it only reports NA when my target is falling around the west side of Polaris.
This is not correct. The Pointing State changes when the mount moves from one side of the pole to the other.
What is happening is that in the first state the mount is crossing the normal meridian South of the pole at an hour angle of about 0. This is the normal pointing state change and SGP handles it.
In the second state the mount is also crossing the meridian but it is now at an hour angle of about 12 hrs and is crossing the meridian below the pole. That tiny change in the mount axis declination has caused a masive 12 hour change in hour angle and Ra.
I’m not sure if SGP will handle this, even if the pointing state is reported correctly. It needs an additional check, using hour angle and the pier side to detect the meridian crossing close to 12 hrs.
Very few people will image circumpolar objects when they are low to the north, they wait until they are higher.
Blockquote
This is not correct. The Pointing State changes when the mount moves from one side of the pole to the other.
That’s what I thought. After reading the attached document I’m thinking EQMOD is reporting incorrectly and does not comply with the ASCOM standard. I’m going to do some conformance testing based on this document and see what I find. If it’s incorrect I could compile a custom EQMOD driver to correct it and then see how SGP handles it.
Blockquote
Very few people will image circumpolar objects when they are low to the north, they wait until they are higher.
Yes, I generally do not go any lower than 20 degrees from the horizon. This time of the year there are some interesting targets up there. I seen a few posts from folks in the southern hemisphere with similar problems and they are also using EQMOD.
I’ll do some more testing and report back in case it helps someone else someday.
You caught me at a good time Ken because I’m trying to get exactly this implemented in EKOS at the moment, just had my first successsful flip slew North of the pole.
IMO the whole pier side/pointing state thing got confused by the original Pier Side name and East/West states. Everyone things they know what this means but they tend to think different things. Really we should have bit the bullet and forced a name change, to PointingState with states called Normal and Inverted. Bizarrely this would have been less understandable but then people might have stopped and found out what it actually meant.
Once you understand it then it becomes much clearer; it all depends on the declination axis position. If the Dec Axis position is in the range -90 to 0 to +90 that’s the Normal Pointing state and if it’s in the range +90 to 180 to 270/-90 that’s the Inverted state. It’s very obvious if you have an AltAz fork mount because in the inverted state the scope is inverted.
The more I read the more I can see why there’s so much confusion around the pointing state. I am experimenting with the EQMOD simulator and can duplicate what I see on my mount. It does not appear to comply with the ASCOM specification. It seems to always report the physical position of the telescope and does not change when you slew DEC through the pole. EQMOD has a “strick ASCOM” compliance mode which also doesn’t work. So I’m about to dive into the code…
Well I ran the ASCOM conformance test on the EQMOD 2.00q driver. According to the conformance test tool the driver is reporting correctly. So I’m back to this looking like an SGP problem.
Are there any SGP developers in this forum?
11:13:34.317 SideofPier OK Reports the pointing state of the mount as expected
11:13:34.323 SideofPier INFO Reported SideofPier at HA -9, +9: WE
11:13:34.330 SideofPier INFO Reported SideofPier at HA -3, +3: WE
11:13:34.338 SideofPier OK pierWest is returned when the mount is observing at an hour angle between -6.0 and 0.0
11:13:34.345 SideofPier OK pierEast is returned when the mount is observing at an hour angle between 0.0 and +6.0
11:13:34.352 DestinationSideofPier OK Reports the pointing state of the mount as expected
11:13:34.360 DestinationSideofPier OK pierWest is returned when the mount will observe at an hour angle between -6.0 and 0.0
11:13:34.367 DestinationSideofPier OK pierEast is returned when the mount will observe at an hour angle between 0.0 and +6.0
11:13:34.373 DestinationSideofPier INFO Reported DesintationSideofPier at HA -9, +9: WE
11:13:34.380 DestinationSideofPier INFO Reported DesintationSideofPier at HA -3, +3: WE
I could have sworn we addressed this many years ago, but it appears that the “below the pole” state is currently broken for meridian flips. I’ll address this.
I advanced my PC time to 22:30 or so and completed some additional testing with my telescope and the EQMOD simulator. Both behave the same. What I did was connect all equipment and slew to NGC7822. SGP reports N/A for time to meridian flip.
There’s not much in the SGP log file so maybe I need to enable some additional options? The EQMOD ASCOM log has this which I think would be relevant.
22:43:12.909 RightAscension Get GET RightAscension - COM
22:43:12.912 RightAscension Get 0.0555555696264847
22:43:12.913 Declination Get GET Declination - COM
22:43:12.916 Declination Get 67.2346675531915
22:43:12.917 Altitude Get GET Altitude - COM
22:43:12.920 Altitude Get 23.4261729813859
22:43:12.921 Azimuth Get GET Azimuth - COM
22:43:12.924 Azimuth Get 349.078208243956
22:43:12.932 SiderealTime Get GET SiderealTime - COM
22:43:12.935 SiderealTime Get 10.2757389005286 22:43:12.936 SideOfPier Get GET SideOfPier - COM 22:43:12.939 SideOfPier Get 0
Enumeration 0 is:
pierEast 0 Normal pointing state - Mount on the East side of pier (looking West)
Which I believe is correct as it’s not looking through the pole.
Let me know if you would like me to test something else.
Looking at the position you give the hour angle is +10 so as you say the flip will be below the pole at an Ha of about +12h/-12h.
I’ve set my AVX to what looks to be the same position, I’m at a different time so a different Ra but I’ve set an Ha of +11, a dec of +73, a pier side of East (looking West) and, using EKOS, a time to flip of 50 mins.and reducing. The azimuth is 355 so just East of North.
Sorry to use EKOS, it’s because I’m set up with it and it gives me all this data in one window.
It sounds like EKOS is doing it correctly. Also, EQMOD has an indicator as to when a meridian flip is needed and it is also correct. In fact it will do the flip for me but that would throw SGP into the recovery routine I’m sure. Maybe a work around for now? Hopefully Jared can find what’s going on inside SGP. Other than this issue I think SGP is fantastic software!
Here’s the test case I’m using with Polaris circled.
It is August of 2021 and I’m encountering this same problem. Imaging below the pole (target traveling west to east) SGP shows “N/A” for time to flip, and when the flip time comes, it does not occur. Just checking in to see if it has been addressed yet. I’m using 3.2.0.660.
It’s been 3 weeks since I posted my question above and haven’t seen a reply. Just posting again in case it fell through the cracks. Has this been addressed yet? Or is it on the roadmap?
I seen a few posts from folks in the southern hemisphere with similar problems and they are also using EQMOD.
