AZ GTI, astroberry (raspberry pi), PHD2 autoguiding setting up trouble issues

[Elp]

Hi, first post so please bear with me, having issues with autoguiding, looked at numerous forum threads and cannot find the issue specific to my setup and the issue I am having.

Equipment in question:

ZWO 224 using as guide camera plugged into raspberry pi running Astroberry via USB3,

Lynx Astro EQDIR cable plugged from USB on raspberry pi into hand controller port on AZ GTI.

 

Configuration:

Synscan android app successfully connected to AZ GTI via wifi and can control via mobile phone,

AZ GTI setup to connect to raspberry pi (so it's on the raspberry pi network) AZ GTI connected successfully as it is recognised in PHD2 and EKOS,

In PHD2 the mount is setup as INDI mount (AZ-GTI) and connects.

 

Issue:

PHD2 is unable to guide in either RA or declination (see screenshot error showing up), it is always one or the other. I have tried setting up multiple times, tried using the network cable which came with the camera directly from the camera into the hand controller port and setup in PHD2 as "on camera" (I suspect this setup is wrong anyway and was one of the first I tried). Polar alignment has been checked multiple times, the end result is always the same, the star field within PHD2 window will always drift in one direction so any star chosen will eventually disappear out the field of view as the mount isn't moving to follow it.

Looking at the PHD2 graph I know it is trying to send pulses to the mount but either the movement is too much for the mount to move or something isn't happening as it should, in the example screenshot provided I tried this indoors on a fairly fast (compared to in the field) rotating star field looking at a screen so it will fail, though the mount didn't adjust at all, no matter how I've setup prior the AZ GTI refuses to adjust to follow a guide star. I have tried manually moving the mount in PHD2 and it doesn't seem to move in any direction, manually moving however does work in EKOS so the hardware seems to be plugged in correctly. EKOS even knows where the mount is pointing and can issue go-tos (although it is slightly off target at the moment).

I am kind of at my wits end to why autoguiding isn't working, if anyone can help please assist.

On another note if someone can advise how to configure PHD2 so the off yellow warning box colour can be changed so the error message can be read clearly - I know theres a line of code I can use in the terminal window which refers to a resource file to change to the default PHD2 colours and launches the software but the changes are never saved.

 

[barbulo]

Hi and welcome to SGL. 

Is your mount in tracking mode? PHD2 sends orders to the mount to correct the actual movement.

Be sure your mount is in tracking mode at sideral rate.

[Elp]

Hi, is that set in synscan?

[Stuart1971]

The cable DOES NOT go from the ST4 port on the camera to the hand controller port, if you are using the ST4 cable for guiding, it goes from camera to the ST4 guide port on the mount, but you are better to use pulse guiding, which does away with this cable and just uses the USB connection from camera to PC…so which one are you actually using…??

[Elp]

At first I tried st4 from camera to hand controller port on azgti but I've read that does not work.

Now I use a Lynx Astro EQDIR from raspberry pi usb to hand controller port on azgti. That is how it was done in the above post.

[barbulo]

If you are using EKOS, you can switch the tracking on and the select the track mode in the “INDI Control Panel”, “Telescope” tab, “Main Control” tab.

EQDIR usb cable is the best option. 

HTH

[Elp]

Think I tried that once before and it didn't help with what phd2 was doing. At the moment I want to try everything within phd2 to eliminate any issues, question is why isn't sidereal tracking an option within phd2 if it is a necessary setting to enable?

[michael8554]

Many questions to ask,  so it would be easier if you post the PHD2 GuideLog file.

The yellow message refers to insufficient movement during Cal, which suggests your Guide Rate setting is too low in one of the softwares you are using.

Equal and opposite 2500ms RA and Dec guide pulses from PHD2 could indicate that either RA or Dec pulses are going to both axes, due to cabling problems.

Note that those equal 2500ms pulses were calculated during Cal to move RA 98.2 pixels, but Dec only 22.2 pixels. 

Did you Cal at Dec =0 ?

Otherwise that indicates a lot of Dec Backlash that became part of the calculated Guide Rates during the PHD2 Cal.

Michael

 

[Elp]

Hello Michael, no I haven't calibrated at zero declination. Looking into drift alignment I suppose it goes hand in hand to setup on the celestial equator first to ensure my alignment is spot on. Should be a clear night tonight so I'll try again and report back, I suspect my equipment connection is okay, my software setup is generally okay so it must be a missing step such as this. Previously I only physically aligned the setup to Polaris and tried guiding from a nearby star, might also explain why the polar alignment within phd2 also didn't work (target is off screen).

[michael8554]

Calibrating at Dec =  0 is important, but the suspected very low Guide Rate is your main area of concern.

Post your previous GuideLog.

Michael

 

 

[Elp]

Michael - guide log below, it's not necessarily relevant to my above screenshot at that was at 16:22hr and the log stopped prior to that but it will give you an idea of settings and what was being done. It is not the best data to look at as I was testing it indoors looking at a slow rotating starfield at 0.25 speed which will be too fast:

 

Once I try again outdoors I will update.

PHD2_GuideLog_2021-09-20_152211.txt

[michael8554]

Oh dear.....

Yes, you were Calibrating at Dec = 90, where stars are effectively "stationary".

The first three Cals were done with the INDI mount driver, which reported your Guide Rate = 7.5arcsec/sec, and the RA and Dec positions.

But your exposure of 20ms is crazy fast, leading to Star Lost messages.

And probably exposures were occurring before Cal moves had completed.

Exposures in the order of 1.5 to 3 seconds are usual.

Then you switched to ST-4, so RA, Dec, and Guide Rate were unknown.

Were you still at Dec = 90 ?

Reported Guide Rates were RA = 21.6, Dec = 24.4, your previous setting was 7.5, which is okay.

I get the feeling you are using PHD2, but haven't read how to use it !

Look at the Help and How To guides available via the Help menu.

Start here:

https://openphdguiding.org/phd2-best-practices/

Stick with the INDI driver with a correct setup !

Michael

 

[Elp]

Like I said this was conducted indoors, the guidecam was on the floor pointed at a mobile phone screen so the data presented herein is not indicative of a true test, I tried multiple things at the time hence the strange guidelog. I just wanted to see if phd2 can move my mount which is an issue i don't know whether this is working or not I'll go outside next and try again.

One question, why can't phd2 manually move my azgti like I can do in ekos or via the synscan app?

Edited September 23, 2021 by Elp

[michael8554]

15 hours ago, Elp said:

why can't phd2 manually move my azgti like I can do in ekos or via the synscan app?

It can,  read the instructions 😆

Tools / Manual Guide.

Set the pulse size to 5000.

Each single click on the N, S, E, W buttons will move the mount a small amount that you will only see if you're looking at the guide star.

Used for fine framing, or the Star Cross test.

It's not a replacement for the high speed slew buttons on the handset, that's not a requirement for guiding.

Michael

[michael8554]

23 hours ago, Elp said:

Like I said this was conducted indoors,

Ah, my bad, I didn't spot your test conditions.

I just latched onto the Log which I falsely assumed was a proper guiding session.

So I gather you were testing your RA and Dec movements, but Dec=90 is not going to give any meaningful information.

Michael

 

[Elp]

Just an update on this thread to anyone who may face a similar issue.

I have since bought an Asiair Pro which I have found to be much more user friendly and stable than the Raspberry Pi running Astroberry (I still have it as a backup and to use for imaging only), more so the Asiair has a proper mobile app which is easy to use on a small mobile screen so no more needing to use a computer.

I can now control the AZGTI via the Asiair on screen controls, there were no issues setting up my equipment in a similar fashion to before.

The key change I believe is having also updated the firmware of the AZGTI from v3.26 to v3.37, and have tried imaging at 2, 3 and 5 minutes with success though 1-2 minutes seems to be a good sweet spot.

I can now concentrate on imaging with this excellent little mount.

[AstroNebulee]

7 minutes ago, Elp said:

Just an update on this thread to anyone who may face a similar issue.

I have since bought an Asiair Pro which I have found to be much more user friendly and stable than the Raspberry Pi running Astroberry (I still have it as a backup and to use for imaging only), more so the Asiair has a proper mobile app which is easy to use on a small mobile screen so no more needing to use a computer.

I can now control the AZGTI via the Asiair on screen controls, there were no issues setting up my equipment in a similar fashion to before.

The key change I believe is having also updated the firmware of the AZGTI from v3.26 to v3.37, and have tried imaging at 2, 3 and 5 minutes with success though 1-2 minutes seems to be a good sweet spot.

I can now concentrate on imaging with this excellent little mount.

Definitely agree the asiair pro is so user friendly and great to get into astrophotography, clear skies friend 👍