As suggested, have started a new thread to deal with the specific behaviours of IOptron EC mounts when pulseguided
Once more, i used the 8 oct dataset from StarFlyer, as it has everything in one bit.
I modified my app so i can read out a full session ( with timestamps ) from the PHD debug log ( vs the guidelog ), as this allows a continuous plot to be compared to the commander data.
There are 4 attached diags below
1) Shows the RA data for the session from calibration through to oscillation
i also manually superimposed what the commander log showed for the calibrate section
You can clearly see that the "theoretical" distance travelled via pulses is not achieved by the mount. Why??
2) Shows a closeup of the initial ( West )calibrate section
Again, we see the mount is moving but nowhere near the speed requested
He used 900ms pulses and 1000ms exposures so there was roughly 2100-2200ms between pulses, ie heaps of time
3) Shows the rapid ( East ) return to home after the cal had moved enough
In this case, one pulse "appears" to move at almost the correct speed, but then the next 2 pulses get ignored???
4) Shows the post calibration oscillation starting up when guiding ( it only stopped when the aggression was dropped )
The interesting bit here is how once again, the mount is not applying the move at the expected rate
and this is creating a hysteresis effect where the guides are out of synch with the real error
and the system starts chasing its tail
Thus, analysing something "similar" to a calibrate may assist in finding what settings can be used to get the mount to match the guide requests.
This really needs a scripted process, where PHD is run at a high framerate to merely collect data
and a third party app can supply scripted pulses at whatever cadence is chosen, to see the effects.
No idea how to do that with the IOptron driver tho.
Andrew Johansen Melbourne Australia