×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Wrong guide rate for AP900 mount - Guide Calibration Failure

  • Posts: 77
  • Thank you received: 16
Hi,
First, I want to thank Jasem and all the developers and contributors to this project. It is maturing into a wonderful tool. Well done!

I am encountering a problem with guiding my mount which has been present since version 2.7.6 when I first started using KStars/Ekos up to my current version of 2.8.6. In searching the forum there may be others having problems similar to mine.

The System includes:
Raspberry Pi 3 running Mate 16.04.3 LTS.
Full KStars/Ekos with GSC, drivers, etc. from the PPA.
Astro-Physics 900GTO mount with GTOCP2 control updated to version E Firmware (Chip).
ZWOASI174MM camera as guider.
ZWOASI071MC or Canon XTi (400D) as imager.
Serial RS232 WiFi Adapter (USCONVERTERS.COM) connected to the AP900 mount.
Bluetooth to serial adapter connected to Robofocus.

I VPN to the desktop on the Pi 3 and run a command line utility called socat to set up an ethernet to serial virtual port I call virtcom0 which controls the AP900 mount. I connect the bluetooth adapter to rfcomm0 for the Robofocus. I then run Kstars/Ekos and connect to the AP900 mount, Robofocus, guiding cameras, imaging cameras, etc. I will do a “warm” connect to the mount from the indi driver interface (the mount seems to connect and start already unparked). Slew the telescope in Kstars to a suitable star or to my intended target i.e. M31, M33, etc. for focusing. Run a plate solve (run locally on the Pi) then run the guider calibration. This is where I have the problem. The ASI174MM is set as guider (connected to my 45MM ED Borg guide scope at 300mm focal length). The Control Via is set to the ASI174MM (ST4 port) which has a cable running down to the mount (see attached Ekos screen shot) and the guide rate is set to 0.5 sidereal.


Sometimes (rarely) this works and the calibration succeeds and guiding can begin, however, most of the time it fails with the mount moving rapidly away from the target. I have discovered that it is using a guide rate of 64X and not the 0.5 that it is set for. It seems tied to the slew rate setting in the indi control panel as in the attached screen shot. When I changed that rate as an experiment it tried to guide and calibrate at whatever rate I changed it too. I was unaware that the GTCPO2 control was able to guide at such rates through the ST4 port.


I ran an indoor simulation of this problem using the CCD simulator outputting guide commands through the ASI174MM to the mount ST4 port and was able to replicate the problem and have attached the logs with this post. I can work around this problem by setting the guide rate to 0.5 on the hand controller and then do the calibration and guiding, however, I want to move to a more automated setup without having to be at the scope to correct this.

I am also having an ongoing issue with the mount not always parking in the proper position and it will continue to track after it is parked but this will be debugged in another post later.

Thank you for your help!

File Attachment:

File Name: log_11-02-...16-3.zip
File Size:207 KB
The following user(s) said Thank You: Jasem Mutlaq
6 years 4 months ago #20957
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 30
The "Slew Rate" shown as 64x should not have anything to do with guiding - it is the rate that the virtual hand controller in Ekos (or a joystick if you have that enabled) will move the mount.

If you reference this protocol guide:

www.astro-physics.com/tech_support/mounts/protocol-G.pdf

I think you'll see all the commands send during the guide calibration are just the commands to poll the RA/DEC of the mount and the pier side. That is all the "::GR#" ":GD#" ":pS#" commands.


The guide rate is actually not exposed in the INDI driver. That would be using the ":RG" command shown in the guide. This command is not present in the AP driver so the mount uses whatever the mount (via handcontroller?) is configured to use. I don't own a hand controller but I think mine is always at 1.0x which I believe is what AP recommends for guiding.

