Ron,

I believe this particular issue with long pulses being required is considered fixed.
indilib.org/forum/development/4442-lx200...ing-fixes.html#33815

The last time I used the driver with my Mach1 (CP4) PHD2 worked fine with pulse guiding. This was probably about 2 months ago. I'm not using INDI for my setup these days so I haven't tried any recent INDI releases. Someone could check the commits against the driver since say Jan 2019 and see if anyone changed it.

My advice is for AP owners to make it clear to AP they are interested in INDI support so AP can decide if they want to make it a priority.

I last tested this using a nightly build from 4-1-19. At that time it was working correctly. When the weather clears and my schedule allows I will run another test using a greater than 999 pulse for guide calibration and see how it goes. I will update to whatever the latest nightly build is at the time.

I agree with Mike about letting Astro-Physics know your interest in INDI support for their mounts. The more people they hear from about INDI will only help them take it more seriously.

The problem is just how the AP serial protocol (that is documented) works.

The command to move the mount at guide rate only accepts up to 999ms.

Otherwise you have to do a convoluted sequence just for a simple guide motion:

1) Set mount to move at guide speed
2) Tell mount to start moving
3) Wait the duration desired for the guide action
4) Tell mount to stop moving

AP really made it even more exciting as you cannot read the current move speed from the mount and there are no return codes for any of these operations.

So you can't verify you are at guide speed before doing the move.

You are just hoping the start and stop commands were accepted as you don't get any confirmation.

I found that on my CP4 you could actually send durations up to 9999ms but this is not documented (like most of the stuff for AP mounts).

It is tempting to make it an option to compile the driver to just use up to 9999ms durations but since it isn't documented I wasn't confortable shipping the code this way. I did run it that way for months without any problems.

My current view is AP should get involved in some fashion as clearly people are using the driver and the current documentation from AP is not adequate. If you look at an ASCOM debug log from the AP driver there are so many commands being used we have no documentation for it is clear writing and supporting a proper driver is just not possible without more support.

That said the driver is light years better than when I first tried to use it about 2 years ago and for an _attended_ imaging session I think it will do everything required for imaging. I still would not use it unattended imaging - but that is partly based on my poor experiences trying to have EKOS run an overnight session unattended compared to something like ACP or Voyager under Windows.

I procured GTO3-4 control code data. Will this help the driver advance? I've kicked the bee's nest in the AP support group - and lots of interest in the topic. It's sounding rather positive in our favor.

Maybe I'm missing something but I just compared it side by side with the protocol-G.pdf from over 10 years ago and all that is different is now at the top it says it will work with a CP4 box.

There are no new commands in this document - someone please correct me if I'm wrong.

I'm still waiting for a clear set of log files showing a problem with pulse guiding. It has been working for me for over 2 years.

The log should clearly show if there is a problem sending pulses over 999ms.

In normal guiding conditions this situation should never occur so the :Mnxxx# command is used for corrections up to 999ms and this is completely handled inside the AP firmware and no timing is done by the INDI driver.

FWIW I've been using PHD2 only under Linux to guide so I do not have any experience with the internal guide algorithm in EKOS.

Oh. That's disappointing. If you are interested in further development of this driver, should we put together a list of commands or protocols that you would like to see?

My take on this is we would want a publicly downloadable document with updated commands so other developers could reference and verify or maintain the source code. I think that would be the best practice going forwards for open source drivers in general if possible. And that is the spirit of open source development anyways as I see it. To decouple dependency on the original provider to enable people to truly own their equipment.

Ah I'll try PHD on the PI again - though I would prefer insternal (all in one) but which ever works.

I didn't try PHD on the PI again, but I did boot and calibrate and used internal guiding last night. Started up around 1.0 rms - I tweaked settings and quickly got it down to .50... with a bit more watching and tweaking I was a good .39 - .49. It works VERY WELL through out the nightly test. HOWEVER - I have never had focus problems before. I have not changed anything. I could not get focus to work. I tried single/auto select crop and focus. (generallly it lost the star after some attemps to correct. Other times it continued to try and focus (near very low HFR) numbers and never stopped. Later I could get better results (it would try) with full frame. HOWEVER it would say 1.0 or even under (nice) HFR and the subs were horrible. After an hour of fiddling with settings... I stopped it and manualy focused visually pretty close using the automatic control. But manually looking at stars and HFR. It then managed to shoot a couple infocus subst then I believe it was lost again.

Another night of nothing useful. Guiding was promising.

When it did complete focus it would say 1.2 or 1.0 or even less HFR. I run DSS live and it weighed the same subs with a HFR of >3 or even >4.
I've never had it give me any problems in focus before.

Glad to see you made some progress.

I never had much luck with the focusing in Ekos either.

I'm happy with the driver support of INDI mostly but still find Linux is lacking a robust imaging program for unattended imaging. I think it will require a start from scratch with that as the intended purpose instead of bolting some CCD functionality on a planetarium program.