Jump to content

PHD2 "cable snag" error.


SteveBz

Recommended Posts

Hi Guys,
After many months of successful guiding with PHD2, it suddenly stopped guiding and gives me that cable snag error we've all seen from time to time.

I checked the cables and the connection pins and everything looks fine. Really what I think I need to do is swap out the cables and the camera to narrow down the source of the error. Sadly I don't have spares of either.

Does anyone have any other ideas to help find out what's gone wrong?

I'm about to order a spare cable from eBay, but I don't really want to throw 100 quid at a spare camera.

Thanks for your help.

Setup:

- qhy5

- raspberry pi 3b+ with PHD2

- synscan mount.

Regards

Steve.

 

Edited by SteveBz
Link to comment
Share on other sites

Hi Steve

What do you mean when you say "stopped guiding" ?

The PHD2 graph has frozen ?

PHD2 is issuing guide corrections but the mount isn't responding ?

The guidecam isn't looping?

Is this a ST4 or EQMOD setup?

I didn't know there was a PHD2 cable snag error message.

Can you post the relevant PHD2 Guidelog ?

Michael

  • Like 1
Link to comment
Share on other sites

Hi Michael,

It's looping fine and the software is behaving well. It's just when you start guiding the star seems to drift in RA and when the star has drifted out of the little rectangl, you get this error message, like one axis is not responding. I imagined that one of the ST4 pins was corroded, but it's not so, they are beautiful and shiny.

I'll find the logs later and post them here, but it seems to be a physical thing, maybe the cable, maybe the camera, maybe synscan (I hope not!).

