CPWI and PHD2 update

[JohnS]

I don't know whether this has been posted before - but further to another current post I found this on the Team Celestron Beta site:

This from Chris Rowlands the ASCOM driver developer:

"The way my ASCOM driver works is that it reads the guide rate from the motor controllers at connect time. It will use that for the guide commands. ASCOM only specifies a duration, not a rate.

If the application changes the rate through ASCOM this will set both the ASCOM and ST4 rate. It will be copied to the motor controllers, this is the only place that the guide rate is stored.

While applications can read and change the guide rates most do not.

There's a window where if people change the ST4 guide rate after ASCOM is connected then ASCOM won't see this but this is pretty unlikely and I've never had a complaint.

I really don't think that ASCOM implementations will notice if the default guide rate when they connect is the same as the ST4 rate."

and this response from Celestron Support:

"ASCOM provides a method to set/read the guide rate. And a second Method to start guiding (which includes a duration and a direction). That does not imply that the mount needs to support these functions. Some Celestron mounts do support both of these functions, and other only support one or the other.

Getting back to the original post, it seems like the best solution to avoid this confusion would be to change CPWI's dialog box to make it clear that it is showing the AG rates for the ST-4 ports (not ASCOM). And of course CPWI won't even show you the guide rate setting if your mount does not have ST-4 ports.

As for displaying the setting of the ASCOM driver, that seems to be impossible (or at least hard). CPWI doesn't even know if the ASCOM driver is being used much less what the guide rate set by the client of that driver is. For that matter, there could be multiple instances of the ASCOM driver loaded and each client could have set a different rate!

Chis' solution of storing the value in the EEPROM of the mount gives multiple drivers and CPWI a way to communicate. But for it to work all these programs need to poll the EEPROM every time "getXxxGuideRate" is called from any client. And, of course, the mount has to support saving the values in EEPROM (and lots of modern mounts do not support this)."

this next from the orignal poster:

"I re-read the thread but feel I don't have a clear understanding of what would happen with a PHD2 + CPWI + CGX setup (with pulse guiding, not ST-4), specifically about reading and setting the guiding rate.

As per https://openphdguiding.org/manual/?sect ... nt_Profile, "PHD2 never sets the mount guide speed, it only reads it". So PHD2 cannot set it but it reads it from CPWI.

As per your last message, if I understood it correctly, CPWI shows the ST-4 rate, not the ASCOM rate. CGX mounts do have an ST-4 port, but there's no reason to use it since we have pulse guiding.

In an earlier message your were saying that it's the client of the ASCOM driver that sets the AG rate (let's assume there's only one in use at a given time ) and that might be stored in the driver and that CPWI cannot read that value.

So, in the PHD2 + CPWI + CGX (via USB, without H/C) setup, who is then the client of the ASCOM driver who sets the AG rate? I thought it'd be PHD2 but PHD2 doesn't set the rate. Is it CPWI? But then it'd be able to know the rate what itself sets. Is the default value stored in the driver what is used? If CPWI cannot read it, then PHD2 cannot read it. Is it working because, intentionally or not, the rate hard-coded in the driver matches the ST-4 values stored in the mount so what PHD2 reads happens to match the real but unrelated value?"

and from Support:

"When I say that the ASCOM client is the one who sets it, I am referring to PhD2 in this case. CPWI's ASCOM driver is expecting the client (PhD2) to set the guide rate. If it does not do so, the default will be used. If I recall correctly, that is 85% sidereal speed."

So from that I'm assuming that it doesn't matter what CPWI displays with regard to guide rate because it isn't actually the ASCOM application guide rate and therfore not effecting guiding.  It appears that it will almost always display it as 85%.  So my instinct to "work with it" appears to have been the right one.  It would appear that the solution to this "problem" would be to program in to the CPWI GUI a means of setting the guide rate - just as EQASCOM does.

Hope this is of interest

John S

[Michael 8554]

Hi John S,

Wow that's complicated.

"work with it" - you mean accept it's broken, but carry on anyway ?

Then two things :

1)  Is there a way to alter guide rate that sticks ?

2)  If PHD2 can't read that value, then play with the Calibration Step Size until you get a Calibration in about 12 steps.

That should work ?

Michael

Wiltshire UK

[John Smith]

Hi Michael  -  it looks complicated but it actually isn’t.  In a nutshell – and as I see it – it simply means that CPWI displays the wrong information for ASCOM guiding.  It’s just plain wrong.  So ignore it and carry on.

 

Yes there is a way to alter guide rate that sticks – all ways of altering it will stick.  And I remember now that CPWI does actually have the ability to set the guide rate of the mount as well.  So why doesn’t it display it correctly?  Weird!  Apparently it picks the data from the ST4 port on the mount.  If you don’t have an ST4 port it doesn’t display anything!

 

PHD2 can read the correct value – and does – it’s the number on the CPWI GUI that’s wrong.  But it doesn’t effect the guiding.  It just bemuses everyone who notices it.

 

So the recommendation would be:  if you notice a difference in guide rate between PHD2 and CPWI ignore the one in CPWI.  No tinkering required.

 

John S

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c1ecdfc0-c29a-4632-af26-647765a3dd62%40googlegroups.com.