Need help with guiding issue

[Chuck Koos]

Logs: http://openphdguiding.org/logs/dl/phd2_logs_38w2.zip

I need some help with my guiding. I’m fairly new at this so I have no expertise at analyzing the data PHD2 provides.

Here’s the background: Struggled up until last week to get good guiding. But last week I finally got hours of sub 1” guiding. I thought I was golden. Then, on Monday, without any changes being made, I couldn’t get guiding to work. RA was all over the place. I tried to calibrate and that also failed, orthogonal basically a straight line (log 3-1-2021). I created a new profile (Test) and tried again(22:12:41) and calibration looked OK, but guiding was still bad (20:23:30). So I stop guiding and just let the mount do the work. I was then able to get almost two hours of pretty good subs of the Flame Nebula. This makes me think that the mount hardware is performing OK. Then, at 22:12:41, I tried another calibration, which looked OK. Guiding was reasonable after that. I don’t know why.

Last night I tried again, but still the same issue with RA as early on Monday. Here are the steps I followed:

·        Polar alignment with the mount scope, plus star alignment.

·        Slew to 0, 0. Mount was on the West side. Try a calibration (log 3-3-2021 19:02:53), RA all over the place. Tried drift alignment but clearly that wasn’t going to work when dec kept swinging all over, so I quit that immediately.

·        Tried calibrating in a couple different parts of the sky, same bad RA.

·        Slewed back near 0,0, this time the mount decided to go to the east side.

·        Installed an ST-4 cable and left the USB connected. Used my ST-4 equipment profile for guiding and the USB connection to keep mount location available to PHD2. Calibration and guiding look good (19:28:13).

·        Ran guide assistant, no major issues reported.

·        Took several hours of subs with OK guiding (1.2”-1.3” total RMS), with occasional moderate swings in RA and dec. Seeing? I have no idea how to determine good vs. bad seeing conditions.

·        Finished taking subs, and without making any other changes, removed the ST-4 cable and changed back to the USB only equipment profile in PHD2. Calibration wasn't terrible (23:14:31), guiding not OK, again have wild swings in RA. I don’t know why calibration worked.

·        Replaced the USB cable, no change, bad guiding.

·        Tried a couple more calibrations that were bad, then at 23:22:07, an OK calibration. But guiding still bad. I don’t know why calibration worked.

·        Last, I don’t change anything else, but go back to ST-4 cable set up, and as before, calibration (23:42:02) and guiding (23:46:18) OK. Not great guiding, but OK (1.41” total RMS).

·        Ran out of ideas to try, cleaned up and went to bed.

Since unguided, the mount tracks well, this makes me think the mount is OK (it's only a few months old). Since guiding using ST-4 configuration works OK, this makes me think that the guide camera, PHD2 and the mount are OK. That would seem to leave the laptop and the USB connection on the mount in question. But everything worked fine last week and I didn’t change anything. I’m stuck.

Any advise?

-chuck-

[Brian Valente]

Hi Chuck

that link does not appear to work for me?

--
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/897407be-f1b9-4ee2-a0de-4c6bc7373ab6n%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Chuck Koos]

Sorry, typo on the timestamp here:  "tried again(22:12:41) and calibration looked OK, but guiding was still bad (20:23:30)." Should be: "but guiding was still bad (22:14:39)."  

[Chuck Koos]

Try this. https://openphdguiding.org/logs/dl/PHD2_logs_BDEg.zip

[Chuck Koos]

Oh, and I checked repeatedly for any cable snags and there were none.

[Chuck Koos]

Went back and looked a saw several time errors in my original post. Here's a corrected version. Apparently I type as well as I guide.

https://openphdguiding.org/logs/dl/PHD2_logs_BDEg.zip

I need some help with my guiding. I’m fairly new at this so I have no expertise at analyzing the data PHD2 provides.

