Auto meridian flip with iOptron CEM60 - Part 2


I’ve installed the new iOptron ASCOM driver (v3.2) which now also shows pier side on the interface itself. So far it seems correct just from some of the slews I’ve done.

I have the newest beta of SGP installed (beta 5).

Because it is cloudy tonight I can’t do any outdoor testing so I just set up a simple sequence with only a camera and the mount. I turned off the plate solver, focus, centering, etc… I picked a target nearing meridian and had it start imaging. Auto flip was to start at 1 degree past. Well… It didn’t happen. I picked another target and did it again, this time with flip set to happen at meridian. No go.

I restarted everything and set it again. This time I noticed what I think is the problem. As I am setting up the target, the telescope control window of SGP is giving me the time to meridian correctly. But as soon as I check the “use Auto Meridian Flip” under telescope in the control panel, the telescope control now shows N/A for time to meridian. If I uncheck the box, the correct time comes back.

I don’t know if this is still an issue with the iOptron driver or with SGP but I thought I would report it and see if anyone might know what the issue is.



I tried using the POTH and it does the same thing however it then tells me that this scope cannot do an automated flip.



I just tried to initiate a flip manually by hitting the “run” button of auto meridian flip. It didn’t slew at all. It’s almost like iOptron disabled the ability to do a flip. Unless something changed in SGP?



Logs would be helpful.

Also what does SGP report on the telescope tab for time to meridian?



I will set up a run again with meridian flip enabled and post a log.

On the telescope tab, time to meridian is a positive number counting down to zero. As soon as I check the “use auto meridian flip” box in the control panel, the time to meridian just shows “NA”

I did a test (without auto flip enabled) where a target stops just prior to meridian with a duplicate target starting just after meridian. I checked “slew to” for the second, duplicate, target and when it reached the correct time SGP started the slew, and since it was on the other side of the meridian, the mount flipped. In the iOptron ASCOM driver, the reported pier side went from “East” to “West”.



sg_logfile_20150117213701.txt (93.7 KB)

Here is the log file. I set up a sequence as M42 was approaching meridian. Auto flip was set to go at meridian. I let it run a couple of degrees past meridian and SGP parked the scope. An automatic meridian flip did not occur.

iOptron’s interface is now called iOptron Commander and shows pier side in the window. It showed East through the sequence.



This is happening because when you’re not using the meridian flip we just show you when your object will get to the meridian based on the sidereal time and RA. If you enable the flip then this changes to “Time until flip” where we take the side of pier into account. If you’re pier side is East (meaning scope on the east side of the pier, looking West) then there is no need to do a flip…thus the NA.

That’s unfortunate. Essentially that means it’s still broken provided your scope was indeed on the west side of the mount (looking east).

I see the same in the SGP logs. Pier side reported is East which means it would not do a pier flip.

I’ll contact iOptron about this.



The scope was on the west side looking east and iOptron Commander showed east. As it crossed meridian it is on the west side looking west because the flip did not occur and still reported east. So it’s backwards then? Scope on west side looking east should be pier side west?

Thanks for the help,


Yes the easiest way to think of this is that it should report what side of the pier the SCOPE is on. That’s almost always true except when the mount is below the pole but in our cases that’s extremely rare unless you enjoy imaging down in the “muck”.

iOptron Commander can report whatever it wants as long as the ASCOM driver adheres to the standard. So if they want the Commander to display the “gaze” of the scope that’s certainly fine. But from your SGP logs I can see that the driver is mimicking this behavior.



As iOptron works to fix the side of pier issue, I think I have found a work around to image across the median with a CEM60 and SGP.

Before the fog rolled in tonight I was doing some testing. First I needed to see if PHD2 would at least see the change in pier side and flip calibration. I calibrated and guided on a star east of meridian and then moved to a star west of meridian and started guiding. Calibration appeared to have flipped because the star stayed centered and corrections resulted in the correct movement. Looking at PHD2 logs, it looks like it just reacts to a change in state compared to its calibration side and doesn’t care that it is east or west.

Next, in SGP I made a sequence with a target east of meridian. The scope is set to stop 15 deg after meridian. I set the target to stop just before meridian. Although I think it would work stopping a bit after meridian as well. A duplicate target is then set to start west of meridian with the “slew to” and “center on” options clicked.

When I ran it, the sequence paused when the first target hit its end time. Because the “slew to” was checked and the target was now west of meridian, it caused the mount to flip to the other side. It centered and resumed guiding and off it went again. PHD2 calibration appeared to flip as it should.

I was only able to try it once but it appeared to work. Foggy out now so I’m done for the night.




Thanks for continuing to poke at this problem. I plan to try your work-around on Friday night if our weather forecast holds. It has been a very poor winter for astronomy in Indiana so I plan to take advantage of clear skies if they materialize.

Hopefully, iOptron will correct the final issue with the Ascom driver soon. Then we will be able to take advantage of the full scope of SGP.

Thanks again,



I did it again last night and it worked out fine. Make sure you extend the settle time of the mount out to about 30 seconds or it will start to plate solve while it is still moving. I had it too short last night and the first plate solve failed but recovery took over and resumed the sequence without problems.



I was sent a new version of the iOptron ASCOM driver to test and can report that side of pier appears to work correctly now and that automated meridian flip works (mostly). What I mean by that is there is a problem with the driver not reporting that the mount is still slewing causing SGP to start the image run too early. It requires putting in a mount settling time of 60 seconds to delay long enough for the slew to complete. Jared has been a great help in getting iOptron to see what has been going on which has gotten the side of pier issue resolved. iOptron has also been receptive in getting it solved.

We’re getting closer!



Hi Chris

Do you have any update from iOptron on this?

I already have my new CEM60 and I think the procedure you suggest will work. I did something similar with my former iEQ45. But the whole point is to take advantage of the automated meridian flip.

Best regards,

Bogotá, Colombia


I can confirm that the new driver I got fixed the side of pier problem. I still had to put in a 60 sec mount settling time to keep SGP from starting to image too soon. The driver was not reporting the slew correctly either. I just got another one (v3.22) which so far seems to work well. It fixed some connectivity issues introduced in the v3.21 driver I was using. But it is cloudy and way to bright to be testing much now. The little bit I did seems to work fine though.

Chris M



Let’s hope they release the new driver soon.

Thanks for all the time you’re taken to solve this.

Best regards




I really appreciate your work on this issue. It is very encouraging that iOptron is taking this seriously and trying to develop a fix. Did they give any indication when they might release the updated Ascom driver?




I have not heard from them in a while now. There is still an issue with slewing that they are working on. I don’t know when they will release a new version.



Oops, just looked farther down in my email. I will have a new main board firmware and ASCOM driver to test soon.



Hi Chris

Any news on the new version of the ascom driver?