I can replace the cable easily enough (it's in the post), I'm going to try to replace the qhy5 with an Orion Autoguider, but at the moment Raspbian doesn't recognise it. It's apparently the same as a qhy5, but with a different device number. I'm going to try to hack it later. If it's one of those two, great. If it's the synscan controller I have no idea what to do.

Thanks and regards,

Steve

Link to comment
Share on other sites

Hi Steve

I think you've discovered what is covered again and again here on SGL. 

For reasons unknown, ST4 connection can be extremely flakey. 

What appears to be a perfectly good cable stops working, but a replacement fixes it. 

A bit like USB, works fine for some of us, others have endless problems for no apparent reasons. 

If you continue to get problems I would switch to an ASCOM EQMod type connection. 

Has the advantage of providing PHD2 with RA and Dec and Guiderate setting. 

Just saying....... 

Michael 

 

  • Like 1
Link to comment
Share on other sites

Hi Michael,

Raspberry Pi runs on Linux, so it'd have to be INDI, the ASCOM equivalent.  I have got it installed and I did have a play with it, but not got it quite right yet.  I may try more later.

If it's just the ST4, that would be great.  Cheap and easy to fix.

Steve.

Link to comment
Share on other sites

5 hours ago, michael8554 said:

Has the advantage of providing PHD2 with RA and Dec and Guiderate setting. 

Hi Michael,

What does this mean.  Does it not have the same with direct camera?

Regards

Steve.

Link to comment
Share on other sites

Well I'm having to guess what your setup is since you haven't specified it.

If you have a connection from the PC to the mount and a USB cable from the camera to the PC then I'm not sure why you need an ST4 cable.

Michael

  • Like 1
Link to comment
Share on other sites

2 hours ago, michael8554 said:

 you have a connection from the PC to the mount and a USB cable from the camera to the PC then I'm not sure why you need an ST4 cable.

There's a lot of string and chewing gum.

I have a main application running on my PC hand coded in Python, then over the WiFi there is a raspberry pi running phd2 for guiding, gphoto2 for dslr photos, another bit of python that directly communicates with the synscan via an rs232 cable. The guide cam has an st4 on camera guiding port that communicates with the synscan handset. So synscan has two inputs. The main control port and a guiding port. I suppose I could guide through the control port, but I'm not sure how I would  collect the signals from phd2 and relay them to the control port. And since it already works, or used to, it seems OK.

I did manage to get the Orion Autoguider talking to phd2, but I don't really want to spend several evenings orientating it, focusing it and calibrating it. I'm really banking on the st4 fixing the problem.

I also reinstalled phd2, just in case. No change.

Link to comment
Share on other sites

15 hours ago, michael8554 said:

With the PHD2 Manual Guide buttons, with a big step entered say 5000 ?

Ok, I did that but with the default value of 600.  I'll try again with 5000.

In the future, how would knowing RA, Dec and Guiderate help?

S.

Link to comment
Share on other sites

3 hours ago, SteveBz said:

In the future, how would knowing RA, Dec and Guiderate help

If PHD2 knows the RA and Dec and you've Calibrated at Dec 0, PHD2 will compensate for guiding at different Decs.

And permanent setups can use the same Cal for months, so long as the kit or orientation of the guidescope isn't changed. 

If it doesn't then you have to Cal at every change of target. 

And knowing the Guide Rate gives a baseline for Cal and allows PHD2 to give help if say one axis is behaving differently. 

Michael 

  • Like 1
Link to comment
Share on other sites

2 hours ago, michael8554 said:

If PHD2 knows the RA and Dec and you've Calibrated at Dec 0, PHD2 will compensate for guiding at different Decs.

And permanent setups can use the same Cal for months, so long as the kit or orientation of the guidescope isn't changed. 

If it doesn't then you have to Cal at every change of target. 

And knowing the Guide Rate gives a baseline for Cal and allows PHD2 to give help if say one axis is behaving differently. 

Michael 

Great info.  OK, it's on my list of things to improve.

So I'm there now and I'm manually guiding in all 4 directions in PHD2.  None work.  So unless the ST4 earth is loose, it's the QHY5 or the SynScan.  Either way, your solution would fix. it.

As I mentioned I'm on Linux so I can't use ASCOM, but INDI is the Linux equivalent.  If I can do the same thing with INDI, that would fix it.

S.

Link to comment
Share on other sites

On 08/04/2020 at 21:44, SteveBz said:

If I can do the same thing with INDI, that would fix it.

Yes, you can.

 

On 07/04/2020 at 22:53, SteveBz said:

There's a lot of string and chewing gum.

I have a main application running on my PC hand coded in Python, then over the WiFi there is a raspberry pi running phd2 for guiding, gphoto2 for dslr photos, another bit of python that directly communicates with the synscan via an rs232 cable. The guide cam has an st4 on camera guiding port that communicates with the synscan handset. So synscan has two inputs. The main control port and a guiding port. I suppose I could guide through the control port, but I'm not sure how I would  collect the signals from phd2 and relay them to the control port. And since it already works, or used to, it seems OK.

That does sound like a lot of string and chewing gum.

What about this: indi & kstars/ekos & phd2 on a raspberry pi; eqdir cable from RPi to mount (no synscan); usb cable to imaging & guide cams; connect to RPi over wifi using windows remote desktop on you pc? And if you don't want to use ekos, you can use ccdciel & cdc on your laptop. You can keep phd on the RPi in order to keep wifi communications down. With everything running on a Raspberry Pi, an imaging session won't get interrupted in case you lose wifi connection between the RPi and PC.

  • Like 1
Link to comment
Share on other sites

3 hours ago, wimvb said:

What about this: indi & kstars/ekos & phd2 on a raspberry pi; eqdir cable from RPi to mount (no synscan); usb cable to imaging & guide cams; connect to RPi over wifi using windows remote desktop on you pc? And if you don't want to use ekos, you can use ccdciel & cdc on your laptop. You can keep phd on the RPi in order to keep wifi communications down. With everything running on a Raspberry Pi, an imaging session won't get interrupted in case you lose wifi connection between the RPi and PC.

Hi Wim, thanks for your response.  Actually, I've been playing with a similar idea all day.  I'm just building a second RPi with Indi, Indi-Web and PHD2 on it.  It works quite nicely from Ekos on my pc in simulation mode.  The eqdir idea is an excellent one.  I didn't think of that.  I'll look into it. The QHY cam could direct either directly to PHD2 or via Indi and to the mount via Indi.  The mount could also connect directly to Indi via EQDIR. There is a PyIndi wrapper that I could use to connect my desktop app to the RPi over WiFi.

I didn't mention that I'm Linux and I have an Arduino doing weather, autofocus and 'bulb' (because it's Nikon and you can't do more than 30secs bulb through gphoto2). 

Thanks,

Steve.

Link to comment
Share on other sites

As I read up on PHD2, I'm beginning to get the idea that if I use an ST4 cable without a direct mount connection, I need to re-calibrate each time I change the Dec.  Is that true?  Could this be causing my problems?

Regards

Steve.

Link to comment
Share on other sites

1 hour ago, michael8554 said:

Correct. PHD2 wants to compensate the RA guiding for changes in Dec, based on the Dec position supplied by the mount 

Michael 

Hi Michael and Wim,

so that was the problem. I normally image overhead and in a westerly direction. When I moved to m81/2 in an easterly direction it all went wrong.

Recalibrate and it returned to operation.

Thanks for your help.

Longer term, Indi and eqdir are the way to go.

Regards

Steve.

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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.