Here’s the background: Struggled up until last week to get good guiding. But last week I finally got hours of sub 1” guiding (log 2-24-2021 21:55:30). I thought I was golden. Then, on Monday, without any changes being made, I couldn’t get guiding to work. RA was all over the place. I tried to calibrate and that also failed, orthogonal basically a straight line (log 3-1-2021). So I stop guiding and just let the mount do the tracking from 20:23:30 until 22:01:38. I was then able to get almost two hours of pretty good subs of the Flame Nebula. This makes me think that the mount hardware is performing OK. I created a new profile (Test) and tried again (22:12:41) and calibration looked OK, but guiding was still bad (22:14:39), not horrific, but not great, 1.62”. Then, at 23:45:14 I tried another calibration, which looked OK. Guiding was not terrible, 1.58”. I don’t know why.

Last night I tried again, but still the same issue with RA as early on Monday. Here are the steps I followed:

·        Polar alignment with the mount scope, plus star alignment.

·        Slew to 0, 0. Mount was on the West side. Try a calibration (log 3-3-2021 19:02:53), RA all over the place. Tried drift alignment but clearly that wasn’t going to work when dec kept swinging all over, so I quit that immediately.

·        Tried calibrating in a couple different parts of the sky, same bad RA.

·        Slewed back near 0,0, this time the mount decided to go to the east side.

·        Installed an ST-4 cable and left the USB connected. Used my ST-4 equipment profile for guiding and the USB connection to keep mount location available to PHD2. Calibration and guiding look OK, 1.55” (19:28:13).

·        Ran guide assistant, no major issues reported, 19:37:34.

·        Took several hours of subs with OK guiding (1.56”-2+” total RMS), with occasional moderate swings in RA and dec. Seeing? I have no idea how to determine good vs. bad seeing conditions.

·        Finished taking subs, and without making any other changes, removed the ST-4 cable and changed back to the USB only equipment profile in PHD2. Calibration OKish (23:14:31), guiding not OK, again have wild swings in RA.

·        Replaced the USB cable, no change, bad guiding.

·        Tried several more calibrations that were bad, then at 23:22:07, an OK calibration. But guiding still bad. I don’t know why calibration worked this time.

·        Last, I don’t change anything else, but go back to ST-4 cable set up, and as before, calibration (23:42:02) and guiding (23:46:18) OK. Not great guiding, but OK (1.41” total RMS).

·        Ran out of ideas to try, cleaned up and went to bed.

Since unguided, the mount tracks well, this makes me think the mount is OK. Since guiding using ST-4 configuration works OK, this makes me think that the guide camera, PHD2 and the mount are OK. That would seem to leave the laptop and the USB connection on the mount in question. But everything worked fine last week and I didn’t change anything. I’m stuck.

Any advise?

-chuck-

[bw_msgboard]

Hi Chuck.  I’ll be surprised if anyone is going to be able to follow all this, you were kind of all over the map here.  There are clearly a number of problems with your physical setup and it’s going to take some dedicated time to sort them out.  That means time spent only on trouble-shooting, you can’t expect to be imaging until you’ve gotten these things resolved.  Here are a few of the things I can separate from all the thrashing around:

 

1. If you are going to use ASCOM guiding for the mount, you *cannot* leave the ST-4 cable connected to the mount.  I don’t know if you were doing that, but it’s something you have to remember
2. Since you are having a lot of trouble with ASCOM guiding, you should go back and triple-check that you’ve correctly set all the EQMOD parameters that are described in this doc:

https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings

3. Before you do a calibration, you should manually clear the Dec backlash at least until we can get a good measure of how big it is.  Just use a hand-control to move the mount north (‘up’ button) until you see the stars in the PHD2 display clearly moving – then start the calibration.
4. If you’re using ASCOM pulse guiding, get one good calibration near Dec = 0, then keep using it for the rest of the night.  Don’t keep re-doing the calibrations unless you are physically changing the orientation of the guide cam/ guide scope.  And don’t do that while you’re trouble-shooting
5. There are many times, independent of the guiding method, where the guide star is making a large deflection that has nothing to do with guiding.  This is probably because of a mechanical problem with the guide scope assembly – something is loose and moving around or a cable is pulling on it, etc.  

 

