For info. There is a new ASCOM telescope driver for TheSkyX - now located on SB’s website rather than ASCOM’s. I checked with SB, it is an enhanced version that allows access to direct guide from third party programs. I’m assuming there are some operational advantages to that over separate PEC / pulse guide commands. When the weather clears, I’ll give it a try with PHD2/SGP.
Would be interested to know how it works. Cloudy here as usual this time of year.
where did you find the driver? Can you post a link to it please?
The main difference in functionality is that it can use DirectGuide instead of PulseGuide for SB mounts. I’m told this is more accurate.
The exact functionality will vary depending on what the real mount is and how it’s connected. This is because it’s using the SB scripting and is vulnerable to the vagaries of that.
I wrote this for SB but haven’t tried the DirectGuide because I don’t have a SB mount. Feedback from the SB crowd is that it works.
Hi - the driver is on the SB driver download section, if you list in order of recent, it is the third one down right now.
I have it working tonight. I’m using it through the Generic Hub at the moment. Like the pulse guide on the old driver, it requires PHD2 to be set up to reverse DEC after a flip. I’m getting sub 0.3"RMS errors with a 5 second exposure time and a Paramount MX.
I think this is the link: http://www.bisque.com/sc/media/p/106120.aspx
The ASCOM site downloads section has been updated to point to this as well.
Chris - looks like you have done a good job at enhancing the driver. Many thanks. It works well with PHD2.4.
When SGP gets to 2.4, it will be a match made for heavens.
Looks nice but I have not renewed my SB subscription so can’t access it (I hate that, BTW, one reason I am now an SGP user is this subscription crap). I suppose I will eventually pay the $75 but will wait until spring when our winter weather is gone and SGP 2.4 is available, not much imaging in the Pacific NW in the winter/spring so it makes sense to have the subscription overlap two springs.
I like the SB mount but I suspect when I do replace it some day I will not buy a mount that needs ongoing payments to keep things up to date. I can afford the subscription easily enough - it is more the principle that counts for me. It is one thing to get a suite of SW (think Photoshop/Lightroom for $10/month) where you don’t pay an initial purchase, quite another to pay $10-15 K for a mount, as much as $1200 for the SW and still be asked for as much as another $200 per year. That is just abusive, IMHO.
Of course I would not object too badly if someone wanted to send me the file.
I think I have a problem with the driver - it refused to meridian flip (set to 10 degrees) implying I was on the wrong side. I paused the sequence, did a slew to target command and it flipped.
Has anyone else seen similar? Looks like I will have to set up a deliberate experiment to confirm.
[08/12/2014 18:32:27] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[08/12/2014 18:32:27] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[08/12/2014 18:32:48] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[08/12/2014 18:32:48] [DEBUG] [MF Update Thread] Performing serialize…
[08/12/2014 18:48:40] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: -349.913870402631 >= 10
[08/12/2014 18:48:40] [DEBUG] [Sequence Thread] Running blocking meridian flip…
[08/12/2014 18:56:40] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (True)
The TheSkyX ASCOM driver log would help - more like be essential. At least a section showing the mount tracking past the meridian so the pier side change can be seen.
However all I’m doing is read the side of pier from TSX using it’s scripting and sending it out unchanged other than translating the data to the ASCOM PierSide enumeration.
You said you set to flip Meridian after 10 minutes but the log says 10 degrees. 10 degrees is a lot. I believe there are 4 degrees per minute so 10 degrees is 40 minutes past the meridian.
Peter - thanks, yes it was set to 10 degrees. With my pier extension I can actually go up to an hour and a half with my longest refractor. In this case I reduced the amount as the guider camera was in a different orientation and I did not want a crunch. I have edited my post so that it reads correctly.
Fortunately I kept a copy of the original driver, which has been removed off the ASCOM site. I’ll do a simple back to back experiment over the weekend, weather permitting. That should quickly highlight if the driver is the cause. It is the old adage of proving something by turning the problem on, off and on again.
Using the old driver will not help to generate a fix for the new driver.
Even if the old driver does not show the problem I will still need a log file from the new driver that shows what is going on with that driver when you have this problem. Please try enabling logging in the new driver, reproduce the error, and post the logs (both SGP and the STX driver).
No problem Chris, I do problem definition for a living - first I have to establish if the problem comes and goes with the driver and then, as you say, supply the detail working in each case to see what is changing in the inner workings. I need to rule out SGP / customer root causes first!
Chris - I have managed to reproduce the error - the displayed SGP message is:
" Telescope must be pointing across the meridian to polar flip" I was imaging C11 - the scope is on the west side pointing east at the start and was trying to flip. SGP flip point was set to 10 degrees. Declination of object was 61 degrees.
I’m doing a few exposures before the moon rises and then will try again with the old driver at the same declination.
BTW, the log file has just three line entries and then stops. (Trace is enabled in the driver settings)
19:04:16.493 Telescope Version 6.0.5391.19493
19:04:16.497 Telescope Completed initialisation
19:04:16.665 Connected Get - False
I disconnected, reset the computer and loaded the old driver. I set the same declination and nudged the scope round to the meridian. I set an exposure time just less than the time to flip. The mount flipped successfully. If I can get the log file on the new driver to run properly, maybe I can find out what the issue is.
I reconnected to the new driver and the log file started to fill up, so I’m good to do more evaluation. Fog stopped play and I will try again later on.
That is what you get when doing the set up, not when you connect. It says that it isn’t connected so won’t be passing any information about the side of pier.
Is there no other log file?
What I get when I connect starts like this:
12:14:57.679 Telescope Version 6.0.5391.19493
12:14:57.679 Telescope Completed initialisation
12:14:57.683 Connected Set - True
12:14:57.683 Connected Creating TheSkyXAdaptor.RASCOMTele
12:14:58.481 Connect TSX Version 10.3.0, build 8458
12:14:58.703 Tracking Get - 0
12:14:58.704 Tracking Set - True
12:14:59.811 Tracking Get - 0
12:14:59.811 Connected CanSetTracking - Failed
12:14:59.812 Connected Get - True
12:14:59.814 Connected Get - True
12:14:59.830 m_SkyTele.GetRaDec Ra 19.8669345003998, Dec 8.91078214485722
12:14:59.830 RightAscension Get - 19.8669345003998
12:14:59.831 Declination Get - 8.91078214485722
There should be a log file starting in a similar way and showing SGP’s communication with the TSX scripting. The SGP log file covering the same period will also be useful because I can correlate what that shows with the TSX driver log file.
I will stress again that I need the whole files, not the bits that you feel may be relevant.
I tried the TSX driver and it seems fine. It swapped pier as expected.
I set up TSX with my AVX mount, connected using the ASCOM driver, and connected SGP to TSX.
I slewed to an object about 10 minutes from the meridian and set up a sequence of 10 2 minute exposures. The pier swap was set to 1 degree past. All the centring is turned off.
It collected images. When the time to flip went negative it did a slew to the other side of the pier and continued.
This seems to show that the TSX ASCOM driver will behave as expected if it gets the correct data from TSX.
That’s good to know Chris. It seems then to be something in the setup. On Dan Bisque’s advice, I’m connecting via the Generic Hub to your new driver. Unlike the prior driver, I have not manually changed the ASCOM profile but just selected the direct drive, prevented synch inhibit etc in the driver properties. I have SGP meridian flip set to centering turned on - but the failure occurs before that process kicks in. I’m using a Paramount MX mount.
If the generic hub is somehow messing things up - I guess it should show up in the SGP logfile. I will set up a dropbox and pop it up there and highlight the times for the two trials.
Don’t forget the TSX Driver log as well. There is nothing I can do without this.
I take it Chris that you are not connecting through the Generic Hub? I can try both ways and see if it makes a difference. Hopefully the log will populate this time.