Re: Pulse Guiding

Ross Salinger

Can I to assume by this exchange that SiTech uses the technique of pulse width modification to implement ASCOM guiding? Is it also the case that the guiding program sends a message which contains the duration of the required pulse? SiTech  then, I surmise, uses that duration to forward the command to the control unit and onto the motors.


In the SiTech ASCOM log that I looked at most recently, it also appeared that all of the durations were in 10’s of milliseconds which would correspond to a correction of .01 seconds times the guide rate in arcseconds/second or .15 for 1x sidereal. I figure that’s coming from the guiding program as well but it seemed odd to me that is was always in 10’s. I guess that’s the minimum pulse that a typical mount can accurately respond to.


Answers appreciated to give me a hand with some strange guiding results.




From: SiTechservo@... [mailto:SiTechservo@...]
Sent: Monday, January 15, 2018 4:19 PM
To: SiTechservo@...
Subject: [SiTechservo] Pulse Guiding





The best definition I have seen was by Craig Stark, author of Nebulosity and PHD:


“If I might interject here... as the author of PHD Guiding, I've spent a bit of time looking into the subject. The term "pulseguide" has at least two common meanings. The original meaning from AP was basically pulse-width modulation of the motors. This would enable any tracking rate to be smoothly set. One could speed up and slow down the mount very nicely this way.

In common useage today, though, is another variant. What it means is to be able to send a mount a command "move in direction X for Y msec" as one command. This is a big issue for many computer-controlled mounts as their CPU only processes commands every so often - perhaps once every few hundred msec. So, if you had to send a start and a stop command, your guide pulses would only start and stop at times the CPU processed a command. Certainly not ideal.

But, if you could send one packet of information - one command - with this guide pulse - you get around this and can guide very well. Note the CPU latency has nothing to do with the serial communication speed - it is how often the CPU clocks in new instructions off of that port.

ST4 ports give you typically more direct access to the motors (some actually still run through the CPU). You are not jerking them on and off hard - as you are not running them in short bursts at slew speeds. In RA, you tend to run the motor at 1.5-2x and at 0-0.5x. Commands are simple start/stop.

The accuracy of this comes down to the guiding program's ability to start and stop at the right time. These days, even with multitasking operating systems, millisecond accuracy or even 10ms accuracy is not tough. Sure, at times of huge load on the computer it might lengthen the pulse, but I've yet to see this in practice.

What I have seen are mounts that support "pulse guide" via their ASCOM driver but don't actually support it on the onboard CPU. So the ASCOM driver sends a "start" command, pauses, and sends a "stop" command. This emulates PulseGuide (in the current parlance) but still gives the same CPU latency problem. To the best of my knowledge, the Tak Temma driver works this way. (Note, I know that at least some of the Meade ASCOM drivers do not - they use the undocumented but widely known LX200 commands put in just for this reason).

Personally, I use ST4. Then again, I have a Tak Temma mount....

Craig “



The beauty of Sitechexe.exe is it DOES understand pulse guiding correctly!





From: SiTechservo@... [mailto:SiTechservo@...]
Sent: Monday, January 15, 2018 3:40 PM
To: SiTechservo@...
Subject: RE: [SiTechservo] Re: PHD2 Calibration Issue



Hi Dan,

I'm with Chuck, with the same questions.

Also SiTech uses "Pulse Guiding" - what is it???  How is it different from the old standard relay timed move?  Or is it exactly the same??

Don W

---In SiTechservo@..., <candcshaw@...> wrote :



OK, I may have just learned something (again!!) J


I have always been under the impression that the Dec cosine compensation has ALWAYS been ACTIVE no matter whether you use ASCOM guiding or relay guiding.      And when you added the checkbox to turn OFF dec cosine compensation, it would only turn off the compensation for Relay guiding.  The “implied” assumption on my part was that the box would turn it off for relay guiding by it was still on for pulse guiding.


So, two things I want to see if I have correct:


1.       So, your last note seems to say that the dec compensation can’t be turned off for ASCOM guiding because IT WAS NEVER ON for ASCOM guiding…..   Is that correct????


2.       So, if you are using ASCOM guiding and you do want to use the dec cosine compensation, the ONLY place you can turn it on is in PHD2…. (and I assume in MaxDL) …   Correct????



I like the idea of using the declination cosine dec compensation because my guiding calibration in PHD2 is good at all declinations instead of needing to re-perform the calibration if I change targets to one at a different declination from where the calibration was performed.




By the way,  I had no issues with the download and install on my W10-64 laptop…. And so far everything seems to work fine….








From: SiTechservo@... [mailto:SiTechservo@...]
Subject: Re: [SiTechservo] Re: PHD2 Calibration Issue



Would love to hear if anyone can install and test this.  Don W. had problems with the installer.  It worked fine on my computer....


Chuck, if you're using ASCOM Pulse Guiding, then the SiTech checkboxes don't do anything.

I think you should check it in PHD or PHD2, "Use Dec Compensation", because SiTech doesn't do it.


Join to automatically receive all group messages.