Newbie and iOptron SmartEQ Pro Sequencing Issues

Since I’m new to SGP, the problems I’m having may be me. I did post to and Ken directed me here.

I’m having issues with a Sequence I’ve made to monitor 21 Variable Stars in UMa. The sequence seems to work on an Alt/Az NexStar mount, with the ASCOM simulators, but fails miserably on my SmartEQ Pro.

Using the newest version of SGP, iOptron ASCOM drivers, and an hand controller firmware I’m getting multiple windows that say the Sequence Complete between each event image in the sequence. Sometimes as many four Sequence Complete, dissmiss, resume sequence cycles to successfully capture the next image event. Like I said, this doesn’t happen on my NexStar.

my log can be found at:

I see problems in the log, but don’t have a clue what they mean.

the variable star sequence can be found at:

Mount: iOptron SmartEq Pro
ASCOM scope: iOptron ASCOM Driver for 2013 and earlier
Camera: Camera V2 simulator
The sequence was 21 variable stars in UMa, each with 5 events
Camera and mount connected and grayed out

Pressing “run sequence”… slewing to first target
The message Sequence Complete appeared first at end of slew when the mount beeped end of slew.
I dismissed the window, it took the first event image, downloaded and the Sequence Complete happened again.

Contacting iOptron support says “SGP should work with ASCOM V3.11 directly(no POTH).”

Should and does are two very different things.

Has anyone gotten an iOptron SmartEQ Pro working with SGP and does anyone have any suggestion?

Thanks to all…


When you click “Run Sequence”, do you get a pop-up dialog telling you that your mount is parked and then SGPro asking of it’s OK to unpark it when the sequence starts? The problem is that every time you click it, SGPro quite because the mount is parked.

[2/15/2016 9:20:47 AM] [DEBUG] [Sequence Thread] Mount is parked! Aborting capture event (and sequence… recovery is not allowed here… assuming mount has been parked for safety).

While I’ve seen reports about the mount being parked and asking to unpark it in other software, I have never seen the popup that you are asking about while running SGPro. I never park/unpark the mount and as far as I know there isn’t any way to do it. Park isn’t even in the SmartEQ’s manual.

Should I ask iOptron about the mount being parked?


I’m not sure… racking my brain. I am not sure how this can happen right now. When you click run sequence, one of the first things SGPro will do is connect your mount (if needed) and then check to see if it’s parked. If it is parked it will ask for your permission to unpark it. Since you are not seeing this, it means your mount is not parked when you click the run sequence button (I think). Then… about 5 seconds later SGPro quits because your mount is parked.

Try enabling the ASCOM DriverAccess log. This will show the commands that SGP is sending to the mount, and their response.

What Ken describes could happen in the driver is reporting AtPark as False but then throws the ParkedException in response to another command.


I’ve never turned on ASCOM logging before so I may not have done as asked.

I tried a run at this morning with the same results. The link to the sequence remains the same as above. The Park problem shows up at 11:12:00 near the bottom of the SGPro log. Problems show up in the ASCOM log at 11:11:54.871
with Index was outside the bounds of the array messages.

The SGPro log is at: Dropbox - Error - Simplify your life
The ASCOM DriverAccess log for the mount is at: Dropbox - Error

That’s great, exactly what was needed.

It’s not obvious why there should be a parked message from SGP, AtPark is false and there’s no obvious park exception. But maybe the index errors are interpreted as a park error. It’s strange that some get SideofPier commands work and some seem to give exceptions.

Maybe the two logs will make sense to Ken, it may also be worth involving iOptron, they may be able to give further information - or want to fix that index exception.



@Chris is right about the side of pier issue… you’ll need to contact iOptron about that… for the issue you are reporting though, it is not relevant (it might lead to problems later though).

The problem here is kind of disguising itself as a park issue… it does not appear to be related to this since your mount is not able to park. SGPro is actually quitting because it is not able to convince your mount to track (and not doing a great job of logging or reporting it)… we can fix that part, but I’m not sure why your mount reports it is not tracking.

11:12:00.751 Tracking Get False

I have made one change that I hope will accommodate for situations like this in a more user friendly manner…

I loaded this morning, but I’m not sure much has changed although you may not have addressed the problem yet. I still get the window with dismiss about 1/2 the time and then have to resume

Dropbox link to ASCOM Dropbox - Error
Dropbox link to SGPro log Dropbox - Error

Yes, should have addressed any remaining issues in SGPro. If it didn’t, it seems like a problem with your mount or the driver. You can see here, within the span of a couple seconds, your mount reports both true and false for “IsTracking” with no command in between to actually toggle the tracking state. Something is wrong here:

09:17:25.724 Tracking Get GET Tracking - .NET
> 09:17:25.724 Tracking Get True
09:17:25.750 Slewing Get GET Slewing - .NET
09:17:26.423 Slewing Get False
09:17:26.433 AtPark Get GET AtPark - .NET
09:17:26.433 AtPark Get False
09:17:26.434 Tracking Get GET Tracking - .NET
> 09:17:27.145 Tracking Get False

Looks like it is the SmartEQ Pro mount and not the ASCOM driver. I have an older iOptron original MiniTower that uses the same driver. I connected to SGPro today with it and the run was flawless.

Now to get the MiniTower on a wedge :flushed:

Thanks for the help and I’ll watch to see if anyone has success or problems with the SmartEQ Pro.