Here are just two examples:

 

 

 

To figure out what the mount is doing, it’s best to follow this procedure:

https://www.dropbox.com/s/os1thorvswmzaul/How%20to%20create%20a%20baseline%20for%20guiding%20results%20using%20OpenPHD2.pdf?dl=0  

 

If you want to experiment with both ST-4 and ASCOM guiding, do them separately in dedicated sessions, don’t keep flipping back and forth.  Do all of your guiding sessions within 20 degrees of Dec=0, pointing at least 45 degrees above the east or west horizon.  You’re just testing so it doesn’t matter what you’re pointing at, you just need some guide stars.  When you are looking at guiding results while pointing at high Dec positions, you’re just masking whatever tracking and guiding problems exist in RA.

 

To figure any of this out, you’re going to need to be very methodical, keeping notes about times and what you saw when things went astray.  And you must let things run for awhile, we can’t conclude anything from these short (e.g. 20-60s) guiding runs other than “gee, this doesn’t look good.”

 

Good luck,

Bruce

 

---

--

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/81e17e46-5026-4dd6-b85e-b2b32f693fden%40googlegroups.com.

[Chuck Koos]

Sorry if my descriptions were confusing to you, let me try to set a baseline here.

My background is in computer engineering final test. I have several decades experience running the Engineering test department for several companies. It was this background that allowed me to test and identify the problem with the v2.6.9dev3 release that prevented it from working on the 32b version of Windows 10. My small payback to you folks for the gift of all this great software and support you provide to the world for free. I'm now running v2.6.9dev4.

The flow with my set up was this.

SkyWatcher EQ6R Pro, 60/240mm guide scope, ASI120 guide camera. All software up to date as of Feb 2021.

On 2/24/21, using USB pulse guiding, I was able to calibrate, guide, train PPEC on my EQ6r-pro, and then image successfully all evening.

On 3/1/21, I took the exact same set up, with no changes of any kind to it, and was not able to guide. I slewed to the junction of the celestial equator and meridian and tried to run calibration, but that also failed. The star in the Star Profile kept jumping around randomly. At that point I let the mount tracking take over, without any guiding, and was able to capture some good images. I was impressed with how well the EQ6 tracked without guiding, no start trails with 60sec exposures. This led me to believe that the mechanical internals of the mount must be OK.

On 3/2/21, I double checked the EQmod and PHD2 settings as well as the cabling, etc. But since nothing had been changed since the successful 2/24/21 guiding, I wasn't surprised to find that everything checked out OK. 

On 3/2/21, After a polar alignment and star alignment, I slewed to the junction of the celestial equator and meridian. I tried to calibrate and got the same strange jumping around of stars in the Star Profile window as I did on 3/1/21. I then tried to calibrate in a couple of other sky locations, just to see if that would change the result. In engineering test, we referred to this as characterizing the system. It's exactly this type of testing that led me to the trouble with v2.6.9dev3. Not random, not all over the map. A methodical "poking" of the system to see it's reaction, and hopefully learn something from that. I didn't learn anything from this particular poke.

I then slewed back to the equator and meridian and switched to ST-4 guiding, in order to eliminate the USB subsystem. Another technique in engineer test, eliminate subsystems until you identify the one causing the failure. The ST-4 configuration used a mount setting of "On Camera", and the EQ6 as a "Aux Mount". As you know, this configuration sends guide pulse through the camera, but lets PHD2 still talk to the mount via USB so PHD2 always has mount position data.

And? This worked fine. Calibration and guiding ran without issue. Conclusion: The camera is OK (not loose or sending bad images), PHD2 is OK, the laptop is OK Sends pulse commands to the camera vis USB), the mount hardware is OK (I.e. motors, motor control logic, no cable snags, no imbalance, etc.).

