UPDATE: The firmware appears to have been updated to fix this bug. See the note at the end of this post.

The other evening I was doing some imaging using my refractor on my iOptron GEM45 mount, and ran into a bit of a snag. I use N.I.N.A to manage my imaging runs, and I set up N.I.N.A and the iOptron ASCOM driver (iOptron Commander) together to handle the meridian flip needed during the imaging run. But while the meridian flip had worked just fine in previous imaging sessions, this time the meridian flip failed, and I had to manually intervene. But why?

Of course, I had to figure out what had caused this particular failure. One of the possible answers was that I had just recently updated the firmware in the mount, to version 20210105. The release notes for this firmware version indicated that it as a major update, fully implementing the latest iOptron command set. In fact, this particular firmware update required that I update my version of iOptron Commander from version 5.7.5 to version 6.4. These updates seemed like prime suspects in my search for the cause of the failed meridian flip.

The specific error that was reported in the iOptron Commander log file for the failed meridian flip was, “ERROR: Mount slew failed. Target exceeds the limit!” The log file also indicated that the command issued by Commander to the mount to perform the meridian flip was “MS2#”, which is the command to do a counterweight-up slew. So what is a counterweight-up slew? This was a new one to me.

The Counterweight-Up Slew

When the mount is commanded to slew to a position that is on the east side of the meridian but near to the meridian, it would normally slew to that position by putting the telescope on the west side of the mount, pointing east. As the target crosses the meridian (something that would happen within a few minutes), the mount would then need to do a meridian flip in order to continue tracking the target to the west. However, a counterweight-up slew would combine the slew with the meridian flip in a single maneuver, so the mount would end up in a position where the telescope would be on the east side of the mount despite the target having not quite crossed the meridian. It’s called a counterweight-up slew because under the circumstances I just described, the counterweight ends up higher than the telescope for a few minutes until the target crosses the meridian.

(Note that iOptron’s mounts are either German equatorial mounts or a similar type of mount called a center-balanced equatorial mount. Both mount types use counterweights to balance the telescope. Other types of equatorial mounts, such as fork mounts, operate differently and without counterweights, and the counterweight-up slew doesn’t apply.)

The ability to command a counterweight-up slew was included in the latest firmware update for the GEM45 mount. While the GEM45 manual doesn’t mention this yet, the manual for the CEM70 mount documents the behavior of the counterweight-up slew in its description of the mount settings:

Enable CW Up Position

This setting will allow the CW moving to an up position. The upward angle limit is same as the meridian flipping setting, or 14 degree at maximum. When this set is enabled, the mount will goto pass the meridian if an object is close to the meridian, within the angle limit. There will be no meridian flip when pass the meridian.

The meridian flipping setting referred to in the description above is the “degrees past meridian” setting in Commander that determines how far the mount is allowed to track past the meridian before stopping. So one could assume that if the “degrees past meridian” setting is zero, a counterweight-up slew would not be allowed (and would produce the “Target exceeds the limit” error message if requested).

So at this point I’m speculating that any requested meridian flip by Commander would be rejected by the mount if the “degrees past meridian” setting is zero. Seems reasonable. But that setting in my mount was set to 10 degrees, not zero. What gives?

When Ten Degrees is Really Zero

Why would the requested meridian flip fail? My mount settings should have allowed the mount to slew past the meridian by 10 degrees. But I remembered doing some previous bench testing of the mount that caused me to suspect that the mount wasn’t honoring my setting. Indeed, through some additional testing I discovered that when the mount is first powered up, it behaves as if the “degrees past meridian” setting has a value of zero, even though the setting appears to have a nonzero value when checked in Commander (or the hand controller).

I fiddled around with various ways to get the mount to accept and use the setting. What I found was that changing the value of that setting–say, from 10 to 9–caused the mount to honor the new value. This was my workaround.

Correspondingly, testing the N.I.N.A-commanded meridian flip confirmed that meridian flips always failed in the mount after it was powered up but before the workaround was applied, but meridian flips after the workaround was applied were successful.

Fixed! (I Think…)

So the bottom line is that my meridian flip failed because the mount thought that my “degrees past meridian” setting was zero, which I believe is intended behavior for the “counterweight-up slew” command. But I think that the fact that the mount thinks the value of that setting is zero on power-up is a bug in the mount’s firmware–specifically the latest version. The workaround for this bug is to change the value of this setting to a different non-zero value right after powering up the mount (simply re-entering the same value does not work–I tried it).

This only appears to be an issue with the latest firmware. I never ran into this issue with earlier firmware versions.

I have emailed iOptron support with this information but have not yet received any confirmation or refutation of my findings, so I could be wrong, but all the evidence points this way. Update 3/10/21: I learned today that iOptron has updated the GEM45 firmware to fix the issue with using a value of zero for the “degrees past meridian” setting at power-up that I described above. The firmware version is still shown as 210105, but a closer look reveals that the main board firmware is now at version 210106. I tested this version and it appears that this particular problem has been fixed.