Terminology might be different but when operating locally you use the driver name and when
indi is remote from Ekos use the display/label name. In the Ekos profile hovering on the name will show you both. I think they are also shown if you use -vv switch when running adminserver.
With EKos and INDI both running on your small remote machine, where is PHD2 running?
I have had good luck with this 12V hub over the past year, it came through the winter outside in obs okay.
Not that I can answer your questions, but I did look at the logs when you posted them, mainly to see if you were getting the calibration error I was last time I imaged. You were not, and calibration when pulse guiding appeared to succeed for you.
The way I understand the maximum pulse business is that its use has a limit of ~999ms. When the amount of needed correction exceeds that amount an alternative approach is needed. That is when the move command is used instead, but I don't think it is imprecise as these things go. The movement's progress is monitored and stopped when the needed correction has been reached.
When I experienced the bug, the problem was the movement was not being stopped and the mount continued to move until it crashed or was manually stopped. As previously stated that is no longer a problem and the bug was fixed some time ago.
I thought perhaps the "simulated" phrase you referred to was with this use of the move command.
It might be but there seem to be additional cases. There seems to be a "Timeout" of some kind related, and also the 0 value instances. I don't know if these indicate some kind of issue or are just diagnostic logging information.
Something that does stand out is the high values of the guide correction pulses in the file, often up at the 900 limit, indicating the wild swings you describe.
I believe this particular issue with long pulses being required is considered fixed.
No errors in your log/indi telescope panel when it goes bad?
Hope the 900ms setting helps but you should not be encountering that problem, Mike fixed it about 4 months ago.
Comparing your good night to the bad ones, was the quality of "seeing" and the target/elevation similar.
The guide star you presented on the good night looks decent compared to the bloated one on the bad night.
Just wondering why the results with same balance/focus settings etc. are so different.
I'm out of it for a bit, just changing over to a heavy long focal length payload and waiting for some extra weights to arrive
to be able to balance.
There are a couple of things. When you do not have to calibrate when making the switch from ST4 to pulse guiding, perhaps it is because it is using a calibration from some previous time. There is a clear calibration button near the top (trash can?). Perhaps if you cleared that it would then need to recalibrate.
Rather than being able to switch modes between calibration and guiding it would be preferable to fix calibration using pulse guiding. Can you enable logging for the guiding and the AstroPhysics driver the next time you use pulse guiding to calibrate? And/or check the mount's indi panel for errors during calibration. For me it doesn't work and generates mount errors, it would be of interest to know if it is just me or you also encounter an error problem.
You chose to use an ST4 cable (via guide camera) or pulse mode (via mount) in the guide panel.
At least with the AstroPhysicsExperimental driver there is "use pulse guding" setting that needs
to match the guide panels choice. Also in the driver panel is the setting for guiding rate, normal
recommendation if the mounts own guide rate is not known is 0.5.
On the internal solver not working a simple thing is to check the astrometry INDI panel to make sure the ENABLE button is indeed enabled. On my system in the indi astrometry panel the option tab's save never retains the enabled state and it needs to be reset each session.
I'll try Ron's settings next time out, but the forecast looks like that will be over a week away.
Yes I varied from 2 to 10 seconds, 25% to 66% etc without dramatic effect or finding a sweet spot. The incorrect/excessive 8 seconds 33% would track below 0.5 for a while and sometimes exceed 1.0. I did not learn much from the exercise on how the parameters work, but the way it tracks really well, then goes off for a while makes it seem like something external to the software needs attention. Think I will next try and run guiding without issuing any corrections, and see how the scope drifts to get a baseline.
The ST4 connection is usable. Nearly full moon, average seeing this evening according to the web site. The guiding calmed down though it goes off from time to time but was generally staying under 1.0 with a small refractor. The attached was with exposure extended to 8 seconds, Control Parameters: minimum guide pulse 20, Proportion reduced from 66 to 33. Probably not optimal but it improved over the defaults.
Another thread recommended something like 20ms for minimum pulse width, which is what I am trying.
Testing last night after a good polar alignment with new OAG setup, seeing described as poor, using pulse guiding, and the guiding was awful, could hear the mount slewing around trying to track.
However once again starting guide calibration had caused "Invalid pier side response from device" errors from AstroPhysics Experimental driver which can be found in the kstars log. So cancelled guiding and took 60 second test image unguided which came out with nice round stars. If it remains clear will try again tonight using the ST4 cable instead of pulse guiding.