13 replies to this topic

[Terry D]

I recently switched over from my Skywatcher EQ6 mount to an iOptron CEM70 mount. Installation and connection to PC with iOptron Commander and Stellarium went smoothly. However when I tried to add a game controller

(GameBoy) for fine tuning slew I couldn't find any option for this in Commander as there was in EQMod. Has anyone added or tried to add a game controller to a CEM70 mount? Is it somehow possible to connect to the mount using Commander and EQMod simultaneously? 

[Notdarkenough]

I use an Xbox controller when using my Evo mount via CPWI, but I don't know of any such solution for my CEM70.

[Cliff Hipsher]

 Is it somehow possible to connect to the mount using Commander and EQMod simultaneously? 

NO.

[tjay]

NO.

More precisely, EQMOD doesn't support iOptron Mounts, so you couldn't even use EQMOD alone either.

 

ASCOMPAD might be a solution, but it appears to be a separate stand alone application for using a gamepad with any ASCOM mount.

Edited by tjay, 05 January 2025 - 12:39 PM.

[Terry D]

Thanks for the replies. It looks like I'm currently out of luck. I sent a suggestion to iOptron about adding functionality for the game controller to Commander, but am not too optimistic.

[voidcomp]

More precisely, EQMOD doesn't support iOptron Mounts, so you couldn't even use EQMOD alone either.

Wow, I can't tell you the number of tutorials that never mentioned this simple fact.  Thank you.

 

CEM25P owner.

[Cliff Hipsher]

Thanks for the replies. It looks like I'm currently out of luck. I sent a suggestion to iOptron about adding functionality for the game controller to Commander, but am not too optimistic.

Yeah.  I wouldn't hold my breath.

[dghent]

The top Google search hit for "ASCOM gamepad"

 

https://eq-mod.sourc...et/apindex.html

 

I really should charge for my services.

[Cliff Hipsher]

Two things I am not fond of:

 

#1.  Game controllers

#2.  ASCOM.

 

I do have an iOptron GEM45  and a ZWO AM3.   I have played with iOptron Commander and ZWO ASI Mount.  Even though I do not care for ASCOM I cannot understand why iOpton and ZWO had to write custom server apps for ASCOM.

[rgsalinger]

EQMOD is a project that contains EQASCOM which is a driver exclusively made for Synta made mounts. Each mount manufacturer has their own command language to talk between a computer and the mount and so some unique software (device driver) is always needed to run the mount. The command languages are sometimes in the public domain and sometimes not.

 

That's where ASCOM comes in. By setting a standard method of communicating (exposed methods) between a mount and 3rd party apps, it's vastly simpler to support a wide range of mounts than it used to be when each 3rd party app had to learn and code the language used by each brand of mount. 

 

At the same time, "custom" apps for mounts that do NOT need ASCOM to are extremely useful from time to time to troubleshoot mount problems. That includes any ASCOM issues (there rarely are any). 

[dghent]

Even though I do not care for ASCOM I cannot understand why iOpton and ZWO had to write custom server apps for ASCOM.

ASCOM itself defines an API for interacting with different classes of equipment - mounts ("telescopes" in ASCOM parlance), cameras, focusers, and so on. Each class defines a set of APIs that are appropriate for controlling that type of equipment. The Camera class obviously has properties and methods for starting exposures and getting image data, for setting cooling and getting its status, and so on. Mount/Telescope class has properties and methods for getting mount disposition, to command a slew, to sync coordinates. The focuser class has APIs for moving the focuser, and so-on and on.

 

Each vendor of these types of devices furnishes an ASCOM driver that implements these APIs. Clients such as your imaging apps can load these drivers and interact with the equipment they control in a standardized manner via those ASCOM APIs. There is no need for the imaging app itself how to control the device in its own low-level language or methods - that is what the ASCOM driver does. To the imaging app, a slew operation for your iOptron mount is programmatically identical to a slew operation for a ZWO, or Astro-Physics, or Losmandy, or 10micon mount. If these APIs didn't exist, every imaging app maintainer would have to go to every device vendor and beg/borrow/plead for sufficient device programming documentation. A big time-sink as every imaging app creator/vendor would have to spend time creating this in-app support for every piece of hardware they want to control. Would I, as a contributor to NINA, want to have to drop whatever I'm doing to work on integrating support for the newest ZWO mount whenever they release one? Not at all. ZWO releases their new hardware with a driver for it (or adding support to it in their existing driver) and I don't have to lift a finger to deal with interruptions like that.

 

ASCOM is Windows-specific because the API is designed to use Windows' COM (Common Object Model) system. That's what the "COM" in "ASCOM" refers to. The full name is "AStronomy Common Object Model". This is why "ASCOM" doesn't exist for other OSes, as COM is largely a Windows thing. Alpaca is the ASCOM API but implemented over a HTTP REST-alike interface instead of COM, which brings a cross-platform and distributed aspect to it.

[Bob Denny]

Two things I am not fond of:

 

#1.  Game controllers

#2.  ASCOM.

 

I do have an iOptron GEM45  and a ZWO AM3.   I have played with iOptron Commander and ZWO ASI Mount.  Even though I do not care for ASCOM I cannot understand why iOpton and ZWO had to write custom server apps for ASCOM.

Adding to Dale's post, what's there not to like about ASCOM? It's a set of standards. Unless you think the standards themselves are somehow unlikeable (joking here).

 

To understand why ASCOM exists as Dale explains, have a look at this little slide-show Motivation for ASCOM. It might help put things into perspective. Be sure to look at all of the slides.

 

I've seen "It's that [bleeping] ASCOM!" posts and complaints, when actually "It's that [bleeping] mount|camera|focuser|dome ... it's so buggy!" The implementation of the device (firmware, driver, software) being bad, but since the driver is called ASCOM then "It's that [bleeping] ASCOM!". This has been our number one reputational disappointment, and one which we constantly try to clarify. So my apologies if you already know this stuff. 

 

Anyway, neither of the things you don't like are the actual source of your frustration. "Game Controllers" are ubiquitous, and if they were all trash, there would be no market for them and they would not even exist. And ASCOM is a set of specifications, so when your device has problems it is not the specification that is the cause. In both cases, it's the implementation (by iOptron or ZWO in your case) and they are the people to whom you should turn for help.

Edited by Bob Denny, 09 January 2025 - 03:10 PM.

[Cliff Hipsher]

I never said that ASCOM and Game Controllers were inherently bad.  I simply don't care for either of them.

 

And just so you know, I run 3 rigs with ASI Air controllers.  Everything I need is in one little red box, and everything works.

[dghent]

You asked _why_ vendors had to make drivers. You got a detailed answer. If you don't really care about the particulars, then don't ask such questions.