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

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.

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.

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.

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.

Michael, you mentioned you just added the commands for pulse guiding for AP mounts. Have you been using this?

Yes it works fine. I have put the ST4 cable back in the drawer (for good hopefully!).
Jasem made an important change earlier that made the actual pulse guide option appear correctly in the INDI Control Panel.
Then I corrected the serial protocol commands used to send pulses to the mount - it had been using the LX200 generic commands which do not work on the Astro-Physics.
So all should work now - please let me know if there are any problems.
BTW - everything we're doing is based on the GTOCP3 protocol document so it is useful to have reports from older firmwares. At the moment the driver does nothing to discern the protocol level of the controller - hopefully that won't be required for too many features.

Great news thanks!

Just looking at the code and the driver is already identifying the firmware version.
LinuxUser - could you tell me what firmware version is reported on the 'Firmware data' tab of the INDI Control Panel?
On my GTPCP4 controller I get "VCP4-P01-01".

I've added some code to set the guide rate from the INDI Control Panel - I'll try to test it tonight and I'll submit a PR.

Changes have been accepted.
I don't know if this fixes the original problem but hopefully will allow one to reset the guide rate to a desired rate if it gets changed (in a way I'm still not clear about). I hope to get in contact with AP next week to see if anything additional is required.
Note if the interface shows the rate you want selected you will need to select a different rate and then reselect the rate you want to actually get the command sent to the mount.

Hi Mike,
As noted in my earlier post here:
www.indilib.org/forum/mounts/2819-wrong-...l?limitstart=0#20998
I am unable to connect to my mount from the Raspberry PI 3 at all now due to this time format error message. I have updated to the latest KStars 2.8.8 and still have the same error, INDI driver (indi-lx200ap) crash and connection problem. The strange thing is I have the same error message from the latest KStars/Ekos VM, however the driver does not crash and this will connect to the mount despite the error. Not sure what the difference is between the VM and the Pi 3. I can do a screen share with you or Jasem to help get this resolved, we just need to set a time and then "meet" virtually to get this done. I do have TeamViewer on the VM.

My mount reports firmware "E" in the INDI control panel when it does connect. This makes sense as I do have the E1 firmware chip installed, which is the latest available for the GTOCP2 control (if memory serves).

Thanks for adding the guide rate to the INDI driver and interface. Once we can get the mount connecting again after fixing this time format error message then I will give that a test.