You need to be a member of one of those groups to get at the file.
I need to persuade the SkyWatcher people to put it on their site but that’s where it is for now,
Chris
PS Part of the reason there’s a new HC version is that we added extra functionality to the HC so I was able to provide better control of it through the serial port. There’s also a new version of the serial protocol on the SkyWatcher downloads site.
This is why you need both the new HC firmware and the new skyWatcher driver. They have been designed to work together. I check the HC version and only enable the more advanced features if the HC supports them.
C
Yahoo seems to have become almost impossibly slow for everyone. I’m beginning to think that we need to have a different way to handle ASCOM discussion and support. Every time we have tried before we have ended up coming back to Yahoo, in spite of its defects.
Read the driver help. It tells you what information I need, in this case a driver log. This will show why the driver thinks that it doesn’t support pulse guiding.
You need to talk to the PHD people about why their application fails to close properly.
I’ve just tried it with my AZEQ6 and PHD 2.6.1 and had no problems. It connects and can do pulse guiding. This is an indoor test but I can see the position change when pulseguide commands are sent.
Chris
Edit:
I’ve got the logs you sent to me privately, thanks, just what I needed.
From a quick look there didn’t seem to be any problem from the driver point of view.
The log starting at 2359 shows CanPulseGuide returnng true and guide commands being done with no obvious problem.
But then, at 00:17:08 there’s a CanPulseGuide that’s returning false, even though there was a successful guide done a few seconds earlier.
Do you know if something changed at this time? I guess that PHD was connected before that and was guiding. Did another application connect to the driver?
I’ve had a total of 6 emails from you today so it looks as if this connection works - but you do need to give me time to respond.
Guiding is only allowed for equatorial mounts and the correct HC version. I check both of these by reading the HC.
What I’m seeing is that when I read the track mode from the mount the correct response is being returned correctly most of the time but occasionally it’s returning the wrong mode - AltAz instead of equatorial - and this is causing CanPulseGuide to return false.
I have to read trackMode because it’s also used to check if tracking is on or not and make sure that the correct tracking mode is set.
There seems to be a series of get track mode - “send t” - at 10 second intervals which return the correct value [02]# then a single one at 00:17:05 which returns [01]#
This also seems to trigger a set track mode command which sets Tracking to AltAz and this could explain the bad guiding after this.
I’ve reported this to the HC driver author but obviously a work round would be nice. I’ll think about that and see what I can come up with.
It would be great if you could post your PHD2 debug log in the PHD2 forum. That way we can investigate and hopefully fix it. (Unless somebody reports the problem – preferably on the phd2 forum – we don’t know about it and can’t fix it.)
This isn’t Apollo 13, no one will die if you don’t image tonight. How about taking the night off, the stars will still be there tomorrow and I get the impression that it would help if you had a bit more sleep.
I’ve got a potential solution but I’d like to get some feedback from SkyWatcher first because it’s not bullet proof.