Any time I find a solution to a failing configuration, I go back to the original configuration to ensure that it still fails. Otherwise, what you think fixed it, actually didn't. So I stop guiding, unplugged the ST-4 cable, and reselected the USB pulse guiding profile that was being used before. And? Failed. Oh, wait, I should replace the USB cable! Nope, still failed.

During all this I checked for snagged cables at least 3-4 time, and there were none. At this point in the evening, I couldn't think of any more tests to try, so plugged in the ST-4 cable again and reverted to the ST-4 profile. As expected, guiding was good and I took almost two hours of good images (IC434, ended up with a nice picture).

So my conclusion was that there is a problem somewhere between the USB port in the laptop, and the circuits that translate the PHD2 pulses into motor commands. To eliminate one more subsystem, I borrowed my daughter's laptop, installed all the appropriate software and built the configuration. Same problem calibrating and guiding. Not surprising since the ST-4 configuration gets all the pulse commands sent to the camera via the laptop's USB, but it was easy enough to check.

So unless someone with more knowledge and experience with all this than me can think of any other tests I can run, my next step is to contact Sky Watcher, because I think there's something that isn't working somewhere between the Prolific chip in the mount and the motor command board. But since almost everyone reading this (assuming you haven't gotten bored and quit a while ago) is more knowledgeable and experienced with this, I'm all ears for suggestions.

Bruce, FYI this document appears to be out of date. There's no longer a setting for pulse width override in the Ascom PulseGuide Settings window. Also, Side of Pier: "Pointing (Ascom)" and Guiding: (Ascom Pulseguiding) seem to be the default, at least they were for me. And trust me, I've rechecked these way more than three times! This problem is making me crazy. This works, that doesn't, WHY??? ARRRRRRG

1. Since you are having a lot of trouble with ASCOM guiding, you should go back and triple-check that you’ve correctly set all the EQMOD parameters that are described in this doc:

https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings

[bw_msgboard]

I wasn’t trying to suggest you didn’t know what you were doing during the tests, only that I couldn’t follow what you were doing and that it’s very hard for us to conclude anything from little 30 second guide sequences without much context.  Anyway, with regard to the EQMOD settings – I don’t have an EQ mount but I have what I think is the current release of the EQ software which comes with an EQ-mount-simulator for s/w development purposes.  The settings panels look like this:

 

 

The panel above is reached via the ASCOM setup dialog – from inside PHD2, PHD2 you click on the ‘mount properties’ icon in the Connect Equipment dialog.

 

The second set of options are in a fly-out panel in the EQMOD runtime UI:

 

 

The arrows point to things than can negatively affect guiding if they aren’t set correctly.  I don’t know what the default settings are.

 

If I boil down all your tests, it sounds like, at this point, you’re saying you can always calibrate and guide with ST-4 but never with EQMOD.  That is exactly backwards from the normal sort of problem.  This doesn’t look like a mount electronics problem to me assuming that you can use the EQMOD interface to slew the scope around at various speeds.  The ASCOM connection is mostly all software, there aren’t generally “circuits that translate the PHD2 pulses into motor commands.”  The mount firmware usually polls the serial port interface to receive the pulse-guide commands which are just text strings.  It parses those strings and translates the parameters (direction, duration) into on/off motor control commands – almost surely the same motor control commands that are used for slewing.  Further, the bad calibrations don’t suggest the mount isn’t moving – it’s just not moving consistently to produce the orthogonal pattern we expect.  Are you sure you are manually clearing the Dec backlash before *every* calibration?  As far as what happened on 3/1, the guide log shows you guided reasonably well for over 1 hour while using the ASCOM mount interface.  So I can’t line this up with your summary of what happened on that night.  The same appears to be true of your 3/2 experience – a bunch of bad calibration attempts with EQMOD, then a good one at 23:14.  One other point is that the mount is guiding at 0.5x sidereal via ST-4 but at a higher rate based on your EQMOD settings – you could try putting the EQMOD settings at 0.5x sidereal just to eliminate that difference.

 

I don’t think I can help you much further at this point beyond my comments above.

 

Cheers,

Bruce

 

---

From: 'Chuck Koos' via Open PHD Guiding [mailto:open-phd...@googlegroups.com]
Sent: Sunday, March 07, 2021 10:43 AM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] Re: Need help with guiding issue

 

