Pulse guiding performance EQASCOM, GS Server via cable and Bluetooth

[han59]

For the internal guider development for the CCDCiel program, I did an extensive test of the accuracy of guide pulses. So how accurate does the mount move after a sending a guide pulse.

 

The measuring principle was simple. Send guide pulses of different length to my HEQ5 mount and measured the indicated position change. For this I wrote a test program to send ASCOM pulses to the mount and read the resulting change in RA axis expressed in "arc seconds axis rotation" and write the results to a .csv file for analysing in a spreadsheet.

 

After the test I came to the following conclusions:

1. GS server pulse accuracy is better then EQASCOM.
2. Guide pulses below 40 ms equals  0.3 arc seconds at 0.5x rate are pointless, The error is often bigger then the correction. The pulse effect (gain) seems also larger for short pulses then for the longer pulses. See trend lines in graphs below. Note that the stepper accuracy of the HEQ5 pro Synscan is 0.14". At 0.5x rate, the 0.14" minimum step is about 19 ms.
3. A Bluetooth connection is muss less accurate for guiding then a wired USB_to_serial cable!!
4. A guide rate of 0.5x tracking rate is fine. For higher rate the pulse become too short. For lower rate the pulse the pulse accuracy doesn’t increase.

Since then I switched from my Bluetooth connection back to a traditional USB to serial cable and switched from EQASCOM to GS server.

 

Han

 

Test results in graphs:

GS server versus EQASCOM up  to 1000 ms pulses for an USB_to_serial and Bluetooth connection:

 

GS server versus EQASCOM up  to 300 ms pulses for for an USB_to_serial and Bluetooth connection:

 

Bluetooth connection performance east and south:

[AstroMuni]

Would be good to see a comparison of this vs Ekos internal guider too

[han59]

The above test didn't involve guiding on a star. It just analyses the mount indicating position changing after applying guide pulses. So apply a pulse and see how in ASCOM the RA, DEC position changes. The problem is that it is not a digital controlled process. EQASCOM or GS server can only instruct the stepper motors to start and stop and set the speed. The timing is analog and not stable due to an unpredictable lag in the communication. That is a pity. That is why a cable with shorter lag time works better then Bluetooth connection. It would have worked better if you could instruct the mount digitally to step some many motor steps. Then the communication lag would have been irrelevant. But that is not possible with HEQ5  or EQ6 mounts.

 

About guiding:

The CCDCiel internal guider uses a simular algorithm as what they call in PHD2 ResistSwitch. It is described in the documentation.

Personally I don't have any experience with EKOS guiding but noted the PI or PID control algorithms do not work for pulse guiding except for the P action. The reason is that pulse guiding process is an integrating process. After a pulse correction the offset is permanent gone. A PID controller algorithm you normally use for a linear process. So if there is an offset you have to apply a permanent correction. This is achieved by the I-action of the controller. For the pulse controlled guiding process the I-action is counter productive.

 

Han

 

 

[malc-c]

1 hour ago, han59 said:

For the internal guider development for the CCDCiel program, I did an extensive test of the accuracy of guide pulses. So how accurate does the mount move after a sending a guide pulse.

The measuring principle was simple. Send guide pulses of different length to my HEQ5 mount and measured the indicated position change. For this I wrote a test program to send ASCOM pulses to the mount and read the resulting change in RA axis expressed in "arc seconds axis rotation" and write the results to a .csv file for analysing in a spreadsheet.

After the test I came to the following conclusions:

1. GS server pulse accuracy is better then EQASCOM.

 

Han,  I think the core of EQMOD was originally written in VB some ten or twelve years back and probably hasn't changed which May play a part in its accuracy ???

What I like about this post is whilst the guiding was simulated rather than real using a guide star where other factors such as seeing quality and such play a part, it does provide documented evidence in the form of graphs to back up the findings which make interesting reading.  You mention lag between bluetooth and hard wired, I wonder if having a faster serial port speed seen on newer mounts of 115200 baud compared to the 9600 that talk direct to the 16F886's in the HEQ5 makes any difference when guiding.  As you say, normally the command to move is set to the mount and its the firmware in the mount that does all the work, hence why 9600 is adequate.

 

[AstroMuni]

1 hour ago, han59 said:

Personally I don't have any experience with EKOS guiding but noted the PI or PID control algorithms do not work for pulse guiding except for the P action.

Thanks Han. I am not familiar with how these work at all so its a good prompt for me to read up. 🙂

All I know is in Ekos there is the Guiding module and it has option to enable GPG (Gaussian process guider) RA guider too.

[han59]

Malcom,

