I have failures with pulse guiding while ST4 works using the internal guider, previous experience is that pulse guiding also fails using PHD2.

Fedora 29
Kstars 3.0.0 Build: 2018-12-07
3.0.0-32.4
INDI: 1.7.4-2.fc29

Setup after m31 had crossed meridian, auto focused, adjusted guide camera focus, set mount tracking, aligned target and took test image. Set guiding to pulse guiding through astrophysics experimental driver.

Started calibration 19:43
Started capture of 60 second images 19:46
The mount goes wrong around 19:47

Mount starts moving away from the target.
The mount control panel was open and it indicated Status Error, it was changing every second or so between tracking and "moving" (not sure if it indicated moving/slewing...

The red driver tracking indicator is flashing between on and off indicators.

It is hard to get control to stop the mount, park did not work and I think I wound up just shuting things down.

Released the clutches and manually moved the mount back to the park position. Restarted KStars, went through the setting up again and ran without guiding to take a few images without incident.

The mount tracks very well without guiding.

Are you using a CP3 or CP4?

I'm running about a 6 month old build (once I get my software stack stabilized I rarely change it) and it is working correctly with my CP4.

I'm running CP4. There was a period when it seemed to work but then I had to revert back to ST4. So I was just trying it again to see if things had changed. I'm suspecting there is some condition or timing coincidence when it occurs. I want next to just run it guiding without imaging [edit] and also try it away from the meridian[/edit]. Beyond that I need to be next to the mount in order to catch it and it is cold out now. Might wait until Spring to try and narrow it down more.
There have been other reports that appear to describe the same thing, post 25659 I saw today.
[2018-12-07T18:00:25.395 EST DEBG ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[SCOPE] RES <VCP4-P01-11> "
[2018-12-07T18:00:25.397 EST INFO ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[INFO] Servo Box Controller: GTOCP4. "
[2018-12-07T18:00:25.399 EST INFO ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[INFO] Firmware Version: 'V' - P01-11 "
[2018-12-07T18:00:25.402 EST INFO ][ org.kde.kstars.indi] - AstroPhysics Experimental : "[INFO] Firmware level 'V' detected - driver loaded. "

The only change I've made related to pulse guiding was several months ago and I switched the code to use a maximum of 999ms pulse per command. The CP3 boxes seem to only support this while I found accidentally a CP4 box can handle > 999ms per command. I haven't been able to get AP to confirm this is intended or not.

So for a pulse guide command > 999ms the driver has to actually time the move so it starts the mount moving, starts a timer, then when the timer fires it stops the move.

I've been using this for several months and dozens of hours of imaging without any apparent guiding issues but it is certainly possible there is a corner case you might have tripped over.

Over the holidays if I get a chance I will setup a new chroot and build all the latest and greatest (?) EKOS/INDI code and see what regressions there might be. I haven't made any changes to the AP driver so presumably it is still working.

Understand I find that EKOS moves way too fast and loose for my liking and does not have a maintenance branch so I tend to find a build that works and plan on sticking to it for a long time until I find a problem or have a new piece of hardware that requires a driver update.

Mike,

Thanks for considering this. The log posted might be an example of what you describe. I was trying a PHD2 suggestion about not chasing seeing and to reach for a 4 second x1 binned exposure. Also it was encountering some guide camera imaging failures both of these might have contributed to a longer correction pulse being needed.

Most of the log is just messing about getting setup.
Guding starts around 19:45:16 and things start out fine with pulse commands being issued. But the pulse widths in the guide processing blocks keep on increasing for whatever reason.

At 19:47:01 The pulse length is 1472 and rather than a ApSendPulseCmd a <SetSlewMode> is seen. We then see the "Cannot pulse guide while manually in motion" message. Perhaps there are multiple threads involved but from then on the log makes it look likes the command and the response are out of sync and it is time to bail out.
Normally ST4 guiding provides fractional RMS error and unguided 4 minute subs look decent. Happy to test as weather permits if you want to keep your setup intact.

Tom

I have this problem too. ST4 usually works but guiding is poor.
Pulse worked once EXTREMELY WELL, but switching from ST4 to Pulse - for some reason it didn't recalibrate and guided extremely accurately for 2 hours until I shut down.

I tried pulse with PHD2 (same result).

The mount either starts huge jumps during calibration. Or will start guiding then perform huge jumps. I have been able to STOP them by clicking STOP on the guiding panel.

I have GTO4 - and I have had large pulse set to 1000 - 5000. I did not try less. I will try <999 tonight - appears it may be clear again.
I am unable to set my remote setup until the guiding issue is resolved.

Where do I look/check to see what INDI driver version I have installed?

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.