Sorry if my descriptions were confusing to you, let me try to set a baseline here.

My background is in computer engineering final test. I have several decades experience running the Engineering test department for several companies. It was this background that allowed me to test and identify the problem with the v2.6.9dev3 release that prevented it from working on the 32b version of Windows 10. My small payback to you folks for the gift of all this great software and support you provide to the world for free. I'm now running v2.6.9dev4.

 

The flow with my set up was this.

SkyWatcher EQ6R Pro, 60/240mm guide scope, ASI120 guide camera. All software up to date as of Feb 2021.

 

On 2/24/21, using USB pulse guiding, I was able to calibrate, guide, train PPEC on my EQ6r-pro, and then image successfully all evening.

On 3/1/21, I took the exact same set up, with no changes of any kind to it, and was not able to guide. I slewed to the junction of the celestial equator and meridian and tried to run calibration, but that also failed. The star in the Star Profile kept jumping around randomly. At that point I let the mount tracking take over, without any guiding, and was able to capture some good images. I was impressed with how well the EQ6 tracked without guiding, no start trails with 60sec exposures. This led me to believe that the mechanical internals of the mount must be OK.

On 3/2/21, I double checked the EQmod and PHD2 settings as well as the cabling, etc. But since nothing had been changed since the successful 2/24/21 guiding, I wasn't surprised to find that everything checked out OK. 

On 3/2/21, After a polar alignment and star alignment, I slewed to the junction of the celestial equator and meridian. I tried to calibrate and got the same strange jumping around of stars in the Star Profile window as I did on 3/1/21. I then tried to calibrate in a couple of other sky locations, just to see if that would change the result. In engineering test, we referred to this as characterizing the system. It's exactly this type of testing that led me to the trouble with v2.6.9dev3. Not random, not all over the map. A methodical "poking" of the system to see it's reaction, and hopefully learn something from that. I didn't learn anything from this particular poke.

I then slewed back to the equator and meridian and switched to ST-4 guiding, in order to eliminate the USB subsystem. Another technique in engineer test, eliminate subsystems until you identify the one causing the failure. The ST-4 configuration used a mount setting of "On Camera", and the EQ6 as a "Aux Mount". As you know, this configuration sends guide pulse through the camera, but lets PHD2 still talk to the mount via USB so PHD2 always has mount position data.

 

And? This worked fine. Calibration and guiding ran without issue. Conclusion: The camera is OK (not loose or sending bad images), PHD2 is OK, the laptop is OK Sends pulse commands to the camera vis USB), the mount hardware is OK (I.e. motors, motor control logic, no cable snags, no imbalance, etc.).

 

Any time I find a solution to a failing configuration, I go back to the original configuration to ensure that it still fails. Otherwise, what you think fixed it, actually didn't. So I stop guiding, unplugged the ST-4 cable, and reselected the USB pulse guiding profile that was being used before. And? Failed. Oh, wait, I should replace the USB cable! Nope, still failed.

 

During all this I checked for snagged cables at least 3-4 time, and there were none. At this point in the evening, I couldn't think of any more tests to try, so plugged in the ST-4 cable again and reverted to the ST-4 profile. As expected, guiding was good and I took almost two hours of good images (IC434, ended up with a nice picture).

 

So my conclusion was that there is a problem somewhere between the USB port in the laptop, and the circuits that translate the PHD2 pulses into motor commands. To eliminate one more subsystem, I borrowed my daughter's laptop, installed all the appropriate software and built the configuration. Same problem calibrating and guiding. Not surprising since the ST-4 configuration gets all the pulse commands sent to the camera via the laptop's USB, but it was easy enough to check.

 