The "Slew Rate" UI sets the ":RC" rate (AP calls it the "centering" rate") and the "GOTO Rate" control sets the ":RS" rate which AP refers to as the "slew rate".

Very confusing but before we made some changes a few months it was even more confusing!

So it is likely the problem is elsewhere.

I think the problem with calibration could be with the ASI174MM as it is actually generating the ST4 guide pulses? I don't see anything in the log about these pulses however but I'm not familiar with the ASI driver.

As a data point I have been using the AP driver for a few months now with the ST4 port on my ASI1600MM and haven't had any calibration issues but I use PHD2 for guiding. I haven't tried the internal guide functionality in Ekos.

BTW - very recently (last couple of weeks) I put in code so the AP driver will properly support pulse guiding. It had been using the generic LX200 command so nothing was actually happening as the AP command is slightly different.
The following user(s) said Thank You: Jasem Mutlaq, Midwest Astronomer
6 years 4 months ago #20971

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
Mike,
Thanks for your reply and information. Indeed I know the “Slew Rate” should not have any bearing on the guide rate and is a puzzle to me. I do have my hand controller attached to the mount and move the mount with that as I do the initial polar alignment with my Polemaster. I leave the hand controller attached throughout the night. It seems that when the mount is initialized upon connection to EKOS or possibly in some other interaction with Kstars/Ekos that the guide rate may be some how affected so I use the hand control to cycle through the guide rates stopping at 0.5X sidereal for my mount. In doing this I reset the guide rate in the control box. I am aware that Astro-Physics recommends1.0X guide rate but I have had better overall guiding at 0.5X with my mount. I downloaded some months ago the command protocol for my mount with the GTOCP2 control box from here:
www.astro-physics.com/tech_support/mounts/protocol-D.pdf
This covers my control box through the version E firmware. The link you shared with me is for the GTOCP3 control box, however, I am sure these control boxes share most of the same commands with the exception of those specific to the GTOCP3 and newer controllers. It would be nice to have the guide rate exposed to the INDI driver so it could be monitored and set from there.

As you point out the problem may be elsewhere as in the ASI174MM or some other part of the system. Complex systems can present a challenge to troubleshoot and I will be doing some more testing on my system. Unfortunately I will have to do most of that indoors running the CCD simulator as I did recently because our weather here does not look to cooperate any time soon.

I have been using the internal guide module exclusively so far, however, I have had PHD2 installed on my system for some time now but just have not tried that. Perhaps I will give that a go in my next outdoor run. I will say that when I get the guide rate correct the internal guide module has worked well for me as a whole.

I have to say that I have wondered all along why others with Astro-Physics mounts have not had similar issue, however, how many people with an AP900 mount with GTOCP2 version E firmware are using this software?

I will update my PI3 to the latest software which I hope has your code changes for proper pulse guiding and see how that works with my mount. I believe (if memory serves) that my control box is too old to support pulse guiding but the updates my have some positive effect on my issue.

Again I thank you for your knowledgeable and helpful reply and hope to have some answers to post here from further testing.
6 years 4 months ago #20985

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 30
My thinking is the guide ST4 port on the ASI174MM is what is generated the pulses and these go directly into the AP mount controller so that would seem to be the problem area. Since the lx200ap driver doesn't have any code to change the guide rate I don't see how it is involved at this point.

I am running a Mach1 with GTOCP4. Honestly I don't know if the code in the lx200ap driver is backwards-compatible with a GTOCP2 control box - I've only recently started looking at the lx200ap driver and so I can't speak for what version of the firmware it was originally targeted.

It wouldn't be hard to expose the guide rate in the INDI driver - I'll put that on a list of things I'll look at as I have time.
6 years 4 months ago #20986

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
Mike,
I was able to do some more tests today. I duplicated my SD card with KStars/Ekos 2.8.4 and then updated to the latest KStars/Ekos/INDI software which is now at 2.8.7 on the duplicate SD card. In this way I was able to run some test on the 2.8.4 and 2.8.7 versions by just changing the SD card (a nice benefit of running on the Raspberry PI). I ran a test with the updated 2.8.7 software and ran into a problem with connecting to my mount straight away. The errors are included in the screenshots here:





I also included this screen shot to show how the computer is set to update the time and location to the telescope.



I then ran a test with 2.8.4 and was able to connect to the AP900 with GTOCP2 control box without issue. It seems there may indeed be some differences in these mount control box versions that introduce problems depending on control box and/or firmware version the driver is addressing. I will call Astro-Physics support this coming Monday for clarification on this. If I get a chance I will look in the protocol documents to see if there are any obvious differences. It is looking more imperative to solve these issues now as there may be others affected by this as well. As it stands I am wholly unable to use my mount on the most recent version of Kstars/Ekos (2.8.7).

If there do turn out to be real differences between these control boxes and firmware versions then either a set of conditionals need be implemented in the driver depending on the version of firmware polled from the control box (if that is possible in the driver) or separate drivers for each. It is obviously too early to tell at this point and hopefully some information will be forthcoming from Astro-Physics (their support is top level). I also tried this test connecting to the mount directly with an FTDI USB to Serial converter with the same results. I wanted to see if the ethernet to serial converter was causing any problems which, it seems not at this point. I have also attached log files from each of the tests labeled with the software version used.

File Attachment:

File Name: 2_8_4_log_....txt.zip
File Size:3 KB

File Attachment:

File Name: 2_8_7_log_....txt.zip
File Size:6 KB
Last edit: 6 years 3 months ago by Midwest Astronomer.
6 years 4 months ago #20998

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 30
Seems like the problem with the newer code happens here in your log:

[2017-11-18T14:51:04.356 EST DEBG ][ org.kde.kstars.indi] - INDI Server: "2017-11-18T19:51:04: Driver indi_lx200ap: *** stack smashing detected ***: terminated"
[2017-11-18T14:51:04.356 EST DEBG ][ org.kde.kstars.indi] - INDI Server: ""

I'm not really sure what is going on there.

I just built the HEAD of INDI and kstars and have no problems connecting to and controlling my GTOCP4 Mach1.

I always run a development snapshot of INDI so I'm not sure how the 2.8.7 version refers to what I'm working with - hopefully someone can help with that.

BTW I only use Intel Linux systems with INDI - I had problems with Arm based versions and they are so slow I just gave up on them for now.
Last edit: 6 years 4 months ago by Michael Fulbright.
6 years 4 months ago #20999

Please Log in or Create an account to join the conversation.

  • Posts: 57
  • Thank you received: 12
Another AP user monitoring with interest. I have a CP3 with the latest firmware. I have seen the two errors you are seeing
Error reading date from Telescope.
Failed to retrieve time format from device.

Jasem made some changes that eliminated the error reading the date. It still seems in my case the correct location and date/time are making it the mount.
indilib.org/forum/mounts/2791-ap-600e-mo...-initialization.html

I have yet to be outside to test guiding.

Edit: I'm am under OSX and am building the latest from git/master
Last edit: 6 years 4 months ago by DAVID J EISENLORD.
6 years 4 months ago #21089

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
Hi Mike & Jasem,

I talked with Howard at Astro-Physics and learned a bit about the GTOCP2 control box and why it is different from the GTOCP3 and newer controls. It seems that any keypress event on the hand control that moves the motors, such as pressing the arrow keys, or sending a move command from a PC over the serial port causes the guide rate to change. The guide rate then needs to be reset to the original value right after the keypress event. The GTOCP3 and newer control boxes do not have this behavior. I think it will be needed to include the guide rate setting in the INDI driver and use that value as set point on initialization and to return to after each move command. As I understand, the hand control for these mounts is basically a small computer that talks with the mount via a serial interface and is sending the same command set to the control box as the driver for the PC (Linux box or PI 3, etc.) does. So this would cover the guide rate problem I am seeing. The next issues are of course the problem with time and date errors that I and deisenlord are seeing. I hope to be able to have Jasem connect remotely to my system and sort that out.
6 years 4 months ago #21142

Please Log in or Create an account to join the conversation.

Thanks that's very useful information. I will check if we can differentiate between GTOCP2 and GTCOP3 and if that's possible, then the guide rate can be reset after each motion command.
6 years 4 months ago #21152

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
You're welcome! One thought that just came to mind and will need clarification is regarding the exact timing of resetting the guide rate. Does it need done right after the keypress event or when the mount has finished the commanded move? It may not matter, however I believe I will make another phone call or email to clarify this.

As I mentioned before, I think including the guide rate setting in the INDI driver will be needed to facilitate this working change in order to be able to use that value as set point on initialization and to return to after each move command (correct me if I am wrong).

One thought about differentiating the control boxes from each other - the firmware is labeled in letters such as A, B, C, D, E, etc. and reported back to the INDI driver on connection or at least that is my observation. The control box models may end and start at different levels i.e GTOCP2 ends at firmware E and then maybe GTOCP3 starts at level F or higher and so on. I am sure Astro-Physics would be helpful here. Anyway it is just a quick thought.
Last edit: 6 years 4 months ago by Midwest Astronomer.
6 years 4 months ago #21156

Please Log in or Create an account to join the conversation.

  • Posts: 105
  • Thank you received: 30
I think the ":V#" command would return what we need to determine the firmware level. Then we could make the code for guide rates dependent on that as for newer firmwares I'd rather not be sending commands every guide correction that are unnecessary.

I'll follow up with Howard next week after Thanksgiving. I have a few other questions I'd like to discuss with him for possible driver enhancements.
6 years 4 months ago #21180

Please Log in or Create an account to join the conversation.

  • Posts: 57
  • Thank you received: 12
Michael, you mentioned you just added the commands for pulse guiding for AP mounts. Have you been using this?
6 years 4 months ago #21181

Please Log in or Create an account to join the conversation.

Time to create page: 0.700 seconds