Jump to content

NLCbanner2024.jpg.2478be509670e60c2d6efd04834b8b47.jpg

QHY5 and AstroTortilla error

Photosbykev

By Photosbykev
in Discussions - Cameras

Recommended Posts

Photosbykev

Photosbykev

Posted
Posted

Has anyone come across this error and more importantly fixed it?

My QHY5 is fitted to an Altair Astro guider scope and generally works very well i.e. I can guide using it in PHD etc.

but when I try to use it in AT (v0.5) for plate solving I get the error attached about requiring a 64-bit com driver for it ????. If I capture an image with QGVideo and use AT it solves in about 10 seconds :) but I can't get it to capture inside AT.

My laptop is running Win7 64-bit and the QHY5 works with all the other programmes.

post-4594-0-01382600-1363076781_thumb.jp

Link to comment
Share on other sites
Photosbykev

Photosbykev

Posted
  • Author
Posted
Why does PHD need to have any connection with AT ? They both utilize the ASCOM hub but other than that the two do not speak to each other?
all three of them, if you add Starry Nights, talk to the mount and I thought I could avoid disconnecting a programme before reconnecting another one

Sent from my iPhone using Tapatalk. Blame Apple for the typos and me for the content

Link to comment
Share on other sites
kirkster501

kirkster501

Posted
Posted

Wait for Chris to come along to detail this. But I don't think any of them talk to the mount like that. The ASCOM hub and its driver (Prolific) is what "talks" to the mount. And ASCOM opens API's to which EQMod and other astronomy applications can write to control the mount via ASCOM. In turn, AT can "correct" EQmod with its plate solving process which in turn drives/positions the mount via ASCOM. When you open AT and connect to the mount, its the ASCOM hub and its EQmod front end you are connecting to.

Link to comment
Share on other sites
chrisshillito

chrisshillito

Posted
Posted

ASCOM is reallly just the glue that holds applications and drivers together. ASCOM isn't involved with any mount comunications itself but it does provide a mechanism for a client application (say PHD) to make requests of a server (driver). The driver then does whatever it needs to do to service that request - that might involve direct mount comms but sometimes may involve a fucntion that can be handled entirly at the the driver level.

Some drivers that support an ASCOM interface do it in such as way as to allow multiple clients to connect to the driver. When the first client connects the driver springs into life, when the last client disconnects the driver closes. It is important to realsise that there is never any client-client communication. Clients never know what each other is doing and you have to watch out that contradictory information is being written to the driver by separate clients (this is why by default EQMOD doesn't allow clients to write its site details).

So you can quite legitimately have SNP, PHD and AT all connected to the mount simultaneously - they don't talk to each other but, providing they are polling common properties, such as RA/DEC they can at least will notice the effects of each others control of the mount. So if you plate solve in AT you will see a cursor shift in SNP.

Hope this makes some sense.

Chris

Link to comment
Share on other sites
Photosbykev

Photosbykev

Posted
  • Author
Posted

It makes sense Chris. But your last para says they can all be connected to the mount can you give a connection sequence that allows this to happen please. Especially to run snp and phd together

Sent from my iPhone using Tapatalk. Blame Apple for the typos and me for the content

Link to comment
Share on other sites
chrisshillito

chrisshillito

Posted
Posted

Sorry, but I don't have SNP pro so can only tell you that from an EQMOD point of view it really shouldn't matter which client connects first or indeed which leaves last. I regularly have at least four separate applications simultaneously connected to EQMOD and I can start them in any order with no problem.

If you are experiencing issues where one app must be started before another then that most likely comes down to coding specific to those client apps. For instance some planetariums will automatically unpark a mount when they connect to a driver, some applications can only perform their functions on an unparked mount. So running the planetarium first puts the mount in a state where the second app can function. Of course you would expect some kind of error/warning message if a particular app can't do its thing but in the ASCOM world this means catching exceptions. If the app code is poor and exceptions aren't caught then they get passed up to windows which may well terminate the app.

Chris.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.