So unless someone with more knowledge and experience with all this than me can think of any other tests I can run, my next step is to contact Sky Watcher, because I think there's something that isn't working somewhere between the Prolific chip in the mount and the motor command board. But since almost everyone reading this (assuming you haven't gotten bored and quit a while ago) is more knowledgeable and experienced with this, I'm all ears for suggestions.

 

 

Bruce, FYI this document appears to be out of date. There's no longer a setting for pulse width override in the Ascom PulseGuide Settings window. Also, Side of Pier: "Pointing (Ascom)" and Guiding: (Ascom Pulseguiding) seem to be the default, at least they were for me. And trust me, I've rechecked these way more than three times! This problem is making me crazy. This works, that doesn't, WHY??? ARRRRRRG

1.      Since you are having a lot of trouble with ASCOM guiding, you should go back and triple-check that you’ve correctly set all the EQMOD parameters that are described in this doc:

https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings

 

On Thursday, March 4, 2021 at 8:44:03 PM UTC-7 bw_m...@earthlink.net wrote:

Hi Chuck.  I’ll be surprised if anyone is going to be able to follow all this, you were kind of all over the map here.  There are clearly a number of problems with your physical setup and it’s going to take some dedicated time to sort them out.  That means time spent only on trouble-shooting, you can’t expect to be imaging until you’ve gotten these things resolved.  Here are a few of the things I can separate from all the thrashing around:

 

1.      If you are going to use ASCOM guiding for the mount, you *cannot* leave the ST-4 cable connected to the mount.  I don’t know if you were doing that, but it’s something you have to remember

2.      Since you are having a lot of trouble with ASCOM guiding, you should go back and triple-check that you’ve correctly set all the EQMOD parameters that are described in this doc:

https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings

3.      Before you do a calibration, you should manually clear the Dec backlash at least until we can get a good measure of how big it is.  Just use a hand-control to move the mount north (‘up’ button) until you see the stars in the PHD2 display clearly moving – then start the calibration.

4.      If you’re using ASCOM pulse guiding, get one good calibration near Dec = 0, then keep using it for the rest of the night.  Don’t keep re-doing the calibrations unless you are physically changing the orientation of the guide cam/ guide scope.  And don’t do that while you’re trouble-shooting

5.      There are many times, independent of the guiding method, where the guide star is making a large deflection that has nothing to do with guiding.  This is probably because of a mechanical problem with the guide scope assembly – something is loose and moving around or a cable is pulling on it, etc.  

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/5ae5ebc0-9742-46e1-8624-7997f2ae2c5an%40googlegroups.com.

[Chuck Koos]

Thanks for sticking with me on this Bruce. The assistance is greatly appreciated.

Here's the EQMOD screens I get with my scope. As you can see, the Pulse Width Override slider isn't shown. It's always been like that, so I don't think it is relevant to the current issue. Other than baud rate, the settings look the same to me. 115200 baud is the default setting when the profile is created. Maybe I should try slower speeds?

The EQMOD controls seem to operate correctly when I use the slew controls to move the mount, as does the hand controller.

"there aren’t generally “circuits that translate the PHD2 pulses into motor commands.”"

What I meant by this is that there has to be electronics in the path that change the USB format data into the type the mount's motor control circuits use. This used to be done with an external cable that contained a Prolific brand chip in it. I have a similar cable for a Meade mount I own, I.e. USB to RS232. I assume that now that the latest EQ6R has a USB port on it, and Windows is using a Prolific driver to control the USB port on the laptop, that the data conversion is being done that way, inside the mount. Lots of assumptions on my part.

"Are you sure you are manually clearing the Dec backlash before *every* calibration? " 

I can't swear I do it EVERY time. It is my usual habit because I know it's important, but it's possible to forget. I'll make sure from now on.

"As far as what happened on 3/1, the guide log shows you guided reasonably well for over 1 hour while using the ASCOM mount interface."

You're right, I was focusing on the bad calibration and guiding at 20:22. I don't know why it decided to start working at that point. I'll pay anyone $100 if they can make it work like that all the time. But I have noticed that the calibration is inconsistent. I'll do several in a row and each one looks different (3-3-21 log, 19:14:18 & 19:16:37). Sometimes the star doesn't move in the Star Profile window, sometimes it moves, but in the wrong direction, sometimes it makes huge leaps, and sometimes it looks reasonable. But, except for that one you pointed out, the guiding following OK calibrations are horrendous. Here's the calibration before the good one:

"a bunch of bad calibration attempts with EQMOD, then a good one at 23:14."

Yes, the calibration was OKish, but all the guiding attempts after it were off the chart like the one below. Then another attempt with the ST-4 set up immediately after, and solid calibration and guiding.

"One other point is that the mount is guiding at 0.5x sidereal via ST-4 but at a higher rate based on your EQMOD settings  – you could try putting the EQMOD settings at 0.5x sidereal just to eliminate that difference."

I'll try this.

One thing I definitely take away from this conversation is that I need to slow down and as you said, be more methodical. I'm taking notes, but clearly they aren't detailed enough. Shame on me. How could I just miss that good guiding on 3/1? Late at night, frustrated as can be, and ready to pull out a baseball bat to see if that will fix the problem does not lead to superior thinking.

I should have clear skies at the end of the week, I'll see how it goes.

One other question. Is the quality of the calibration or guiding inherently worse with ST-4? Or is the final result the same as using Ascom via USB? That way, if I can't resolve this, maybe I can still get good guiding/imaging.

My understanding is that if I use the USB connection to the mount as an "Aux Mount", which seems to work, PHD2 knows the scope position and I wouldn't need to recalibrate every time I move to a new target, is that correct?

OK, that was actually three questions.

The good news is that even using ST-4, I was able to capture this image a couple nights ago:

-chuck-

[bw_msgboard]

Hi Chuck.  I’ll cut to the bottom line here before getting into any of this other stuff.  There’s no reason to think your actual guiding with ST-4 is any worse than it would be with ASCOM.  Since you have an aux-mount connection working and don’t think you’re having trouble with the extra guide cable swinging around, you’re good to go.  The reason we exhort people to use ASCOM is that most don’t understand how to use the aux-mount-connection and we don’t have any round-trip visibility to individual guide commands.  The ST-4 cables themselves are problem-prone because they often get handled a lot and coiled or kinked and then they fail in mysterious ways. Maybe you should view your current problem as a sideline issue that you can look into as you have time but not something you want to block your imaging efforts.

 

It looks like you must have a later version of EQMOD than me but the guiding-related params you’ve shown here look ok.  Just as a side note, you probably don’t want the ‘EPOCH’ setting to be unknown, JNOW is probably what your mount wants and reports.  That doesn’t have anything to do with guiding though.  The physical USB connection from the PC to the mount is just a data conduit, it’s just like a network connection, and it only passes ASCII character strings.  There is software running in the mount controller that reads the strings, parses them, then does whatever it needs to do to execute them.  For pulse-guiding, that means to run one of the motors at the established guide speed for the specified duration.  

 

I do think that reducing the baud rate on the ASCOM link would be a good idea.  The amount of traffic on that link is miniscule so there’s no need for speed.  And if you are getting intermittent garbled data on that link, it could be causing problems.  I think 19200 baud is a more typical default transmission rate.  I would also try specifying a guide speed of 0.5x sidereal just to eliminate another point of difference.

 

Onward,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/fb008579-e0d3-445e-b8ea-4ebe4c32ca28n%40googlegroups.com.

[Chuck Koos]

Good to hear that my guiding should be OK with ST-4. I'll keep at the Ascom issue and let you know if it gets resolved.

Thanks for all the help.

-chuck-