I got feedback that EQASCOM had a timing problem in the very beginning of the development. I can imagine that the VB compiler could play a role.

A faster serial connection could theoretically help. My HEQ5 is about 10 years old and as far I remember you can't change serial communication speed. You could also evaluate using the ST4 autoguider port instead of the serial port.  But I assume the lag in both the serial and ST4 is normally small and there is not so much to gain. The Bluetooth connection is probably an outlier.

It would be nice if they would allow to transmit the number of steps for the step motor. That would take communication delay out of the control loop. Now the serial connection is doing more or less the same as manual guiding with four buttons or the ST4 interface. This proposal would probably also require an ASCOM extension.

I have experimented with "slew to" position commands for guiding but that works miserable for guiding.

 

AstroMuni,

I was not aware of the Gaussian Process approximation. I assume it does something similar as the Hysteresis setting. Looking to the past to predict the future. I have experiment with some algorithms but returned to the ResistSwitch algorithm. This one looks pretty optimal. More improvements are only to be made with a better and more expensive mount. Not with guiding software. I have installed the so called belt modification on my HEQ5 but still the movement is on arc seconds level not smooth. Still I'm happy with the mount but there are better and more expensive mounts.

Han

[han59]

AstroMuni, 

We are drifting a little off topic but comparing guiding algorithms is pretty difficult.  It would be nice to have two identical mounts running at the same time imaging the same object.  But that is not very practical. My HEQ5 performance also depends a lot of the azimuth altitude position. In some positions it it performs good and in other position less good. What worked best is to run the guide algorithms in simulation and apply step responses or noise and look to the guiding results. I did that to compare the CCDCiel internal guider with PHD2 using my Sky simulator for Ascom & Alpaca. I never tried Ekos.

Han

 

[AstroMuni]

50 minutes ago, han59 said:

My HEQ5 performance also depends a lot of the azimuth altitude position. In some positions it it performs good and in other position less good.

I have the same mount and noticed that too 🙂

52 minutes ago, han59 said:

I did that to compare the CCDCiel internal guider with PHD2 using my Sky simulator for Ascom & Alpaca. I never tried Ekos.

Thats a great idea to build a simulator for ASCOM. Ekos comes with its own Simulator for all the standard devices and this has helped me a lot in learning the tool as well as plan & try out things during daytime.

[malc-c]

21 hours ago, AstroMuni said:

I have the same mount and noticed that too 🙂

Thats a great idea to build a simulator for ASCOM. Ekos comes with its own Simulator for all the standard devices and this has helped me a lot in learning the tool as well as plan & try out things during daytime.

Just want to clarify something.  If by ASCOM you mean EQASCOM (EQMOD) then you can run it in simulation mode from the Toolbox option contained within the EQASCOM folder.    I know ASCOM as the platform that runs in the background to handle communications between software packages.

[malc-c]

22 hours ago, han59 said:

Malcom,

I got feedback that EQASCOM had a timing problem in the very beginning of the development. I can imagine that the VB compiler could play a role.

A faster serial connection could theoretically help. My HEQ5 is about 10 years old and as far I remember you can't change serial communication speed. You could also evaluate using the ST4 autoguider port instead of the serial port.  But I assume the lag in both the serial and ST4 is normally small and there is not so much to gain. The Bluetooth connection is probably an outlier.

It would be nice if they would allow to transmit the number of steps for the step motor. That would take communication delay out of the control loop. Now the serial connection is doing more or less the same as manual guiding with four buttons or the ST4 interface. This proposal would probably also require an ASCOM extension.

I have experimented with "slew to" position commands for guiding but that works miserable for guiding.

Han

Yes older HEQ5's (in fact all SW mounts that are based on PIC micos in the synscan controller have serial ports (TTL) that run at fixed 9600 baud.  My comment was really aimed at newer mounts that have ARM controllers and operate at 115200 baud, so any lag in data packets whilst guiding would be minimal 

[han59]

7 hours ago, malc-c said:

Just want to clarify something.  If by ASCOM you mean EQASCOM (EQMOD) then you can run it in simulation mode from the Toolbox option contained within the EQASCOM folder.    I know ASCOM as the platform that runs in the background to handle communications between software packages.

toolbox option, did know that is exists. Looked to a 12 year old video to understand.

 

This is not what I meant.  You need a simulated star image based on the mount position as feedback to feed the guider. The "Sky simulator for Ascom" can do that. This simulator reads the mount position and creates a corresponding star image like a planetarium program. That star image can be read by the guider and then the control loop is closed. The simulator can add disturbances in the loop as required for the simulation.  The connections are as follows:

 

Han